Re: [TLS] early code point assignment for draft-ietf-tls-certificate-compression

[Eric Rescorla <[e-mail]>]

+1

On Mon, Apr 23, 2018 at 9:33 AM, Sean Turner <[e-mail]> wrote:

> All,
>
> tl;dr: If you object to the following early code point assignments 1) add
> the compress_certificate in the TLS ExtensionType Registry and 2)
> compressed_certificate in the TLS HandshakeType Registry, then please let
> the list know why by 2359UTC on 10 May 2018.  The Certificate Compression
> Algorithm IDs will be populated with two values: zlib and brotli.
>
> At IETF101, we discussed beginning the process of getting an early code
> point assignment for the extension defined in draft-ietf-tls-certificate-compression.
> The one technical comments raised at the meeting was extending the
> compression code point space from 1 byte to 2 might be a good idea.  The
> authors have merged a PR to address this in the gh repo and once they
> submit a new version of the draft the process for an early code point
> assignment will begin.  The rules for this are specified in RFC7120, and
> the four criteria for a draft to be eligible for early code point
> assignment are:
>
> Criteria A
>
>        The code points must be from a space designated as "RFC
>        Required", "IETF Review", or "Standards Action".  Additionally,
>        requests for early assignment of code points from a
>        "Specification Required" registry are allowed if the
>        specification will be published as an RFC.
>
> The Transport Layer Security (TLS) Extensions and TLS HandshakeType
> Registry registries are both RFC Required.  While we’re changing that
> registry’s rules with draft-ietf-tls-iana-registry-updates, there’s still
> every intention to publish draft-ietf-tls-certificate-compression as an
> RFC so we’re still good to go.
>
> Criteria B
>
>        The format, semantics, processing, and other rules related to
>        handling the protocol entities defined by the code points
>        (henceforth called "specifications") must be adequately described
>        in an Internet-Draft.
>
> When asked at IETF101 what other outstanding comments there were on the
> draft the only one identified was increasing the code point size for the
> compression algorithms.  Version -05 will address this point.
>
> Criteria C
>
>        The specifications of these code points must be stable; i.e., if
>        there is a change, implementations based on the earlier and later
>        specifications must be seamlessly interoperable.
>
> At IETF101, it was noted that this specification was stable enough.
> Implementation issues might be identifier later, but, well, that’s the
> point.
>
> Criteria D
>
>        The Working Group chairs and Area Directors (ADs) judge that
>        there is sufficient interest in the community for early (pre-RFC)
>        implementation and deployment, or that failure to make an early
>        allocation might lead to contention for the code point in the
>        field.
>
> 5 WG participants all from different organizations indicated their
> interest in implementing this draft (even if it was just for
> experimentation).
>
>
> There are also 6 steps identified in RFC 7120 for early assignment, but
> only four involve the chairs:
>
>   1.  The authors (editors) of the document submit a request for early
>        allocation to the Working Group chairs, specifying which code
>        points require early allocation and to which document they should
>        be assigned.
>
> An in-person request was made at IETF 101 for the early code point
> assignments.  There was also an earlier on-list request.
>
>    2.  The WG chairs determine whether the conditions for early
>        allocations described in Section 2 are met, particularly
>        conditions (c) and (d).
>
> The chairs agree that the four conditions have been met.
>
>    3.  The WG chairs gauge whether there is consensus within the WG that
>        early allocation is appropriate for the given document.
>
> The sense of the room at IETF 101 was that yes early allocation is
> appropriate, but this email is verifying that.
>
>    4.  If steps 2) and 3) are satisfied, the WG chairs request approval
>        from the Area Director(s).  The Area Director(s) may apply
>        judgement to the request, especially if there is a risk of
>        registry depletion.
>
> Once the chairs have determined WG consensus, we’ll pass it to Ben.
>
> spt
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>