Hi Sandy, Les, Please see [ST] inline.
On Mon Oct 06 19:33:02 2025, [email protected] wrote: > 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. > > > > >>>> 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. [ST] Done: https://www.iana.org/assignments/isis-tlv-codepoints > >>>> 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? [ST] I checked with my team, and we should continue to point to https://www.iana.org/assignments/isis-tlv-codepoints, as you have been doing. In the future, the fragment URIs will no longer point to the specific registry; instead, they will point only to the registry group. Permanent URLs will be made available in the future, but this feature is still under development. > 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. > > > > >>>> 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. [ST] Thank you for pointing this out. We've removed "TLV" from the description. Thanks, Sabrina > > 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]
