Hi Jeff, Thank you for your reply. We have noted your approval on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9774).
Since we now have all necessary approvals, the AUTH48 process has concluded, and we will move this document forward in the publication process. Thank you to all for your time! Best regards, RFC Editor/kc > On May 7, 2025, at 10:24 AM, Jeffrey Haas <jh...@pfrc.org> wrote: > > 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
