At 11:09 AM 24-12-2024, Salz, Rich wrote:
> Version 1.2 of the proposed standard for the Transport Layer Security
> protocol was labelled as "Obsolete" [1] since Version 1.3 of the
> proposed standard was issued in 2018.
I do not understand the point you are trying to make.
The IETF community usually labels the previous version of a
"standard" as "Obsolete" when it publishes a revision of the
"standard". RFC 7230, for an example, labelled RFC 2616 as
"Obsolete". Some implementations, which were based upon the previous
version of the "standard", are still running out there. My web
browser has an automated updates feature. The vendor could decide to
support non-obsolete "standards" only and switch off TLS v1.2. In
theory, six years should be more than enough to get implementations
to support the latest "standard". The reality is a bit different.
I read the shepherd writeup. It is dated 4 July 2022. It is
somewhat odd that the writeup was written before version -00 of the
draft was available.
As one of the TLS experts, and in consultation with the other two, I
believe we all understand. IANA will not forward any request for
TLS 1.2 codepoints (other than the two exceptions) to the designated
experts for review.
There is the following on Page 17 of RFC 8477:
[IANA] "SHOULD direct all requests for registration to the review
mailing list"
"Criteria that SHOULD be applied by the designated experts ..."
"Within the review period, the designated experts will either approve
or deny the registration request, communicating this decision to the
review list and IANA. Denials SHOULD include an explanation and, if
applicable, suggestions as to how to make the request successful."
My reading of the above is that:
1. The service provider (IANA) sends all registration requests to the
experts.
2. The designated experts take a decision based the criteria which they
have been provided.
3. The designated experts explain why they denied a registration request.
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?
The intent is only to show a timetable. If there are no minutes or
recording, that doesn't matter. The slides show that a discussion
happened and that's the point the draft is making.
Let's assume that your draft were slides. In my opinion, this email
exchange would be the discussion. The practice, outside the
"standards process", is to have a record which is known as
"minutes". I took a quick look at the relevant process document just
in case. :-)
If this is really a concern then we can say "first discussion in the
IETF community"
I'll say okay to your suggestion.
I don't know, it's hard to get more current than *just last month* :)
:-)
As EKR said, you misunderstand the context. You would have to look
through the discussion about the "TLS 1.2 LTS" draft, where it is
more clearly evidenced that the WG wants *no changes* to TLS 1.2
other than how it is configured. Many people in that thread missed
that the extension point had already been assigned.
Even though I disagree with your points, I do appreciate the very
careful read you have to this draft.
I read the "1.2" draft. I noticed that the code point was already
assigned. I also noted the point which Eliot was trying to express
somewhere on this thread (word used loosely). From what I
understand, Independent Submissions provided a path for critiques and
discussions of alternatives to IETF protocols to be seen by the
communities out there. I don't think that this draft should close
that path. The TLS code point requests would still be under IETF policy.
Regards,
S. Moonesamy
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
