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 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
