draft-sheffer-tls-pinning-ticket has been presented for publication as an Independent Submission Experimental RFC.
The document describes experimental extensions to TLS with opaque pinning tickets as a way to pin the server's identity across multiple sessions without requiring manual management actions.
The document was presented to the TLS WG at IETF-98 where a hum in the room indicated inadequate support to adopt the work (https://datatracker.ietf.org/doc/minutes-98-tls/). There was no record of comments about security issues or conflicts with other standards, just lack of energy to adopt the work in the WG. The responsible AD at the time declined to AD-sponsor the draft, so it was presented it at SecDispatch (IETF-100) and the discussion there resulted in the decision to take the draft to the ISE. (This history was checked briefly with Sean Turner and seems to be accurate.)
Reviews of the document were performed for the ISE by Jim Schaad and Yoav Nir and led to good discussions with the authors and a number of updates to the document.
Additionally, we worked through the fact that this is an Experimental document by adding Section 1.2 that describes the scope and objectives of the Experiment, and that sets out the authors' intentions to bring the work back to the IETF if the Experiment is a success.
The document makes a request for a code point allocation from the "TLS ExtensionType Values" registry (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml). The allocation policy for the registry is "Specification Required" and the ISE reviews of the document were performed by two of the three Designated Experts for the registry. It should be noted that there is no "Experimental" range in the registry and that "Specification Required" is consistent with an Experimental Independent Stream RFC. It appears to be the intention that the "Private Use" range can be used for experimentation, but the authors specifically request allocation from the regular range (so that transition to IETF work could be made possible in the future) setting the "recommended" indicator in the registry to "N" to show that this is not IETF consensus work.