+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
