I agree on both points. Joe Touch wrote: > > Ron Bonica wrote: > >>Jari Arkko wrote: >> >>>Ron, all, >>> >>>I have reviewed this specification. I have a few technical issues >>>and one question to the community about IPv6 support in this >>>space. >>> >>>Technical issues: >>> >>> >>> >>>> - An ICMP Extension Structure MAY be appended to any ICMP message >>>> except for those excluded below. >>> >>>Given the nature the extensions we can do at this stage, >>>and the goals of this draft, I think it would be much better >>>if the draft explicitly restricted itself to a known subset of ICMP >>>messages (as opposed to "any"). >>> >> >>Jari, >> >>In the interest of getting the draft published, I am willing to make >>this change, but before doing so, I would like to push back a little bit. >> >>Why would we want to restrict the applicability of the extension >>structure more than we need to? I agree that it makes no sense to ever >>extend some ICMP messages (e.g., Source Quench). But if someone, >>someday, finds that he needs to add information to the Parameter Problem >>message, why should he not use the extension structure defined in this >>draft? > > > FWIW, it might be cleaner to state the specific current subset, and > state 'and future messages'; that avoids any ambiguity. > > >>>>5. Backwards Compatibility >>> >>>I have some unease about this section, mainly due >>>to the central role that the interoperability with >>>the currently deployed extension scheme that is >>>not compatible with what this spec says. It is >>>indeed important that we document how to >>>stay interoperable to the old extension scheme. >>>However, Section 5.5 almost recommends >>>making a non-compliant implementation due to >>>the backwards compatibility reasons. I would >>>suggest requiring compliant behaviour and >>>then allowing backwards compatibility mode >>>to be enabled through configuration or traceroute >>>option. Perhaps also some editorial changes. >> >>Agreed. I will replace the last two paragraphs of section 5.5 with the >>following: >> >>To ease transition yet encourage compliant implementation, compliant >>TRACETOUE implementations MAY include a non-default operation mode >>to also interpret non-compliant responses. Specifically, when a >>TRACEROUTE application operating in non-compliant mode receives an ICMP >>message that contains 144 octets or more in its payload and does not >>specify a length attribute, it will parse for a valid extension header >>beginning at octet 137. If the application detects a valid version and >>checksum, it will treat the following octets as an extension structure. >> >> Ron > > > The doc ought to state that if the checksum fails, the implementation > MUST NOT interpret the message as containing an extension - again, for > clarity. > > Joe > > > >>>This issue was also raised by the two reviewers >>>that I asked to look at this spec (Joe Touch and >>>Pekka Savola; thanks for your reviews! The detais >>>have been forwarded to Ron.). >>> >>>The question: >>> >>>In the discussion on the int-area list it was brought up that >>>that we need to "accept reality" in the IPv4 world but for IPv6 >>>we should design something better. Now, as it turns out, one >>>of reasons for doing this, MPLS traceroute, *has* already >>>been implemented for IPv6, by at least one large vendor. >>>I'd like to get input from this list whether this fact changes >>>any of the conclusions we've had on this topic so far. >>>Including, for instance, that the draft should be silent on >>>IPv6. >>> >>>--Jari >>> >> >>_______________________________________________ >>Int-area mailing list >>[email protected] >>https://www1.ietf.org/mailman/listinfo/int-area > >
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
