On Wed, Oct 22, 2025 at 2:00 AM Bill Fenner <[email protected]> wrote: >> Per >> https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/, >> explanations about when the "SHOULD" can be bypassed (I note that there is >> a `whenever` but this does not seem to cover all cases).
>> And I would assume that basic MTU & fragmentation consideration should be >> added. > > > Good point regarding the MTU; I lean towards prohibiting insertion. I assume this excludes RFC7915 cases, right? So we are talking about more text to Section 4 to discuss insertion by intermediate nodes which are not translating between protocols? > In a previous age I would have said SHOULD NOT insert if it results in the > new packet exceeding the MTU, and let it be obvious that if you want to do it > you have to deal with the consequences of fragmentation; now that you've > pointed out the IESG statement I'm more inclined to say MUST NOT because I > don't want to get into the details. It is only possible to append that object to a very limited list of error messages. I do not think we want an ICMP error message to get fragmented, so clearly intermediate nodes MUST NOT insert the structure if the resulting packet exceeds min. MTU for the given protocol family. (Practically it means it's impossible to do insertion for IPv4...) > >> ### Section 6 >> >> >> >> Please request the creation of `The corresponding Class Sub-types Registry ` >> as it is not yet at >> https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-ext-classes > > > OK > >> >> Also use a URI reference for `ICMP Extension Object Class` > > > Is the URL that you mention above the right URI to use? > >> >> >> ## Non-critical / cosmetic issues >> >> >> >> Note: these points must also be addressed. >> >> >> >> ### Title >> >> >> >> Possibly a matter of taste, but s/Adding Extensions to ICMP Errors for >> Originating Node Identification/ICMP Message Extension for Originating Node >> Identification/ is probably clearer. > > > OK > >> ### Nexthop or Next-Hop >> >> >> >> As the abstract use `next-hop`, let's be consistent and let's use 'next-hop' >> everywhere rather than 'next-hop'. > > OK > >> >> ### Section 1 >> >> >> >> s/traceroute to an IPv4 destination can not represent intermediate IPv6-only >> routers/traceroute to an IPv4 destination can not display an intermediate >> IPv6-only routers as it does not have an IPv4 address/ ? > > > Sure > >> >> ### Section 3 >> >> >> >> s/The extension defined herein/The extension defined herein, Node >> Identification Object,/ > > > OK > >> >> It is also unclear why it is only "appended" rather than "included", must >> this extension be the last extension? If so, why. > > > "appended" is just the word that RFC4884 and RFC5837 use. Would you be ok > with "added"? > >> >> ### Section 3.3 >> >> >> >> The SVG tool seems to have an issue with the "o" of "homestar" in the >> graphic. > > > Yeah, I struggled with the SVG tool. I'll struggle some more. > >> >> Unsure how to handle a 2-byte UTF-8 character whose 2nd octet would be the >> 65th character of the name. > > > Good point. I wrote this: > > The node name MUST be represented in the UTF-8 charset {{RFC3629}} > -using the Default Language {{RFC2277}}. > +using the Default Language {{RFC2277}}. When truncating a name > +to 63 octets, the truncation MUST occur on a character boundary > +(e.g., if the 63rd octet is the first octet of a 2-octet character, > +then the truncation will omit that octet altogether, and be padded > +with an ASCII NUL character to reach the 4-octet boundary.) > > Is this clear, or, does it need more work? Perhaps it should move to the part > before the example that talks about truncation in the first place, and talk > about "include enough characters from sys:hostname to encode to a string of > 63 octets or less"? > >> ### Reference >> >> >> >> The draft reference draft-equinox-v6ops-icmpext-xlat-v6only-source (version >> 02) is stale. It was replaced by draft-ietf-v6ops-icmpext-xlat-v6only-source >> (version 00). > > > Updated > > Bill > > _______________________________________________ > Int-area mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Cheers, Jen Linkova _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
