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]
