Jari,
I have copied this text verbatim into the draft and posted it as version
6. You can get a sneak preview of the text at
http://www.bonica.org/draft-bonica-internet-icmp-06.txt.
Ron
Jari Arkko wrote:
> On the topic of what this extension means for future
> ICMP messages:
>
> Its obvious that whoever designs new ICMP messages
> should consider this work and decide whether it
> applies to those new messages or not. We should
> add words to this effect to the document. I would
> rather not use keywords or a strict must requirement,
> however, because whether this or some other way to
> extend a new message is appropriate probably depends
> on the nature and format of that message.
>
> By the way, Section 3 contains still some text
> that talks about "any ICMP messages".
>
> Here's some suggested text:
>
> To replace the item list from Section 3:
>
> - An ICMP Extension Structure MAY be appended to ICMP
> messages Destination Unreachable, Source Quench,
> Time Exceeded, and Parameter Problem.
>
> - These messages include an "original datagram" field, and
> the message formats are updated to specify a length
> attribute for the "original datagram" field.
>
> The "original datagram" field MUST include at least 128
> octets. If the original datagram did not contain 128 octets,
> the "original datagram" field MUST be zero padded to 128
> octets.
>
> The "original datagram" field MUST be zero padded to
> the nearest 32-bit boundary.
>
> To replace the current statement from Section 4.5:
>
> ICMP messages defined in the future should indicate
> whether or not they support the extension mechanism defined
> in this specification. It is recommended that all new messages
> employ some mechanism that allows later extensions.
>
> --Jari
>
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
