Re: [OPSAWG] [Technical Errata Reported] RFC5343 (7645)

[Jürgen Schönwälder]

You have to make sure that the right people and WG receive the
erratum, RFC 5340 belongs to the OSPF WG.

/js

On Mon, Sep 18, 2023 at 04:32:02PM -0700, Chris Smiley wrote:
> 
> Greetings,
> 
> This errata reports a problem with Section A.3.3/RFC 5343.  It has been 
> corrected to Section A.3.3/RFC 5340
> 
> Please let us know any concerns. 
> 
> Thank you.
> 
> RFC Editor/cs
> 
> 
> > On Sep 17, 2023, at 10:49 PM, RFC Errata System  
> > wrote:
> > 
> > The following errata report has been submitted for RFC5343,
> > "Simple Network Management Protocol (SNMP) Context EngineID Discovery".
> > 
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid7645
> > 
> > --
> > Type: Technical
> > Reported by: Owen DeLong 
> > 
> > Section: A.3.3
> > 
> > Original Text
> > -
> > Section A.3.3 (in part) reads:
> > 
> > Interface MTU
> >  The size in bytes of the largest IPv6 datagram that can be sent
> >  out the associated interface without fragmentation.  The MTUs of
> >  common Internet link types can be found in Table 7-1 of [MTUDISC].
> >  Interface MTU should be set to 0 in Database Description packets
> >  sent over virtual links.
> > 
> > 
> > Corrected Text
> > --
> > Interface MTU
> >  The size in bytes of the largest IPv6 datagram that can be sent
> >  out the associated interface without fragmentation.  The MTUs of
> >  common Internet link types can be found in Table 7-1 of [MTUDISC].
> >  Interface MTU should be set to 0 in Database Description packets
> >  sent over OSPF virtual links. This rule should not be applied to tunnel
> >  or other software interfaces.
> > 
> > 
> > Notes
> > -
> > OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed 
> > and this provision makes sense. For interfaces that have an actual MTU, 
> > even though they may be "virtual" interfaces, they are not "virtual links" 
> > in the intended meaning of this paragraph. As such, this change will 
> > provide clarification and remove ambiguity from the current standard. At 
> > least one popular router vendor implements this RFC as MTU = 0 sent on all 
> > GRE interfaces which results in incompatibilities with most other router 
> > platforms which expect an actual value. The router vendor points to this 
> > provision in the RFCs as justification for their implementation. It is 
> > (arguably) a legitimate, if nonsensical interpretation of the existing text.
> > 
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party  
> > can log in to change the status and edit the report, if necessary. 
> > 
> > --
> > RFC5343 (draft-ietf-opsawg-snmp-engineid-discovery-03)
> > ------
> > Title   : Simple Network Management Protocol (SNMP) Context 
> > EngineID Discovery
> > Publication Date: September 2008
> > Author(s)   : J. Schoenwaelder
> > Category: PROPOSED STANDARD
> > Source  : Operations and Management Area Working Group
> > Area: Operations and Management
> > Stream  : IETF
> > Verifying Party : IESG
> > 
> 

-- 
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://constructor.university/>

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

Re: [OPSAWG] [Technical Errata Reported] RFC5343 (7645)

[Jürgen Schönwälder]

This erratum should be rejected since the text does not appear in RFC
5343. It seems the text is found in 5340, 'OSPF for IPv6', and this is
a typo when the erratum was entered.

/js

On Sun, Sep 17, 2023 at 10:49:29PM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC5343,
> "Simple Network Management Protocol (SNMP) Context EngineID Discovery".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7645
> 
> --
> Type: Technical
> Reported by: Owen DeLong 
> 
> Section: A.3.3
> 
> Original Text
> -
> Section A.3.3 (in part) reads:
> 
>  Interface MTU
>   The size in bytes of the largest IPv6 datagram that can be sent
>   out the associated interface without fragmentation.  The MTUs of
>   common Internet link types can be found in Table 7-1 of [MTUDISC].
>   Interface MTU should be set to 0 in Database Description packets
>   sent over virtual links.
> 
> 
> Corrected Text
> --
>  Interface MTU
>   The size in bytes of the largest IPv6 datagram that can be sent
>   out the associated interface without fragmentation.  The MTUs of
>   common Internet link types can be found in Table 7-1 of [MTUDISC].
>   Interface MTU should be set to 0 in Database Description packets
>   sent over OSPF virtual links. This rule should not be applied to tunnel
>   or other software interfaces.
> 
> 
> Notes
> -
> OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed 
> and this provision makes sense. For interfaces that have an actual MTU, even 
> though they may be "virtual" interfaces, they are not "virtual links" in the 
> intended meaning of this paragraph. As such, this change will provide 
> clarification and remove ambiguity from the current standard. At least one 
> popular router vendor implements this RFC as MTU = 0 sent on all GRE 
> interfaces which results in incompatibilities with most other router 
> platforms which expect an actual value. The router vendor points to this 
> provision in the RFCs as justification for their implementation. It is 
> (arguably) a legitimate, if nonsensical interpretation of the existing text.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC5343 (draft-ietf-opsawg-snmp-engineid-discovery-03)
> --
> Title   : Simple Network Management Protocol (SNMP) Context 
> EngineID Discovery
> Publication Date: September 2008
> Author(s)   : J. Schoenwaelder
> Category: PROPOSED STANDARD
> Source  : Operations and Management Area Working Group
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG

-- 
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://constructor.university/>

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

Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-tlstm-update-12: (with COMMENT)

[Jürgen Schönwälder]

It may help to point out that the MIB module is mostly unchanged,
nothing in the design or structure of the MIB module did change
as far as I know.

/js

On Tue, Feb 28, 2023 at 02:39:47PM +, Joe Clarke (jclarke) wrote:
> Thanks for the review, Eric (and Lars).
> 
> There was no formal MIB Doctor review, but we did receive comments from 
> Jürgen and Randy, who are members of MIB Doctors (I believe), during the 
> progress of this draft.  Those comments were helpful in deciding on the 
> language changes within the MIB object descriptions, as well as fixing some 
> syntax errors.
> 
> https://mailarchive.ietf.org/arch/search/?q=tlstm_list=opsawg_from=J%C3%BCrgen%20Sch%C3%B6nw%C3%A4lder
> 
> https://mailarchive.ietf.org/arch/search/?q=tlstm_list=opsawg_from=Randy%20Presuhn
> 
> I know they weren’t reviewing in the formal MIB Doctors sense.  If the IESG 
> feels a more formal MIB Doctor review is needed, we can ask for it.
> 
> Joe
> 
> From: Éric Vyncke via Datatracker 
> Date: Tuesday, February 28, 2023 at 08:32
> To: The IESG 
> Cc: draft-ietf-opsawg-tlstm-upd...@ietf.org 
> , opsawg-cha...@ietf.org 
> , opsawg@ietf.org , Joe Clarke 
> (jclarke) , Joe Clarke (jclarke) 
> Subject: Éric Vyncke's No Objection on draft-ietf-opsawg-tlstm-update-12: 
> (with COMMENT)
> Éric Vyncke has entered the following ballot position for
> draft-ietf-opsawg-tlstm-update-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-tlstm-update/
> 
> 
> 
> --
> COMMENT:
> --
> 
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-tlstm-update-12
> CC @evyncke
> 
> Thank you for the work put into this document.
> 
> Please find below some non-blocking COMMENT points.
> 
> Special thanks to Joe Clarke for the shepherd's detailed write-up including 
> the
> WG consensus **and** the justification of the intended status.
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> ## COMMENTS
> 
> ### MIB Doctor review
> 
> Like Lars, I wonder whether there was a MIB doctor review.
> 
> ### Section 3.1
> 
> This text is repeated, is it on purpose ?
> ```
> The reason 0-RTT is disallowed is that there are no "safe" messages that if
> replayed will be guaranteed to cause no harm at a server side: all incoming
> notification or command responses are meant to be acted upon only once. See
> Security considerations section for further details ```
> 
> ## Notes
> 
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
> 
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> 
> 

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


-- 
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

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

Re: [OPSAWG] [Editorial Errata Reported] RFC7666 (7258)

[Jürgen Schönwälder]

Indeed.

The more important action though would be to tell IANA...

/js

On Thu, Dec 01, 2022 at 04:01:30PM -0800, Randy Presuhn wrote:
> Hi -
> 
> There *is* an issue - the first two possible values spelled out
> in the DESCRIPTION clause do not match the enumerated SYNTAX
> values' labels.
> 
> Randy
> 
> On 2022-12-01 1:46 PM, Chris Smiley wrote:
> > 
> > Greetings,
> > 
> > FYI - this report has been deleted as junk.
> > 
> > Thank you.
> > 
> > RFC Editor/cs
> > 
> > > On Nov 30, 2022, at 6:26 PM, RFC Errata System 
> > >  wrote:
> > > 
> > > The following errata report has been submitted for RFC7666,
> > > "Management Information Base for Virtual Machines Controlled by a 
> > > Hypervisor".
> > > 
> > > --
> > > You may review the report below and at:
> > > https://www.rfc-editor.org/errata/eid7258
> > > 
> > > --
> > > Type: Editorial
> > > Reported by: Dana Renee Hopkins 
> > > 
> > > Section: 3233702267
> > > 
> > > Original Text
> > > -
> > > Search RFCs
> > > number, title, keyword, or author surname
> > > Advanced Search
> > > RFC Editor
> > > RFC Errata
> > > RFC 7666, "Management Information Base for Virtual Machines Controlled by 
> > > a Hypervisor", October 2015
> > > Source of RFC: opsawg (ops)
> > > Found 1 record.
> > > 
> > > Errata ID: 4710
> > > Status: Verified
> > > Type: Editorial
> > > Publication Format(s) : TEXT
> > > Reported By: jean-marie Kubek
> > > Date Reported: 2016-06-15
> > > Verifier Name: Benoit Claise
> > > Date Verified: 2016-06-17
> > > Section 6.2 IANA MIB says:
> > > 
> > > IANAStorageMediaType ::= TEXTUAL-CONVENTION
> > >STATUS   current
> > >DESCRIPTION
> > >"The media type of a storage device:
> > > 
> > >unknown(1) The media type is unknown, e.g., because
> > >   the implementation failed to obtain the
> > >   media type from the hypervisor.
> > > 
> > >other(2)   The media type is other than those
> > >   defined in this conversion.
> > > It should say:
> > > 
> > > IANAStorageMediaType ::= TEXTUAL-CONVENTION
> > >STATUS   current
> > >DESCRIPTION
> > >"The media type of a storage device:
> > > 
> > >  other(1)   The media type is other than those
> > > defined in this conversion.
> > > 
> > >  unknown(2) The media type is unknown, e.g., because
> > > the implementation failed to obtain the
> > > media type from the hypervisor.
> > > 
> > > Notes:
> > > 
> > > Inversion of other and unknown integer values in the description of the 
> > > IANAStorageMediaType TEXTUAL-CONVENTION.
> > > 
> > > FIrst referenced at IANA RT as [IANA #913286] Incoherency in 
> > > IANA-STORAGE-MEDIA-TYPE-MIB
> > > 
> > > Search for errata for other RFCs.
> > > 
> > > Report New Errata
> > > 
> > > 
> > > 
> > > IAB • IANA • IETF • IRTF • ISE • ISOC • IETF Trust
> > > Reports • Privacy Statement • Site Map • Contact Us
> > > 
> > > 
> > > Document Retrieval
> > > Errata
> > > Frequently Asked Questions
> > > Future Format FAQ
> > > History
> > > About Us
> > > Other Information
> > > Publication Process
> > > Publication Queue
> > > Style Guide
> > > Advanced Search
> > > number, title, keyword, or author surname
> > > 
> > > 
> > > Corrected Text
> > > --
> > > Enclosure
> > > 
> > > Notes
> > > -
> > > It's not the right document
> > > 
> > > Instructions:
> > > -
> > > This erratum is currently posted as "Reported". If necessary, please
> > > use "Reply All" to discuss whether it should be verified or
> > > rejected. W

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-03.txt

[Jürgen Schönwälder]

We made the mistake by simply reusing the TLS hash algorithm for a
different purpose. We now factor things out by having a separate
registry for the hashing algorithms used to create certficate
fingerprints. But why would we now tie this back to TLS hashing
algorithms? In modern TLS, I think they only register entire
ciphersuites, do we really expect them to go an register any new hash
algorithm that comes along into the registry of hash algorithms for
producing certificate fingerprints?

I understand the "we are too lazy to do this" argument but then still
I would expect that if a new hash is being implemented for certificate
fingerprinting, someone would find the energy to register it.

/js

On Thu, May 05, 2022 at 11:15:46AM -0500, Kenneth Vaughn wrote:
> > There is no definition of TLSTMv1.3 nor do we version MIB modules
> Agreed, This is old text that I missed from when this was intended to be a 
> replacement to RFC 6353 rather than an update. I think it is best to just 
> delete the sentence so the paragraph would now read "[RFC6353] stated that 
> TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0. [RFC8996] 
> prohibits the use of (D)TLS versions prior to version 1.2." While the 
> statement is not technically required as it is stated elsewhere, I believe 
> there was a comment during IETF 113 that we should be explicit about this.
> 
> > In addition, a new entry
> >   MUST be added to the SNMP-TLSTM HashAlgorithm Registry every time a
> >   new hash algorithm is approved for any version of TLS or DTLS.
> I guess there are two issues here: 1) What do we want and 2) What wording is 
> used for IANA instructions
> 
> In the first case, while I accept that there is not a strict technical 
> requirement to implement every hash algorithm adopted by TLS, I am hard 
> pressed to think of why we would ever not want to support one (or what 
> practical harm it would cause). If we don't make the cross-assignment 
> automatic, it seems as if it would be incumbent upon the WG to explicitly 
> make requests every time a new hash algorithm came along. That seems to be 
> extra bureaucratic work for OPSAWG and it seems as if it would be easier to 
> make it a part of the IANA process. So the proposal is that it should be 
> automatic (which is in agreement with a comment made at the IETF 113 meeting)
> 
> If we agree that it should be automatic, then the second issue is how do we 
> state this. I am happy to revise the wording as appropriate; I certainly am 
> not an expert in writing those statements. 
> 
> If we don't want it to be automatic, then perhaps we need to reach consensus 
> on how new entries will be added.
> 
> 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 May 5, 2022, at 10:32 AM, Jürgen Schönwälder 
> >  wrote:
> > 
> > Before I go and check the details...
> > 
> >   [...] TLSTMv1.3 MUST only be used with
> >   (D)TLS version 1.2 and later.
> > 
> > What does this MUST tell me? There is no definition of TLSTMv1.3 nor
> > do we version MIB modules. I understand the intention of the statement
> > but we need to be more careful about the wording.
> > 
> > And what about this:
> > 
> >   [...] In addition, a new entry
> >   MUST be added to the SNMP-TLSTM HashAlgorithm Registry every time a
> >   new hash algorithm is approved for any version of TLS or DTLS.
> > 
> > Why would that be a MUST? The SnmpTLSFingerprint is used by the MIB
> > module to hash certificates and as such this hashing has nothing to do
> > with any TLS internal use of hash algorithms. The reuse of the TLS
> > hash registry back then was a matter of convenience, not a matter of
> > having a strong binding to the TLS internal usage of hash algorithms.
> > 
> > /js
> > 
> > On Thu, May 05, 2022 at 10:09:45AM -0500, Kenneth Vaughn wrote:
> >> I have uploaded a new version of the "Updates to the TLS Transport Model 
> >> for SNMP". This version includes the following changes:
> >> Changed the name of the registry to the SNMP-TLSTM registry
> >> Updated reference to DTLS 1.3 to reflect the publication of RFC 9147
> >> Clarified the first paragraph of Conventions to indicate that references 
> >> to TLS, DTLS, (D)TLS, and TLSTM are version neutral except where specific 
> >> versions need to be cited.
> >> Changed "SNMPv3" to "SNMP" in several locations where the specific version 
> >> reference was unnecessary with our convention statement
> >&g

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-03.txt

[Jürgen Schönwälder]

Before I go and check the details...

   [...] TLSTMv1.3 MUST only be used with
   (D)TLS version 1.2 and later.

What does this MUST tell me? There is no definition of TLSTMv1.3 nor
do we version MIB modules. I understand the intention of the statement
but we need to be more careful about the wording.

And what about this:

   [...] In addition, a new entry
   MUST be added to the SNMP-TLSTM HashAlgorithm Registry every time a
   new hash algorithm is approved for any version of TLS or DTLS.

Why would that be a MUST? The SnmpTLSFingerprint is used by the MIB
module to hash certificates and as such this hashing has nothing to do
with any TLS internal use of hash algorithms. The reuse of the TLS
hash registry back then was a matter of convenience, not a matter of
having a strong binding to the TLS internal usage of hash algorithms.

/js

On Thu, May 05, 2022 at 10:09:45AM -0500, Kenneth Vaughn wrote:
> I have uploaded a new version of the "Updates to the TLS Transport Model for 
> SNMP". This version includes the following changes:
> Changed the name of the registry to the SNMP-TLSTM registry
> Updated reference to DTLS 1.3 to reflect the publication of RFC 9147
> Clarified the first paragraph of Conventions to indicate that references to 
> TLS, DTLS, (D)TLS, and TLSTM are version neutral except where specific 
> versions need to be cited.
> Changed "SNMPv3" to "SNMP" in several locations where the specific version 
> reference was unnecessary with our convention statement
> Indicated that Additional Rules for TLS 1.3 "may additionally apply to future 
> versions of TLS" 
> The document has been through several review cycles and has also been vetted 
> by the TLS WG. At this point, changes are primarily editorial and I believe 
> it is stable enough to proceed to the next step of the approval process.
> 
> 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 May 5, 2022, at 10:07 AM, internet-dra...@ietf.org wrote:
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > This draft is a work item of the Operations and Management Area Working 
> > Group WG of the IETF.
> > 
> >Title   : Updates to the TLS Transport Model for SNMP
> >Author  : Kenneth Vaughn
> > Filename: draft-ietf-opsawg-tlstm-update-03.txt
> > Pages   : 30
> > Date: 2022-05-05
> > 
> > Abstract:
> >   This document updates the TLS Transport Model (TLSTM), as defined in
> >   RFC 6353, to reflect changes necessary to support Transport Layer
> >   Security Version 1.3 (TLS 1.3) and Datagram Transport Layer Security
> >   Version 1.3 (DTLS 1.3), which are jointly known as "(D)TLS 1.3".
> >   This document is compatible with (D)TLS 1.2 and is intended to be
> >   compatible with future versions of SNMP and (D)TLS.
> > 
> >   This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353.
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-opsawg-tlstm-update/
> > 
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-03.html
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tlstm-update-03
> > 
> > 
> > Internet-Drafts are also available by rsync at 
> > rsync.ietf.org::internet-drafts
> > 
> > 
> > ___
> > 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


-- 
Jürgen Schönwälder  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

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

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

[Jürgen Schönwälder]

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 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 been better off creating our own.
> 
> Perhaps, though that would have brought its own coordination problems.
> 
> > Does it make sense to republish an entire MIB module to just change
> > the registry location? Ideally this would not be required and we would
> > simply publish a document updating RFC 6353 and defining the new
> > registry (and even more so given that no registry content change is
> > envisioned).
> 
> I agree with your analysis that, while a bit of a stretch, an update
> to the DESCRIPTION seems like the right thing to do to placate the
> TLS folks, since it would not affect the bits on the wire nor, as far
> as I can see, what implementations do internally.  My questions were
> based in my skepticism with regard to to the stance that *any* MIB
> module changes would really be technically (rather than politically)
> necessary.
> 
> Randy
> 
> > /js
> > 
> > On Mon, Feb 28, 2022 at 10:24:53AM -0800, Randy Presuhn wrote:
> > > 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 not have to redefine
> > > > its fingerprint algorithm. The TLS community expressed a valid concern
> > > > that if the registry is maintained by adding new values, it would imply
> > > > that those new values could be used within TLS 1.2; thus our proposal to
> > > > continue to reference the existing table was not accepted.
> > > 
> > > I don't understand the fear here.  Are they worried that:
> > > 
> > > - someone would misconstrue additions to the IANA TLS HashAlgorithm
> > >   Registry as somehow *requiring* TLS 1.2 implementations to be
> > >   updated, even though they've been "designated obsolete"?
> > > 
> > > - that despite TLS 1.2 having been "designated obsolete", folks
> > >   maintaining those implementations would take it upon themselves
> > >   to add support for later additions to the IANA TLS HashAlgorithm
> > >   Registry?
> > > 
> > > - that there might be a proliferation of TLS 1.2 deployments that
> > >   attempt to use the additions to the IANA TLS HashAlgorithm
> > >   Registry, despite TLS 1.2 having been "designated obsolete"?
> > > 
> > > - that the possibility of adding these algorithms might somehow
> > >   prolong the lifetime of existing TLS 1.2 deployments or even
> > >   lead to new ones, despite it having been "designated obsolete"?
> > > 
> > > - something else?
> > > 
> > > 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

-- 
Jürgen Schönwälder  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

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

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

[Jürgen Schönwälder]

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 republish an entire MIB module to just change
the registry location? Ideally this would not be required and we would
simply publish a document updating RFC 6353 and defining the new
registry (and even more so given that no registry content change is
envisioned).

/js

On Mon, Feb 28, 2022 at 10:24:53AM -0800, Randy Presuhn wrote:
> 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 not have to redefine
> > its fingerprint algorithm. The TLS community expressed a valid concern
> > that if the registry is maintained by adding new values, it would imply
> > that those new values could be used within TLS 1.2; thus our proposal to
> > continue to reference the existing table was not accepted.
> 
> I don't understand the fear here.  Are they worried that:
> 
>- someone would misconstrue additions to the IANA TLS HashAlgorithm
>  Registry as somehow *requiring* TLS 1.2 implementations to be
>  updated, even though they've been "designated obsolete"?
> 
>- that despite TLS 1.2 having been "designated obsolete", folks
>  maintaining those implementations would take it upon themselves
>  to add support for later additions to the IANA TLS HashAlgorithm
>  Registry?
> 
>- that there might be a proliferation of TLS 1.2 deployments that
>  attempt to use the additions to the IANA TLS HashAlgorithm
>  Registry, despite TLS 1.2 having been "designated obsolete"?
> 
>- that the possibility of adding these algorithms might somehow
>  prolong the lifetime of existing TLS 1.2 deployments or even
>  lead to new ones, despite it having been "designated obsolete"?
> 
>- something else?
> 
> Randy
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

-- 
Jürgen Schönwälder  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

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

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

[Jürgen Schönwälder]

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 hash algorithm is used for
calculating a fingerprint of some data, it is not really tied to the
mechanisms of specific security protocols (or specific versions of
security protocols).

My personal observation is that sharing IANA registries has proven to
be complicated and it may thus be best to create a rather specific
registry for exactly this use case. Yes, this may require to have
multiple registrations if new hash algorithms come along (rare) but it
avoids problems of (unwanted) side effects if registries are used in
multiple different contexts.

/js

On Mon, Feb 28, 2022 at 08:28:21AM -0600, 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 not have to redefine its 
> fingerprint algorithm. The TLS community expressed a valid concern that if 
> the registry is maintained by adding new values, it would imply that those 
> new values could be used within TLS 1.2; thus our proposal to continue to 
> reference the existing table was not accepted. 
> 
> We now have two potential options as follows:
> 1. Deprecate and replace the existing fingerprint algorithm with a new one. 
> The fingerprint algorithm is used in the index of most of the tables within 
> the RFC 6353 MIB; as a result, deprecating the fingerprint algorithm requires 
> deprecating the assocaited tables; in practice, this results in redefining 
> the entire MIB in RFC 6353.
> 
> 2. Revise the DESCRIPTION clause of SnmpTLSFingerprint to refer to a new, 
> parallel HashAlgorithm Registry. Specifically, we would replace the second 
> paragraph of its DESCRIPTION clause, which currently reads: 
> 
> > An SnmpTLSFingerprint value is composed of a 1-octet hashing algorithm 
> > identifier followed by the fingerprint value.  The octet value encoded is 
> > taken from the IANA TLS HashAlgorithm Registry (RFC 5246).  The remaining 
> > octets are filled using the results of the hashing algorithm.
> 
>
> To something like the following:
> 
> > An SnmpTLSFingerprint value is composed of a 1-octet hashing algorithm 
> > identifier followed by the fingerprint value.  The octet value encoded is 
> > based on the IANA TLS HashAlgorithm Registry (RFC 5246), However, this 
> > registry is only applicable to (D)TLS protocol versions prior to 1.3, which 
> > are now designated as "obsolete" and are not expected to ever support 
> > additional values. To allow the fingerprint algorithm to support additional 
> > hashing algorithms that might be used by later versions of (D)TLS, the 
> > octet value encoded is taken from IANA SnmpTLSFingerprintAlgorithm 
> > Registry, The initial values within this registry are identical to the 
> > values in the TLS HashAlgorithm registry but can be extended to support new 
> > hashing algorithms as needed.
> 
> 
> While option 2 greatly simplifies the update, the question is whether this 
> can be considered a valid revision to the MIB. Per RFC 2578 Section 10, the 
> DESCRIPTION clause can only be updated with "clarifications and additional 
> information ... Otherwise, if the semantics of any previously defined object 
> are changed (i.e., if a non-editorial change is made to any clause other than 
> those specifically allowed above), then the OBJECT IDENTIFIER value 
> associated with that object must also be changed." 
> 
> So our question to the group is "Does option 2 qualify as a valid 
> "clarification and additional information" or are we forced into option 1?". 
> Option 1 would require a complete replacement MIB with corresponding impacts 
> to existing code to support the new TLS version, so I believe Option 2 would 
> be preferred, if allowed.
> 
> 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
> 

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


-- 
Jürgen Schönwälder  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

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

Re: [OPSAWG] CALL FOR ADOPTION: Transport Layer Security Verion 1.3 (TLS 1.3) Transport Model for the Simple Network Management Protocol Version 3 (SNMPv3)

[Jürgen Schönwälder]

On Tue, Jan 18, 2022 at 08:00:12PM +, Joe Clarke (jclarke) wrote:
> 
> 
>   1.  RFC 6353 indicated that it was "NOT RECOMMENDED" to use a 
> non-transport-aware security model, including USM and previous versions of 
> SNMP. However, support for USM remained a requirement (inherited from STD 62) 
> and other comments were included regarding implementations that supported 
> previous versions of SNMP. Given that a system is only as secure as its 
> weakest link, what should our position be on the use and support of USM and 
> previous versions of SNMP?
> 

I think there is some confusion here. RFC 6353 says:

   Using a non-transport-aware Security Model with a secure Transport
   Model is NOT RECOMMENDED.

The text does _not_ say that USM is NOT RECOMMENDED. It says that the
combination USM/(D)TLS is not recommended, instead TSM/(D)TLS should
be used (with TSM defined in RFC5591). RFC 6353 does not say anything
concerning the usage of STD 62. The scope of RFC 6353 is the transport
of SNMP messages over DTLS/TLS - and nothing else.

One of the big challenges back in the SNMPv3 days was to get
modularity right and from this perspective it feels very wrong if a
secure transport specification provides recommendations about the
usage of something entirely unrelated to the secure transport
specification. If people want to deprecate or retire USM, then this
requires a separate document that changes STD 62.

/js

-- 
Jürgen Schönwälder  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

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

Re: [OPSAWG] CALL FOR ADOPTION: Transport Layer Security Verion 1.3 (TLS 1.3) Transport Model for the Simple Network Management Protocol Version 3 (SNMPv3)

[Jürgen Schönwälder]

USM is a part of STD62 and I do not think it is the job of an update
of RFC 6353 to make any changes concerning STD62 and the status of
USM. SNMP RFCs usually talk about what is mandatory to implement (to
guarantee some level of interoperability), they usually are silent
about enablement (whatever that means) and about usage policies.

I believe the focus of an update should be on the technical aspects
necessary to clarify to use SNMP over (D)TLS 1.3 - focus on the
mechanisms, staying away from any policies.

/js

On Wed, Jan 05, 2022 at 08:39:30AM -0600, Kenneth Vaughn wrote:
> RFC 6353 indicated that it was "NOT RECOMMENDED" to use a non-transport-aware 
> security model, including USM and previous versions of SNMP. However, support 
> for USM remained a requirement (inherited from STD 62) and other comments 
> were included regarding implementations that supported previous versions of 
> SNMP. Given that a system is only as secure as its weakest link, what should 
> our position be on the use and support of USM and previous versions of SNMP?
> a. Support and enablement mandatory
> 
> b. Support mandatory; enablement silent; use not recommended (RFC 6353 
> for USM)
> 
> c. Support mandatory; ability to disable mandatory
> 
> d. Support optional/silent; use not recommended (RFC 6353 for old SNMP 
> versions)
> 
> e.   Support optional/silent; ability to disable, if supported, mandatory
> 
> f.  Support prohibited
> 
> Answers to the above should provide a good amount of direction to the effort; 
> if we are successful in having IANA maintain the one-octet identifier, most 
> of the other comments suggested by Tom will be rendered moot by removing the 
> MIB. The others are largely editorial and can be addressed once we have the 
> other questions answered.
>  
> 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
> 
> > 
> 
> 

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


-- 
Jürgen Schönwälder  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

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

Re: [OPSAWG] CALL FOR ADOPTION: Transport Layer Security Verion 1.3 (TLS 1.3) Transport Model for the Simple Network Management Protocol Version 3 (SNMPv3)

[Jürgen Schönwälder]

On Thu, Dec 09, 2021 at 10:17:20AM -0600, Kenneth Vaughn wrote:
> > "all these references"
> RFC 7407
> draft-ietf-netconf-https-notif-09.txt
> any other imports of this YANG definition
> 
> > the values in the TLS HashAlgorithm
> > registry are only applicable to version of (D)TLS protocol versions
> > prior to 1.3.  Perhaps we need to let IANA know somehow that
> > there are non (D)TLS specifications depending on the registry values
> Correct, based on my reading of the standards, I was concerned that, at some 
> point in the future, hash algorithms might not be assigned the one octet 
> identifier. This concerned seemed to be shared by several others (e.g., 
> including those in the TLS community). If we can convince IANA to continue to 
> assign the one octet values, we should be able to continue to use the 
> existing fingerprint algorithm. That would then make this update quite minor, 
> although I believe it still necessary to clarify other ambiguities that arise.
>

I am not sure we should go and try to fix problems that are not yet
concrete problems. I looked at the numbers registered and there is
lots of space left.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [OPSAWG] CALL FOR ADOPTION: Transport Layer Security Verion 1.3 (TLS 1.3) Transport Model for the Simple Network Management Protocol Version 3 (SNMPv3)

[Jürgen Schönwälder]

Ken,

note sure what "all these references" are. I am now looking at Section
15 of RFC 8447 and it states that the values in the TLS HashAlgorithm
registry are only applicable to version of (D)TLS protocol versions
prior to 1.3. This does not necessarily imply that we can't continue
to use them for the fingerprint algorithm. Hence, this might have all
been a false alarm... Perhaps we need to let IANA know somehow that
there are non (D)TLS specifications depending on the registry values
so that they can take a note in case people in the future want to
deprecate the registry.

/js

On Thu, Dec 09, 2021 at 08:54:36AM -0600, Kenneth Vaughn wrote:
> Juergen,
> 
> It seems to me that all of these references argue for asking IANA to maintain 
> the one-octet identifiers for the hashing algorithms (i.e., including the 
> addition of new identifiers as new algorithms are developed), even after TLS 
> 1.2 fades from use. That will allow the fingerprint algorithm to remain 
> unchanged in all of these scenarios and greatly simplifies our update effort.
> 
> 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 Nov 19, 2021, at 1:40 PM, Jürgen Schönwälder 
> >  wrote:
> > 
> > Let me add one additional observation: RFC 6353 has been a blueprint
> > for the YANG data model for SNMP configuration defined in RFC 7407.
> > The ietf-x509-cert-to-name module, which is part of RFC 7407, defines
> > a tls-fingerprint, which is also using a 1 octet hashing algorithm
> > identifier. If we expand SNMP's TC, we should also look at the YANG
> > equivalent. I also spotted that the YANG definition is imported by
> > draft-ietf-netconf-https-notif-09.txt, I am not sure whether there are
> > any other imports of this YANG definition (or the SNMP TC).
> > 
> > /js
> > 
> > On Fri, Nov 19, 2021 at 07:57:32PM +0100, Jürgen Schönwälder wrote:
> >> Hi,
> >> 
> >> any clarifications that are necessary to run SNMP over (D)TLS 1.3 are
> >> worth to work on. Looking at the document, it leaves me a bit puzzled
> >> of what is actually changed. I think all text that is in RFC 6353 and
> >> not modified should be removed from the update (for example, I think
> >> there is no need to republish text concerning USM). For the MIB
> >> module, it would help a lot if the revision clause would detail what
> >> has actually changed instead of just saying "This version updated the
> >> MIB to support (D)TLS 1.3." I like to see concrete text like
> >> 
> >> - SnmpTLSFingerprint has been depracted and SnmpTLS13Fingerprint
> >>  has been introduced.
> >> 
> >> - The snmpTlstmCertToTSNTable has been deprecated and a new
> >>  snmpTlstmCertToTSN13Table has been introduced.
> >> 
> >> - The snmpTlstmParamsTable has been deprecated and a new
> >>  snmpTlstmParams13Table has been introduced
> >> 
> >> I find it problematic to embed "13" in the new object names as this
> >> suggests the objects work only for TLS 1.3, which I hope is not the
> >> case, i.e., I hope we do not have do yet another update when (D)TLS
> >> 1.4 comes along in the future - or is the idea we actually do that? I
> >> think there should also be clear guidelines what implementations
> >> should do, implement the new objects and accept also D(TLS) 1.2
> >> configurations via them or should the new objects only be supported
> >> for D(TLS) 1.3 (and higher?) configurations?
> >> 
> >> /js
> >> 
> >> PS: There are also some bugs in the MIB module, mpTlstmAddrCount
> >>should be snmpTlstmAddrCount and CONTACT-INFO string is not
> >>terminated.
> >> 
> >> On Fri, Nov 19, 2021 at 04:26:50PM +, Joe Clarke (jclarke) wrote:
> >>> Hello, WG.  Kenneth presented
> >>> https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update/ at IETF112
> >>> to us, and this was previously presented at SecDispatch at IETF111.  The
> >>> feeling there was that this work had merit, but Sec didn't have enough
> >>> SNMP experience to be the owner.  At the AD level, the feeling was that
> >>> perhaps opsawg did have the expertise and could pick this up.
> >>> 
> >>> Therefore, this serves as a three week call for adoption of this draft. 
> >>> The three weeks is being given due to the US holiday next week.  There
> >>> has already been some comments regarding scope that hav

Re: [OPSAWG] CALL FOR ADOPTION: Transport Layer Security Verion 1.3 (TLS 1.3) Transport Model for the Simple Network Management Protocol Version 3 (SNMPv3)

[Jürgen Schönwälder]

Let me add one additional observation: RFC 6353 has been a blueprint
for the YANG data model for SNMP configuration defined in RFC 7407.
The ietf-x509-cert-to-name module, which is part of RFC 7407, defines
a tls-fingerprint, which is also using a 1 octet hashing algorithm
identifier. If we expand SNMP's TC, we should also look at the YANG
equivalent. I also spotted that the YANG definition is imported by
draft-ietf-netconf-https-notif-09.txt, I am not sure whether there are
any other imports of this YANG definition (or the SNMP TC).

/js

On Fri, Nov 19, 2021 at 07:57:32PM +0100, Jürgen Schönwälder wrote:
> Hi,
> 
> any clarifications that are necessary to run SNMP over (D)TLS 1.3 are
> worth to work on. Looking at the document, it leaves me a bit puzzled
> of what is actually changed. I think all text that is in RFC 6353 and
> not modified should be removed from the update (for example, I think
> there is no need to republish text concerning USM). For the MIB
> module, it would help a lot if the revision clause would detail what
> has actually changed instead of just saying "This version updated the
> MIB to support (D)TLS 1.3." I like to see concrete text like
> 
> - SnmpTLSFingerprint has been depracted and SnmpTLS13Fingerprint
>   has been introduced.
> 
> - The snmpTlstmCertToTSNTable has been deprecated and a new
>   snmpTlstmCertToTSN13Table has been introduced.
> 
> - The snmpTlstmParamsTable has been deprecated and a new
>   snmpTlstmParams13Table has been introduced
> 
> I find it problematic to embed "13" in the new object names as this
> suggests the objects work only for TLS 1.3, which I hope is not the
> case, i.e., I hope we do not have do yet another update when (D)TLS
> 1.4 comes along in the future - or is the idea we actually do that? I
> think there should also be clear guidelines what implementations
> should do, implement the new objects and accept also D(TLS) 1.2
> configurations via them or should the new objects only be supported
> for D(TLS) 1.3 (and higher?) configurations?
> 
> /js
> 
> PS: There are also some bugs in the MIB module, mpTlstmAddrCount
> should be snmpTlstmAddrCount and CONTACT-INFO string is not
> terminated.
> 
> On Fri, Nov 19, 2021 at 04:26:50PM +, Joe Clarke (jclarke) wrote:
> > Hello, WG.  Kenneth presented
> > https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update/ at IETF112
> > to us, and this was previously presented at SecDispatch at IETF111.  The
> > feeling there was that this work had merit, but Sec didn't have enough
> > SNMP experience to be the owner.  At the AD level, the feeling was that
> > perhaps opsawg did have the expertise and could pick this up.
> > 
> > Therefore, this serves as a three week call for adoption of this draft. 
> > The three weeks is being given due to the US holiday next week.  There
> > has already been some comments regarding scope that have been raised
> > on-list, and Kenneth has called out potential courses of action in his
> > 112 presentation.
> > 
> > Please respond by December 10, 2021 regarding your thoughts on adopting
> > this work as well as comments on the work so far.
> > 
> > Thanks.
> > 
> > Joe
> > 
> > ___
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

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

Re: [OPSAWG] CALL FOR ADOPTION: Transport Layer Security Verion 1.3 (TLS 1.3) Transport Model for the Simple Network Management Protocol Version 3 (SNMPv3)

[Jürgen Schönwälder]

Hi,

any clarifications that are necessary to run SNMP over (D)TLS 1.3 are
worth to work on. Looking at the document, it leaves me a bit puzzled
of what is actually changed. I think all text that is in RFC 6353 and
not modified should be removed from the update (for example, I think
there is no need to republish text concerning USM). For the MIB
module, it would help a lot if the revision clause would detail what
has actually changed instead of just saying "This version updated the
MIB to support (D)TLS 1.3." I like to see concrete text like

- SnmpTLSFingerprint has been depracted and SnmpTLS13Fingerprint
  has been introduced.

- The snmpTlstmCertToTSNTable has been deprecated and a new
  snmpTlstmCertToTSN13Table has been introduced.

- The snmpTlstmParamsTable has been deprecated and a new
  snmpTlstmParams13Table has been introduced

I find it problematic to embed "13" in the new object names as this
suggests the objects work only for TLS 1.3, which I hope is not the
case, i.e., I hope we do not have do yet another update when (D)TLS
1.4 comes along in the future - or is the idea we actually do that? I
think there should also be clear guidelines what implementations
should do, implement the new objects and accept also D(TLS) 1.2
configurations via them or should the new objects only be supported
for D(TLS) 1.3 (and higher?) configurations?

/js

PS: There are also some bugs in the MIB module, mpTlstmAddrCount
should be snmpTlstmAddrCount and CONTACT-INFO string is not
terminated.

On Fri, Nov 19, 2021 at 04:26:50PM +, Joe Clarke (jclarke) wrote:
> Hello, WG.  Kenneth presented
> https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update/ at IETF112
> to us, and this was previously presented at SecDispatch at IETF111.  The
> feeling there was that this work had merit, but Sec didn't have enough
> SNMP experience to be the owner.  At the AD level, the feeling was that
> perhaps opsawg did have the expertise and could pick this up.
> 
> Therefore, this serves as a three week call for adoption of this draft. 
> The three weeks is being given due to the US holiday next week.  There
> has already been some comments regarding scope that have been raised
> on-list, and Kenneth has called out potential courses of action in his
> 112 presentation.
> 
> Please respond by December 10, 2021 regarding your thoughts on adopting
> this work as well as comments on the work so far.
> 
> Thanks.
> 
> Joe
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

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

[Jürgen Schönwälder]

+1

/js

On Wed, Oct 20, 2021 at 10:44:37PM +0200, 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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

[OPSAWG] Yangdoctors early review of draft-ietf-opsawg-nat-yang-06

[Jürgen Schönwälder]

Reviewer: Jürgen Schönwälder
Review result: Not Ready

Summary

>From a YANG modeling point of view, the module is rather straight
forward and I did not discover anything that seems fundamentally
problematic. That said, there are a number of details where I doubt
the model is correct and things where I believe things are incomplete.
Given that there are many different NAT functions, I also expected to
see usage of YANG features.

One fundamental question one could raise is whether this model should
have been broken down into a generic NAT core model plus extensions of
the core model for the different types of NATs. Well, a single model
with YANG features is an inline version of that as this still requires
to mark clearly which parts are specific to certain types or NATs.

I did not compile the module myself since the IETF tracker says no
errors using pyang and yanglint (and I would not have run anything
different). (Is it OK for YANG doctors to trust the tracker tools?
Well, since this is labelled as an early review and I expect more
updates, I assume this is fine.)

I can't tell whether the model makes sense from a NAT point of view. I
am not an expert in the various types of NATs and surely more reviews
of NAT experts would be good (and they would have likely spotted some
things I have spotted, so I guess the usual problem of getting enough
substantial reviews).

Details

- We use revision statements only for published modules. Hence, please
  replace the revision statements with

  // RFC Ed. update to match the date of the latest edits
  revision 2017-xx-yy {
description
  "Initial revision.";
reference
  "RFC : A YANG Data Model for Network Address Translation
 (NAT) and Network Prefix Translation (NPT)";
  }

- We usually follow a different template for the contact statement
  that has more context and just a list of names and email addresses.

- We usually write

 reference
   "RFC 3022: Traditional IP Network Address Translator
  (Traditional NAT)";

  instead of just

 reference
   "RFC 3022.";

  since not everybody remembers all the numbers equally well.

- Is there a reference for dst-nat?

- What is the vrf-routing-instance identity good for? Its used only in
  the leaf external-vrf-instance and the description of that leaf is
  not telling me how this is going to be used. Who is going to derive
  identities? I fear you are trying to achieve something where using
  identities is really the wrong approach. Section 2.10 does not tell
  how this is supposed to work either. I assume this needs to be
  checked by the routing area experts to make sure things fit with
  their modeling of VRFs.

- s/start-port-numbert/start-port-number/

- Are comments like

  // port numbers: single or port-range

  necessary given that there are description statements? Note that
  comments may be removed by tools while description statements
  usually are preserved. So it is important to have anything important
  covered in description statements.

- What is a PSID algorithm? Spell out acronyms on first usage.

- The leafs start-port-number and end-port-number are commented out in
  port-range, probably in favour of the uses port-number. If they are
  not needed anymore, they should be removed.

- I do not understand port-set-algo from the descriptions. What is the
  psid-offset applied? What is a 'sharing ration for an IPv4 address'?
  Is this stuff IPv4 specific? Is the psid something that has a
  certain meaning outside of this YANG module? If so, where do I find
  more details (missing reference statement?)?

- mapping-entry/index: is this an arbitrary identifier? how are these
  identifiers allocated? Are they created by the NAT or are they created
  via configuration? Or even both? Well, I guess it is both given the
  mapping-entry/type leaf.

- mapping-entry/type: instead 'manually configured', I would write
  'explicitly configured' (configuration does not have to be a manual
  process). I also find the other enum labels at least a bit confusing.

enum "dynamic-explicit" {
  description
"This mapping is created by an
 outgoing packet.";
}

enum "dynamic-implicit" {
  description
"This mapping is created by an
 explicit  dynamic message.";
}

  Note the 'implicit' vs 'explicit' clash here. Perhaps this should be
  aligned with the definition of dynamic and implicit mappings:

   o  Dynamic implicit mapping: is created implicitly as a side effect
  of traffic such as an outgoing TCP SYN or an outgoing UDP packet.
  A validity lifetime is associated with this mapping.

   o  Dynamic explicit mapping: is created as a result of an explicit
  request, e.g., PCP message [RFC6887].  A validity lifetime is
  associated with this mapping.

  But the