RE: Conclusion of the last call on draft-housley-two-maturity-levels

At 04:29 PM 9/2/2011, Ross Callon wrote:
> In looking through this discussion, I see:
>
>  - People saying that moving from 3 steps to 2 steps is a small 
> step in the right direction, lets do it. Many people who have said 
> this (including I) have been silent for a while quite possibly 
> because they have gotten frustrated with the endless discussion.
I think there are many that have voiced their frustrations that this 
draft isn't addressing the more important issue (or issues) in their 
minds. I don't see a consensus on what that 1 issue is, but many 
(including I) have said it's the problem of such a high hurdle to get 
a draft to PS. Because this draft isn't addressing that problem, I'm 
frustrated with this draft - because - I don't know that if this 
draft were to RFC that the high hurdle for PSs is the next thing tackled.
OTOH, if the high hurdle for PSs were what we worked on initially, 
and solve it, then I'd probably be much more comfortable with this 
draft progressing (then having started to appreciate what this means 
as a second step where getting a draft to PS is the first step).
just my opinion

James


>  - People saying that there are other more important problems that 
> we should be focusing on. Therefore, rather than either making this 
> simple change or discussing other possible improvements in the 
> process, instead let's debate this simple step forever and never 
> get anything done.
>  - People saying that this step won't do anything.
>
> Two things that I don't seem to have picked up on: (i) Any consensus 
> that a 3 step process is better than a 2 step process; (ii) Any hint 
> of moving towards an agreement on other things that we might do to 
> improve the process.
> I think that we should go to a "two maturity level" process, be done 
> with this little step, and also enthusiastically encourage people to 
> write drafts that propose *other* changes to the process. Then at 
> least we can be debating something different 6 months from now than 
> we were debating last year.
> Ross
>
> -----Original Message-----
> From: ietf-bounces(_at_)ietf(_dot_)org [mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf 
> Of John C Klensin
> Sent: Friday, September 02, 2011 4:20 PM
> To: Jari Arkko
> Cc: ietf(_at_)ietf(_dot_)org
> Subject: Re: Conclusion of the last call on draft-housley-two-maturity-levels
>
>
>
> --On Tuesday, August 30, 2011 23:17 +0300 Jari Arkko
> <jari(_dot_)arkko(_at_)piuha(_dot_)net> wrote:
>
> > I have reviewed the discussion from the last call on this
> > document.
> >
> > My conclusion as the sponsoring AD is that we have consensus
> > to move forward. There was clearly a constituency who believed
> > this is a good (albeit small) step forward. A number of other
> > people did not care so much; did not believe there was either
> > harm or benefit. I also saw a couple of opposing opinions,
> > though some of them were more about a desire to do something
> > else than specific objections about this proposal. I will be
> > recommending that the IESG approve the draft.
>
> Jari,
>
> Like Scott, I wonder if there is some misunderstanding here.
> Part of the problem is the way that this draft was developed and
> the discussion has been handled, despite your heroic efforts.
> For example:
>
> (1) If someone says "we should be looking in this different
> direction instead", the response has been "irrelevant to
> consideration to this proposal, so it should go forward".  The
> irrelevancy is debatable, but that may be another issue.
>
> (2) If someone says "the proposal claims to solve problem X, but
> there is no evidence for that", the assertion about what
> problems are being solved is removed, but there is no
> substantive change to the draft.
>
> (3) If someone says "this solves no problem", the response has
> been that things have been broken for years and therefore this
> proposal should be approved.   (The difficulty with that logic
> should be clear.)  Sometimes that has been accompanied by a
> claim that it is the only proposal on the table and should
> therefore be adopted (even though that statement isn't true and,
> true or not, would never even be considered if we were
> considering a protocol specification).  One of the co-authors
> has recently argued for a very high standard of compelling
> necessity to make changes to important processes or related
> documents, but that criterion obviously does not apply to this
> document.
>
> (4) There have been a few arguments made that making this sort
> of change --without compelling justification and without
> evidence that it would accomplish anything-- would actually be
> harmful.  There has been no substantive response to those
> arguments.   In normal Last Calls, such comments are known as
> "unresolved issues" and the sponsoring AD does not move the
> document forward until they are addressed (or even dismissed) in
> some substantive way.
>
> (5) This is probably off-topic unless someone decides to appeal,
> but, to a certain extent, the processing of this document points
> out a far more significant problem with the handling of process
> change suggestions in the IETF.  The IESG holds a discussion.
> An IESG member prepares a draft.  An IESG member (the same one
> or a different one - it makes a difference, but not much)
> decides what other process change proposals can be considered
> (either at the same time or otherwise).  While the IESG would
> normally decide that anything that has produced this much
> controversy needs a Working Group to consider alternatives and
> get a real consensus determination, the IESG decides that no WG
> will be considered for this work (the claim that previous WGs
> addressed to process issues have been a problem --one with which
> I personally agree-- may not be relevant unless the IESG is
> ready to consider other review and mechanisms).   The IESG gets
> to pick and choose which arguments for and against the proposal
> "count" -- normal, but see (4) above and the many "solves no
> problem" comments.  And then the IESG decides to advance the
> document.
>
> (6) Unfortunately, although the document has improved
> significantly since -00 --by removing material for which there
> was little or no support and some question about relevance and
> by removing unsupportable claims-- the basic pattern outlined in
> (5) has been perceived as inevitable, i.e., that this
> AD-produced draft, produces in response to a discussion and
> conclusion already reached by the IESG, was going to go through
> because the IESG had prejudged the ultimate outcome before the
> draft was written.  Whether that perception is correct or not,
> it leads all but the most persistent members of the community to
> tune out and stop making comments, either early on or after
> several rounds.   I am not going to take a position about
> consensus among some silent majority because I simply don't know
> how those who are not speaking up feel, but I think the
> community should exercise caution about the possibility of
> consensus-by-exhaustion in any discussion that has dragged on as
> long as this document and its predecessors have been debated on
> the IETF list.
>
> regards,
>     john
>
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf