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.
The problem is that anything short of having this be standards-track means that future standards-track docs _need_ not consider this work at all. If that's not the goal, than this needs to go a different track. > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
