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

[David Benjamin <[e-mail]>]

+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
>