Hi Tony and Shraddha, Thank you for your replies - we have noted your approvals on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9885> and will continue with publication shortly.
Thank you, Sandy Ginoza RFC Production Center > On Oct 28, 2025, at 12:03 AM, Antoni Przygienda <[email protected]> wrote: > > good to go for me. thanks. tony > >> On 28 Oct 2025, at 05:11, Shraddha Hegde <[email protected]> wrote: >> >> Hi, >> >> I have reviewed the document and approve for publication. >> >> Rgds >> Shraddha >> >> >> Juniper Business Use Only >> -----Original Message----- >> From: Sandy Ginoza <[email protected]> >> Sent: 21 October 2025 04:54 >> To: [email protected]; [email protected] >> Cc: [email protected]; [email protected]; [email protected]; Shraddha >> Hegde <[email protected]>; RFC Editor <[email protected]>; Antoni >> Przygienda <[email protected]>; Parag Kaneriya <[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 >> >> [External Email. Be cautious of content] >> >> >> 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9885-lastdiff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q9sYqwVTw$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9885-lastrfcdiff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8JI_6pEA$ >> (side by side) >> >> The current files are available here: >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9885.xml__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8anMsGmg$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9885.txt__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8nub2bmA$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9885.pdf__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q-tR2dDkA$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9885.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q-TpTVqdg$ >> >> AUTH48 diffs: >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9885-auth48diff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q-qQ31VAg$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9885-auth48rfcdiff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8DQUluPA$ >> (side by side) >> >> Comprehensive diffs: >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9885-diff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8RRXA6kQ$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9885-rfcdiff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8_rbUbJQ$ >> (side by side) >> >> >> Thank you. >> Sandy Ginoza >> RFC Production Center >> >> >> >>> On Oct 8, 2025, at 11:05 AM, Sabrina Tanamal via RT <[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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc988 >>>> 5.xml__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwv >>>> m0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8anMsGmg$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc988 >>>> 5.txt__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwv >>>> m0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8nub2bmA$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc988 >>>> 5.pdf__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwv >>>> m0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q-tR2dDkA$ >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc988 >>>> 5.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSw >>>> vm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q-TpTVqdg$ >>>> >>>> Diffs of the most recently updates only: >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc988 >>>> 5-lastdiff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uy >>>> aq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q9sYqwVTw$ >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc988 >>>> 5-lastrfcdiff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P >>>> 0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8JI_6pEA$ (side by >>>> side) >>>> >>>> AUTH48 diffs: >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc988 >>>> 5-auth48diff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0 >>>> uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q-qQ31VAg$ >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc988 >>>> 5-auth48rfcdiff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku >>>> 1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8DQUluPA$ (side by >>>> side) >>>> >>>> Comprehensive diffs: >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc988 >>>> 5-diff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6Q >>>> izvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8RRXA6kQ$ >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc988 >>>> 5-rfcdiff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uya >>>> q6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8_rbUbJQ$ (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://urldefense.com/v3/__https://www.iana.org/assignments/isis-tl >>>> v-codepoints/isis-tlv-__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5H >>>> ku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q_sGQ_oeg$ >>>> codepoints.xhtml#isis-tlv-codepoints-242>, please capitalize >>>> “Implicit Support” in the description for value 30. >>> >>> [ST] Done: >>> https://urldefense.com/v3/__https://www.iana.org/assignments/isis-tlv- >>> codepoints__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6Qiz >>> vSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8EoesvEw$ >>> >>>>>>>> 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://urldefense.com/v3/__https://www.iana.org/assignments/isis-t >>>>>> lv-__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwv >>>>>> m0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q98NTX3yQ$ >>>>>> 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://urldefense.com/v3/__https://www.iana.org/help/protocol-registration__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q9-MZ7toA$ >>>>>> >: >>>>>> >>>>>> • 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://urldefense.com/v3/__https://www.iana.org/assignments/bgp-parameters__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8igIF7fg$ >>>>>> • No: >>>>>> https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-pa >>>>>> rameters/bgp-__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uy >>>>>> aq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q_YAmQXwg$ >>>>>> parameters.xhtml >>>>>> • No, regrettably: >>>>>> https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-__ >>>>>> ;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAm >>>>>> eFycFu1RLxVCPN_XbMeFcql4f2VF4q-oncTNVQ$ >>>>>> 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://urldefense.com/v3/__https://www.iana.org/assignments/isis-tl >>>>> v-__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0 >>>>> gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q98NTX3yQ$ >>>>> 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://urldefense.com/v3/__https://www.iana.org/assignments/isis-tlv-codepoints__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8EoesvEw$ >>> , 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://urldefense.com/v3/__https://www.iana.org/assignments/isis-tl >>>> v-codepoints__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8EoesvEw$ >>>> > — 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://urldefense.com/v3/__https://www.iana.org/assignments/isis-t >>>>>> lv-codepoints/isis-tlv-__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfU >>>>>> h5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q_sGQ_oeg$ >>>>>> codepoints.xhtml#isis-tlv-codepoints-advertising-prefix-reachabilit >>>>>> y >>>>>> - 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>> 885.xml__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6Qiz >>>>>> vSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8anMsGmg$ >>>>>> >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>> 885.txt__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6Qiz >>>>>> vSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8nub2bmA$ >>>>>> >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>> 885.pdf__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6Qiz >>>>>> vSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q-tR2dDkA$ >>>>>> >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>> 885.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6Qi >>>>>> zvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q-TpTVqdg$ >>>>>> >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>> 885-diff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uy >>>>>> aq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8RRXA6kQ$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>> 885-rfcdiff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P >>>>>> 0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8_rbUbJQ$ (side by >>>>>> side) >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>> 885-auth48diff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hk >>>>>> u1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q-qQ31VAg$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>> 885-auth48rfcdiff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh >>>>>> 5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8DQUluPA$ >>>>>> (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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8ioxeHzw$ >>>>>>>> ). >>>>>>>> >>>>>>>> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8f8Wxylg$ >>>>>>>> ). >>>>>>>> >>>>>>>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q96s6fDmQ$ >>>>>>>> >. >>>>>>>> >>>>>>>> * 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg >>>>>>>> /ietf-announce/yb6lpIGh-__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59 >>>>>>>> RfUh5Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q-9oVA0u >>>>>>>> Q$ >>>>>>>> 4Q9l2USxIAe6P8O4Zc >>>>>>>> >>>>>>>> * The archive itself: >>>>>>>> >>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/bro >>>>>>>> wse/auth48archive/__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5H >>>>>>>> ku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q_b1p28xA$ >>>>>>>> >>>>>>>> * 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf >>>>>>>> c9885.xml__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq >>>>>>>> 6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8anMsGmg$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf >>>>>>>> c9885.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uya >>>>>>>> q6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q-TpTVqdg$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf >>>>>>>> c9885.pdf__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq >>>>>>>> 6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q-tR2dDkA$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf >>>>>>>> c9885.txt__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq >>>>>>>> 6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8nub2bmA$ >>>>>>>> >>>>>>>> Diff file of the text: >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf >>>>>>>> c9885-diff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1 >>>>>>>> P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8RRXA6kQ$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf >>>>>>>> c9885-rfcdiff.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5H >>>>>>>> ku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q8_rbUbJQ$ >>>>>>>> (side by >>>>>>>> side) >>>>>>>> >>>>>>>> Diff of the XML: >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf >>>>>>>> c9885-xmldiff1.html__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5 >>>>>>>> Hku1P0uyaq6QizvSwvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q_bToRJZA$ >>>>>>>> >>>>>>>> >>>>>>>> Tracking progress >>>>>>>> ----------------- >>>>>>>> >>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc >>>>>>>> 9885__;!!NEt6yMaO-gk!AtKcq7cMHWJ7RFGUuX6pUd59RfUh5Hku1P0uyaq6Qizv >>>>>>>> Swvm0gAmeFycFu1RLxVCPN_XbMeFcql4f2VF4q_wBEyi5A$ >>>>>>>> >>>>>>>> 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]
