I also approve publication. Thank you, W
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-editor@ > rfc-editor.org>" <rfc-edi...@rfc-editor.org <mailto:rfc-editor@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
