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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
