Yepp, thats why i was suggesting independent submission in the first place as
the right way to go,
and let OPSAWG just help as mutually beneficial. And then take over with
extensions afterwards.
But then Warren threw rfc8017 into the room, and i have no idea what
the policies where to do that RFC. datatracker isn't very helpful to figure it
out.
And hence i brought up the question how to have similar constraints to what
seemingly
where applied for rfc8017. And what would then be the difference to independent
submission..
Cheers
Toerless
On Fri, Nov 13, 2020 at 08:55:50AM +1300, Brian E Carpenter wrote:
> On 12-Nov-20 23:24, tom petch wrote:
> > From: OPSAWG <opsawg-boun...@ietf.org> on behalf of Toerless Eckert
> > <t...@cs.fau.de>
> > 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 <t...@cs.fau.de> 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
> >
> > --
> > ---
> > t...@cs.fau.de
> >
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> >
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> >
--
---
t...@cs.fau.de
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
