Re: [Idr] Review of draft-abraitis-bgp-version-capability-07

[John Scudder <[e-mail]>]

Yep. I’ll follow up with you unicast.

—John

> On Aug 28, 2020, at 3:37 PM, Donatas Abraitis <[e-mail]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Thanks, John, for this explanation.
> 
>> If you do want to offer it to IDR as a WG document, we’d be happy to work with you on that. Here’s a short précis of procedure, pros, and cons.
> 
> I would love to continue with IDR. Could you help me and tell me what
> actions do I need to do at first?
> 
>> On Fri, Aug 28, 2020 at 10:31 PM John Scudder <[e-mail]> wrote:
>> 
>>> On Aug 28, 2020, at 3:10 PM, Donatas Abraitis <[e-mail]> wrote:
>>> 
>>> P.S. I just want to double-check, because sorry, don't know the process, what should I do actually now with this draft?
>> 
>> It really depends on you.
>> 
>> If you want to proceed forward with the ISE publication, that depends on Adrian and his colleagues. From my point of view, there’s nothing to stop it.
>> 
>> If you do want to offer it to IDR as a WG document, we’d be happy to work with you on that. Here’s a short précis of procedure, pros, and cons.
>> 
>> - You tell the chairs you’d like to request WG adoption of your document.
>> - The chairs initiate a discussion on the list, customarily two weeks are given for people to provide their input about whether to adopt it or not.
>> - The expectation when a document is adopted as a WG draft is that the WG wants to work on the problem, and considers the document a good starting point. It is common, even usual, for the details to change as the WG works on the document though.
>> - I imagine part of the discussion would be whether to resurrect operational-message and use that as the basis for a solution instead. One of the comments that came up last August was the idea of hollowing out operational-message to make it a framework only, so that it would be less intimidating to implement when using it for a small extension like yours.
>> 
>> At the end of the process, the chairs judge whether the “rough consensus” is for the WG to take the work on, or not. If the document is adopted, the WG has change control over the document, formally speaking — what this means practically, is that the author needs to take into account what the WG consensus is, he doesn’t just make the decisions on his own. The next formal step after adoption, is working group last call (“WGLC”) where the authors say “we’re done” and the chairs judge whether the WG agrees. Once that’s done, the draft goes to the IESG to become an RFC (there are several more details I’m skipping over).
>> 
>> The con of engaging in this process is it’s more demanding of your time (and patience) than simply proceeding ahead with ISE, and you might end up having to negotiate a quite different solution than you currently have. The pro is that you’d end up getting a lot more review and help, and hopefully would end up with a more robust and general solution, and one that has community consensus and is an actual IETF standard.
>> 
>> I hope that helps.
>> 
>> Thanks,
>> 
>> —John
> 
> 
> 
> --
> Donatas Abraitis
> Systems Engineer
> @: [e-mail]
> W: www.hostinger.com