If we were adopting the TLS 1.3 registry, that would be a possibility - but we
aren't. We are proposing to create a new registry that will parallel the
existing registry specifically for TLSTM (or at least specific to standards
that reference a range of TLS versions). As a result, we would not
Hi -
On 2022-03-02 8:03 AM, Joe Clarke (jclarke) wrote:
Yes, there are plans to add new additions. If there is a new, paralell
registry for the sole use of this SNMP transport, then there should not
be a chance for TLS implementors to be confused.
Admittedly, this isn't completely optimal,
Yes, there are plans to add new additions. If there is a new, paralell
registry for the sole use of this SNMP transport, then there should not
be a chance for TLS implementors to be confused.
Admittedly, this isn't completely optimal, but in light of other
options, which would involve larger MIB
Hi -
Wait... are there or are there not any plans for additions to the
registry? If there are no plans for additions, the argument about
confused TLS implementors seems hypothetical. If there are plans for
additions, is it envisioned that any of the existing algorithms will
eventually be in
Maybe "fear" is too string a word, but the sentiment was that it gave
mixed messages to start adding new values to that table (which they feel
is static at this point) and could lead to confusion with implementors.
Given that it seemed to me _this_ change in DESCRIPTION could be
considered
I agree, an update can be delayed until we actually need to add
support for additional hash algorithms. (And some of the concerns by
the TLS folks may disappear once the usage of TLS 1.2 further
declines.)
/js
On Mon, Feb 28, 2022 at 11:04:15AM -0800, Randy Presuhn wrote:
> Hi -
>
> On
Hi -
On 2022-02-28 10:45 AM, Jürgen Schönwälder wrote:
Randy,
I assume it is fear of all of that, whether this is justified or not
can be debated. Frankly, we used a protocol registry because it was
handy and we likely did not like a proliferation of registries. In
hindsight, we would have
Randy,
I assume it is fear of all of that, whether this is justified or not
can be debated. Frankly, we used a protocol registry because it was
handy and we likely did not like a proliferation of registries. In
hindsight, we would have been better off creating our own.
Does it make sense to
Hi -
On 2022-02-28 6:28 AM, Kenneth Vaughn wrote:
To OPSAWG, especially MIB doctors and SNMP-experts:
We have contacted the TLS community about potentially allowing for the
continued use and maintenance of the IANA TLS HashAlgorithm Registry
(RFC 5246) in the update to RFC 6353 so that we do
If we change the registry but none of the semantics of any existing
allocations (i.e., we make a deep copy initially), then I think this
is just fine regarding the updating rules (since nothing should of
this should affect on the wire interoperability).
We should be careful with the wording. The
To OPSAWG, especially MIB doctors and SNMP-experts:
We have contacted the TLS community about potentially allowing for the
continued use and maintenance of the IANA TLS HashAlgorithm Registry (RFC 5246)
in the update to RFC 6353 so that we do not have to redefine its fingerprint
algorithm. The
11 matches
Mail list logo