Ron, Jari, Maybe adding a small note that future ICMPs may make use of this extension structure if/when defined?
Thanks, --Carlos. On 6/8/2006 10:56 AM, Ron Bonica allegedly said the following: > OK. I'm convinced. > > I will update the draft and resubmit it in a few hours. > > -ron > > > Jari Arkko wrote: >> Ron Bonica wrote: >> >> >>>>> - 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"). >>>> >>>> >>>> >>> ... >>> >>> 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? >>> >>> >> I do not worry about the extension to Destination Unreachable, >> Parameter Problem, Source Quench, or Time Exceeded messages. >> >> My issue was the statement in the draft that indicated you >> can use this extension mechanism on any ICMP message except >> those explicitly listed. As you note in the draft, the extension >> mechanism is unsuitable for some types of messages. For instance, >> Echo Request/Reply cannot be extended due to lack of a suitable >> reserved field, and RFC 4065 messages already have their own >> option structure. The current IANA registry lists >> ~ 40 ICMP Type values -- and there could be more in the >> future. We should not say anything about existing messages >> without analysis of the suitability of this mechanism for them, >> and obviously its hard to say what future ICMP messages might >> look like. And if it turns out that people are going to do this >> this also for IPv6, it has many ICMP messages where >> this style of extension would be inappropriate >> since another option mechanism already exists. >> >> I would suggest that we limit this draft to extend >> the messages that we know can and should be >> extended. This may be the four messages that >> you already cover in Section 4. Or if you can see >> some other message that need this, lets list them >> too, explicitly. >> >> >>> 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. >>> >>> >> This text looks good to me. >> >> --Jari >> > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
