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
