> The IETF community usually labels the previous version of a > "standard" as "Obsolete" when it publishes a revision of the I apologize, I still do not understand what you want changed. Is this commentary on the way thigngs work, or is there something actionable? > I read the shepherd writeup. It is dated 4 July 2022. That is a cut/paste error. The *questionnaire* that Sean used to complete his writeup was last changed in 2022. > This draft proposes to introduce a step before (1) for the service > provider not to forward some registration requests which do not fit > the criteria being proposed. Will the service provider also be > making suggestions as to how to make the request successful? Almost every draft I have seen says, "IANA is requested" or "IANA will" or "IANA added..." Treating the IANA, and any Designated Experts, as a block box, a single entity. We are doing the same thing here. If there is consensus to change the words to say "IANA and the TLS Designated Experts..." we can do that, if the IESG says to do so. >If this is really a concern then we can say "first discussion in the >IETF community" > I'll say okay to your suggestion. Thanks. >. I don't think that this draft should close > that path. The TLS code point requests would still be under IETF policy. The point of this document is exactly that: to close off the path of any new extensions points (other than the two exceptions). You disagree with that, but it was the strong consensus of the WG that nothing else, and nobody else, be allowed to add things to TLS 1.2 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
