Re: [OPSAWG] draft-vaughn-tlstm-update-01 (TLSTM Update to support TLS 1.3)

[Randy Presuhn]

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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] draft-vaughn-tlstm-update-01 (TLSTM Update to support TLS 1.3)

[Kenneth Vaughn]

Randy,

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. If this is an accurate 
summary of your request, it is largely captured by our original draft 
(https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update/00/ 
). The only 
caveat is that version 00 did not include support for DTLS 1.3 because it had 
not been finalized when we wrote that draft. Once DTLS 1.3 was finalized, the 
number of changes became much smaller and the concept of doing an update seemed 
to make more sense, but it was still debated among our team members. We largely 
picked the update format just to show that either could be done. We are happy 
to follow the consensus of the group on this point. I think this is probably 
one of the two most important questions to answer (i.e., should we produce a 
stand-alone document or an update?)

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.

I would be very encouraged if we are able to gain consensus on those two topics 
by the end if IETF 112. 

Regards,
Ken Vaughn

Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
+1-936-647-1910
+1-571-331-5670 cell
kvau...@trevilon.com
www.trevilon.com

> On Oct 21, 2021, at 1:38 AM, Randy Presuhn 
>  wrote:
> 
> Hi -
> 
> On 2021-10-20 8:38 PM, Kenneth Vaughn wrote:
>> I would like to present 
>> https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update-01/ 
>> . This 
>> document is a proposal to update to RFC 6353 (TLS Transport Model for SNMP) 
>> to reflect the needs of TLS 1.3.
> 
> It seems to me that the document combines two distinct proposals:
>  (1) deprecating most of the MIB Module from RFC 6353
>  (2) defining a new transport model and putting its management
>  interface into the gutted shell left behind from 6353.
> 
> I think the document would be easier to digest if it were simply
> crafted to be solely what its title says it is: a Transport Layer Security 
> Verion 1.3 (TLS 1.3) Transport Model for SNMPv3.  Any
> question of casting support for (D)TLS 1.2 into the outer darkness
> of "historical" classification or deprecating 6353's MIB module's
> definitions could then be handled separately.
> 
> Randy
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Adoption Call for draft-tuexen-opsawg-pcapng-03

[Michael Richardson]

Carsten Bormann  wrote:
> While the original pcap format has held up very well over time, a more
> modern format is needed for some applications.  Pcapng is widely agreed
> to be that(*), and publishing a specification that has had input from
> the operational community is an important next step.  I support WG
> adoption of this draft.

> Grüße, Carsten

> (*) even if I would have preferred it to use CBOR — but CBOR would have
> had to be around much earlier to enable that choice.

There are a number ways in which I'd like to extend pcapng, and CBOR would
fit nicely them.


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Adoption Call for draft-gharris-opsawg-pcap-02

[Eliot Lear]

+1.

On 20.10.21 22:44, Carsten Bormann wrote:

On 2021-10-20, at 22:22, Henk Birkholz  wrote:

this email *extends* the ongoing call for Working Group Adoption on 
https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02 until 
*Sunday, October 24th*.

I believe WG time spent to get an authoritative description of this widely used 
format published as an RFC, with some of the original players being involved, 
is time spent very well.
I advocate adoption of this draft.

Grüße, Carsten

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg



OpenPGP_signature
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] draft-vaughn-tlstm-update-01 (TLSTM Update to support TLS 1.3)

[Randy Presuhn]

Hi -

On 2021-10-20 8:38 PM, Kenneth Vaughn wrote:
I would like to present 
https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update-01/ 
. This 
document is a proposal to update to RFC 6353 (TLS Transport Model for 
SNMP) to reflect the needs of TLS 1.3.


It seems to me that the document combines two distinct proposals:
  (1) deprecating most of the MIB Module from RFC 6353
  (2) defining a new transport model and putting its management
  interface into the gutted shell left behind from 6353.

I think the document would be easier to digest if it were simply
crafted to be solely what its title says it is: a Transport Layer 
Security Verion 1.3 (TLS 1.3) Transport Model for SNMPv3.  Any

question of casting support for (D)TLS 1.2 into the outer darkness
of "historical" classification or deprecating 6353's MIB module's
definitions could then be handled separately.

Randy

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg