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

[Christopher Wood <[e-mail]>]

+1

On Monday, April 23, 2018, David Benjamin <[e-mail]> wrote:

> +1
>
> On Mon, Apr 23, 2018 at 12:51 PM Eric Rescorla <[e-mail]> wrote:
>
>> +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
>>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>