Re: [Int-area] Re: AD evaluation of draft-bonica-internet-icmp

[Ron Bonica <[e-mail]>]

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
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/int-area
> 
> 

_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area