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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf