On Tue, Aug 19, 2025 at 9:36 AM Eric Vyncke (evyncke) <evyn...@cisco.com> wrote:
> Suggested actions by authors of: > > - draft-ietf-intarea-rfc8335bis: the above is an incentive to work faster > on this I-D ;-) else the I-D is not impacted at all by the decision > Hi Eric, As far as I know, there is nothing (other than cheerleading) for the authors to do for this document. The 2-week Working Group Last Call began May 23, some discussion occurred about the relationship with draft-ietf-6man-icmpv6-reflection and I submitted a minor update to the document on July 21. I don't think that rfc8335bis needs to refer to exten-hdr-len directly, since rfc8335bis says that you use the RFC4884 extension mechanism, and exten-hdr-len updates RFC4884. The packet header modified in exten-hdr-len isn't mentioned directly in rfc8335bis. if the PROBE bis could do without requiring the exn-hdr-len PROBE bis has very specific wording that when you are using the PROBE-specific extension header, they are treated unusually, so does not require exten-hdr-len. exten-hdr-len would allow consumers to perform fewer calculations to do this unusual treatment of headers, but I don't believe that means that one document requires the other. Just a quick reminder that the decision that we took was to make the bis document reflect deployed implementations, as opposed to sticking with the letter of the original RFC and making the deployed implementations non-conforming. That's where this funny length problem came from in the first place, trying to write a spec that reflects what current implementations do. Bill
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
