On Mon, 10 Apr 2017, David Bird wrote:
I view this relatively SIMPLE protocol, which at its core is just telling you the 'truth' (or at least as close as you can get to it, subject to the same risks as ICMP in general) about what happened to your packets and why.
So while I don't have any objections to the ICMP method (but I would like to know what operating system implementors have to say about it), my point is more about what can be communicated using this option.
Would it for instance make sense for ALTO to also use this option? Do we have enough stuff in the ICMP type to say "please carry on what you're doing, but btw, here is an interesting URI to go to if you support X" where X, could be for instance ALTO protocol. It could be something else.
I don't really want to invent things only for the capport use-case, because it's not too distant from other use-cases. I really want to make sure that whatever we come up with here is generic enough so that it can be use for similar use-cases, for instance the PVD/network properties use-case.
So should the ICMP not be an "unreach" type, but something else? Should we include more codespace to have future codes that could signal something else? Perhaps there should be some TLV text field to signal future extensions? Should there be a version field so we don't have to use more ICMP code space in case we want to change the structure? The C-type does give extensibility, but perhaps there should be some kind of "informational" type as well? The icmp-unreach draft seems to be very much use-case focused, it's not really generic. Is this a good thing?