Re: Withdrawing sponsorship of draft-housley-tls-authz-extns

Robert Elz <kre@munnari.OZ.AU> Fri, 15 June 2007 13:15 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBdw-0000A6-F0; Fri, 15 Jun 2007 09:15:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBdu-0008Cv-8X; Fri, 15 Jun 2007 09:15:10 -0400
Received: from [202.12.74.196] (helo=jade.coe.psu.ac.th) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzBds-0000Yn-2r; Fri, 15 Jun 2007 09:15:09 -0400
Received: from delta.noi.kre.to (delta-194 [172.30.3.194]) by jade.coe.psu.ac.th with ESMTP id l5FDEj24013157; Fri, 15 Jun 2007 20:14:46 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.11/8.11.6) with ESMTP id l5FDEWld018548; Fri, 15 Jun 2007 20:14:35 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: Thomas Narten <narten@us.ibm.com>
In-Reply-To: <200706150008.l5F08EXt014583@cichlid.raleigh.ibm.com>
References: <200706150008.l5F08EXt014583@cichlid.raleigh.ibm.com> <tslveduxfp2.fsf@mit.edu> <B356D8F434D20B40A8CEDAEC305A1F24043F6B4D@esebe105.NOE.Nokia.com> <466E959D.80601@cisco.com> <466EA98D.9010401@dcrocker.net> <D2C66431AE5E7F688AB7DA5C@[192.168.0.3]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 15 Jun 2007 20:14:32 +0700
Message-ID: <20009.1181913272@munnari.OZ.AU>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: John C Klensin <john-ietf@jck.com>, mark.brown@redphonesecurity.com, ietf@ietf.org, iesg@ietf.org, dcrocker@bbiw.net
Subject: Re: Withdrawing sponsorship of draft-housley-tls-authz-extns
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

    Date:        Thu, 14 Jun 2007 17:08:13 -0700
    From:        Thomas Narten <narten@us.ibm.com>
    Message-ID:  <200706150008.l5F08EXt014583@cichlid.raleigh.ibm.com>

  | (Now would be an excellent time to
  | consider updates/clarifications to the above text.)

Aside from the minor problem that the paragraph you quoted is way more
wordy and chatty than is really needed, it gets the "should be" procedure
all wrong.

The IANA is the Internet Assigned Numbers AUTHORITY and should be treated
that way - allowing assignment requirements in specs to be ignored in cases
where they're obviously wrong is fine.   But is the IANA which (who) should
make the decision, not the IESG.

By all means, require the IANA to notify the IESG (or IETF) in advance,
and allow time for objections to an assignment (or for general input to
the IANA which may influence either the yes/no decision, or in some cases
the actual value assigned).  But the decision belongs to IANA, not the IESG
(just as the final decision whether to publish a RFC rests with the RFC
editor, and not the IESG).

There's a tendency, especially in procedures authored by IESG (or ex-IESG)
members for everything to be made the responsibility of the IESG.  That's
the wrong approach in most cases.

Under the same section heading you have now (5.3....) the text I would
include would be something like...

	Not withstanding any requirement in any document published before
	or after this specification, the IANA has the power to allocate
	a code point in any IANA maintained registry whenever it appears to
	the IANA that doing so is in the best interests of the Internet
	community.

	Before the IANA makes a registry entry in accordance with this
	procedure it shall advise the IESG (or the IETF as a whole) of
	the request for registration, and wait a period of not less than
	21 days to receive comments and advice from the Internet community
	before proceeding with the registration.

That's all that's needed (the "21 days" is just an arbitrary number, seems
long enough without being too long, but use whatever you prefer).

kre


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