Hi -
On 2021-10-21 1:28 PM, Kenneth Vaughn wrote:
...
If I properly understand your suggestion, you are requesting that we
make the new document a stand-alone document and the group could
separately consider the retirement of RFC 6353 - perhaps on a separate
timeline.
...
That seems sensible to me. It might have the advantage of being
(potentially) less confusing during phased deployments, and I can
imagine situations in which management infrastructure might need
to support both - those transitions always seem to take longer than
anyone would like.
The other key question (which might impact the answer to the first) is
whether the change to the MIB is necessary or if we can convince IANA to
maintain the one-octet hash algorithm identifier such that we can have
confidence that there will always be a unique number that we can use.
That would solve most of our problems (but perhaps add to the workload
of IANA) as I think any changes to the MIB would become trivial. As a
result, the update document would become very short.
As I understand it, RFC 5246 already established an IANA-maintained
registry in section 12, saying:
TLS HashAlgorithm Registry: The registry has been initially
populated with the values described in Section 7.4.1.4.1. Future
values in the range 0-63 (decimal) inclusive are assigned via
Standards Action [RFC2434]. Values in the range 64-223 (decimal)
inclusive are assigned via Specification Required [RFC2434].
Values from 224-255 (decimal) inclusive are reserved for Private
Use [RFC2434].
The registry seems to still observe those constraints:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18
I *think* that provides exactly what you're asking for. If the
assignment hasn't already been made, your document could be, depending
on what the WG thinks of it, the Standards Action or "required
Specification" needed to make it happen through its own IANA
considerations section.
It sounds to me like it might be possible to just spell out the
new elements of (protocol) procedure, the two(?) OBJECT IDENTIFIERS
for these transport domains, the IANA considerations, and you'd be
pretty much done. But TLS in all its subtle glory isn't my thing;
if you haven't already done so, reach out to Wes Hardaker.
Randy
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
