Re: text suggested by ADs

I see that many points made _may_ lead to personal controversy (not the 
target). I hate rigidity and procedures but I love method. We may like it 
or not, but IETF is only subject to good practices as a guidance to 
imperfect members trying their best. Rules will not change that.
But we might accept some IETFiquette permitting to achieve more. I have 
always been impressed by RFC 1958 which actually defines the architecture 
of the Internet without any rule. I think it misses a model, the same as I 
think sometimes IETF misses method; but it seems to work.
I would suggest that instead of commenting at length on each others 
comments, those who have a suggestion makes it a short sentence and we make 
a list of it. Not as a rule, but as guidance. After a while, the ones which 
work would de facto become part of the Thao of the IETF.
I would suggest one:

"When a Charter is assigned or updated, the WG should review it until the 
AD are satisfied it has been understood, and the WG is satisfied the AD and 
the IESG have understood the enhancements proposed by the WG from its own 
members experience."
As discussed here AD and IESG may know better than the WG in some cases, or 
less in other cases. It is important that in both cases they first 
understand each other over the expected deliverables, rather than dispute 
at the end. IETFiquette should prevent any WG work before there is a 
consensus that such a common understanding has been reached. A Charter 
should not be "not up for debate" until the Chair and a part of the WH has 
complete their work on a predetermined proposition.
jfc

At 02:22 04/05/2005, Ralph Droms wrote:
> On Fri, 2005-04-29 at 12:19 -0400, Keith Moore wrote:
> > Let me also restate for clarity:
> >
> > > Let me restate for clarity - ADs aren't necessarily more technically
> > > astute than *all* the rest of us.  That is, we need to be careful that
> > > technical input from ADs isn't automatically assigned extra weight or
> > > control (veto power).
> >
> > There's no way to avoid that happening and still have quality control.
>
> Why is that?  If an AD has a compelling reason that a specification
> needs work, the AD should be able to make a convincing argument to the
> IETF as a whole.  Best way to do that is in an open conversation during
> the IETF last call.
>
> > > Which is why I suggest ADs provide technical input in open mailing lists
> > > during last calls, to make sure their technical input is on the same
> > > footing as everyone else's technical input.  I agree that the IESG's job
> > > is to ensure correctness, completeness, etc.  That feedback should be
> > > provided earlier, in an open forum.
> >
> > I agree that input should be provided as early as possible.  But some
> > kinds of feedback inherently follow Last Call,
>
> Such as?
>
> >  and limiting IESG input
> > to before Last Call would just serve to make the process even slower
> > than it already is (by requiring multiple IESG reviews rather than just
> > one),
>
> I disagree - suppose the gating function comes *before* the IETF last
> call: before a draft goes to IETF last call, the ADs all agree that they
> are prepared (have cycles, aren't travelling, etc.) to review and
> comment on the draft.
>
> My experience has been that the there can be an unbounded delay between
> the IETF last call and the IESG review.
>
> >  while lowering publication quality (by preventing IESG from
> > objecting to valid technical issues noticed after Last Call, and perhaps
> > discovered while considering Last Call input, but not directly related
> > to issues raised in Last Call).
> >
> > Keith
>
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf