Re: [OPSAWG] AD review of draft-ietf-opsawg-sap-09

[mohamed.boucadair]

Hi Rob, all,

One update related to your comment about how to identify "interfaces that are 
ready to host per-service sub-interfaces". We used to rely upon an implicit 
approach that combines the type of the attachment interface (phy, in 
particular) and the status, however after thinking about this more, it is 
better to have an explicit approach where a SAP is explicitly tagged to hots 
child SAPs. 
We added a new leaf to reflect this in the model and updated the examples to 
reflect the usage.

The changes can be tracked using the same link: https://tinyurl.com/sap-latest 

Cheers,
Med

> -Message d'origine-
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : vendredi 23 septembre 2022 15:04
> À : 'Rob Wilton (rwilton)' ; draft-ietf-opsawg-
> sap@ietf.org; opsawg@ietf.org
> Objet : RE: AD review of draft-ietf-opsawg-sap-09
> 
> Hi Rob,
> 
> Thank you for the review. The changes can be tracked at:
> https://tinyurl.com/sap-latest
> 
> Please note that I made a change to better allow for reuse of the
> SAP information in other modules (this can be tracked here:
> https://github.com/IETF-OPSAWG-
> WG/lxnm/commit/e8b406d7fad5225dd84ad7ff03f6da446eae6736).
> 
> Please see inline for more context.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton)  Envoyé : vendredi
> 23
> > septembre 2022 14:01 À : draft-ietf-opsawg-sap@ietf.org;
> > opsawg@ietf.org Objet : AD review of draft-ietf-opsawg-sap-09
> >
> > Hi authors, WG,
> >
> > Thank you for this document.  I also think that this document is
> well
> > written and in good shape, and I mostly found the explanations
> and
> > examples clear.  There were two specific points that I found
> slightly
> > confusing related to differentiating between SAPs in use, and
> those
> > that are not, and also parent interfaces also be listed as SAPs,
> > details below.
> 
> [Med] Thanks
> 
> >
> > Moderate level comments:
> >
> > (1) p 10, sec 5.  SAP Module Tree Structure
> >
> >   SAPs that are associated with the interfaces that are
> directly
> >   hosting services, interfaces that are ready to host per-
> service
> >   sub-interfaces (but not yet activated), or service that
> are
> >   already instantiated on sub-interfaces are listed as SAPs.
> >
> > >From the model, is isn't clear to me how different
> differentiates
> > between a SAP that has been pre-provisioned to potentially be
> used for
> > a service in future, v.s., one is that is actively provisioned.
> 
> [Med] This is inferred from the service-status=down for these
> SAPs.
> 
> 
>   I think that it would be helpful if these two cases
> > can be clearly distinguished.  Note, I have made a similar
> comment
> > related to appendix D about identifying a "free" SAP.
> 
> [Med] Added this NEW to the appendix:
> 
> "SAPs that are ready to host per-service (but not yet activated)
> are identified by the "service-status" set to "ietf-vpn-common:op-
> down"."
> 
> >
> >
> > (2) p 28, sec Appendix B.  A Simple Example of SAP Network
> Model:
> > Node Filter
> >
> 
> [Med] Please note "Simple" in the title :-)
> 
> >A service orchestrator can query what services are provided
> on
> > which
> >SAPs of PE1 from the network controller by sending, e.g., a
> GET
> >RESTCONF request.  Figure 9 shows the body of the RESTCONF
> response
> >that is received from the network controller.
> >
> > In this example, you have GE0/6/4 as being ready to host SAPs,
> but I
> > could equally imagine that given GE0/6/4 is just a UNI, then you
> may
> > not want the parent interface to be available to host SAPs
> directly at
> > all.  I.e., it may always the case that sub-interfaces are used
> as
> > SAPs.  Hence, did you consider whether it makes sense for there
> to be
> > a different category of SAP service-types for UNI's and NNI's
> that
> > don't host services directly on the interface, but always on
> > sub-interfaces?
> 
> [Med] Yes, we do need this for the LxVPN case.
> 
>   Related to this, it
> > feels slightly strange to me to have GE0/6/4 listed under both
> l3vpn
> > and vpls SAP lists.
> 
> [Med] Actually there are attached to distinct sub-interfaces:
> 
>Also, let us assume that, for
>the SAPs that are associated with the physical interface
> "GE0/6/4",
>VPLS and L3VPN services are activated on the two sub-interfaces
>"GE0/6/4.1" and "GE0/6/4.2", respectively.
> 
> Updated the example to align with this text.
> 
>   Having the same information twice in
> > the data model introduces the risk that a device could export
> > inconsistent information and hence it hard for the customer to
> know
> > which data is accurate.  I can understand why having it twice
> might be
> > convenient, but having an indication that it is actually just a
> > container node for SAPs rather than a SAP itself might be
> better.
> >
> >
> >
> > Minor level comments:
> >
> > (3) p 3, sec 3.  Sample SAP Network Model Usage
> >
> >Management operations of a ser

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

[Kenneth Vaughn]

This new draft restores a sentence that was inadvertently deleted from the 
definition of SnmpTLSAddress and fixes a couple of typos (commas to periods and 
updates the address in the contact information). The document now addresses all 
received comments and should be ready for the next stage.

Regards,
Ken Vaughn

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

> On Sep 26, 2022, at 8:30 PM, 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-07.txt
>  Pages   : 31
>  Date: 2022-09-26
> 
> 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-07.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tlstm-update-07
> 
> 
> 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

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

[internet-drafts]

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-07.txt
  Pages   : 31
  Date: 2022-09-26

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-07.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tlstm-update-07


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

Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt

[Joe Clarke (jclarke)]

Go ahead and push a -07.

Joe

From: Kenneth Vaughn 
Date: Monday, September 26, 2022 at 6:58 PM
To: Joe Clarke (jclarke) 
Cc: opsawg@ietf.org 
Subject: Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt
I just noticed that an important sentence somehow got deleted from the 
definition of SnmpTLSFingerprint definition. The missing sentence that was in 
the original RFC 6353 occurs at the end of the second paragraph and reads as 
follows:

The remaining octets are filled using the results of the hashing algorithm.

Should I produce a new 07 draft now or have you already sent to the IESG (in 
which case, I can presumably take care of it during final editing)?

Regards,
Ken Vaughn

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


On Sep 26, 2022, at 7:55 AM, Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>> wrote:

Hey, Ken and WG.  I did not hear back on any interested shepherd, so I’ll take 
this one up and move this forward to IESG.  I will have the shepherd review and 
write-up ready this week.

Joe

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>
Date: Monday, September 12, 2022 at 15:24
To: Kenneth Vaughn mailto:kvau...@trevilon.com>>, 
opsawg@ietf.org 
mailto:opsawg@ietf.org>>
Subject: Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt
Thanks, Ken.  Your new text addresses my concern on the use of MUST NOT.

I’m a bit disappointed we didn’t see other reviews from the directorates, but 
perhaps the summer doldrums are still at play.

What other comments do people have on the current draft?  If none, I’ll close 
the LC.  We do need a document shepherd.  If anyone is interested, please let 
me know.

Joe

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of Kenneth Vaughn mailto:kvau...@trevilon.com>>
Date: Friday, September 9, 2022 at 4:57 PM
To: opsawg@ietf.org 
mailto:opsawg@ietf.org>>
Subject: Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt
Based on the comments received during the Last Call process, I:
- Updated the boilerplate text for the reference to BCP14
- Clarified the 5th paragraph of the definition of SnmpTLSAddress, and
- and updated the revision notes of the MODULE-IDENTIFY macro to reflect the 
above tweak.

I believe this version resolves all comments made to date.

Regards,
Ken Vaughn

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




On Sep 9, 2022, at 3:53 PM, 
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-06.txt
 Pages   : 31
 Date: 2022-09-09

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-06.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tlstm-update-06


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

Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt

[Kenneth Vaughn]

I just noticed that an important sentence somehow got deleted from the 
definition of SnmpTLSFingerprint definition. The missing sentence that was in 
the original RFC 6353 occurs at the end of the second paragraph and reads as 
follows:

> The remaining octets are filled using the results of the hashing algorithm.

Should I produce a new 07 draft now or have you already sent to the IESG (in 
which case, I can presumably take care of it during final editing)?

Regards,
Ken Vaughn

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

> On Sep 26, 2022, at 7:55 AM, Joe Clarke (jclarke)  wrote:
> 
> Hey, Ken and WG.  I did not hear back on any interested shepherd, so I’ll 
> take this one up and move this forward to IESG.  I will have the shepherd 
> review and write-up ready this week.
>  
> Joe
>  
> From: OPSAWG  on behalf of Joe Clarke (jclarke) 
> 
> Date: Monday, September 12, 2022 at 15:24
> To: Kenneth Vaughn , opsawg@ietf.org 
> Subject: Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt
> 
> Thanks, Ken.  Your new text addresses my concern on the use of MUST NOT.
>  
> I’m a bit disappointed we didn’t see other reviews from the directorates, but 
> perhaps the summer doldrums are still at play.
>  
> What other comments do people have on the current draft?  If none, I’ll close 
> the LC.  We do need a document shepherd.  If anyone is interested, please let 
> me know.
>  
> Joe
>  
> From: OPSAWG  on behalf of Kenneth Vaughn 
> 
> Date: Friday, September 9, 2022 at 4:57 PM
> To: opsawg@ietf.org 
> Subject: Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt
> 
> Based on the comments received during the Last Call process, I:
> - Updated the boilerplate text for the reference to BCP14
> - Clarified the 5th paragraph of the definition of SnmpTLSAddress, and 
> - and updated the revision notes of the MODULE-IDENTIFY macro to reflect the 
> above tweak.
>  
> I believe this version resolves all comments made to date.
> 
> Regards,
> Ken Vaughn
>  
> Trevilon LLC
> 6606 FM 1488 RD #148-503
> Magnolia, TX 77354
> +1-571-331-5670 cell
> kvau...@trevilon.com 
> www.trevilon.com 
> 
> 
> 
> On Sep 9, 2022, at 3:53 PM, 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-06.txt
>  Pages   : 31
>  Date: 2022-09-09
> 
> 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-06.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tlstm-update-06
> 
> 
> 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

Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt

[Kenneth Vaughn]

Great, let me know if you have any questions.

Regards,
Ken Vaughn

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

> On Sep 26, 2022, at 7:55 AM, Joe Clarke (jclarke)  wrote:
> 
> Hey, Ken and WG.  I did not hear back on any interested shepherd, so I’ll 
> take this one up and move this forward to IESG.  I will have the shepherd 
> review and write-up ready this week.
>  
> Joe
>  
> From: OPSAWG  on behalf of Joe Clarke (jclarke) 
> 
> Date: Monday, September 12, 2022 at 15:24
> To: Kenneth Vaughn , opsawg@ietf.org 
> Subject: Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt
> 
> Thanks, Ken.  Your new text addresses my concern on the use of MUST NOT.
>  
> I’m a bit disappointed we didn’t see other reviews from the directorates, but 
> perhaps the summer doldrums are still at play.
>  
> What other comments do people have on the current draft?  If none, I’ll close 
> the LC.  We do need a document shepherd.  If anyone is interested, please let 
> me know.
>  
> Joe
>  
> From: OPSAWG  on behalf of Kenneth Vaughn 
> 
> Date: Friday, September 9, 2022 at 4:57 PM
> To: opsawg@ietf.org 
> Subject: Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt
> 
> Based on the comments received during the Last Call process, I:
> - Updated the boilerplate text for the reference to BCP14
> - Clarified the 5th paragraph of the definition of SnmpTLSAddress, and 
> - and updated the revision notes of the MODULE-IDENTIFY macro to reflect the 
> above tweak.
>  
> I believe this version resolves all comments made to date.
> 
> Regards,
> Ken Vaughn
>  
> Trevilon LLC
> 6606 FM 1488 RD #148-503
> Magnolia, TX 77354
> +1-571-331-5670 cell
> kvau...@trevilon.com 
> www.trevilon.com 
> 
> 
> 
> On Sep 9, 2022, at 3:53 PM, 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-06.txt
>  Pages   : 31
>  Date: 2022-09-09
> 
> 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-06.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tlstm-update-06
> 
> 
> 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

Re: [OPSAWG] 🔔 WG Last Call for draft-ietf-opsawg-mud-tls-07

[tirumal reddy]

Thanks Tom and Med for the feedback. We will add a note that users should
visit the IANA URL with the Yang module. The new guidelines for the
IANA-maintained modules need to be discussed in the netmod WG (updating
RFC8216), till then, we will have to follow the existing guidelines as
other specifications.

Cheers,
-Tiru

On Fri, 16 Sept 2022 at 16:15, tom petch  wrote:

> From: mohamed.boucad...@orange.com 
> Sent: 15 September 2022 12:35
>
> Hi Tom,
>
> This is a fair comment.
>
> There is currently no recommendation on whether the initial full
> IANA-maintained modules should (not) be included or whether "an
> IANA-maintained module should
> always be published on its own". Publishing the module in a separate
> document has the same issues as those that are called out in the last two
> sentences of the excerpt below from
> https://datatracker.ietf.org/doc/html/draft-boucadair-netmod-iana-registries-04;
> I don't think it is worth to be considered by the authors here:
>
> 
> Well, I have a recommendation.  I think that the initial version of an
> IANA-maintained module should appear in an RFC on its own.  That RFC can
> then be classified as Historic after a brief pause.
>
> The initial version should be there so that we can see how we got to
> whereever we later get to.  Authors can, and do, add a note to the effect
> that users should visit the IANA website, and give a URL,  Such a note
> should always be present IMO.
>
> Tom Petch
>
>Designers of IANA-maintained modules MAY supply the full initial
>version of the module in a specification document that registers the
>module or only a script to be used (including by IANA) for generating
>the module (e.g., an XSLT stylesheet as in Appendix A of [RFC9108]).
>When a script is used, the Internet-Draft that defines an IANA-
>maintained module SHOULD include an appendix with the initial full
>version of the module.  Including such an appendix in pre-RFC
>versions is meant to assess the correctness of the outcome of the
>supplied script.  The authors MUST include a note to the RFC Editor
>requesting that the appendix be removed before publication as RFC.
>Initial versions of IANA-maintained modules that are published in
>RFCs may be misused despite the appropriate language to refer to the
>IANA registry to retrieve the up-to-date module.  This is problematic
>for interoperability, e.g., when values are deprecated or are
>associated with a new meaning.
>
> As an alternative to the script mentioned above, I wonder whether the
> authors can simply include a note to the RFC Editor asking to remove the
> module from the RFC and replace it with a link to the IANA page with the
> module.
>
> That's said, I'm having troubles with the content of the IANA-maintained
> module itself because it does not reflect the content of the authoritative
> registries it refers to. Also, I'm not sure the current IANA instructions
> are unambiguous so that IANA can maintain the module.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : OPSAWG  De la part de tom petch
> > Envoyé : jeudi 15 septembre 2022 11:25
> > À : Henk Birkholz ; opsawg
> > 
> > Objet : Re: [OPSAWG] 🔔 WG Last Call for draft-ietf-opsawg-mud-
> > tls-07
> >
> > From: OPSAWG  on behalf of Henk Birkholz
> > 
> > Sent: 14 September 2022 15:07
> >
> > Dear OPSAWG members,
> >
> > this email starts a two week period for a Working Group Last Call
> > of
> >
> > > https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-
> > 07.html
> >
> > ending on Thursday, September 28th.
> >
> > The authors believe the Internet-Draft is ready for a WGLC and the
> > chairs agree. The draft has been discussed visibly at IETF 114 and
> > review feedback has been incorporated in -07.
> >
> > Please send your comments to the list and your assessment of
> > whether or not it is ready to proceed to publication before
> > September 28th.
> >
> > 
> > Not Ready.
> >
> > This I-D contains a YANG module for IANA to maintain along with
> > YANG modules and other data which are not.  I think that this
> > approach is always wrong.  The two sets of material have different
> > life cycles.  The IANA-maintained module is effectively obsolete
> > as soon as the RFC is published since the contents are then
> > maintained by IANA; anyone seeing the module in the RFC will be
> > looking at obsolete - sooner or later - material.  Users should
> > always be looking at the IANA website.  There is no way to tell
> > users this in the published status of an RFC.
> >
> > The remaining material in the I-D is likely to be updated over
> > time and then the authors have a choice of two bad approaches.
> > They can cut out the IANA-maintained module in which case the new
> > document sort of obsoletes the old one but not quite and a lot
> > more editing is needed; or they can republish the IANA-maintained
> > module which by then will have been obsolete for some time and
> > almost certainly wro

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-service-assurance-architecture-09.txt

[Tianran Zhou]

Hi Michael,

Thank you very much for your contribution!

Cheers,
Tianran






Sent from WeLink
发件人： Michael Richardsonmailto:m...@sandelman.ca>>
收件人： Jean 
Quilbeufmailto:jean.quilbeuf=40huawei@dmarc.ietf.org>>
抄送： opsawgmailto:opsawg@ietf.org>>
主题： Re: [OPSAWG] I-D Action: 
draft-ietf-opsawg-service-assurance-architecture-09.txt
时间： 2022-09-26 18:58:19

Jean Quilbeuf  wrote:
> Dear All, This update addresses comments from Michael Richardson.

Confirmed!  Thank you.
Tianran has asked me to update some things in the writeup, which I'll do
Wednesday.


___
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] draft-ietf-opsawg-tlstm-update-06.txt

[Joe Clarke (jclarke)]

Hey, Ken and WG.  I did not hear back on any interested shepherd, so I’ll take 
this one up and move this forward to IESG.  I will have the shepherd review and 
write-up ready this week.

Joe

From: OPSAWG  on behalf of Joe Clarke (jclarke) 

Date: Monday, September 12, 2022 at 15:24
To: Kenneth Vaughn , opsawg@ietf.org 
Subject: Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt
Thanks, Ken.  Your new text addresses my concern on the use of MUST NOT.

I’m a bit disappointed we didn’t see other reviews from the directorates, but 
perhaps the summer doldrums are still at play.

What other comments do people have on the current draft?  If none, I’ll close 
the LC.  We do need a document shepherd.  If anyone is interested, please let 
me know.

Joe

From: OPSAWG  on behalf of Kenneth Vaughn 

Date: Friday, September 9, 2022 at 4:57 PM
To: opsawg@ietf.org 
Subject: Re: [OPSAWG] draft-ietf-opsawg-tlstm-update-06.txt
Based on the comments received during the Last Call process, I:
- Updated the boilerplate text for the reference to BCP14
- Clarified the 5th paragraph of the definition of SnmpTLSAddress, and
- and updated the revision notes of the MODULE-IDENTIFY macro to reflect the 
above tweak.

I believe this version resolves all comments made to date.

Regards,
Ken Vaughn

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



On Sep 9, 2022, at 3:53 PM, 
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-06.txt
 Pages   : 31
 Date: 2022-09-09

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-06.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tlstm-update-06


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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-service-assurance-architecture-09.txt

[Michael Richardson]

Jean Quilbeuf  wrote:
> Dear All, This update addresses comments from Michael Richardson.

Confirmed!  Thank you.
Tianran has asked me to update some things in the writeup, which I'll do
Wednesday.


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

[OPSAWG] Tsvart last call review of draft-ietf-opsawg-yang-vpn-service-pm-11

[Bob Briscoe via Datatracker]

Reviewer: Bob Briscoe
Review result: On the Right Track

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this review.

==

This draft is a useful contribution. I was good to see that the ability to
monitor delay percentiles had been included. This review was written against
draft-10, but then checked against draft-11 via the diff.

I'm afraid I have 14 comments, some of which are fairly major (e.g. #3, #4 &
#12). It should be borne in mind that this implies that everything else in the
draft is just fine :) However, all reviews tend to look fairly negative,
because they necessarily focus on points of concern and disagreement.

==1. Granularity of Units==

  Measurement interval ("measurement-interval"):  Specifies the
  performance measurement interval, in seconds.

Making the minimum granularity 1 s seems too coarse. 1 s is quite a common
interval for certain metrics (e.g. utilization), so it seems wrong to also make
it the minimum. However, I wouldn't fight hard if you disagree.

 typedef percentile {
   type decimal64 {
 fraction-digits 2;

2 decimals doesn't seem enough for percentiles. I suggest 3 at least, so that
five-9s percentiles can be specified (for instance, at a packet rate of 100,000
pkt/s, a 99.999%-ile delay statistic would imply 1 pkt/s is above the
percentile).

Is there a reason why the default percentiles are 10% and 90%? I think these
defaults would be rarely used. If this is just an arbitrary choice, 1% and 99%
might be better choices.

==2. Recursion==

I don't think this draft precludes a VPN over a VPN over a physical network
(e.g. a CVLAN over an SVLAN). However, it doesn't mention the possibility
either. An example with multiple layers of VPNs would be useful.

==3. Is the definition of TP adequate to determine different types of loss?==

I could not work out whether this YANG model would enable an operator to
identify whether losses are due to:
  * tail loss (buffer full),
  * selective early discard (AQM),
  * or discards due to transmission errors.
I read RFC8345 which was cited as the reference for the definitions of link and
TP. However, the definition of TP was 'a physical or logical port or, more
generally, an interface', which is not specific enough to determine exactly
where the TP of a physical or logical link is. Is a TP before or after the
output buffer? Before or after the input buffer? Before or after packet error
checking?

Also, is the TP of a VPN before or after encap. Is it before or after decap?
Whether per-class-id PM statistics include a packet or not will be highly
dependent on the answer to this question. Because encap and decap can alter the
class of a packet if the operator is using the pipe model where the DSCP is not
copied to and from the outer on encap and decap [RFC2983].

==4. Per traffic descriptor PM statistics?==

"§4.4 Link & TP PM Augmentation" includes  the following

   | +--ro one-way-pm-statistics-per-class* [class-id]

Is there a reference for how class-id can be used? The description says:

   "The class-id is used to identify the
class of service. This identifier is internal
to the administration.";

but that seems unworkable. The administration of a VPN is often separate from
the administration of the network it runs over. So how does one administration
know what the other means by each class-id? The whole point of OAM
standardization is to ensure that network administration doesn't need to be
complemented by ad hoc manual techniques, which are prone to human error.

Ideally, rather than class-id being just an opaque string, it would be
associated with a generic traffic descriptor (filter) that could also use
wildcards, for example:
dst_addr==unicast
next_header!=udp# in IPv6, equivalent to protocol ID in IPv4
DSCP==0b000???
ECN==0b?1
Is there anything like this in YANG already?
If not, it surely needs to be created for this PM draft.
I presume it would have to encompass Ethernet, MPLS etc, not just IP.

==5. Why only unicast and non-unicast?==

   +--ro inbound-unicast?yang:counter64
   +--ro inbound-non-unicast?yang:counter64

It seems rather arbitrary to pick this particular traffic filter in the TP part
of the YANG tree in Fig 7. First, it begs the question why no distinction can
be made between anycast and multicast. But, more generally, it beg

Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

[tom petch]

From: Rob Wilton (rwilton) 
Sent: 23 September 2022 12:53

Hi Tom,

Perhaps you can suggest some text/clarifications and the authors could consider 
it as part of the IETF last-call?


Rob

Consistency is my biggest concern with -10.  Search on 'underlay' and I see 
underlay network
underlay networks
underlay link
underlay technology
underlay-tunnel
underlay tunnels
underlay transport type
underlay network instances
underlay network links 
underlay network termination  points 

which leaves me uncertain, confused even and this I think should be addressed.  
I see similar variation in the use of 'overlay, 'VPN', 'service'.  

The difference between 'network' and 'networks' may be slight but I find it 
material.  The I-D talks of Layer 3 and Layer 2 in a stack.  My sense of the 
I-D is a focus on a L2VPN over a Layer 2 network.  Layer 3 and L3VPN get a 
mention but  L3VPN will have a Layer 3 underlay network which will have a Layer 
2 underlay network but in places, the use of 'network' singular suggests that 
this is not what the model is about, that the model only countenances a single 
underlay network to a service network.  One of the changes in the I-D was the 
augment of 'link' becoming a list, that there might be more than one link 
involved, and I have the same uncertainty about 'network'. Is it just the one 
underlay and service or more than one and if more than one, what are the 
relationships?  I do not know .  It is the sort of uncertainty that some Genart 
reviewers are good at spotting so I will wait to see what else Last Call brings 
up.

Tom Petch
Thanks,
Rob


> -Original Message-
> From: tom petch 
> Sent: 23 September 2022 12:20
> To: Rob Wilton (rwilton) ; 'Wubo (lana)'
> ; draft-ietf-opsawg-yang-vpn-service-
> pm@ietf.org; adr...@olddog.co.uk
> Cc: opsawg@ietf.org
> Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-vpn-service-pm-
> 09
>
> From: Adrian Farrel 
> Sent: 16 September 2022 10:33
>
> Hi Tom, all,
>
> I think my review as Shepherd ran into the same concern. And it is one of my
> long-standing gripes that "we" (the IETF) repeatedly confuse VPN as a service
> with the means and mechanisms to realise the VPN within the network. Of
> course, as network engineers, it is understandable why we make that
> mistake, but it is also harmful to the way we talk about the customers' view
> of VPNs.
>
> Now, in discussing this document with the authors, I wanted to distinguish
> between the performance measurement that the customer can perform
> (which is strictly edge-to-edge because the customer cannot see what is
> happening within the network), and the measurements that the provider can
> perform that can be far more analytic about the resources and routes/paths
> within the network. My feeling was that the authors completely got this
> distinction, but that they wanted to look at the performance monitoring from
> the provider's perspective with two viewpoints: what can they measure
> about how their network is performing, and what can they measure that will
> match what the customer might measure. Of course, the provider wants to
> know the latter before the customer notices and complains, but the provider
> also wants to be able to link the edge-to-edge measurements back to the
> more detailed measurements from within the network to determine causes.
>
> It is possible that I have expressed that differently from the way the
> document describes it, and it also possible that I have misrepresented the
> authors and the working group. But that was my take-away.
>
> 
>
> Adrian
>
> As I expect you will have seen, I took a look at -10 and still get confused.  
> It
> seems that several different  terms get used and I am left uncertain as to
> whether or not it is just two concepts,, 'underlay networks and overlay VPN
> services' to quote the Abstract, or if there is more involved.
>
> From your discussion with the authors I think just two, but I do not find the
> body of the I-D clear on that.
> Tom Petch
>
> Cheers,
> Adrian
>
> -Original Message-
> From: OPSAWG  On Behalf Of tom petch
> Sent: 15 September 2022 11:37
>
> From: OPSAWG  on behalf of Rob Wilton
> (rwilton) 
> Sent: 15 September 2022 09:09
>
> Hi Bo,
>
> Looks good.
>
> Let me know when you have an updated version of the draft posted and I
> will kick off the IETF LC.
>
> Thanks for the updates and for taking my comments onboard.
>
> 
> I have been following this thread with a sense of deja vu having made similar
> comments, much on s.4.2 , back in May.  Except, I do not think I ever hit
> 'send'.  I was trying to make clear comments that were not confused but
> found the I-D so confusing that I kept on changing my comments to try and
> make them clear and never finished.
>
> My comments were that the document contradicted the Abstract, that the I-
> D was mostly about VPN services and not about network level.  I concluded
> that this I-D was really two separate pieces of work, headed for two separa

[OPSAWG] IANA question regarding draft-ietf-opsawg-ipfix-srv6-srh-01

[Benoit Claise]

Dear IPFIX doctors, (IANA),

We would like to get your feedback regarding the IANA section in 
draft-ietf-opsawg-ipfix-srv6-srh-01.

Especially, the two following information elements:
srhFlagsIPv6: 
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01#section-5.1
srhSegmentEndpointBehavior: 
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01#section-5.11


I went to the IANA table in Philly and we discussed those. Hence I 
copied IANA here.
In the currentdraft-ietf-opsawg-ipfix-srv6-srh-01 
 
version, we created two IPFIX subregistries, which mimic existing 
Segment Routing registries.
The main reason is that we are in favor of having a self contained IPFIX 
IANA registry, which we can download as a cron job in the collector. We 
discussed such a project with Michelle Cotton in the past (I know that 
Michelle moved on). On top of that, it might be beneficial for the IPFIX 
experts to review any changes coming from a registry we mimic, just to 
see if there are no new inconsistencies from an IPFIX point of view.


However, Med, in cc., has a valid point that the current IPFIX IANA 
entries are inconsistencies already.

Ex: destinationTransportPort points to a different registry
Ex: tcpControlBit. See 
https://datatracker.ietf.org/doc/draft-boucadair-opsawg-rfc7125-update/
So he advocated that we don't duplicate, with an IPFIX subregistry, 
information stemming from a different source. Pointing to the existing 
registry (ex: "Segment Routing Header Flags") + a RFC reference is 
sufficient for him. Solving the self-contained IPFIX registry issue 
would be a (too) huge job at this point in time.


This is what we currently have in the draft:

   5.1
   
.
   srhFlagsIPv6

   Name:  srhFlagsIPv6

   ElementID:  TBD1

   Description:  This Information Element identifies the 8-bit flags
  defined in the SRH.  Values for this Information Element are
  listed in the "IPFIX IPv6 SRH Flags" registry, see [IANA-IPFIX  
].
  srhFlagsIPv6 values must not be directly added to this "IPFIX IPv6
  SRH Flags" registry.  They must instead be added to the "Segment
  Routing Header Flags" registry.  Both the "IPFIX IPv6 SRH Flags"
  and the "Segment Routing Header Flags" registries must be kept in
  synch.  Initial values in the registry are defined by the table
  below.

  ++---+--+
  | Value  |Description|  Reference   |
  ++---+--+
  | 0-1| Unassigned|  |
  ++---+--+
  | 2  | O-flag|  [RFC-ietf-6man-spring-srv6-oam-13]  |
  ++---+--+
  | 3-7| Unassigned|  |
  ++---+--+

   Table 2: "IPFIX IPv6 SRH Flags" registry


   Note to IANA:  Add a note to the "IPFIX SRV6 Endpoint Behavior"
  registry so that new values are echoed in the new "IPFIX SRv6
  EndPoint Behavior

   Abstract Data Type:  unsigned8

   Data Type Semantics:  flags

   Reference:  [RFC-to-be],RFC8754  


This is what Med proposes:

   5.1
   
.
   srhFlagsIPv6

   Name:  srhFlagsIPv6

   ElementID:  TBD1

   Description:  This IE identifies the 8-bit flags defined in the SRH.
 Assigned flags and their meanings are provided in the "Segment 
Routing
 Header Flags" registry.

   Abstract Data Type:  unsigned8

   Data Type Semantics:  flags

   Reference:  [RFC-to-be],RFC8754  



We basically agree that a registry lookup is required for the IPFIX 
Collector.
An IPFIX Exporter will export what he sees, regardless of the semantic 
or an IANA registry. The IPFIX Collector will report a potential problem 
if the observed value is not in the IANA registry (bug, IANA entry 
hijacked, another convention => if value not observed, I'll send an 
error code instead, etc)


Bottom line: we have two different ways to model the srhFlagsIPv6 and 
srhSegmentEndpointBehavior in IANA, with or without an IPFIX subregistry.

Can you share your views on the best way to register those IEs.

Thanks and regards, Benoit

[OPSAWG] Publication has been requested for draft-ietf-opsawg-service-assurance-yang-07

[Tianran Zhou via Datatracker]

Tianran Zhou has requested publication of 
draft-ietf-opsawg-service-assurance-yang-07 as Proposed Standard on behalf of 
the OPSAWG working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/


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

[OPSAWG] Publication has been requested for draft-ietf-opsawg-service-assurance-architecture-09

[Tianran Zhou via Datatracker]

Tianran Zhou has requested publication of 
draft-ietf-opsawg-service-assurance-architecture-09 as Informational on behalf 
of the OPSAWG working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-architecture/


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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-service-assurance-architecture-09.txt

[Jean Quilbeuf]

Dear All,
This update addresses comments from Michael Richardson.

Best,
jean

> -Original Message-
> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of internet-
> dra...@ietf.org
> Sent: Monday 26 September 2022 09:58
> To: i-d-annou...@ietf.org
> Cc: opsawg@ietf.org
> Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-service-assurance-
> architecture-09.txt
> 
> 
> 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   : Service Assurance for Intent-based Networking 
> Architecture
> Authors : Benoit Claise
>   Jean Quilbeuf
>   Diego R. Lopez
>   Dan Voyer
>   Thangam Arumugam
>   Filename: draft-ietf-opsawg-service-assurance-architecture-09.txt
>   Pages   : 26
>   Date: 2022-09-26
> 
> Abstract:
>This document describes an architecture that aims at assuring that
>service instances are running as expected.  As services rely upon
>multiple sub-services provided by a variety of elements including the
>underlying network devices and functions, getting the assurance of a
>healthy service is only possible with a holistic view of all involved
>elements.  This architecture not only helps to correlate the service
>degradation with symptoms of a specific network component but also to
>list the services impacted by the failure or degradation of a
>specific network component.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-
> architecture/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-assurance-
> architecture-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-
> architecture-09
> 
> 
> 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

[OPSAWG] I-D Action: draft-ietf-opsawg-service-assurance-architecture-09.txt

[internet-drafts]

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   : Service Assurance for Intent-based Networking 
Architecture
Authors : Benoit Claise
  Jean Quilbeuf
  Diego R. Lopez
  Dan Voyer
  Thangam Arumugam
  Filename: draft-ietf-opsawg-service-assurance-architecture-09.txt
  Pages   : 26
  Date: 2022-09-26

Abstract:
   This document describes an architecture that aims at assuring that
   service instances are running as expected.  As services rely upon
   multiple sub-services provided by a variety of elements including the
   underlying network devices and functions, getting the assurance of a
   healthy service is only possible with a holistic view of all involved
   elements.  This architecture not only helps to correlate the service
   degradation with symptoms of a specific network component but also to
   list the services impacted by the failure or degradation of a
   specific network component.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-architecture/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-assurance-architecture-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-architecture-09


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