At Fri, 6 Mar 2009 13:59:04 -0800,
Kurt Zeilenga wrote:
On Mar 6, 2009, at 1:59 PM, Eric Rescorla wrote:
At Fri, 6 Mar 2009 11:34:19 -0800,
Kurt Zeilenga wrote:
I think if the IESG chooses not to publish draft-housley-tls-authz
now, the authors should immediately take it RFC Editor for
publication
and the IESG should not object to its timely publication. In this
case, the authors should not be asked to wait on a WG effort as they
have done well, I think, to try to publish this through the IETF. It
would be disingenuous for us to now delay independent publication of
this I-D via the RFC Editor.
This avenue is specifically precluded by RFC 5246: draft-housley-tls-
authz
contains new ExtensionType code points, and they can only be
assigned by IETF Consensus:
- TLS ExtensionType Registry: Future values are allocated via IETF
Consensus [RFC2434]. IANA has updated this registry to include
the signature_algorithms extension and its corresponding value
(see Section 7.4.1.4).
Obviously, the authors can publish a document without code point
assignments, but it's hard to see what the value of that is.
The IETF can hold a consensus call on the assignment of code points
(certainly this question has not been answered by any previous call).
I would hope folks would place a lessor hurdle upon assignment of code
points then they do for IETF RFC publication.
That's not what "IETF Consensus" means in the context of
RFC 2434:
IETF Consensus - New values are assigned through the IETF
consensus process. Specifically, new assignments are made via
RFCs approved by the IESG. Typically, the IESG will seek
input on prospective assignments from appropriate persons
(e.g., a relevant Working Group if one exists).
-Ekr
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf