It occurs to me a bit late that grow should have been cc'd on this adoption call which was targeted to end this week.
If you have an opinion on the draft's adoption, please respond to the idr thread using the criteria below. -- Jeff > Begin forwarded message: > > From: Jeffrey Haas <[email protected]> > Subject: WG adoption call for draft-abraitis-bgp-version-capability (ending > 14 June, 2025) > Date: May 30, 2025 at 3:53:52 PM EDT > To: idr <[email protected]> > > Working Group, > > The author of draft-abraitis-bgp-version-capabiity has (re-)requested this > document be adopted by IDR. This begins a two week adoption call. > > It's the consensus of the IDR chairs that we'll be requesting this work be > adopted in a constrained form. That constrained form is: > - A simple human-readable string. > - The working group is welcome to make comments on what is contained in that > human-readable string. > - This string is encoded in a BGP capability. The draft currently has a FCFS > capability code point assigned by IANA. > - This capability requires the use of RFC 9072. > > If you support the adoption of the draft with these constraints, please reply > to this thread with your support. > > If you do not support the adoption of the draft with these constraints, > similarly reply to this thread with your lack of support. However, please do > not try to recommend alternative mechanisms in this adoption thread - reserve > those to new threads. > > Feedback on the contents of the current document is appreciated by the author > and the working group, however, please provide that in other threads. > > While the current document has a status of "informational", that is primarily > due to its prior work with the independent submissions track. If adopted by > the working group, the status will likely be Proposed Standard or > Experimental. Discussion about the status will happen in the future. > > ----- > > Several few items of note for this adoption call: > > This feature currently is deployed using a first-come, first-served > capability code in an existing implementation. > > - This isn't the first round of adoption request. A prior thread from 2020: > https://mailarchive.ietf.org/arch/msg/idr/Qxq0W3gTZXM2pHxKQAaxOVnda9Y/ > <https://mailarchive.ietf.org/arch/msg/idr/Qxq0W3gTZXM2pHxKQAaxOVnda9Y/> > - This draft has received several rounds of discussion and feedback in the > mailing list already, the majority of which has been integrated in the > current version of the draft. > - The feature requires the extended optional parameter length RFC 9072, which > enables carrying more data for BGP capabilities in a BGP OPEN message. > > Some items raised from the prior discussion: > - Unicode gotchas. (See RFC 9003 as an example.) These still need to be > addressed in the current text. > - More complicated encoding schemes are certainly possible, but have failed > to achieve any consensus for their content. > - Ensure there are recommendations about using this string only for > informational purposes and not to alter BGP protocol behaviors. > - Concerns about the capability preventing the peering session from coming up > for versions that may not care for it. This point was extensively discussed > and not considered to be a core concern for compliant BGP implementations. > However, requiring text to disable the sending of this capability would be > in-scope for a WG adopted draft. > - Discussed the use of URIs or similar in the text field. However, due to > security concerns, this is probably not what we want. > - While the BGP "operational" or "advisory" drafts could carry similar state, > that is not the current proposal. > > Thread for IESG conflict review: > https://mailarchive.ietf.org/arch/msg/idr/Qxq0W3gTZXM2pHxKQAaxOVnda9Y/ > <https://mailarchive.ietf.org/arch/msg/idr/Qxq0W3gTZXM2pHxKQAaxOVnda9Y/> > > This includes discussion (2020) on IDR not picking it up at the time and > justifies the current "Informational" status this document currently has. > Primarily, this is the author's attempt to document the FCFS code point it > uses. > > In that conflict review thread, John Scudder gives a timeline review of the > document at that point. > https://mailarchive.ietf.org/arch/msg/idr/UT-PZaVY3-K7HZ6_PkspgIuxOEo/ > <https://mailarchive.ietf.org/arch/msg/idr/UT-PZaVY3-K7HZ6_PkspgIuxOEo/> > > It is worthy of note that part of the reason prior efforts stalled out was > that this was happening during the height of the COVID-19 pandemic and > members of the working group were "distracted". > > -- Jeff > > > >
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
