+1 On Monday, April 23, 2018, David Benjamin <[email protected]> wrote:
> +1 > > On Mon, Apr 23, 2018 at 12:51 PM Eric Rescorla <[email protected]> wrote: > >> +1 >> >> On Mon, Apr 23, 2018 at 9:33 AM, Sean Turner <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> _______________________________________________ >> TLS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls >> >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
