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

Mykyta Yevstifeyev <evnikita2@gmail.com> Sat, 10 September 2011 04:44 UTC

Return-Path: <evnikita2@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DB021F8582 for <ietf@ietfa.amsl.com>; Fri, 9 Sep 2011 21:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.482
X-Spam-Level:
X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzdQTS0b9cni for <ietf@ietfa.amsl.com>; Fri, 9 Sep 2011 21:44:57 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id B887B21F8581 for <ietf@ietf.org>; Fri, 9 Sep 2011 21:44:56 -0700 (PDT)
Received: by fxe6 with SMTP id 6so3349366fxe.31 for <ietf@ietf.org>; Fri, 09 Sep 2011 21:46:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=2rt51WTdIrClPNcjRVgGBNhoAElu/nHvL2P9EI4z2AA=; b=Zs58oVT4g+Yb1sainLkzcqIgsY7Jue32KdmT20TqkF2+uPyg3BQAqtQROW6NtYPZBh kaaA3PDEaE8K7KMj5S7Wl+t6TzKc1r3KcAm2zDlKS1CuODX0DjN4hmkoQbACB4OD8oSJ VmZnDoIsYJrOAva/UDYkz7sr8LVjwjoHI7zEc=
Received: by 10.223.56.20 with SMTP id w20mr583018fag.117.1315630012672; Fri, 09 Sep 2011 21:46:52 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id n3sm3842435fae.25.2011.09.09.21.46.50 (version=SSLv3 cipher=OTHER); Fri, 09 Sep 2011 21:46:51 -0700 (PDT)
Message-ID: <4E6AEBDC.60002@gmail.com>
Date: Sat, 10 Sep 2011 07:47:24 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Conclusion of the last call on draft-housley-two-maturity-levels
References: <20110728121904.2D22AD7A76F@newdev.eecs.harvard.edu> <4E5D4570.9080108@piuha.net>
In-Reply-To: <4E5D4570.9080108@piuha.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Sep 2011 04:44:58 -0000

Taking into account the controversy we all are able to observe on the 
mailing list, I'd like to point out several points.

1) Did the IESG consider processing this as RFC 3933 process 
experiment?  (I actually don't know whether such approach has already 
been proposed during the discussions, and whether there has been some 
outcome, so, if this has already been proposed, just re-consider.)  I 
personally see no "consensus" or "rough consensus" for this document 
being approved as BCP, i. e., on the permanent basis, but as some people 
claimed that this might be useful, processing the document as 
Experimental process RFC will allow to make the final judgment based on 
the actual experience, not the assumptions.  As soon as we find out that 
two-tier maturity levels system works, the BCP will be simple to be 
written and published; if we reach the agreement that "this is a bad 
idea", then the proposed experimental change will be rescinded, and the 
maturity system will be returned to the 2026 model.

2) How do we make the consensus judgment (in this particular case)?  As 
IETF is based on "rough consensus" model, rough consensus may only be 
claimed if the consensus-qualifier (a WG chair or Sponsoring AD, in case 
of Individual Submission) reaches the inner conviction that the idea 
proposed in the document satisfies the community, or at least its 
predominant part.  Since IETF has no formal membership, the "community" 
size may not be determined precisely, and we take into account those 
folks who participate in the discussion (who, correspondingly, found 
themselves interested in the discussed topic and are assumed to be 
knowledgeable in it) in the WG, or elsewhere.  So now, when many of the 
most experienced and most knowledgeable members of our community claim 
that the proposed change is not a good idea, or is a bad idea, or there 
is no actual problem, or there is a problem but its proposed solution 
isn't fine and has some omissions, or there are a number of other 
problems which are also to be fixed, or something else, I actually have 
no idea how the consensus-qualifier (in our case, Sponsoring AD - Jari 
Arkko) may claim "consensus" or "rough consensus" for, at least, 
adopting it as BCP.  (I'm not following the thread closely, but this is 
what I see from those messages I eventually read.)

3) Do we actually need to make cosmetic changes to our process 
documentation?  RFC 2026 was published in 1996, and precisely 15 years 
have passed.  RFC 2026 is really morally obsolete, and, in presence of 
RFC 4844, that defines RFC submission streams, was to be revised closely 
after it was published.  I see a number of drafts proposing revisions of 
RFC 2026 at 
<https://datatracker.ietf.org/doc/search/?name=Internet+Standards+Process&rfcs=on&activeDrafts=on&oldDrafts=on>, 
but none of them were processed.

BTW, RFC 1310 was published in 1992, RFC 1602 - in 1994, and RFC 2026 - 
in 1996.  I don't believe something happened in 1996 which made the 
procedures unnecessary to be aligned with the current practice.  The 
only changes made were IPR documents, PS->DS reports reqs, and IESG 
procedures for review of Independent Submissions and IRTF stream 
submissions.

More precisely, don't we need to revise RFC 2026 rather than make 
separate changes to it?

Mykyta Yevstifeyev

30.08.2011 23:17, Jari Arkko 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.
>
> There were a number of smaller details raised in the discussion. But I 
> did not see an overwhelming consensus on any specific issue to make 
> changes. But I will ask Russ to take a look at the issue raised by 
> Scott, whether he wants to add an informative reference to RFC 5657.
>
> Another issue that I wanted to highlight is the question of what kinds 
> of discusses are desirable/acceptable for documents that move from PS 
> to IS. It is outside the scope of Russ' document, but generated 
> nevertheless some interest. The IESG has discussed this matter and 
> drafted some suggested guidelines. Look for a different thread on this 
> list, under "Discuss criteria for documents that advance on the 
> standards track". Feedback on the guidelines would be appreciated.
>
> Jari
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>