I acknowledge John's changes have been integrated and approve publication. -- Jeff
> On May 7, 2025, at 12:53 PM, Karen Moore <kmo...@staff.rfc-editor.org> wrote: > > Hi Sriram and Warren, > > We have updated our files to reflect John’s suggested text. We have also > noted Warren’s approval on the AUTH48 status page. > > We now await Jeff’s approval prior to moving forward with the publication > process. > > —Files (please refresh)— > > 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 only the changes made during the last editing round: > https://www.rfc-editor.org/authors/rfc9774-lastdiff.html > https://www.rfc-editor.org/authors/rfc9774-lastrfcdiff.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) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9774 > > Best regards, > RFC Editor/kc > > >> On May 7, 2025, at 7:35 AM, Warren Kumari <war...@kumari.net> wrote: >> >> I also approve publication. >> Thank you, >> W >> > > >> On May 7, 2025, at 6:14 AM, Sriram, Kotikalapudi (Fed) >> <kotikalapudi.sri...@nist.gov> wrote: >> >> I am good to go with John's suggestion. (I re-checked the relevant >> paragraphs with this change-to-be, and they would all read fine.) >> >> Sriram > > >> >> On Tue, May 06, 2025 at 5:49 PM, Karen Moore <kmo...@staff.rfc-editor.org> >> wrote: >> Authors, >> >> We have also noted Sriram’s approval on the AUTH48 status page >> (https://www.rfc-editor.org/auth48/rfc9774). >> >> Best regards, >> RFC Editor/kc >> >> On May 6, 2025, at 2:46 PM, Karen Moore <kmo...@staff.rfc-editor.org> wrote: >> >> Hi John (AD), Jeffrey, Lilia, Sriram, and Warren, >> >> Thank you for your replies. We have updated the commit for "[Analysis]" and >> have noted Lilia’s approval on the AUTH48 status page >> (https://www.rfc-editor.org/auth48/rfc9774). >> >> We will await comments regarding the suggested updates to “traditional" >> before making any changes. >> >> —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) >> >> Best regards, >> RFC Editor/kc >> >> On May 6, 2025, at 1:42 PM, Jeffrey Haas <jh...@pfrc.org> wrote: >> >> ... >> I could be fine with this. Let's see what the other authors think. >> >> If you had a terminology section, that would be the natural place to do >> this, but you don’t, and I don’t think we should introduce one at this late >> date. >> >> Agreed. >> >> -- Jeff >> >> On May 6, 2025, at 1:29 PM, John Scudder <j...@juniper.net> wrote: >> >> Hi All, >> >> About the use of “traditional”, I looked at the current version, and I have >> a suggestion. After reading the text with any of the suggested adjectives, >> none of them fills me with happiness. I think that’s because “brief” is not >> a defined term of art in the BGP document set, so the idea that we can >> qualify it with some adjective and have that speak unambiguously to the >> reader is a bit of a reach. That is, IMO, “traditional” is neither necessary >> nor sufficient for maximum clarity. >> >> My proposal is to fix the problem by being clearer about our terminology in >> Section 5, as in, >> >> OLD: >> it is typically referred to as "brief" aggregation in implementations. Brief >> aggregation results in an AS_PATH that has >> >> NEW: >> it is typically referred to as "brief" aggregation in implementations. That >> terminology is adopted here: in this document, brief aggregation refers to >> what is described in this section, in contrast to consistent brief >> aggregation as described in Section 5.2. Brief aggregation results in an >> AS_PATH that has >> >> And then you can remove “traditional” throughout, without loss of precision. >> You will already have stated explicitly what “brief” means, and have warned >> the reader that “consistent” is the adjective whose presence or absence >> distinguishes the two variants. >> >> (Another alternative would be wherever you use “traditional brief”, replace >> it with something like “brief (as described in Section 5)”, but that ends up >> being more ponderous.) >> >> If you had a terminology section, that would be the natural place to do >> this, but you don’t, and I don’t think we should introduce one at this late >> date. >> >> Thoughts? >> >> —John >> >> On May 6, 2025, at 8:07 AM, Hannachi, Lilia (Assoc) via auth48archive >> <auth48archive@rfc-editor.org> wrote: >> >> RFC Editor: >> >> 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. >> >> I approve this RFC for publication. >> >> Regards >> Lilia >> >> On May 5, 2025, at 8:41 PM, Sriram, Kotikalapudi (Fed) >> <kotikalapudi.sri...@nist.gov> wrote: >> >> Hi Karen, >> >> Thank you for the help from you and all the RFC Editors. >> >> I agree with Jeff’s comments. >> >> About use of the word “traditional”, I lean in the direction of what Warren >> has recommended: “I think that "traditional" is the better word here,…” >> >> About the following : >> >> 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://www.rfc-editor.org/styleguide/part2/#ref_repo) >> >> ….. >> >> Current: >> [Analysis] "Detailed analysis of AS_SETs in BGP updates", commit eb0fc22, >> March 2022, >> <https://github.com/ksriram25/IETF/blob/main/Detailed- AS_SET-analysis.txt>. >> --> >> >> No problem. The change you have made is acceptable. I have added the authors >> names and contact info at the top of the file in GitHub. Please update the >> commit to ef3f4a9 in the citation. >> >> I have looked at the whole updated document, and assuming the above change >> (commit #) would incorporated, I approve this RFC for publication. >> >> Sriram >> >> On May 3, 2025, at 1:46 PM, Warren Kumari <war...@kumari.net> wrote: >> >> I agree with all of Jeff's comments, other than the change from >> "Traditional" to "Conventional" >> >> To me, "conventional" means doing something according to convention - the >> commonly agreed upon manner. For example, "By convention, we state >> temperature in degrees Celsius". This is what we do now / today. >> >> "Traditionally", on the other hand, implies something which we either used >> to do, or something done for a long time — "Traditionally, each town had a >> baker and a smith", or "Traditional Swedish architecture is characterized …". >> >> Basically, convention + time == tradition. >> >> The total of the Appendix B is "Examples of Consistent and Inconsistent BGP >> Origin-AS Generated by Traditional Brief Aggregation" - this is meaning >> "using the system which has been used for a long time", not "using the >> current convention". >> >> I think that "traditional" is the better word here, but this certainly is >> not a hill that I'm willing to die on… W >> >> On Fri, May 02, 2025 at 4:08 PM, Karen Moore <kmo...@staff.rfc-editor.org> >> wrote: 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
