Re: text suggested by ADs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2005-04-30 at 11:12 -0700, Dave Crocker wrote:
> > > >  1. A Discuss may be asserted only when it pertains to a normative
> > > >  concern that involves the viability of the specification.
> >
> >  As a practical matter, the line between normative and informative is
> >  likely grey enough to make this suggestion unworkable...
> 
> interesting point.  first question, then, is why has the ietf been finding it 
> important to make the distinction between the two?

I can't speak for the IETF as a whole; for the most part, classification
as normative/informative is pretty obvious.  But, if a reviewer feels
strongly that something in a spec needs to be fixed, seems likely that
the reviewer will classify the issue as "normative".

> second question is how do we distinguish between Discuss items that really do 
> pertain to "it won't work" and "it's unacceptably deficient" concerns, versus 
> an AD's personal preferences and whims?

I suggest we depend on the IETF as a whole ... by publishing and
discussing the Discuss comments on a widely read mailing list.

> > > >  2. The AD raising the Discuss must post the details of their concern
> > > >  to the mailing list targeted to that specification and must provide
> > > >  clear direction as to how to cure the problem.  Failing the ability to
> > > >  provide the detail about how to fix the specification, the AD must
> > > >  engage in a dialogue that has the goal of specifying that detail.
> >
> >  I agree with the first clause; the concern must be explained and motivated
> >  in detail.  The WG - not the AD or the doc authors in isolation - should
> >  develop the solution.
> 
> This raises two issues.  One is that the focus of the suggestion is making 
> sure that an AD who asserts a late-stage veto is meaningfully obligated to 
> work constructively to remove it.

Agreed and such obligation (which is the usual case now) would be a good
thing.

>   The other is that working groups rarely develop solutions.  Participants or 
> small sub-groups develop solutions; working groups review and approve.

Good point.

> When a random participant raises a concern during specification development, 
> the working group can readily acknowledge the issue and add it to the 
> workload, or it can fail to gain traction.  In the former case, the working 
> group takes responsibility for finding the solution.  In the latter, the issue 
> is, effectively, turned back to the person with the concern.  It is up to them 
> to find some way to get the working group to embrace the concern; the usual 
> way to do this is to propose a solution, so that the working group has a more 
> solid sense of the topic.
> 
> Now we move to a late-stage AD veto.  The working group has put years of 
> effort in and lots of review.  Here comes an AD -- typically one who has not 
> been involved until this point -- blocking progress by stating some concern.
> 
> If the concern is obviously valid to everyone, then there is no issue.  
> Everyone goes wow, we sure are glad you caught that, and goes off to fix it.
> 
> The problem is when the AD's concern is not obviously valid, or at least not 
> obviously valid as a valid reason for blocking progress.
> 
> Today, there is almost no cost to the AD in these situations and, therefore, 
> no pressure on them to be reasonable and constructive to resolve it.

So, without meaning any offense to the ADs, I suggest we lump random
participants, WG members, doc editors and ADs together when the spec is
reviewed - and ensure that all comments are published in the same forum
and given appropriate weight based on technical merit, as supported by
explanatory text when the comments are published.

- Ralph

> 
> We need to change limits and incentives, to fix this.
> 
>  
> > > >  In order to deal with the issue of a pocket veto, whereby the AD is
> > > >  intractable but maintains the veto, there needs to be a mechanism to
> > > >  force review of the Discuss, either to assert that, indeed, it
> > > >  involves a valid showstopper (failure) of the specification or that it
> > > >  can be ignored.
> > > >
> > >  such a mechanism already exists.
> 
> If you are referring to a classic Appeal, then that is too heavyweight and 
> onerous.  The cost to the participant, of making an appeal, is significant.
> 
> If you are referring to something else, what is is and where is it documented?
> 
> 
> 
>  d/
>  ---
>  Dave Crocker
>  Brandenburg InternetWorking
>  +1.408.246.8253
>  dcrocker  a t ...
>  WE'VE MOVED to:  www.bbiw.net

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]