On 12-Nov-20 23:24, tom petch wrote:
> From: OPSAWG <[email protected]> on behalf of Toerless Eckert
> <[email protected]>
> Sent: 11 November 2020 20:24
>
> I am mostly worried to figure out if we can try to lock in the admissable
> changes to
> the document as early as possible.
>
> [ I was recently hit with a post-WG IESG concern on a fundamental
> aspect of one of my drafts, and that not only dragged on the document for a
> year or
> more, it also required to make the final RFC be incompatible with what the
> WG was
> expeting to see through the whole lifetime of the draft in the WG and even
> through
> 90% of IESG review. Not to speak of changing code built against that. ]
>
> That is why i would like to see if there is a form of adopting this document
> under
> specific premises / constraints for acceptable changes
[Suppressed scream.] That is *exactly* the semantic of an Independent
Submission RFC.
Fine, if OPSAWG wants to waste its own time, and that of the IESG, and the
whole IETF during Last Call, in debating editorial details of a document whose
technical content cannot change, feel free to go ahead, but count me out of it;
I'm sending the thread to /dev/null for now.
Brian
> that ideally the rest of IETF
> would have to budge to, and that is not only something the WG _now_ agrees to.
> Not sure if/what the process for this would be. Early IESG review or the
> like ?
>
> <tp>
> I think that you are asking for a perpetual motion machine or whatever the
> analogy might be for you.
>
> Adopt the I-D and change control is up to the WG. Looking at the I-D I think
> that the chances of the IESG agreeing to this I-D are too small to register.
> There is a lot of vendor-related, proprietary data or implementation detail
> that I expect will all have to go. Repeated references to github? err no.
>
> My guess is that about half of the current text would make it through. Even
> the ISE might baulk at some of it.
>
> Tom Petch
>
> "re-publishing + inheriting change authority" as in rfc8017 sounded like a
> cool way
> to potentially achieve that goal. And i was proposing additional text re
> IANA registries
> in a prior email in this thread.
>
> Such an approach should hopefully allow to get the document out to IETF/IESG
> review
> very quickly, locking into the document only all the current "pre-IETF/code"
> state,
> adding registries, and pushing any open issues (that require new code anyhow)
> into
> followup documents from the WG.
>
> Just brainstorming how to process this work best!
>
> Cheers
> toerless
>
> On Wed, Nov 11, 2020 at 09:06:02PM +0100, Carsten Bormann wrote:
>> On 2020-11-11, at 19:13, Toerless Eckert <[email protected]> wrote:
>>>
>>> Agreed. but this is in contradiction to what others here on the thread
>>> claimed
>>> would be in scope of changes toward RFC, such as "anything", so everybody
>>> seems
>>> to chime in wih liking pcapng without first trying to have a clear
>>> understanding
>>> what it is the WG should and should not do.
>>
>> Well, it???s not really a contradiction if:
>>
>> (1) the IETF is allowed to do X
>> (2) it would be stupid to do X
>>
>> (Obviously, a handover would include reaching some trust that the IETF would
>> not be doing stupid things, so the boundary may be a bit more murky.)
>>
>> Grüße, Carsten
>
> --
> ---
> [email protected]
>
> _______________________________________________
> OPSAWG mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/opsawg
>
> _______________________________________________
> OPSAWG mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/opsawg
>
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
