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
