Sandy - Please see inline.
> -----Original Message----- > From: Sandy Ginoza <[email protected]> > Sent: Monday, October 6, 2025 12:32 PM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: RFC Editor <[email protected]>; [email protected]; > [email protected]; [email protected]; [email protected]; [email protected]; > lsr- > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Re: AUTH48: RFC-to-be 9885 <draft-ietf-lsr-multi-tlv-19> for your > review > > Hi Les, IANA, > > Thank you for your quick reply. Please see our notes below (resolved items > have been snipped). > > IANA, please see items 12, 13, and 14. > > The current files are available at the URLs below. Please refer to these > files to > see the examples we mention in item 13. > https://www.rfc-editor.org/authors/rfc9885.xml > https://www.rfc-editor.org/authors/rfc9885.txt > https://www.rfc-editor.org/authors/rfc9885.pdf > https://www.rfc-editor.org/authors/rfc9885.html > > Diffs of the most recently updates only: > https://www.rfc-editor.org/authors/rfc9885-lastdiff.html > https://www.rfc-editor.org/authors/rfc9885-lastrfcdiff.html (side by side) > > AUTH48 diffs: > https://www.rfc-editor.org/authors/rfc9885-auth48diff.html > https://www.rfc-editor.org/authors/rfc9885-auth48rfcdiff.html (side by > side) > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9885-diff.html > https://www.rfc-editor.org/authors/rfc9885-rfcdiff.html (side by side) > > > On Oct 2, 2025, at 5:01 PM, Les Ginsberg (ginsberg) <[email protected]> > wrote: > > > >>>> > >>>> 3) <!-- [rfced] Presumably, the mechanism defined in this document > would > >>>> not be needed if the mechanims defined by RFC 7356 were backwards > >>>> compatible (i.e., the existence of RFC 7356 does not resolve the > problem). > >>>> For clarity, we suggest the update below. Please review and clarify as > >>>> needed. > >>>> > >>>> Original: > >>>> [RFC7356] has defined a 16-bit length field for TLVs in flooding > >>>> scoped Protocol Data Units (PDUs), in which case the problem > >>>> addressed by this document would not exist. However, introduction of > >>>> these new PDU types is not backwards compatible. Therefore, there is > >>>> a need to address how to expand the information advertised in > >>>> existing PDUs that use 8-bit length TLVs. > >>>> > >>>> Perhaps: > >>>> [RFC7356] has defined a 16-bit length field for TLVs in flooding > >>>> scoped Protocol Data Units (PDUs), but it is not backwards > >>>> compatible. Therefore, there remains a need to address how to > >>>> expand the information advertised in PDUs that use 8-bit TLVs. > >>>> --> > >>> [LES:] I prefer the existing text in the document. In theory, MP-TLV is > >> applicable to TLVs with 16 bit length, though the likelihood this would > >> ever > be > >> needed is close to zero. > >>> Still, I see no need to preclude it. > >> > >> We have not made any updates, but we find the first sentence especially > >> confusing. The “in which” statement does not quite fit with the earlier > >> part > of > >> the sentence. Perhaps the “in which” part of the sentence can be removed? > >> > >> In addition, does "8-bit TLVs" mean "8-bit Length fields"? > >> > > [LES:] I think this discussion has highlighted that the current text is not > completely in sync with the intent of the document. Here is a proposed > rewording. > > Also note that the document currently does NOT use the term "8-bit TLVs" > (your proposed changes introduced that). The document uses "8-bit length > TLVs" - but I have clarified that in the new proposal below. > > > > " [RFC7356] has defined a 16-bit Length field for TLVs in flooding scoped > Protocol Data Units (PDUs), in which case the problem addressed by this > document would likely > > not be encountered. However, introduction of these new PDU types is not > backwards compatible. Therefore, there is a need to address how to expand > the information > > advertised in existing PDUs that use TLVs with 8-bit length fields." > > We have updated the document as noted above. However, it is not clear what > text “in which case” is referring to. A colleague provided the following > possible > update — would this retain the intended meaning? > > Perhaps: > The addition of the 16-bit Length field for TLVs in flooding-scoped Protocol > Data Units (PDUs) defined in [RFC7356] means that the problem addressed > by this document would likely not be encountered. However, introduction of > these new PDU types is not backwards compatible. Therefore, there is a need > to address how to expand the information advertised in existing PDUs that use > TLVs with 8-bit length fields. > [LES2:] Here is my alternative: " [RFC7356] has defined a 16-bit Length field for TLVs in flooding scoped Protocol Data Units (PDUs). The problem addressed by this document would likely not be encountered when 16-bit Length TLVs are in use. However, introduction of these new PDU types is not backwards compatible. Therefore, there is a need to address how to expand the information advertised in existing PDUs that use TLVs with 8-bit length fields." > > > > >>>> 12) <!-- [rfced] Please consider whether "implicit support" should be > >>>> capitalized - that is, how should it appear in other documents that refer > >>>> to this TLV? Note that we will ask IANA to update their registry as > >>>> needed. > >>>> > >>>> MP-TLV Support for TLVs with implicit support > >>>> --> > >>> [LES:] I am fine either way - but capitalizing it seems like a good > >>> choice. > >> > >> We capitalized “Implicit Support” and will ask IANA to update their > >> registry. > > IANA, In the "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV” registry > <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv- > codepoints.xhtml#isis-tlv-codepoints-242>, please capitalize “Implicit > Support” in the description for value 30. > > > > >>>> 13) <!-- [rfced] Note that we have removed the URLs from each of the > >>>> subsections in Section 9.2. The URLs would need to be reduced to the > URL > >>>> for the main registry group per IANA guidance, which is already > mentioned > >>>> in Section 9.2. We did not include any introductory text for the tables > >>>> because the registry names are part of the section titles and table > >>>> titles. > >>>> Please review and let us know if you prefer that introductory text be > >>>> added. > >>>> --> > >>> [LES:] The URLs for the individual tables are taken from the list of URLs > >>> at > the > >> beginning of https://www.iana.org/assignments/isis-tlv-codepoints/isis- > tlv- > >> codepoints.xhtml > >>> They are useful in that they can be used to go directly to the relevant > >>> "sub- > >> registry". > >>> I prefer to keep them. > >>> If there is some IANA policy which makes this "illegal" - well OK. But if > >>> not, > >> please restore them. > >> > >> We removed the URLs per the IANA guidance on > >> <https://www.iana.org/help/protocol-registration>: > >> > >> • If the registry should be placed at an existing URL, it's helpful to > >> cite that > URL, > >> but please use the "short" version that doesn't include a file extension > >> (or a > >> URI fragment). More on this below, in the "Future" section. In the > meantime: > >> • Yes: https://www.iana.org/assignments/bgp-parameters > >> • No: https://www.iana.org/assignments/bgp-parameters/bgp- > >> parameters.xhtml > >> • No, regrettably: https://www.iana.org/assignments/bgp- > >> parameters/bgp-parameters.xhtml#bgp-graceful-restart-flags > >> > > [LES:] So, we have a real problem here. Feel free to involve IANA in the > discussion. > > With the URLs, it is straightforward to find the specific "sub-registry" > > which s > being modified. > > Without the URLs, what is a reader to do? > > > > Take the example of 9.2.2. MP-TLV for IS-IS Sub-TLVs for Reverse Metric TLV > > > > How is the reader to find the specific sub-registry which is being modified? > > Try inserting "IS-IS Sub-TLVs for Reverse Metric TLV" into your favorite > > search > engine and see what you get - not very satisfactory. > > The reader would somehow have to know: > > > > 1)Navigate to https://www.iana.org/assignments/isis-tlv-codepoints/isis- > tlv-codepoints.xhtml > > 2)Search for " IS-IS Sub-TLVs for Reverse Metric TLV" on the page > > 3)Click on the link available there > > > > Not very reader friendly. > > > > I appreciate that you are trying to follow the "letter of the law" as per > > the > guidance referenced above - but the end result is not useful. > > I have used the URLs which IANA itself assigned to the sub-registries. If > > the > format of the URLs is not "quotable" it seems to me, it is IANA's problem to > make them quotable. > > > > There is a real need to have usable references to the individual registries > which are being changed. > > IANA, please see the discussion above. How stable are the URLs for the > individual registries within the "IS-IS TLV Codepoints” registry group? > > In the current version, we have included a possible workaround to refer to the > specific registry name with the URL for the registry group > <https://www.iana.org/assignments/isis-tlv-codepoints> — see Section 9.2.1 > for an example. If this is an acceptable solution, we could update the > remaining subsections in a similar manner. > [LES2:] I would still prefer that we be able to use the URLs for each sub-registry. If, however, IANA prohibits that - here is my best alternative. Add a third paragraph to Section 9.2: "To navigate to the specific registry associated with each sub-section, do the following: 1)Go to the IS-IS TLV Codepoints Registry group page (https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml ) 2)On this page search for the name of the registry as specified in the title of each sub-section (e.g., for Section 9.2.2 that would be "IS-IS Sub-TLVs for Reverse Metric TLV") 3)Follow the URL to the specific registry " Again, I prefer being able to use the IANA defined URLs directly. Les > > > >>>> 14) <!-- [rfced] We removed "TLV" from these entries to match what > >> appears > >>>> in the IANA registry. > >>>> > >>>> 126 IPv4 Algorithm Prefix Reachability TLV N > >>>> 127 IPv6 Algorithm Prefix Reachability TLV N > >>>> --> > >>> [LES:] That's fine. Note that I copied the text from the list at > >> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv- > >> codepoints.xhtml#isis-tlv-codepoints-advertising-prefix-reachability - so > IANA > >> might consider updating that text as well. > >> > >> We will mention this to IANA. > >> > >>> <snip> > >>> IPv4 Algorithm Prefix Reachability TLV (126) > >>> IPv6 Algorithm Prefix Reachability TLV (127) > >>> <end snip> > > IANA, note that we have removed TLV from the document to align with the > Names in the “IS-IS Top-Level TLV Codepoints” registry. However, the author > pointed out that the following appear in the description for the "IS-IS > Sub-TLVs > for TLVs Advertising Prefix Reachability” registry: > > IPv4 Algorithm Prefix Reachability TLV (126) > IPv6 Algorithm Prefix Reachability TLV (127) > > Please consider whether an update is needed. > > > Thank you, > Sandy Ginoza > RFC Production Center > > > > > > >> > >> > >> The current files are available here: > >> https://www.rfc-editor.org/authors/rfc9885.xml > >> https://www.rfc-editor.org/authors/rfc9885.txt > >> https://www.rfc-editor.org/authors/rfc9885.pdf > >> https://www.rfc-editor.org/authors/rfc9885.html > >> > >> https://www.rfc-editor.org/authors/rfc9885-diff.html > >> https://www.rfc-editor.org/authors/rfc9885-rfcdiff.html (side by side) > >> https://www.rfc-editor.org/authors/rfc9885-auth48diff.html > >> https://www.rfc-editor.org/authors/rfc9885-auth48rfcdiff.html (side by > >> side) > >> > >> Please let us know how you’d like to proceed. > >> > >> Thank you, > >> Sandy Ginoza > >> RFC Production Center > >> > >> > >> > >> > >> > >> > >> > >>>> > >>>> On Sep 29, 2025, at 9:30 PM, [email protected] wrote: > >>>> > >>>> *****IMPORTANT***** > >>>> > >>>> Updated 2025/09/29 > >>>> > >>>> RFC Author(s): > >>>> -------------- > >>>> > >>>> Instructions for Completing AUTH48 > >>>> > >>>> Your document has now entered AUTH48. Once it has been reviewed > and > >>>> approved by you and all coauthors, it will be published as an RFC. > >>>> If an author is no longer available, there are several remedies > >>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). > >>>> > >>>> You and you coauthors are responsible for engaging other parties > >>>> (e.g., Contributors or Working Group) as necessary before providing > >>>> your approval. > >>>> > >>>> Planning your review > >>>> --------------------- > >>>> > >>>> Please review the following aspects of your document: > >>>> > >>>> * RFC Editor questions > >>>> > >>>> Please review and resolve any questions raised by the RFC Editor > >>>> that have been included in the XML file as comments marked as > >>>> follows: > >>>> > >>>> <!-- [rfced] ... --> > >>>> > >>>> These questions will also be sent in a subsequent email. > >>>> > >>>> * Changes submitted by coauthors > >>>> > >>>> Please ensure that you review any changes submitted by your > >>>> coauthors. We assume that if you do not speak up that you > >>>> agree to changes submitted by your coauthors. > >>>> > >>>> * Content > >>>> > >>>> Please review the full content of the document, as this cannot > >>>> change once the RFC is published. Please pay particular attention to: > >>>> - IANA considerations updates (if applicable) > >>>> - contact information > >>>> - references > >>>> > >>>> * Copyright notices and legends > >>>> > >>>> Please review the copyright notice and legends as defined in > >>>> RFC 5378 and the Trust Legal Provisions > >>>> (TLP – https://trustee.ietf.org/license-info). > >>>> > >>>> * Semantic markup > >>>> > >>>> Please review the markup in the XML file to ensure that elements of > >>>> content are correctly tagged. For example, ensure that <sourcecode> > >>>> and <artwork> are set correctly. See details at > >>>> <https://authors.ietf.org/rfcxml-vocabulary>. > >>>> > >>>> * Formatted output > >>>> > >>>> Please review the PDF, HTML, and TXT files to ensure that the > >>>> formatted output, as generated from the markup in the XML file, is > >>>> reasonable. Please note that the TXT will have formatting > >>>> limitations compared to the PDF and HTML. > >>>> > >>>> > >>>> Submitting changes > >>>> ------------------ > >>>> > >>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all > >>>> the parties CCed on this message need to see your changes. The parties > >>>> include: > >>>> > >>>> * your coauthors > >>>> > >>>> * [email protected] (the RPC team) > >>>> > >>>> * other document participants, depending on the stream (e.g., > >>>> IETF Stream participants are your working group chairs, the > >>>> responsible ADs, and the document shepherd). > >>>> > >>>> * [email protected], which is a new archival mailing list > >>>> to preserve AUTH48 conversations; it is not an active discussion > >>>> list: > >>>> > >>>> * More info: > >>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh- > >>>> 4Q9l2USxIAe6P8O4Zc > >>>> > >>>> * The archive itself: > >>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >>>> > >>>> * Note: If only absolutely necessary, you may temporarily opt out > >>>> of the archiving of messages (e.g., to discuss a sensitive matter). > >>>> If needed, please add a note at the top of the message that you > >>>> have dropped the address. When the discussion is concluded, > >>>> [email protected] will be re-added to the CC list and > >>>> its addition will be noted at the top of the message. > >>>> > >>>> You may submit your changes in one of two ways: > >>>> > >>>> An update to the provided XML file > >>>> — OR — > >>>> An explicit list of changes in this format > >>>> > >>>> Section # (or indicate Global) > >>>> > >>>> OLD: > >>>> old text > >>>> > >>>> NEW: > >>>> new text > >>>> > >>>> You do not need to reply with both an updated XML file and an explicit > >>>> list of changes, as either form is sufficient. > >>>> > >>>> We will ask a stream manager to review and approve any changes that > >> seem > >>>> beyond editorial in nature, e.g., addition of new text, deletion of text, > >>>> and technical changes. Information about stream managers can be > found > >> in > >>>> the FAQ. Editorial changes do not require approval from a stream > manager. > >>>> > >>>> > >>>> Approving for publication > >>>> -------------------------- > >>>> > >>>> To approve your RFC for publication, please reply to this email stating > >>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, > >>>> as all the parties CCed on this message need to see your approval. > >>>> > >>>> > >>>> Files > >>>> ----- > >>>> > >>>> The files are available here: > >>>> https://www.rfc-editor.org/authors/rfc9885.xml > >>>> https://www.rfc-editor.org/authors/rfc9885.html > >>>> https://www.rfc-editor.org/authors/rfc9885.pdf > >>>> https://www.rfc-editor.org/authors/rfc9885.txt > >>>> > >>>> Diff file of the text: > >>>> https://www.rfc-editor.org/authors/rfc9885-diff.html > >>>> https://www.rfc-editor.org/authors/rfc9885-rfcdiff.html (side by side) > >>>> > >>>> Diff of the XML: > >>>> https://www.rfc-editor.org/authors/rfc9885-xmldiff1.html > >>>> > >>>> > >>>> Tracking progress > >>>> ----------------- > >>>> > >>>> The details of the AUTH48 status of your document are here: > >>>> https://www.rfc-editor.org/auth48/rfc9885 > >>>> > >>>> Please let us know if you have any questions. > >>>> > >>>> Thank you for your cooperation, > >>>> > >>>> RFC Editor > >>>> > >>>> -------------------------------------- > >>>> RFC 9885 (draft-ietf-lsr-multi-tlv-19) > >>>> > >>>> Title : Multi-Part TLVs in IS-IS > >>>> Author(s) : P. Kaneriya, T. Li, A. Przygienda, S. Hegde, L. > >>>> Ginsberg > >>>> WG Chair(s) : Acee Lindem, Christian Hopps, Yingzhen Qu > >>>> > >>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > >>>> > >>> > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
