Re: draft-housley-two-maturity-levels

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

 



If it is still possible to get code points issued on an Informational or Experimental RFC and the bar for those documents is not raised, I don't see the problem.


Original  ->  Current ->  2 step

Proposed -> Informational / Experimental ->Informational / Experimental
Draft -> Proposed -> Proposed 
Standard -> Draft -> Standard

Almost none of the STD documents would qualify for DRAFT status these days and some would not make Proposed without radical changes.

All we are talking about here really is acknowledging that what the IETF labels 'DRAFT' standard are in practice full standards.


As for what the IESG should do. Looking at the comments made on KEYPROV, there were some editing changes that really didn't take a great deal of time to process and there were some substantive issues that could not have been changed after the PROPOSED RFC issued.

If someone is suggesting use of a particular identifier space or consistency with another specification, those are changes I want to see made as soon as possible. I do not want to have a process where we can get to PROPOSED really quickly but then have to make major changes to advance to DRAFT because the IESG is giving the type of feedback that would have been useful in the previous iteration.

What I would suggest as a means of speeding up the process is for the IAB to get back into the business of doing architecture and write up a style book for some of the engineering choices. A lot of the discussions we had in KEYPROV recapitulated earlier discussions I have had in every XML based protocol I have worked on. In several cases there are four approaches, all of which have some drawback that I may or may not remember. Most really don't have a good answer and it would be as well just to pick one and move on rather than have the same conversation yet again.


On Tue, Oct 26, 2010 at 8:14 PM, Tony Hain <alh-ietf@xxxxxxxx> wrote:
I will let James speak to most of your points, but I did talk to him as he
exited that session, and he was very clear at that point this was the AD for
that WG not the chair, and there was no misunderstanding.

While I trust this is not an official policy, I look at that event as a
leading indicator for the general IESG 'we are here to protect the Internet'
attitude. We all know that most people stop at PS, because it is not worth
the effort to do anything more, particularly after the effort to get the
first step. That feeds the perception (if not the reality) of the need for
the first PS doc to be perfect. The IESG doesn't do itself any favors by
perpetuating the perception that the first step has to be perfect, and while
I know there have been personal efforts to minimize the blockage the IESG
presents, outside indicators show those have been insufficient. The core
issue is that IESG appears to believe its role is to protect the world,
rather than manage the process of document creation and drive toward some
degree of architectural consistency. Note: driving toward a goal does not
mean preventing progress until the goal has been achieved.

As I suggested in the earlier note, the IESG as a group should really step
back and only get involved in the step for full Internet Standard, where it
actually means that the IETF as a whole has considered this document as
representing a consensus standard, rather than agreeing at PS 'this is a
document we all intend to work on'. Doing that means the sponsoring AD has
to take on more of the role of verifying the WG is progressing toward the
architectural goal, and seeking out cross-Area review, but that approach
will allow incremental progress where the current approach does not.

Yes, the cost for the RFC Editor goes up when we relax the bottleneck the
IESG currently represents, but that is the price of progress. Also, the
external confusion about RFC vs. STD goes up as there are more PS docs, but
the counter to that is that if we can focus the IESG on getting documents
from PS to IS there will be a broader array of more relevant documents at IS
to reference.

Tony


> -----Original Message-----
> From: John Leslie [mailto:john@xxxxxxx]
> Sent: Tuesday, October 26, 2010 4:11 PM
> To: Tony Hain
> Cc: ietf@xxxxxxxx
> Subject: Re: draft-housley-two-maturity-levels
>
> Tony Hain <alh-ietf@xxxxxxxx> wrote:
> >
> > Did you miss James Polk's comment yesterday? The IESG is already
> changing
> > their ways!! They now require 2 independent implementations for a
> personal
> > I-D to become a WG draft.
>
>    Though I'd rather steer clear of this fray, I must question this.
>
>    I'm quite certain the IESG doesn't have such a blanket policy.
>
>    The reported incident _may_ be accurate, but such a requirement
> would have come from the WG Chair, not the responsible AD, least of
> all some other AD. I'd be very surprised if this incident turns out
> to be anything more than a WGC (who may _also_ be an AD) requiring
> implementation reports for a single I-D proposed for adoption.
>
>    I'd also be surprised if there doesn't turn out to be some
> mis-communication of what was requested and why.
>
>    We do, alas, sometimes misunderstand a policy statement and start
> voluntarily following it in cases where the actual policy wouldn't
> apply. That is IMHO a measurable part of why the path to PS takes so
> long. :^(
>
> --
> John Leslie <john@xxxxxxx>

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



--
Website: http://hallambaker.com/

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

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