+1 On Mon, Apr 23, 2018 at 12:51 PM Eric Rescorla <e...@rtfm.com> wrote:
> +1 > > On Mon, Apr 23, 2018 at 9:33 AM, Sean Turner <s...@sn3rd.com> 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 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
