Peter, Thank you for your reply.
Re: Section 2 > it's OR We added 'or' between the two statements of item 2; please review. The revised files are here (please refresh): https://www.rfc-editor.org/authors/rfc9929.html https://www.rfc-editor.org/authors/rfc9929.txt https://www.rfc-editor.org/authors/rfc9929.pdf https://www.rfc-editor.org/authors/rfc9929.xml This diff file shows all changes from the approved I-D: https://www.rfc-editor.org/authors/rfc9929-diff.html https://www.rfc-editor.org/authors/rfc9929-rfcdiff.html (side by side) This diff file shows the changes made during AUTH48 thus far: https://www.rfc-editor.org/authors/rfc9929-auth48diff.html https://www.rfc-editor.org/authors/rfc9929-auth48rfcdiff.html (side by side) This diff file shows only the changes since the last posted version: https://www.rfc-editor.org/authors/rfc9929-lastrfcdiff.html We will wait to hear from you again and from your coauthors before continuing the publication process. This page shows the AUTH48 status of your document: https://www.rfc-editor.org/auth48/rfc9929 Thank you. Alice Russo RFC Production Center > On Feb 19, 2026, at 12:46 AM, Peter Psenak <[email protected]> wrote: > > Hi Alice, > > please see inline (##PP2): > > On 19/02/2026 01:48, Alice Russo wrote: >> Peter, >> >> Thank you for your reply. Please see the follow-ups below. The revised files >> are here (please refresh): >> https://www.rfc-editor.org/authors/rfc9929.html >> https://www.rfc-editor.org/authors/rfc9929.txt >> https://www.rfc-editor.org/authors/rfc9929.pdf >> https://www.rfc-editor.org/authors/rfc9929.xml >> >> This diff file shows all changes from the approved I-D: >> https://www.rfc-editor.org/authors/rfc9929-diff.html >> https://www.rfc-editor.org/authors/rfc9929-rfcdiff.html (side by side) >> >> This diff file shows the changes made during AUTH48 thus far: >> https://www.rfc-editor.org/authors/rfc9929-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9929-auth48rfcdiff.html (side by >> side) >> >> Re: #4 (Section 2) >>> ##PP >>> no, above is not right. >>> - please keep it as two independent statements >>> - please remove the "if" in the first statement >> Updated as requested. What is the connection between those two statements? >> "and"? > > ##PP2 > > it's OR > >> >> Current: >> 2. For any of the planned maintenance cases: >> >> * the node originating the prefix is signaling the overload >> state in IS-IS, or the H-bit in OSPFv2 [RFC8770], or the R-bit >> in OSPFv3 [RFC5340]. >> >> * the metric to reach the prefix from an ABR or ASBR crosses the >> configured threshold. >> >> >> Re: #2, 6, 7, and 8, we interpreted 'Ack' as the OK to update to the >> 'Perhaps' text. Please let us know if any further changes are needed. > ##PP2 > > yes, Ack means OK > > thanks, > Peter > >> >> We will wait to hear from you again and from your coauthors >> before continuing the publication process. This page shows >> the AUTH48 status of your document: >> https://www.rfc-editor.org/auth48/rfc9929 >> >> Thank you. >> >> Alice Russo >> RFC Production Center >> >>> On Feb 18, 2026, at 2:50 AM, Peter Psenak >>> <[email protected]> wrote: >>> >>> Hi Alice, >>> >>> please see inline (##PP): >>> >>> On 17/02/2026 01:30, [email protected] wrote: >>>> Authors, >>>> >>>> While reviewing this document during AUTH48, please resolve (as necessary) >>>> the following questions, which are also in the source file. >>>> >>>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in >>>> the title) for use on https://www.rfc-editor.org/search. --> >>>> >>>> >>>> 2) <!--[rfced] Please clarify this sentence. Specifically, please make the >>>> statements about OSPFv2 and OSPFv3 parallel. Is is accurate that the first >>>> two mechanisms are for OSPFv2, and the last one is for OSPFv3? >>>> >>>> Original: >>>> In OSPFv2 using the cost of MaxLinkMetric for all >>>> non-stub links in the router-LSA [RFC6987], or H-bit [RFC8770], and >>>> R-bit for OSPFv3 [RFC5340] are mechanisms available for that purpose. >>>> >>>> Perhaps: >>>> The mechanisms available for that purpose are (in OSPFv2) using the cost >>>> of MaxLinkMetric for all non-stub links in the router-LSA [RFC6987] or >>>> using >>>> the H-bit [RFC8770], or (in OSPFv3 [RFC5340]) using the R-bit. >>>> --> >>> ##PP >>> Ack >>>> >>>> 3) <!--[rfced] Please clarify item 1. >>>> Original: >>>> 1. Reachability of a prefix that was reachable earlier was lost. >>>> >>>> Perhaps: >>>> 1. A prefix that was reachable earlier is now lost (i.e., no longer >>>> reachable). >>>> --> >>> ##PP >>> I would prefer: >>> "A prefix that was reachable earlier becomes unreachable" >>>> >>>> 4) <!--[rfced] Please clarify item 2. Why is the first item "if"? >>>> Is the second item dependent on the first "if" clause? If so, we >>>> suggest putting them together. >>>> >>>> Original: >>>> 2. For any of the planned maintenance cases: >>>> >>>> - if the node originating the prefix is signalling the >>>> overload state in IS-IS, or or H-bit in OSPFv2 [RFC8770], or >>>> R-bit in OSPFv3 [RFC5340] . >>>> >>>> - the metric to reach the prefix from an ABR or ASBR crosses >>>> the configured threshold. >>>> >>>> Perhaps: >>>> For any of the planned maintenance cases, if the node originating the >>>> prefix is signaling the overload state in IS-IS, or is using the H-bit >>>> in OSPFv2 [RFC8770] or the R-bit in OSPFv3 [RFC5340], then the metric >>>> to reach the prefix from an ABR or ASBR crosses the configured >>>> threshold. >>>> --> >>> ##PP >>> no, above is not right. >>> - please keep it as two independent statements >>> - please remove the "if" in the first statement >>>> >>>> 5) <!--[rfced] Should this be plural "databases"? >>>> >>>> Original: >>>> Not withdrawing the UPA would result in >>>> stale information being kept in the link state database of all >>>> routers in the area. >>>> >>>> Perhaps: >>>> Not withdrawing the UPA would result in >>>> stale information being kept in the link state databases of all >>>> routers in the area. >>> ##PP >>> Above is fine, please use that. >>>> >>>> Or rephrase: >>>> Withdrawing the UPA prevents the LSDB from holding stale >>>> information about all routers in the area. >>>> --> >>>> >>>> >>>> 6) <!--[rfced] Does "preceding section" refer to Section 2 or Section 3? We >>>> suggest updating the text to use the section number. >>>> >>>> Original (Section 3.1): >>>> As per the definitions referenced in the preceding section, any >>>> prefix advertisement with a metric value ... >>>> >>>> Perhaps: >>>> As per the definitions referenced in Section 3, any >>>> prefix advertisement with a metric value ... >>>> --> >>>> >>> ##PP >>> Ack. >>>> >>>> 7) <!-- [rfced] How may this paragraph be rephrased for clarity? >>>> >>>> Original (Section 3.2): >>>> In IS-IS a prefix can be advertised with metric higher than >>>> 0xFE000000, for various reasons. Even though in all cases the >>>> treatment of such metric is specified for IS-IS, having an explicit >>>> way to signal that the prefix was advertised in order to signal UPA >>>> is required to distinguish it from other cases where the prefix with >>>> such metric is advertised. >>>> >>>> Perhaps: >>>> In IS-IS, a prefix can be advertised with a metric higher than >>>> 0xFE000000, for various reasons. >>>> While IS-IS specifies the treatment of such metrics, explicit >>>> signaling is required to distinguish UPA from other high-metric >>>> advertisements. >>>> --> >>> ##PP >>> Ack >>>> >>>> >>>> 8) <!--[rfced] Similarly, how may this paragraph be rephrased for clarity? >>>> >>>> Original (Section 4.2): >>>> In OSPFv2 a prefix can be advertised with metric LSInfinity, or in >>>> OSPFv3 with NU-bit set in PrefixOptions, for various reasons. Even >>>> though in all cases the treatment of such metric, or NU-bit, is >>>> specified for OSPFv2 and OSPFv3, having an explicit way to signal >>>> that the prefix was advertised in order to signal UPA is required to >>>> distinguish it from other cases where the prefix with such metric is >>>> advertised. >>>> >>>> Perhaps: >>>> A prefix can be advertised (in OSPFv2) with the LSInfinity metric or >>>> (in OSPFv3) with the NU-bit set in PrefixOptions, for various reasons. >>>> While OSPFv2 and OSPFv3 specify the treatment of the LSInfinity metric >>>> and the NU-bit, explicit signaling is required to distinguish UPA >>>> from other scenarios using the LSInfinity metric or NU-bit. >>>> --> >>> ##PP >>> Ack >>>> >>>> >>>> 9) <!--[rfced] FYI, we updated this TLV name to match the name used in the >>>> IANA Considerations. Please let us know if this is not accurate. >>>> >>>> Original: Prefix Attributes Sub-TLV >>>> Current: Prefix Attribute Flags Sub-TLV >>>> --> >>> ##PP >>> Ack >>>> >>>> >>>> 10) <!--[rfced] Please clarify this sentence, in particular the opening >>>> phrase. >>>> >>>> Original: >>>> For default algorithm 0 >>>> prefixes with U-Flag it is therefore REQUIRED to advertise the >>>> unreachable prefix in the base OSPFv2 LSA - e.g., OSPFv2 Summary-LSA >>>> [RFC2328], or AS-external-LSAs [RFC2328], or NSSA AS-external LSA >>>> [RFC3101]. >>>> >>>> Perhaps: >>>> Therefore, for the default algorithm 0 with prefixes advertised with >>>> U-Flag, >>>> it is REQUIRED to advertise the >>>> unreachable prefix in the base OSPFv2 LSA - e.g., OSPFv2 Summary-LSA >>>> [RFC2328], AS-external-LSAs [RFC2328], or NSSA AS-external LSA >>>> [RFC3101]. >>> ##PP >>> We need to correct the initial sentence of that section to include both new >>> bits: >>> So the entire section should read as: >>> "The prefix that is advertised with U-Flag or UP-Flag MUST have the metric >>> set to a value LSInfinity. >>> If the prefix metric is not equal to LSInfinity, both of these flags MUST >>> be ignored. Therefore, for the prefixes in default algorithm 0 that are >>> advertised with U-Flag, or Up-Flag, it is REQUIRED to advertise the >>> unreachable prefix in the base OSPFv2 LSA - e.g., OSPFv2 Summary-LSA >>> [RFC2328], AS-external-LSAs [RFC2328], or NSSA AS-external LSA [RFC3101]." >>> >>>> Regarding a similar phrase in Section 4.2.2, may it be updated as follows? >>>> >>>> Original: >>>> For default algorithm 0 prefixes, >>>> the LSInfinity MUST be set in the parent TLV. >>>> >>>> Perhaps: >>>> For prefixes in default algorithm 0, >>>> the LSInfinity MUST be set in the parent TLV. >>> ##PP >>> Above sounds good. >>> >>>> Or: >>>> When advertising prefix reachability in default algorithm 0, >>>> the LSInfinity MUST be set in the parent TLV. >>>> --> >>>> >>>> >>>> 11) <!-- [rfced] Do you want to keep these TLV names as they are, or >>>> change to >>>> match how they appear in RFC 8362? >>>> >>>> This document: >>>> Intra-Area Prefix TLV >>>> Inter-Area Prefix TLV >>>> External Prefix TLV >>>> >>>> [RFC8362] and the corresponding IANA registry >>>> (https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#extended-lsa-tlvs) >>>> use the following (with an additional hyphen in each): >>>> >>>> Intra-Area-Prefix TLV >>>> Inter-Area-Prefix TLV >>>> External-Prefix TLV >>>> --> >>> ##PP >>> Please use the RFC8362 naming as you suggested above. >>> >>>> >>>> 12) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>> online >>>> Style Guide >>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>> and let us know if any changes are needed. Updates of this nature typically >>>> result in more precise language, which is helpful for readers. >>>> >>>> Please consider whether "traditionally" should be updated for clarity. >>>> While the NIST website >>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> >>>> indicates that this term is potentially biased, it is also ambiguous. >>>> "Traditionally" is a subjective term, as it is not the same for everyone. >>>> --> >>>> >>> ##PP >>> please remove the "traditionally" from the text. >>> thanks, Peter >>>> Thank you. >>>> >>>> Alice Russo >>>> RFC Production Center > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
