Sandy - Latest version looks fine. Thanx for all the good work.
Let's get this published. Les > -----Original Message----- > From: Sandy Ginoza <[email protected]> > Sent: Monday, October 20, 2025 4:24 PM > To: Les Ginsberg (ginsberg) <[email protected]>; [email protected] > Cc: Les Ginsberg (ginsberg) <[email protected]>; [email protected]; > [email protected]; [email protected]; RFC Editor <[email protected]>; > [email protected]; [email protected]; [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Re: [IANA #1433072] AUTH48: RFC-to-be 9885 <draft-ietf-lsr-multi- > tlv-19> for your review > > Hi Les, > > My sincere apologies for the delayed response. Per IANA’s reply, we did not > include the URLs to individual registries. Along the lines of your request, > we > did tell the reader how to find the relevant registry and added intro text to > each section to highlight the registry name. Please review and let us know if > this is acceptable or if you prefer that the steps be included as a numbered > list. > > Diffs highlighting the most recent updates only: > https://www.rfc-editor.org/authors/rfc9885-lastdiff.html > https://www.rfc-editor.org/authors/rfc9885-lastrfcdiff.html (side by side) > > 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 > > 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) > > > Thank you. > Sandy Ginoza > RFC Production Center > > > > > On Oct 8, 2025, at 11:05 AM, Sabrina Tanamal via RT <iana- > [email protected]> wrote: > > > > 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]
