Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

[Donatas Abraitis <[e-mail]>]

Hello, guys,

>> But who will work on it if authors would not be interested to change the draft once it becomes a WG doc ? 
Not sure, what is "change the draft" in this context, but I'm ready to do changes if needed.

Sent from my iPhone

> On 2020-09-24, at 21:25, John Scudder <[e-mail]> wrote:
> 
>  On Sep 23, 2020, at 3:59 PM, Robert Raszuk <[e-mail]> wrote:
>> 
>> PS1. And on the other hand if it is not adopted here it will likely get published as an RFC anyway in the ISE track. So honestly I have no idea what's best for BGP. If it would be my call
> 
> It is your call — well, what I mean is that this is exactly the kind of issue that should be discussed during this adoption call. So thanks for bringing it up.
> 
>> in such a situation I would perhaps recommend to adopt it and repackage in a different encoding envelope.
> 
> That’s certainly an option that can be on the table, and if others are interested in the same way forward, they should follow up. It would probably help to discuss what that “different encoding envelope” might be, at least in general terms.
> 
>> But who will work on it if authors would not be interested to change the draft once it becomes a WG doc ? 
> 
> Indeed that’s a key question. For that matter it is for every draft we adopt: not only “do you think it’s a good idea” but “are you willing to put effort into it” (including contributing, reviewing, etc). I think it’s a good idea that everyone should have a pony, but I’m not willing to put effort into it :-). 
> 
> But, in this case it seems like the ’not be interested’ part is getting a little ahead of ourselves. Donatas is in the cc after all, we shouldn’t need to speculate about his preferences. Donatas, as the author, what’s your reaction to Robert’s proposal? (It is OK to say “I would need to know something more specific an just ‘different encoding envelope’.”)
> 
>> PS2. Assume this goes on as ISE RFC. And perhaps magic happens and IDR defines a different encoding for exactly the same information down the road. Would IDR or GROW have power to move ISE RFC to historic or obsolete status at that point ? 
> 
> My guess is that the answer is “no”. Historic is — as far as I know — a designation specific to the IETF standards process. The ISE is — as far as I understand it — not part of the IETF standards process. Figure 1 of RFC 6635, "RFC Editor Model”, seems to confirm this. I’ll see if I can get an authoritative answer.
> 
> —John