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 5, 2025, at 11: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<https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*ref_repo__;Iw!!NEt6yMaO-gk!EXC-r34DpOvOcOKKO2PaAZTS-HxxR9WVtnKA_8NbvSwfJnfwwLrypvbIpb8zDBYfdnX_6RCONdyT3CEMApxoNgO9e-E$>) ….. 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
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
