Hi Jeff, Thank you for your quick reply. We have updated our files accordingly. Please see a few clarifications below.
1) Note that we added “following” to the text below for clarity. Please let us know if this is agreeable. Original: Brief aggregation results in an AS_PATH that has the property (from [RFC4271], Section 9.2.2.2): Current: Brief aggregation results in an AS_PATH that has the following property (from [RFC4271], Section 9.2.2.2): 2) FYI: We will await feedback from your coauthor(s) regarding the reference entry for [Analysis] and before potentially replacing “traditional” with “conventional”. —Files— The updated XML file is here: https://www.rfc-editor.org/authors/rfc9774.xml The updated output files are here: https://www.rfc-editor.org/authors/rfc9774.txt https://www.rfc-editor.org/authors/rfc9774.pdf https://www.rfc-editor.org/authors/rfc9774.html These diff files show all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9774-auth48diff.html https://www.rfc-editor.org/authors/rfc9774-auth48rfcdiff.html (side by side) These diff files show all changes made to date: https://www.rfc-editor.org/authors/rfc9774-diff.html https://www.rfc-editor.org/authors/rfc9774-rfcdiff.html (side by side) Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Please contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process. For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9774 Best regards, RFC Editor/kc > On May 2, 2025, at 8:40 AM, Jeff Haas <jhaas=40juniper....@dmarc.ietf.org> > wrote: > > 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
