Editor, On 5/1/25, 18:59, "rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>" <rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>> wrote: > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the XML file. > > > 1) <!--[rfced] May we update the short title that spans the top of the > PDF file to more closely match the document title as shown below? > > > Original: > AS_SET, AS_CONFED_SET use deprecation > > > Perhaps: > Deprecation of AS_SET and AS_CONFED_SET
I agree with this change. > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on > https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jAIHTBAcM$ > > <https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jAIHTBAcM$> > . The keywords in the title are sufficient, in my opinion. > a) Because this document updates RFC 4271, please > review the errata reported for RFC 4271 > (https://urldefense.com/v3/__https://www.rfc-editor.org/errata_search.php?rfc=4271__;!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jAVq9GQiA$ > > <https://urldefense.com/v3/__https://www.rfc-editor.org/errata_search.php?rfc=4271__;!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jAVq9GQiA$> > ) > and let us know if you confirm our opinion that none of > the errata are relevant to the content of this document. No errata appear to be relevant to this update. > b) Because this document updates RFC 5065, please > review the errata reported for RFC 5065 > (https://urldefense.com/v3/__https://www.rfc-editor.org/errata_search.php?rfc=5065__;!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jA8Gn7YtA$ > > <https://urldefense.com/v3/__https://www.rfc-editor.org/errata_search.php?rfc=5065__;!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jA8Gn7YtA$> > ) > and let us know if you confirm our opinion that none of > the errata are relevant to the content of this document. The errata vs. RFC 5575 are primarily grammar nits. We'll focus on the text in this document. > 4) <!--[rfced] Should "BCP 172" be added as an entry under the > Normative References section, or should "BCP 172" be > replaced with "RFC 6472" since it's the only RFC in > BCP 172? Please let us know your preference. I would recommend keeping BCP 172, even though there is currently only one RFC in that BCP. This permits updates to the BCP to be carried through in documents that cite it. Thus, I believe the changes below covering the BCP are things we don't want to do. Further, keeping the current break-out of RFC 6472 does also capture that at th time of the publication of this document that BCP 172 contained only a single entry. > Abstract/Introduction > > > Original: > BCP 172 (i.e., RFC 6472) recommends not using AS_SET and > AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol > (BGP). > > > BCP 172 [RFC6472] makes a recommendation for not using AS_SET (see > [RFC4271]) and AS_CONFED_SET (see [RFC5065]) AS_PATH path segment > types in the Border Gateway Protocol (BGP). > > > Perhaps: > RFC 6472 recommends not using AS_SET and AS_CONFED_SET AS_PATH segment > types in the Border Gateway Protocol (BGP). > > > [RFC6472] makes a recommendation for not using AS_SET [RFC4271] and > AS_CONFED_SET [RFC5065] AS_PATH path segment types in the Border > Gateway Protocol (BGP). > --> > > > > > 5) <!--[rfced] For conciseness, we updated "possibility of ambiguity" to > "any ambiguity" as shown below. Please let us know of any objections. > > > Original: > In particular, the prohibition of AS_SETs and AS_CONFED_SETs > removes the possibility of ambiguity about origin AS in > RPKI-based route origin validation (RPKI-ROV) [RFC6811] > [RFC6907] [RFC9319]. > > > Current: > In particular, the prohibition of AS_SETs and AS_CONFED_SETs > removes any ambiguity about the origin AS in RPKI-based Route > Origin Validation (RPKI-ROV) [RFC6811] [RFC6907] [RFC9319]. I agree with this change. > 6) <!--[rfced] FYI: In order to make the list parallel in Section 3, we > updated the second bullet point as shown below. > > > Original: > * MUST NOT advertise BGP UPDATE messages containing AS_SETs or > AS_CONFED_SETs, and > > > * Upon reception of BGP UPDATE messages containing AS_SETs or > AS_CONFED_SETs in the AS_PATH or AS4_PATH [RFC6793], MUST > use the "treat-as-withdraw" error handling behavior as > per [RFC7606]. > > > Current: > * MUST NOT advertise BGP UPDATE messages containing AS_SETs or > AS_CONFED_SETs and > > > * MUST use the "treat-as-withdraw" error handling behavior per > [RFC7606] upon reception of BGP UPDATE messages containing > AS_SETs or AS_CONFED_SETs in the AS_PATH or AS4_PATH [RFC6793]. I agree with this change. > 7) <!--[rfced] Please clarify what "the property" refers to in the > following sentence. > > > Original: > Brief aggregation results in an AS_PATH that has > the property (from [RFC4271], Section 9.2.2.2): The immediately following paragraph (with citation bars) is intended to be the property in question. The intention here is to discuss that when using brief aggregation, the resulting AS_PATH is what is discussed in the citation. > 8) <!--[rfced] We updated the following sentence for clarity as > shown below. Please let us know of any objections. > > > Original: > As discussed in Section 5.1 of [RFC4632], the presence of both less > specific and more specific destinations has the possibility to create > forwarding loops between networks. > > > Current: > When both less specific and more specific destinations are present, it's > possible to create forwarding loops between networks, as discussed in > Section 5.1 of [RFC4632]. I agree with this change. > 9) <!-- [rfced] FYI: We updated the reference entry for [Analysis] to > match the guidance for referencing web-based public code repositories > in the Web Portion of the RFC Style Guide > (https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/ > <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/>*ref_repo__;Iw!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jAQ55O9q8$ > ). > > > Original: > [Analysis] Hannachi, L. and K. Sriram, "Detailed analysis of AS_SETs > in BGP updates", NIST Robust Inter-domain Routing Project > Website , October 2019, > <https://urldefense.com/v3/__https://github.com/ksriram25/IETF/blob/main/Detailed-AS_SET-__;!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jA4PAfbOM$ > > <https://urldefense.com/v3/__https://github.com/ksriram25/IETF/blob/main/Detailed-AS_SET-__;!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jA4PAfbOM$> > analysis.txt>. > > > Current: > [Analysis] "Detailed analysis of AS_SETs in BGP updates", commit > eb0fc22, March 2022, > <https://urldefense.com/v3/__https://github.com/ksriram25/IETF/blob/main/Detailed-__;!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jAQ1A-SUw$ > > <https://urldefense.com/v3/__https://github.com/ksriram25/IETF/blob/main/Detailed-__;!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jAQ1A-SUw$> > AS_SET-analysis.txt>. I see that the style guide intentionally discards the authors and title. This seems disrespectful of citing the authors of the work and is problematic on that front. Since this work is Sriram and NISTs, I will let him comment on his desired disposition of this point. One option for him to evaluate is whether there's other places this information may be archived and made available for citation in the RFC that doesn't lose attribution. > 10) <!--[rfced] We updated the following sentence for clarity. Please let > us know if it changes the intended meaning. > > > Original: > Presented here is an illustration of how an AS_SET is not used when > aggregating and still data-plane route loops are avoided. > > > Current: > The illustration presented below shows how an AS_SET is not used > when aggregating and how data plane route loops are avoided. I agree with this change. > 11) <!--[rfced] Regarding Appendices B.1, B.2, and B.3, would it be > clearer and easier to read if an introductory sentence was > included in each section (and thus each section title was > shortened) as shown below? Please review. Shortening the section titles unfortunately reduces clarity. I'd recommend against this change. > Additionally, we note that some lines include a period and some > don't. May we add a period after each sentence for consistency? In general, adding periods for consistency is fine. The place I do not recommend adding such periods is under the list of Routes. > 12) <!-- [rfced] FYI: We have added an expansion for the following > abbreviation per Section 3.6 of RFC 7322 ("RFC Style > Guide"). Please review this expansion and each expansion in the > document carefully to ensure correctness. > > > Classless Inter-Domain Routing (CIDR) I agree with this change. > 13) <!-- [rfced] Please review the "Inclusive Language" portion of the online > Style Guide > <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/ > <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/>*inclusive_language__;Iw!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jAAjt06Wo$ > > > and let us know if any changes are needed. Updates of this nature typically > result in more precise language, which is helpful for readers. > > > For example, please consider whether the following should be updated: > > > - traditional > > > While the NIST website > <https://urldefense.com/v3/__https://web.archive.org/web/20250214092458/__;!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jAW177rII$ > > <https://urldefense.com/v3/__https://web.archive.org/web/20250214092458/__;!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jAW177rII$> > https://urldefense.com/v3/__https://www.nist.gov/nist-research-library/nist-technical-series-publications-__;!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jAKCUbYmU$ > > <https://urldefense.com/v3/__https://www.nist.gov/nist-research-library/nist-technical-series-publications-__;!!NEt6yMaO-gk!Dp2HeBp3w6hEJqydFHmDG2ctOp3E3U5-jKldZm2cJ-zQ8WGQvP88RS5K0zQomFe84h84HwPSACGpA6jAKCUbYmU$> > author-instructions#table1> indicates that this term is potentially biased, it > is also ambiguous. "Tradition" is a subjective term, as it is not the same > for everyone. > --> Understood. In this context, it's my opinion that it doesn't run afoul of inclusivity issues. However, the synonym "conventional" I think conveys the same meaning and might be able to be used in its place if there's concerns. Sriram to comment on the final choice. Juniper Business Use Only -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
