[OPSAWG] Fwd: New Version Notification for draft-ymbk-opsawg-finding-geofeeds-01.txt

[Randy Bush]

[ the major crypto authentication done, so another author who did it
  your comments would be appreciated ]

A new version of I-D, draft-ymbk-opsawg-finding-geofeeds-01.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.

Name:   draft-ymbk-opsawg-finding-geofeeds
Revision:   01
Title:  Finding and Using Geofeed Data
Document date:  2020-09-03
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/id/draft-ymbk-opsawg-finding-geofeeds-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-ymbk-opsawg-finding-geofeeds/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds
Htmlized:   
https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds-01
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ymbk-opsawg-finding-geofeeds-01

Abstract:
   This document describes how to find and authenticate geofeed data.

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

Re: [OPSAWG] Call for adoption: draft-boydseda-ipfix-psamp-bulk-data-yang-model

[Joey Boyd]

Indeed, thank you Benoit for the detailed review. The authors are currently 
analyzing your feedback and will be preparing an updated draft as we feel that 
progressing the draft through the WG is the correct approach.

Best regards,
Joey

From: Joe Clarke (jclarke) 
Sent: Thursday, August 27, 2020 12:00 PM
To: Benoit Claise 
Cc: Joey Boyd ; opsawg@ietf.org; 
draft-boydseda-ipfix-psamp-bulk-data-yang-model@ietf.org
Subject: Re: [OPSAWG] Call for adoption: 
draft-boydseda-ipfix-psamp-bulk-data-yang-model

Thank you for your analysis, Benoit.  I appreciate you taking a deeper look 
into this document’s text than what’s been perhaps done previously in the 
various reviews.  Certainly the proposal of AD-sponsored/experimental would 
mitigate the concern around bypassing IETF process.  Though pursuing this 
route, I feel we’d run into issues ratifying this into the standards track down 
the line when there is sufficient feedback based on the other issues you raise 
(as well as potential issues beyond Section 4).

So a question to the authors and those that have recently expressed support 
(and you, Benoit) is could these issues be fixed and is there a desire to take 
on that work in this WG?  Are those changes worth doing, or would the authors 
like to move forward with your proposed approach?

Joe


On Aug 27, 2020, at 08:37, Benoit Claise 
mailto:bclaise=40cisco@dmarc.ietf.org>> 
wrote:

Dear all,

I finally spent some time reviewing 
draft-boydseda-ipfix-psamp-bulk-data-yang-model-03

A couple of observations to start with:

Let's look at the draft objectives first:
1. Obsoleting RFC 6728 with new IPFIX and PSAMP YANG modules.
RFC 6728 was the first YANG module produced outside of NETMOD. So obviously, we 
learned a lot in the mean time.
As an example, the reference to the ifIndex as opposed to ifName in 
ietf-interfaces.
So starting from a fresh new YANG module, which would follow the new YANG 
guidelines (RFC8407) and NMDA (RFC8342), is obvisously a good idea
2. Removing the SCTP constraint
The requirement is clearly to use UDP, as opposed to SCTP. This makes sense to 
me, as SCTP did not take off in NetFlow/IPFIX/PSAMP world. Now, what would the 
IESG, and transport ADs in particular, say about using UDP in a standard 
document, while it has been imposing congestion-aware protocols? If the answer 
is "no way", the answer might be an experimental RFC.
For your copious leisure time, some IPFIX history, along with my thoughts (*)
3. Bulk-data-export
It goes beyond the RFC6728 scope
What's not clear: bulk data is also for non-PSAMP data?

   This coupling and transport requirement

   makes it difficult for a device, which does not support SCTP, to use

   the model for collecting and exporting non-PSAMP bulk data.
Some feedback:

- the abstract doesn't mention the IPFIX YANG module, while 
https://tools.ietf.org/html/draft-boydseda-ipfix-psamp-bulk-data-yang-model-03#section-2
 does

- The Tree Diagrams (currently in appendix) should be moved inside the document

- You wrote:

   These are some of the other issues with the current model:



   o  The PSAMP YANG model defines the frequency of export in the PSAMP

  cache.  Bulk data needs the export frequency to be controlled by

  the exporting process.
Well, the IPFIX world, as soon as the flow expires (active and inactive 
timers), it streams out of the device b/c we speak about many flow records.
See 
https://tools.ietf.org/html/rfc5470#section-5.1.1

- Terminology.
You chose to cut/paste each definition in this draft. It's your chose, even if 
RFC6728 decided to use this format:

   o  Definitions adopted from 
[RFC5101]:

  *  Collection Process

  *  Collector

  *  Data Record

  *  Exporter

  *  Flow

  *  Flow Key

  *  Flow Record

  *  Information Element

  *  IPFIX Device

  *  IPFIX Message

  *  Observation Domain

  *  Observation Point

  *  (Options) Template
You rightly added the RFC reference in case of cut/paste.
Now, here is one issue. Metering Process and Exporting Process have their own 
definitions in RFC6728 and in this draft.
The following text, from RFC6728, is still useful IMO.

   The terms Metering Process and Exporting Process have different

   definitions in 
[RFC5101]
 and 
[RFC5476].
  In the scope of this

   document, these terms are used according to the following

   definitions, which cover the deployment in both PSAMP Devices and

   IPFIX Devices:

What you decided to do is change the Metering Process definition compared to 
RFC6728 by adding some extra 

Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-ipfix-mpls-sr-label-type

[Joe Clarke (jclarke)]

Sorry for being late to close this out.

While there was a few support emails from opsawg, they were overshadowed by 
some technical concerns from the LSR WG (who arguably would be vested in the 
implementation of draft).  The chairs don’t feel that there is enough support 
to adopt this work in its current form in opsawg.

Our suggestion is to continue to work with the LSR, SPRING, and MPLS WGs to 
refine the approach to address the concerns that have been raised as well as 
include use case examples in the document to provide guidance on implementation 
and consumption.

Finally, there may need to be some cross-WG collab and support to progress this 
work in opsawg.  Hearing from those in the above-mentioned WGs would be helpful 
to know that they can help review the work when it is ready for adoption.

Thanks.

Joe and Tianran

On Aug 13, 2020, at 08:41, Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>> 
wrote:

Hello, WG members.  During the IETF 108 virtual meeting, we had Thomas present 
this work.  It has been reviewed by SPRING as well as on this list.  The SPRING 
consensus was the work is better suited for opsawg.  The adoption hum during 
the IETF 108 virtual meeting was “Piano” which was middle of the road (though 
given the hum rules that is somewhat inconclusive).

Regardless, the chairs want to hear from the list.  This document aims to 
modernize the IPFIX MPLS label type for segment routing in order to provide 
more visibility for the MPLS-SR data plane.  Does opsawg want to adopt this 
work?

This starts a two-week call for adoption.  It will be concluded on August 27, 
2020.

Joe
___
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] vpn-common scope (was RE: CALL FOR ADOPTION: draft-bgbw-opsawg-vpn-common)

[mohamed.boucadair]

Hi Italo, 

> Regarding the approach, my preference is to include in the common
> module all the types/groupings which are common.

I think that you are arguing to add to the common module even nodes that are 
only applicable to L3 or L2 such as nodes that are common between L3NM and L3SM 
or L2NM and L2NM. This is a fair comment. 

Unless there is an objection from the WG, we will update -01 to include items 
that are common between L3xMs or L2xMs. 

Thank you for raising the point. 

Cheers,
Med

> -Message d'origine-
> De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de Italo Busi
> Envoyé : lundi 24 août 2020 11:57
> À : Joe Clarke (jclarke) ; opsawg 
> Objet : Re: [OPSAWG] CALL FOR ADOPTION: draft-bgbw-opsawg-vpn-common
> 
> I support the adoption of this draft as WG document
> 
> I think the scope of the draft/model can also be extended to be
> applicable to any service-type module and not being limited to only
> L2VPN and L3VPN. For example we can call it svc-common rather than
> vpn-common.
> 
> Regarding the approach, my preference is to include in the common
> module all the types/groupings which are common.
> 
> In order not to delay the progress of L3NM, it is possible to follow
> the same approach that has been followed in CCAMP WG with layer0-
> types: once L3NM is ready for WG LC, it is possible to move forward
> for WG LC only the common types/groupings which are needed by L3NM (as
> first revision of the common YANG module) and to move the
> types/groupings needed by other on-going work (e.g., L2NM) into a new
> draft which is intended to become a second revision of the common YANG
> module.
> 
> My 2 cents
> 
> Italo 


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [OPSAWG] AD review of draft-ietf-opsawg-tacacs-yang-07

[Wubo (lana)]

-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com] 
发送时间: 2020年9月3日 19:17
收件人: Wubo (lana) ; Rob Wilton (rwilton) 
; opsawg ; 
draft-ietf-opsawg-tacacs-yang@ietf.org
主题: Re: AD review of draft-ietf-opsawg-tacacs-yang-07

From: Wubo (lana) 
Sent: 03 September 2020 12:11

Hi Tom,

Many thanks for the review, will fix in the rev-09.



Or leave it and treat the comments as part of IETF Last Call (which I hope will 
happen soon) - I am easy either way.

Tom Petch
[Bo] Thanks for the suggestion, If Rob has additional AD comments, I'll post 
the rev-09.

Thanks,
Bo

-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com]
发送时间: 2020年9月3日 0:13
收件人: Rob Wilton (rwilton) ; opsawg 
; draft-ietf-opsawg-tacacs-yang@ietf.org
主题: Re: AD review of draft-ietf-opsawg-tacacs-yang-07

Looking at -08

Title suggest /yang/YANG/

leaf vrf-instance
might benefit from a reference to RFC8529 (ie I did not know where to look:-)

security
/cause the device vulnerable to attacks/make the device vulnerable to attacks/

IANA
Namespace /yang: ietf/yang:ietf/

Tom Petch

From: OPSAWG  on behalf of Rob Wilton (rwilton) 

Sent: 20 August 2020 11:38

Ok, my bad.  It seems that I had already done an AD review of this document :-)

Bo, there may be some additional comments that you would like to consider below 
in your -08 update.

Regards,
Rob



> -Original Message-
> From: Rob Wilton (rwilton) 
> Sent: 20 August 2020 11:23
> To: opsawg ;
> draft-ietf-opsawg-tacacs-yang@ietf.org
> Subject: AD review of draft-ietf-opsawg-tacacs-yang-07
>
> Hi,
>
> This is my AD review of draft-ietf-opsawg-tacacs-yang-07.  Sorry that 
> it has been a little while in coming.
>
> Thank you for this document, I believe that it is in good shape.  I've 
> given my slightly more significant comments first, followed by some 
> editorial comments.
>
>
> COMMENTS:
>
> "Section 3":
>
>The "statistics" container under the "server list" is to record
>session statistics and usage information during user access which
>include the amount of data a user has sent and/or received during a
>session.
>
> 1. Looking at the module, the statistics only seem to cover the number 
> of messages rather than the amount of data.  Possibly delete the part 
> of the sentence from "which include" ... to the end of the sentence.
>
>
> "Regarding the YANG module":
>
> 2. I suggest changing "tacacsplus" to "tacacs-plus" (e.g., in the 
> module title and top level nodes).
>
> 3. "shared-secret", should that be put under a choice statement?  Is 
> it likely that alternative methods of authenticating the server are 
> likely in future?
>
> 4. I'm not sure that the "tacacsplus" feature is required.  Supporting 
> the ietf-system-tacacsplus module should be sufficient to indicate 
> that the device supports TACACS+ client configuration.
>
> 5. Does the tcsplus-server-type indicate what the server is, or how 
> the server is used?  E.g., could a server have the authentication bit 
> set, but then not be used for user authentication?  Or should that be 
> prevented with a must statement?
>
> 6. Should there be a limit on the length of a server name?
>
> 7. I dont' know whether this matters, but the must statement doesn't 
> seem to be quite complete, in that it would still allow TACACS+ to be 
> listed as an authentication mechanims, but only include an accounting 
> server in the
> TACACS+ server list.
>
>
> "Security section":
>/system/tacacsplus/server:  This list contains the objects used to
>   control the TACACS+ servers used by the device.  Unauthorized
>   access to this list could cause a user management failure on the
>   device.
>
> 8. I don't know TACACS+, but I would presume that the risk of 
> accessing this list is much greater than just user management failure.
> If it was possible to modify this configuration to point to a 
> compromised TACACS+ server then would it not be possible to obtain 
> complete control over the device?  If, so I think then I think that it 
> would be helpful to make this risk clear.  [As a nit, we should 
> probably also use 'data nodes' rather than 'objects']
>
>
> "References":
>
> 9. Please can you ensure that your normative references to all RFCs 
> that define YANG modules that are imported by the YANG modules defined 
> in this document.  From a quick scan, it looked like some might be missing.
>
>
>
> EDITORIAL COMMENTS:
>
>
> Abstract:
> 1. that augment -> that augments
> 2. in the RFC 7317 with TACACS+ client model. -> in RFC 7317 with a
> TACACS+ client data model.
>
> 3. The data model of Terminal Access Controller Access Control
>System Plus (TACACS+) client allows ...-> The Terminal Access 
> Controller Access Control System Plus (TACACS+) client data model 
> allows ...
>
> Introduction:
>
> 4. This document defines a YANG module that augment the System
>Management data model defined in the [RFC7317] with TACACS+ client
>model.
>

Re: [OPSAWG] AD review of draft-ietf-opsawg-tacacs-yang-07

[tom petch]

From: Wubo (lana) 
Sent: 03 September 2020 12:11

Hi Tom,

Many thanks for the review, will fix in the rev-09.



Or leave it and treat the comments as part of IETF Last Call (which I hope will 
happen soon) - I am easy either way.

Tom Petch

Thanks,
Bo

-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com]
发送时间: 2020年9月3日 0:13
收件人: Rob Wilton (rwilton) ; opsawg 
; draft-ietf-opsawg-tacacs-yang@ietf.org
主题: Re: AD review of draft-ietf-opsawg-tacacs-yang-07

Looking at -08

Title suggest /yang/YANG/

leaf vrf-instance
might benefit from a reference to RFC8529 (ie I did not know where to look:-)

security
/cause the device vulnerable to attacks/make the device vulnerable to attacks/

IANA
Namespace /yang: ietf/yang:ietf/

Tom Petch

From: OPSAWG  on behalf of Rob Wilton (rwilton) 

Sent: 20 August 2020 11:38

Ok, my bad.  It seems that I had already done an AD review of this document :-)

Bo, there may be some additional comments that you would like to consider below 
in your -08 update.

Regards,
Rob



> -Original Message-
> From: Rob Wilton (rwilton) 
> Sent: 20 August 2020 11:23
> To: opsawg ;
> draft-ietf-opsawg-tacacs-yang@ietf.org
> Subject: AD review of draft-ietf-opsawg-tacacs-yang-07
>
> Hi,
>
> This is my AD review of draft-ietf-opsawg-tacacs-yang-07.  Sorry that
> it has been a little while in coming.
>
> Thank you for this document, I believe that it is in good shape.  I've
> given my slightly more significant comments first, followed by some
> editorial comments.
>
>
> COMMENTS:
>
> "Section 3":
>
>The "statistics" container under the "server list" is to record
>session statistics and usage information during user access which
>include the amount of data a user has sent and/or received during a
>session.
>
> 1. Looking at the module, the statistics only seem to cover the number
> of messages rather than the amount of data.  Possibly delete the part
> of the sentence from "which include" ... to the end of the sentence.
>
>
> "Regarding the YANG module":
>
> 2. I suggest changing "tacacsplus" to "tacacs-plus" (e.g., in the
> module title and top level nodes).
>
> 3. "shared-secret", should that be put under a choice statement?  Is
> it likely that alternative methods of authenticating the server are
> likely in future?
>
> 4. I'm not sure that the "tacacsplus" feature is required.  Supporting
> the ietf-system-tacacsplus module should be sufficient to indicate
> that the device supports TACACS+ client configuration.
>
> 5. Does the tcsplus-server-type indicate what the server is, or how
> the server is used?  E.g., could a server have the authentication bit
> set, but then not be used for user authentication?  Or should that be
> prevented with a must statement?
>
> 6. Should there be a limit on the length of a server name?
>
> 7. I dont' know whether this matters, but the must statement doesn't
> seem to be quite complete, in that it would still allow TACACS+ to be
> listed as an authentication mechanims, but only include an accounting
> server in the
> TACACS+ server list.
>
>
> "Security section":
>/system/tacacsplus/server:  This list contains the objects used to
>   control the TACACS+ servers used by the device.  Unauthorized
>   access to this list could cause a user management failure on the
>   device.
>
> 8. I don't know TACACS+, but I would presume that the risk of
> accessing this list is much greater than just user management failure.
> If it was possible to modify this configuration to point to a
> compromised TACACS+ server then would it not be possible to obtain
> complete control over the device?  If, so I think then I think that it
> would be helpful to make this risk clear.  [As a nit, we should
> probably also use 'data nodes' rather than 'objects']
>
>
> "References":
>
> 9. Please can you ensure that your normative references to all RFCs
> that define YANG modules that are imported by the YANG modules defined
> in this document.  From a quick scan, it looked like some might be missing.
>
>
>
> EDITORIAL COMMENTS:
>
>
> Abstract:
> 1. that augment -> that augments
> 2. in the RFC 7317 with TACACS+ client model. -> in RFC 7317 with a
> TACACS+ client data model.
>
> 3. The data model of Terminal Access Controller Access Control
>System Plus (TACACS+) client allows ...-> The Terminal Access
> Controller Access Control System Plus (TACACS+) client data model
> allows ...
>
> Introduction:
>
> 4. This document defines a YANG module that augment the System
>Management data model defined in the [RFC7317] with TACACS+ client
>model.
>
>->
>
>This document defines a YANG module that augments the System
>Management data model defined in [RFC7317] with a TACACS+ client
>data model.
>
> 5. TACACS+ provides Device Administration ->
>TACACS+ provides device administration
>
> 6. TACACS+ provides Device Administration for routers, network access
>servers and 

Re: [OPSAWG] AD review of draft-ietf-opsawg-tacacs-yang-07

[Wubo (lana)]

Hi Tom,

Many thanks for the review, will fix in the rev-09.

Thanks,
Bo

-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com] 
发送时间: 2020年9月3日 0:13
收件人: Rob Wilton (rwilton) ; opsawg 
; draft-ietf-opsawg-tacacs-yang@ietf.org
主题: Re: AD review of draft-ietf-opsawg-tacacs-yang-07

Looking at -08

Title suggest /yang/YANG/

leaf vrf-instance
might benefit from a reference to RFC8529 (ie I did not know where to look:-)

security
/cause the device vulnerable to attacks/make the device vulnerable to attacks/

IANA
Namespace /yang: ietf/yang:ietf/

Tom Petch

From: OPSAWG  on behalf of Rob Wilton (rwilton) 

Sent: 20 August 2020 11:38

Ok, my bad.  It seems that I had already done an AD review of this document :-)

Bo, there may be some additional comments that you would like to consider below 
in your -08 update.

Regards,
Rob



> -Original Message-
> From: Rob Wilton (rwilton) 
> Sent: 20 August 2020 11:23
> To: opsawg ; 
> draft-ietf-opsawg-tacacs-yang@ietf.org
> Subject: AD review of draft-ietf-opsawg-tacacs-yang-07
>
> Hi,
>
> This is my AD review of draft-ietf-opsawg-tacacs-yang-07.  Sorry that 
> it has been a little while in coming.
>
> Thank you for this document, I believe that it is in good shape.  I've 
> given my slightly more significant comments first, followed by some 
> editorial comments.
>
>
> COMMENTS:
>
> "Section 3":
>
>The "statistics" container under the "server list" is to record
>session statistics and usage information during user access which
>include the amount of data a user has sent and/or received during a
>session.
>
> 1. Looking at the module, the statistics only seem to cover the number 
> of messages rather than the amount of data.  Possibly delete the part 
> of the sentence from "which include" ... to the end of the sentence.
>
>
> "Regarding the YANG module":
>
> 2. I suggest changing "tacacsplus" to "tacacs-plus" (e.g., in the 
> module title and top level nodes).
>
> 3. "shared-secret", should that be put under a choice statement?  Is 
> it likely that alternative methods of authenticating the server are 
> likely in future?
>
> 4. I'm not sure that the "tacacsplus" feature is required.  Supporting 
> the ietf-system-tacacsplus module should be sufficient to indicate 
> that the device supports TACACS+ client configuration.
>
> 5. Does the tcsplus-server-type indicate what the server is, or how 
> the server is used?  E.g., could a server have the authentication bit 
> set, but then not be used for user authentication?  Or should that be 
> prevented with a must statement?
>
> 6. Should there be a limit on the length of a server name?
>
> 7. I dont' know whether this matters, but the must statement doesn't 
> seem to be quite complete, in that it would still allow TACACS+ to be 
> listed as an authentication mechanims, but only include an accounting 
> server in the
> TACACS+ server list.
>
>
> "Security section":
>/system/tacacsplus/server:  This list contains the objects used to
>   control the TACACS+ servers used by the device.  Unauthorized
>   access to this list could cause a user management failure on the
>   device.
>
> 8. I don't know TACACS+, but I would presume that the risk of 
> accessing this list is much greater than just user management failure.  
> If it was possible to modify this configuration to point to a 
> compromised TACACS+ server then would it not be possible to obtain 
> complete control over the device?  If, so I think then I think that it 
> would be helpful to make this risk clear.  [As a nit, we should 
> probably also use 'data nodes' rather than 'objects']
>
>
> "References":
>
> 9. Please can you ensure that your normative references to all RFCs 
> that define YANG modules that are imported by the YANG modules defined 
> in this document.  From a quick scan, it looked like some might be missing.
>
>
>
> EDITORIAL COMMENTS:
>
>
> Abstract:
> 1. that augment -> that augments
> 2. in the RFC 7317 with TACACS+ client model. -> in RFC 7317 with a
> TACACS+ client data model.
>
> 3. The data model of Terminal Access Controller Access Control
>System Plus (TACACS+) client allows ...-> The Terminal Access 
> Controller Access Control System Plus (TACACS+) client data model 
> allows ...
>
> Introduction:
>
> 4. This document defines a YANG module that augment the System
>Management data model defined in the [RFC7317] with TACACS+ client
>model.
>
>->
>
>This document defines a YANG module that augments the System
>Management data model defined in [RFC7317] with a TACACS+ client
>data model.
>
> 5. TACACS+ provides Device Administration ->
>TACACS+ provides device administration
>
> 6. TACACS+ provides Device Administration for routers, network access
>servers and other networked computing devices via one or more
>centralized servers which is defined in the TACACS+ Protocol.
>[I-D.ietf-opsawg-tacacs]
>
>

[OPSAWG] retake LxNM calls

[Oscar González de Dios]

Dear Opsa wg colleagues,

During the summer period that followed last IETF meeting people 
several people had holidays, so there were no attendance to the LxNM calls. 
Hence, it is time to retake now the LxNM calls (reminder every Thursday at 
15:00 CEST). The invitation sent by Joe to the list is still valid. If someone 
has lost the invitation, just check the list history, or ask and I can resend 
it.

As a reminder, the open topics are available in the git 
repository https://github.com/IETF-OPSAWG-WG/l3nm  and 
https://github.com/IETF-OPSAWG-WG/l2nm

Best Regards,

   Oscar



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Dhruv's comments (RE: CALL FOR ADOPTION: draft-bgbw-opsawg-vpn-common)

[mohamed.boucadair]

Re-,

Sure.

Please expect the changes to be implemented -01.

Thank you.

Cheers,
Med

De : Dhruv Dhody [mailto:dhruv.i...@gmail.com]
Envoyé : jeudi 3 septembre 2020 11:09
À : BOUCADAIR Mohamed TGI/OLN 
Cc : opsawg 
Objet : Re: Dhruv's comments (RE: [OPSAWG] CALL FOR ADOPTION: 
draft-bgbw-opsawg-vpn-common)

Hi Med,

Thanks for considering my comments.

> - This text
>
>To avoid the issues discussed above, this document defines a common
>YANG module that is meant to be reused by various VPN-related
> modules
>such as Layer 3 VPN Service Model (L3SM) [RFC8299], Layer 2 VPN
>Service Model (L2SM) [RFC8466], Layer 3 VPN Network Model (L3NM)
>[I-D.ietf-opsawg-l3sm-l3nm], and Layer 2 VPN Network Model (L2NM)
>[I-D.ietf-opsawg-l2nm]: "ietf-vpn-common" (Section 4).
>
> While it is clear how this common model can be used by work-in-
> progress L3NM and L2NM models, I am not sure about the published
> service model. Maybe you want to suggest that a future update of these
> service models MAY use this common model? If yes, better to be
> explicit.
>

[Med] What about:

OLD:
   To avoid the issues discussed above, this document defines a common
   YANG module that is meant to be reused by various VPN-related modules
   such as Layer 3 VPN Service Model (L3SM) [RFC8299], Layer 2 VPN
   Service Model (L2SM) [RFC8466], Layer 3 VPN Network Model (L3NM)
   [I-D.ietf-opsawg-l3sm-l3nm], and Layer 2 VPN Network Model (L2NM)
   [I-D.ietf-opsawg-l2nm]: "ietf-vpn-common" (Section 4).

   The "ietf-vpn-common" module includes a set of identities, types, and
   groupings that are meant to be reused by other VPN-related YANG
   modules independently of their layer (e.g., Layer 2, Layer 3) and the
   type of the module (e.g., network model, service model) including
   future revisions of existing models (e.g., L3SM [RFC8299] or L3SM
   [RFC8466]).

NEW:
   To avoid the issues discussed above, this document defines a common
   YANG module that is meant to be reused by various VPN-related modules
   such as Layer 3 VPN Network Model (L3NM) [I-D.ietf-opsawg-l3sm-l3nm]
   and Layer 2 VPN Network Model (L2NM)[I-D.ietf-opsawg-l2nm]:
   "ietf-vpn-common" (Section 4).

   The "ietf-vpn-common" module includes a set of identities, types, and
   groupings that are meant to be reused by other VPN-related YANG
   modules independently of their layer (e.g., Layer 2, Layer 3) and the
   type of the module (e.g., network model, service model) including
   future revisions of existing models (e.g., Layer 3 VPN Service Model
   (L3SM) [RFC8299] or Layer 2 VPN Service Model (L2SM) [RFC8466]).

Would you also consider adding the word "possible" in front of "future 
revisions of existing models" in the last sentence to highlight the fact that 
no such revision is planned as of now.

Thanks!
Dhruv

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [OPSAWG] Dhruv's comments (RE: CALL FOR ADOPTION: draft-bgbw-opsawg-vpn-common)

[Dhruv Dhody]

Hi Med,

Thanks for considering my comments.

> - This text
> >
> >To avoid the issues discussed above, this document defines a common
> >YANG module that is meant to be reused by various VPN-related
> > modules
> >such as Layer 3 VPN Service Model (L3SM) [RFC8299], Layer 2 VPN
> >Service Model (L2SM) [RFC8466], Layer 3 VPN Network Model (L3NM)
> >[I-D.ietf-opsawg-l3sm-l3nm], and Layer 2 VPN Network Model (L2NM)
> >[I-D.ietf-opsawg-l2nm]: "ietf-vpn-common" (Section 4).
> >
> > While it is clear how this common model can be used by work-in-
> > progress L3NM and L2NM models, I am not sure about the published
> > service model. Maybe you want to suggest that a future update of these
> > service models MAY use this common model? If yes, better to be
> > explicit.
> >
>
> [Med] What about:
>
> OLD:
>To avoid the issues discussed above, this document defines a common
>YANG module that is meant to be reused by various VPN-related modules
>such as Layer 3 VPN Service Model (L3SM) [RFC8299], Layer 2 VPN
>Service Model (L2SM) [RFC8466], Layer 3 VPN Network Model (L3NM)
>[I-D.ietf-opsawg-l3sm-l3nm], and Layer 2 VPN Network Model (L2NM)
>[I-D.ietf-opsawg-l2nm]: "ietf-vpn-common" (Section 4).
>
>The "ietf-vpn-common" module includes a set of identities, types, and
>groupings that are meant to be reused by other VPN-related YANG
>modules independently of their layer (e.g., Layer 2, Layer 3) and the
>type of the module (e.g., network model, service model) including
>future revisions of existing models (e.g., L3SM [RFC8299] or L3SM
>[RFC8466]).
>
> NEW:
>To avoid the issues discussed above, this document defines a common
>YANG module that is meant to be reused by various VPN-related modules
>such as Layer 3 VPN Network Model (L3NM) [I-D.ietf-opsawg-l3sm-l3nm]
>and Layer 2 VPN Network Model (L2NM)[I-D.ietf-opsawg-l2nm]:
>"ietf-vpn-common" (Section 4).
>
>The "ietf-vpn-common" module includes a set of identities, types, and
>groupings that are meant to be reused by other VPN-related YANG
>modules independently of their layer (e.g., Layer 2, Layer 3) and the
>type of the module (e.g., network model, service model) including
>future revisions of existing models (e.g., Layer 3 VPN Service Model
>(L3SM) [RFC8299] or Layer 2 VPN Service Model (L2SM) [RFC8466]).
>

Would you also consider adding the word "possible" in front of "future
revisions of existing models" in the last sentence to highlight the fact
that no such revision is planned as of now.

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

[OPSAWG] Dhruv's comments (RE: CALL FOR ADOPTION: draft-bgbw-opsawg-vpn-common)

[mohamed.boucadair]

Hi Dhruv, 

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de Dhruv Dhody
> Envoyé : mercredi 26 août 2020 16:48
> À : Joe Clarke (jclarke) 
> Cc : opsawg 
> Objet : Re: [OPSAWG] CALL FOR ADOPTION: draft-bgbw-opsawg-vpn-common
> 
> Hi WG,
> 
> I support adoption. Just a few thoughts...
> 
> - This document has "Updates: 8782" in its header. Surely a mistake!

[Med] Yeah. Fixed now in draft-ietf-opsawg-vpn-common-00. 

> - This text
> 
>To avoid the issues discussed above, this document defines a common
>YANG module that is meant to be reused by various VPN-related
> modules
>such as Layer 3 VPN Service Model (L3SM) [RFC8299], Layer 2 VPN
>Service Model (L2SM) [RFC8466], Layer 3 VPN Network Model (L3NM)
>[I-D.ietf-opsawg-l3sm-l3nm], and Layer 2 VPN Network Model (L2NM)
>[I-D.ietf-opsawg-l2nm]: "ietf-vpn-common" (Section 4).
> 
> While it is clear how this common model can be used by work-in-
> progress L3NM and L2NM models, I am not sure about the published
> service model. Maybe you want to suggest that a future update of these
> service models MAY use this common model? If yes, better to be
> explicit.
> 

[Med] What about: 

OLD:
   To avoid the issues discussed above, this document defines a common
   YANG module that is meant to be reused by various VPN-related modules
   such as Layer 3 VPN Service Model (L3SM) [RFC8299], Layer 2 VPN
   Service Model (L2SM) [RFC8466], Layer 3 VPN Network Model (L3NM)
   [I-D.ietf-opsawg-l3sm-l3nm], and Layer 2 VPN Network Model (L2NM)
   [I-D.ietf-opsawg-l2nm]: "ietf-vpn-common" (Section 4).

   The "ietf-vpn-common" module includes a set of identities, types, and
   groupings that are meant to be reused by other VPN-related YANG
   modules independently of their layer (e.g., Layer 2, Layer 3) and the
   type of the module (e.g., network model, service model) including
   future revisions of existing models (e.g., L3SM [RFC8299] or L3SM
   [RFC8466]).

NEW:
   To avoid the issues discussed above, this document defines a common
   YANG module that is meant to be reused by various VPN-related modules
   such as Layer 3 VPN Network Model (L3NM) [I-D.ietf-opsawg-l3sm-l3nm] 
   and Layer 2 VPN Network Model (L2NM)[I-D.ietf-opsawg-l2nm]: 
   "ietf-vpn-common" (Section 4).

   The "ietf-vpn-common" module includes a set of identities, types, and
   groupings that are meant to be reused by other VPN-related YANG
   modules independently of their layer (e.g., Layer 2, Layer 3) and the
   type of the module (e.g., network model, service model) including
   future revisions of existing models (e.g., Layer 3 VPN Service Model 
   (L3SM) [RFC8299] or Layer 2 VPN Service Model (L2SM) [RFC8466]).

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[OPSAWG] svc-common (RE: CALL FOR ADOPTION: draft-bgbw-opsawg-vpn-common

[mohamed.boucadair]

Hi Italo, 

I'm afraid that "svc-common" is too generic and does not reflect what we are 
planning to do in this draft: L2/L3 VPNs. I suggest we maintain the initial 
scope and name. 

Thank you. 

Cheers,
Med

> -Message d'origine-
> De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de Italo Busi
> Envoyé : lundi 24 août 2020 11:57
> À : Joe Clarke (jclarke) ; opsawg 
> Objet : Re: [OPSAWG] CALL FOR ADOPTION: draft-bgbw-opsawg-vpn-common
> 
> I support the adoption of this draft as WG document
> 
> I think the scope of the draft/model can also be extended to be
> applicable to any service-type module and not being limited to only
> L2VPN and L3VPN. For example we can call it svc-common rather than
> vpn-common.
> 
> Regarding the approach, my preference is to include in the common
> module all the types/groupings which are common.
> 
> In order not to delay the progress of L3NM, it is possible to follow
> the same approach that has been followed in CCAMP WG with layer0-
> types: once L3NM is ready for WG LC, it is possible to move forward
> for WG LC only the common types/groupings which are needed by L3NM (as
> first revision of the common YANG module) and to move the
> types/groupings needed by other on-going work (e.g., L2NM) into a new
> draft which is intended to become a second revision of the common YANG
> module.
> 
> My 2 cents
> 
> Italo
> 


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[OPSAWG] I-D Action: draft-ietf-opsawg-vpn-common-00.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   : A Layer 2/3 VPN Common YANG Model
Authors : Samier Barguil
  Oscar Gonzalez de Dios
  Mohamed Boucadair
  Qin Wu
Filename: draft-ietf-opsawg-vpn-common-00.txt
Pages   : 34
Date: 2020-09-02

Abstract:
   This document defines a common YANG module that is meant to be reused
   by various VPN-related modules such as Layer 3 VPN Service Model,
   Layer 2 VPN Service Model, Layer 3 VPN Network Model, and Layer 2 VPN
   Network Model.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-vpn-common-00
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-vpn-common-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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