[OPSAWG]Re: WG LC: Attachment circuits work

[Wubo (lana)]

Hi Joe, all,

AC service model defines the general AC model, covering both Layer2 and Layer3 
attributes, and also enhances bearer, profiles and protocols etc..

While RFC 8299 L3SM also defines L3 AC and RFC 8466 L2SM defines L2 AC, I think 
a comparison might help to choose the appropriate model and would like to seek 
WG feedback.

The authors did some discussion in the  weekly call, but we think this 
comparison can be useful if this content is put into the github because the 
list is a bit long and contains YANG details.

Thanks,
Bo

发件人: Teas [mailto:teas-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2024年4月19日 22:41
收件人: opsawg@ietf.org
抄送: Traffic Engineering Architecture and Signaling Discussion List 
mailto:t...@ietf.org>>
主题: [Teas] WG LC: Attachment circuits work

Thanks to efforts by the WG and cross-collaboration with TEAS, these four 
drafts are at the point to run a WG LC.  All currently reported issues have 
been resolved by the authors, and we are grateful to have four volunteers for 
shepherds.

The Attachment Circuits work is divided into four documents:

https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntw-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ac-lxsm-lxnm-glue/

Given the size of the work, we will run for a three-week LC period (closing on 
May 10), and we are copying teas@ for additional reviews.  Please reply on-list 
with comments.

Joe



   +-+---+--+
   | |   |  |
   | |  AC Service   |  L3SM SNA|
   +-+---+--+
   | |bearer-svc | no equivalent|
   | | sync-ethernet |  |
   |bearer as service| lag   |  |
   | | status|  |
   +---+-+---+--+
   |   | |   |  |
   |   | |encryption |encryption|
   |profile|service-profile  |qos|qos   |
   |   | |bfd|bfd   |
   |   | |forwarding |  |
   |   | |routing|  |
   |   +-+---+--+
   |   | |   |  |
   |   |constraints  |placement  |access-diversity  |
   +---+-+---+--+
   | |bearer-ref |bearer-ref|
   | |l2-connection  |  |
   |l2-connection|   |  |
   +-+---+--+
   | |virtual-address|  |
   |ip-connection|dynamic address|dynamic dhcp  |
   | |pool and dhcp  |  |
   | |static-address |static-address|
   +---+-+---+--+
   |   | static  |ip-prefix  |ip-prefix |
   |   | |bfd|  |
   |   | |status |  |
   +   +-+---+--+
   |   | bgp |neighbors add  |One neighbor  |
   |   | |authentication |with as and   |
   |   | |status |address-family|
   |   | |bfd|  |
   |   | |peer-groups|  |
   +   +-+---+--+
   |   | ospf|area-id|area-id   |
   |  Routing  | |address-family |address-family|
   |   | |authentication |  |
   |   | |status |  |
   +   +-+---+--+
   |   | isis|authentication | none |
   |   | |status |  |
   +   +-+---+--+
   |   | rip |address-family | address-family   |
   |   | |authentication |  |
   |   | |status

Re: [OPSAWG] IPR POLL: Attachment circuits work

[Wubo (lana)]

Hi Joe, all,

No, I'm not aware of any IPR that applies to these drafts.

Thanks,
Bo

From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: Friday, April 19, 2024 10:32 PM
To: opsawg@ietf.org
Subject: [OPSAWG] IPR POLL: Attachment circuits work

We're up to WG LC on these four drafts.  And while we did an IPR poll before, 
we want to be thorough since this work has evolved.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntw-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ac-lxsm-lxnm-glue/

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to these drafts"
or
"Yes, I'm aware of IPR that applies to these drafts"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

As of this time, no IPR has been disclosed on any of the four drafts.

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

Re: [OPSAWG] CALL FOR ADOPTION: Attachment circuits work

[Wubo (lana)]

Hi Joe, all,

I support the adoption of the four drafts. These four drafts are a good 
supplement to the existing VPN and IETF Network Slice service models. 
Decoupling ACs from service models improves service deployment flexibility. And 
the network slice service model has already added ac-as-service method.

I have one review comment for draft-boro-opsawg-ac-lxsm-lxnm-glue. I see that a 
leaf-list of "ac-ref" is defined for lxsm:site-network-access/ 
lxnm:vpn-network-access, which I can understand the 1:1 mapping relationship 
between site-network-access/vpn-network-access and AC, for one-to-many mapping, 
I would suggest to give some examples to clarify the scenarios.

Thanks,
Bo Wu

From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: Monday, October 2, 2023 9:22 PM
To: opsawg@ietf.org
Subject: [OPSAWG] CALL FOR ADOPTION: Attachment circuits work

At IETF 117, we asked the room if there was support to adopt the four 
attachment circuits drafts.  The room had support (of the 75 present, 18 raised 
hands for adoption interest, 1 was opposed), but the list is where it counts.

While the drafts aren't too terribly long, there are four of them, so we will 
do a three week call for adoption.  Please review and comment on-list on the 
following indicating whether you support their adoption or not:

* draft-boro-opsawg-teas-common-ac
* draft-boro-opsawg-teas-attachment-circuit
* draft-boro-opsawg-ntw-attachment-circuit
* draft-boro-opsawg-ac-lxsm-lxnm-glue

The authors and contributors have all signaled there is no known IPR covering 
this work.

The CfA will end on October 23.

Thanks.

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

Re: [OPSAWG] IPR POLL: Attachment circuits work

[Wubo (lana)]

Hi Joe, all,

No, I'm not aware of any IPR that applies to these four drafts.

Thanks,
Bo Wu
From: Joe Clarke (jclarke) 
Sent: Monday, September 25, 2023 11:29 PM
To: opsawg@ietf.org; mohamed.boucadair ; Richard 
Roberts ; Oscar González de Dios 
; samir.barg...@gmail.com; Wubo (lana) 
; victor.lo...@nokia.com; ivan.by...@rbbn.com; Qin Wu 
; ke-oog...@kddi.com; luis-angel.mu...@vodafone.com
Subject: IPR POLL: Attachment circuits work


This is a consolidated poll for the following drafts:
· draft-boro-opsawg-teas-common-ac
· draft-boro-opsawg-teas-attachment-circuit
· draft-boro-opsawg-ntw-attachment-circuit
· draft-boro-opsawg-ac-lxsm-lxnm-glue

Authors and contributors on the To: line, please respond on-list as to whether 
or not you are aware of any IPR that pertains to this work.
Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If you are aware of IPR, indicate whether or not this has been disclosed per 
IETF IPR rules (see RFCs 3669, 5378, and 8179).

Joe

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

Re: [OPSAWG] [Inventory-yang] Getting rid of network-hardware-inventory container for straightfoward model alignment that satisfies both hardware inventory needs and generalization/extensibility goals

[Wubo (lana)]

Hi Alex, all,

Thanks for your detailed clarification. I think your suggestion makes a lot of 
sense to me. An independent NE location model can be extended for various 
outdoor and indoor scenarios, and the separate network inventory model can 
apply to more general network scenarios.

Thanks,
Bo Wu
From: Alexander L Clemm 
Sent: Tuesday, September 12, 2023 2:25 AM
To: Wubo (lana) ; maqiufang (A) 
; inventory-y...@ietf.org
Cc: ivy-cha...@ietf.org; opsawg ; cc...@ietf.org
Subject: Re: [Inventory-yang] [OPSAWG] Getting rid of 
network-hardware-inventory container for straightfoward model alignment that 
satisfies both hardware inventory needs and generalization/extensibility goals 
(was: Re: [inventory-yang] poll for network invento...


Hello Bo, all,

to your question:  With the two inventory models, I was referring to the two 
models in the two drafts as per the poll, i.e.:

(1) draft-ietf-ccamp-network-inventory-yang-02 (ietf-network-hardware-inventory)

 (2) draft-wzwb-opsawg-network-inventory-management-03 (ietf-network-inventory)

To recap the point I was trying to made:  I think both models are closer than 
it may initially appear.  The main obstacle to aligning is the top-level 
container in ietf-network-hardware-inventory, "network-hardware-inventory".  
This object seems to serve no particular purpose, so could be easily removed.  
In doing so, "equipment-rooms" and "network-elements" would become top level 
objects, separable into separate modules (both of which can be specified in the 
same draft, of course).  It will make sense for equipment-rooms to stand on its 
own anway since this contains _location_ information - this information can of 
course be referenced by items in the inventory, but the rooms by themselves are 
not part of the network-hardware-inventory (as the current model seems to 
suggest) and locations other than rooms are conceivable in some cases.  So, not 
only will removing the top-level container make ietf-network-hardware-inventory 
facilitate alignment, but it will also arguably result in a "better" model.

Looking forward to continued discussions

--- Alex
On 9/11/2023 2:19 AM, Wubo (lana) wrote:
Hi Alex, all,

It seems to me you mentioned two IVY models, one is the BASE inventory model 
with minimum inventory attributes, and the other seems to be the CORE inventory 
model, which is the major requirements as charter B. Hardware/Software 
components including licenses. Am I correct?

In addition, you also mentioned that the CCAMP "network-hardware-inventory" may 
develop independently, as the requirements seems different from the IVY core 
model, since the equipment room is only for the indoor RACK location, not for 
the outdoor location.

I also have the same doubts. Is the goal of CCAMP inventory same as IVY CORE 
inventory model? Last Wednesday CCAMP inventory weekly call, I explained the 
following use cases from draft-wzwb-opsawg-network-inventory-management and 
proposed the merged network inventory model :
1. Virtual devices, such as vCPE, vPE, vBNG, etc.
2. Software components, including device platform software, software patch, 
boot-rom, bootloader, etc.
3. Site as a location option
4. License list
5. Terms of network inventory, including network inventory, network element, 
and components
6. The merged network inventory model

Here is some feedback and summary got on the call:

1.   Some authors say virtual device, and software components are not 
considered, as the purpose of CCAMP inventory is to meet ACTN Packet Optical 
integration (POI) requirements for optical and IP multi-domain TE cases etc, 
https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-poi-applicability#section-4.


2. Some author shared the inventory information of Cisco vPE, indicating that 
virtual devices share the same inventory attributes just as physical devices:
RP/0/RP0/CPU0:ron-srpce-791#show inventory all Wed Sep 6 14:50:04.239 UTC
NAME: "0/0", DESCR: "Cisco IOS-XRv 9000 Centralized Line Card"
PID: R-IOSXRV9000-LC-C, VID: V01, SN: B3BC8301B42 NAME: "0/0/0", DESCR: "N/A"
PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/1", DESCR: "N/A"
PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/2", DESCR: "N/A"
PID: PORT-1G-NIC, VID: N/A,SN: N/A NAME: "0/0/3", DESCR: "N/A"
PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/4", DESCR: "N/A"
PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/5", DESCR: "N/A"
PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/6", DESCR: "N/A"
PID: PORT-1G-NIC, VID: N/A, SN: N/A
NAME: "0/RP0", DESCR: "Cisco IOS-XRv 9000 Centralized Route Processor"
PID: R-IOSXRV9000-RP-C, VID: V01, SN: 59D4943FFB2 NAME: "Rack 0", DESCR: "Cisco 
IOS-XRv 9000 Centralized Virtual Router"
PID: R-IOSXRV9000-CC, VID: V01, SN: 76E77892EA1

Re: [OPSAWG] Getting rid of network-hardware-inventory container for straightfoward model alignment that satisfies both hardware inventory needs and generalization/extensibility goals (was: Re: [inven

[Wubo (lana)]

Hi Alex, all,

It seems to me you mentioned two IVY models, one is the BASE inventory model 
with minimum inventory attributes, and the other seems to be the CORE inventory 
model, which is the major requirements as charter B. Hardware/Software 
components including licenses. Am I correct?

In addition, you also mentioned that the CCAMP "network-hardware-inventory" may 
develop independently, as the requirements seems different from the IVY core 
model, since the equipment room is only for the indoor RACK location, not for 
the outdoor location.

I also have the same doubts. Is the goal of CCAMP inventory same as IVY CORE 
inventory model? Last Wednesday CCAMP inventory weekly call, I explained the 
following use cases from draft-wzwb-opsawg-network-inventory-management and 
proposed the merged network inventory model :
1. Virtual devices, such as vCPE, vPE, vBNG, etc.
2. Software components, including device platform software, software patch, 
boot-rom, bootloader, etc.
3. Site as a location option
4. License list
5. Terms of network inventory, including network inventory, network element, 
and components
6. The merged network inventory model

Here is some feedback and summary got on the call:

1.   Some authors say virtual device, and software components are not 
considered, as the purpose of CCAMP inventory is to meet ACTN Packet Optical 
integration (POI) requirements for optical and IP multi-domain TE cases etc, 
https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-poi-applicability#section-4.


2. Some author shared the inventory information of Cisco vPE, indicating that 
virtual devices share the same inventory attributes just as physical devices:
RP/0/RP0/CPU0:ron-srpce-791#show inventory all Wed Sep 6 14:50:04.239 UTC
NAME: "0/0", DESCR: "Cisco IOS-XRv 9000 Centralized Line Card"
PID: R-IOSXRV9000-LC-C, VID: V01, SN: B3BC8301B42 NAME: "0/0/0", DESCR: "N/A"
PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/1", DESCR: "N/A"
PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/2", DESCR: "N/A"
PID: PORT-1G-NIC, VID: N/A,SN: N/A NAME: "0/0/3", DESCR: "N/A"
PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/4", DESCR: "N/A"
PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/5", DESCR: "N/A"
PID: PORT-1G-NIC, VID: N/A, SN: N/A NAME: "0/0/6", DESCR: "N/A"
PID: PORT-1G-NIC, VID: N/A, SN: N/A
NAME: "0/RP0", DESCR: "Cisco IOS-XRv 9000 Centralized Route Processor"
PID: R-IOSXRV9000-RP-C, VID: V01, SN: 59D4943FFB2 NAME: "Rack 0", DESCR: "Cisco 
IOS-XRv 9000 Centralized Virtual Router"
PID: R-IOSXRV9000-CC, VID: V01, SN: 76E77892EA1

3. The author has previously discussed the extension of sites and licenses.

4. The authors and contributors took a quick look at the merged model, and we 
plan to continue the discussion on this week.

Thanks,
Bo Wu

From: OPSAWG  On Behalf Of Alexander L Clemm
Sent: Thursday, September 7, 2023 4:59 AM
To: maqiufang (A) ; 
inventory-y...@ietf.org
Cc: ivy-cha...@ietf.org; opsawg ; cc...@ietf.org
Subject: [OPSAWG] Getting rid of network-hardware-inventory container for 
straightfoward model alignment that satisfies both hardware inventory needs and 
generalization/extensibility goals (was: Re: [inventory-yang] poll for network 
inventory base model)


Hi all,

I have been looking at both of the inventory models that have been proposed and 
think that they are actually closer than it might seem and that it should be 
relatively straightforward to align them.

The main obstacle seems to the top container object 
"network-hardware-inventory" in draft-ietf-ccamp-network-inventory-yang.  Is 
this data node really important?  It seems to serve not particular function, 
other than serving as a container for equipment room  and network-elements.  
However, both could easily stand on their own; there does not seem to be a 
compelling reason that instances would need to be prefixed with 
"network-hardware-inventory/".

By removing this object, we get in effect two separate modules - one for 
equipment-room, the other for network-elements.  This makes sense anyway, as 
only network-elements are items subject to inventorying and equipment-room can 
stand on its own, providing auxiliary information independent of actual 
inventory (plus allowing for network elements to be housed also outside 
equipment rooms  (Plus, depending on use case, not every network element may 
not be located in an equipment room with racks/rows/columns, but possibly in 
other locations eg roadside etc).

The structure of network-elements now very much resembles the same structure as 
we have in draft-wzwb-opsawg-network-inventory-management.  Yes, the list is 
defined in the model, instead of reusing / augmenting the list of nodes, but 
this is a detail - the main thing is the structures are aligned.

The main difference from this point out concerns the actual parameters that are 
actually included.  Both models have a set of parameters in common.  
draft-ietf-ccamp-network-inventory-yang includes a couple of additional 

Re: [OPSAWG] [inventory-yang] poll for network inventory base model

[Wubo (lana)]

Hi Qiufang, Daniele, all,

I voted for option 3. As I read the whole draft of option 1, the content is 
very hardware-centric. I think the attributes of physical and virtual devices, 
or the attributes of software and hardware components, are quite common and can 
be shared rather than augmentation.

I believe the inventory base model is a generic model, not limited to hardware 
inventory.

Thanks,
Bo Wu

From: Inventory-yang  On Behalf Of maqiufang 
(A)
Sent: Monday, August 28, 2023 2:22 PM
To: inventory-y...@ietf.org
Cc: ivy-cha...@ietf.org; opsawg ; cc...@ietf.org
Subject: [Inventory-yang] [inventory-yang] poll for network inventory base model

Hi Working Group,

It's now time to start considering how to move forward with the inventory base 
model. We have two different documents that could be used as a starting point 
for our work or, in case the working group believes none of them is "good 
enough", we can start a brand new ID.
In case the latter option is chosen, Daniele and I will write a -00 version 
including just the table of content and what we'd like to be covered in each 
section. The document will then be handed over to a pool of authors which will 
bring it till the WG adoption.

Hence, we will have a 3 weeks polling starting today. We decided to make it a 
bit longer than usual because this time the working group is requested to 
review two drafts instead of one.

This mail starts a 3 weeks polling, terminating on September 15th,  where we 
would like the working group to express your preference among:

1.   Adopt  draft-ietf-ccamp-network-inventory-yang-02 in IVY and evolve it 
to become the network inventory base model
2.   Adopt draft-wzwb-opsawg-network-inventory-management-03 in IVY and 
evolve it to become the network inventory base model
3.   Start a brand new document from scratch as described above

In the week after the closure of the polling (between September 18 and 25) we 
will have an IVY interim meeting to discuss the issues/concerns raised during 
the polling ( A separate mail will be sent).

Thank you,

Qiufang and Daniele

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

Re: [OPSAWG] New Version Notification for draft-wzwb-opsawg-network-inventory-management-01.txt

[Wubo (lana)]

Hi Marisol,

Thanks for your question. The note is about the questions on the definition of 
entitlement/license in the asset YANG model.

1)It seems the following is related to the attributes of the inventory, such as 
whether the license is applied to hardware, or deployed in the enterprise 
sites, etc..Correct?
  identity offer-type-t {
description
  "License Offer Type, part of the plan to generate revenue
   for specific asset";
  }
  identity perpetual-software {
  base offer-type-t;
  description
  "Perpetual softwar gives the user the right to use the
   program indefinitely";
  }
  identity standalone-hardware {
  base offer-type-t;
  description
  "Standalone hardware is able to function independently
   of other hardware";
  }
  identity on-premise-software-subscription {
  base offer-type-t;
  description
  "On-Premise software subscription, relates to a temporary
   on-prem licencing model, allowing users to pay a per user
   fee";
  }
  identity cloud-software-saas-subscription {
  base offer-type-t;
  description
  "Cloud Software (SaaS) subscription is a service busines
   model where the user is entitled to use the cloud software
   for a specific time period";
  }
  identity third-party-software {
  base offer-type-t;
  description
  "It includes licenses, entitlements, agreements, obligations
  or other commitment under which the user can use the asset
  not directly sold by the manufacturer";
  }
  identity flex-cloud-prem-subscription {
  base offer-type-t;
  description
  "Flex Cloud-Prem subscription allows software vendors to
  limit the number of entitlements for the use of the specific
  asset";
  }

2) :The draft says the focus is on asset-centric lifecycle management and refer 
it as Lifecycle Management and Operations (LMO). Could you elaborate on why an 
entitlement is also a class of lmo?
A entitlement is a class of lmo that represents how the asset(s) or feature(s) 
can be leveraged and what is required in cases the asset(s) or feature(s) are 
changed


Thanks,
Bo


From: Inventory-yang [mailto:inventory-yang-boun...@ietf.org] On Behalf Of 
Marisol Palmero Amador (mpalmero)
Sent: Friday, February 17, 2023 6:53 PM
To: Wubo (lana) ; opsawg@ietf.org; 
inventory-y...@ietf.org
Subject: Re: [Inventory-yang] New Version Notification for 
draft-wzwb-opsawg-network-inventory-management-01.txt

Hi Bo,
Could you please elaborate on your note?

>From your email:
Regarding licenses (or entitlements in draft-palmero-opsawg-dmlmo-09), some 
licenses may affect the functions of physical components or software 
components, though having removed from the current model, but we feel further 
discussion is needed.


Please let me know how I could help to clarify or facilitate the discussion,
Many thanks,
Marisol

Marisol Palmero
CCIE #5122 | Technical Leader EMEA  | Cisco CPX TEAO | P: +34.91.201.2643 | M: 
+34.629.634.595


From: Inventory-yang 
mailto:inventory-yang-boun...@ietf.org>> on 
behalf of Wubo (lana) 
mailto:lana.wubo=40huawei@dmarc.ietf.org>>
Date: Thursday, 16 February 2023 at 11:02
To: opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>, 
inventory-y...@ietf.org<mailto:inventory-y...@ietf.org> 
mailto:inventory-y...@ietf.org>>
Subject: Re: [Inventory-yang] New Version Notification for 
draft-wzwb-opsawg-network-inventory-management-01.txt
Dear Opsawg, inventory colleges,

Based on the review comments from Marisol and authors of 
draft-ietf-ccamp-network-inventory-yang, we update the network inventory draft.

Compared with the network hardware inventory in CCAMP, this model has following 
consideration:
1) Augment RFC 8345, so that the logical L2 or L3 or TE network topology can 
have mapping association with underlying physical infrastructure inventory. 
Therefore, a new " network-inventory" network type has been defined.
2) More device and device component types are supported, such as device 
software component, virtual network devices and network endpoint devices.

Regarding licenses (or entitlements in draft-palmero-opsawg-dmlmo-09), some 
licenses may affect the functions of physical components or software 
components, though having removed from the current model, but we feel further 
discussion is needed.

Thanks,
Bo

-Original Message-
From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
[mailto:internet-dra...@ietf.org]
Sent: Friday, February 10, 2023 7:04 PM
To: Wubo (lana) mailto:lana.w...@huawei.com>>; Cheng Zhou 
mailto:zhoucheng...@chinamobile.com>>; Mohamed 
Boucadair mailto:mohamed.boucad...@orange.com>>; 
Qin Wu mailto:bill...@huawei.com>>; Qin Wu 
mailto:bill...@huawei.com>>
Subject: New Ve

Re: [OPSAWG] New Version Notification for draft-wzwb-opsawg-network-inventory-management-01.txt

[Wubo (lana)]

Hi Italo,



Thanks for the comments. Please see inline.



Regards,

Bo



-Original Message-

From: Inventory-yang [mailto:inventory-yang-boun...@ietf.org] On Behalf Of 
Italo Busi

Sent: Thursday, February 16, 2023 6:54 PM

To: Wubo (lana) ; opsawg@ietf.org; 
inventory-y...@ietf.org

Subject: Re: [Inventory-yang] New Version Notification for 
draft-wzwb-opsawg-network-inventory-management-01.txt



Hi Bo,



Regarding re-using RFC8345 for the mapping between physical (inventory) and 
abstract (network topology) resources, I can see your point for the navigation 
between the physical NEs (within the inventory) and the abstract nodes (within 
network topologies). However, I am not sure you can get more than this.

[Bo Wu] We are considering this approach can further support ACL MOUNT POINT 
augmentation to obtain the ACLs of all devices and perform policy verification.



You still need specific attributes to navigate between the physical ports 
(components within the inventory) and the abstract termination points (within 
network topologies).

[Bo Wu] Agree with you on this point. But the mapping between topology levels 
and possible device configurations, e.g. ACL for security management systems 
can be associated.



Moreover, I have noted that the model augments the network-topology model 
defined in RFC8345. However, according to RFC8345, the inventory model was 
intended to augment only the network model and not the network-topology model. 
This makes sense to me also because the physical links terminates on the 
physical ports (components within the inventory) and not on termination points.

[Bo Wu] Thanks for pointing this out. We will add some clarification on this. 
The termination points part in "network-topology" is optional. When the device 
DOES NOT contain components , termination points can be used instead of 
defining ports in components.



See for example the discussion in 
https://github.com/italobusi/ietf-network-inventory/issues/33



My 2 cents



Thanks, Italo



> -Original Message-

> From: Inventory-yang  On Behalf Of

> Wubo

> (lana)

> Sent: giovedì 16 febbraio 2023 11:01

> To: opsawg@ietf.org; inventory-y...@ietf.org

> Subject: Re: [Inventory-yang] New Version Notification for draft-wzwb-

> opsawg-network-inventory-management-01.txt

>

> Dear Opsawg, inventory colleges,

>

> Based on the review comments from Marisol and authors of

> draft-ietf-ccamp- network-inventory-yang, we update the network inventory 
> draft.

>

> Compared with the network hardware inventory in CCAMP, this model has

> following consideration:

> 1) Augment RFC 8345, so that the logical L2 or L3 or TE network

> topology can have mapping association with underlying physical infrastructure 
> inventory.

> Therefore, a new " network-inventory" network type has been defined.

> 2) More device and device component types are supported, such as

> device software component, virtual network devices and network endpoint 
> devices.

>

> Regarding licenses (or entitlements in draft-palmero-opsawg-dmlmo-09),

> some licenses may affect the functions of physical components or

> software components, though having removed from the current model, but

> we feel further discussion is needed.

>

> Thanks,

> Bo

>

> -Original Message-----

> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]

> Sent: Friday, February 10, 2023 7:04 PM

> To: Wubo (lana) ; Cheng Zhou

> ; Mohamed Boucadair

> ; Qin Wu ; Qin Wu

> 

> Subject: New Version Notification for

> draft-wzwb-opsawg-network-inventory-

> management-01.txt

>

>

> A new version of I-D, draft-wzwb-opsawg-network-inventory-management-

> 01.txt

> has been successfully submitted by Bo Wu and posted to the IETF repository.

>

> Name:draft-wzwb-opsawg-network-inventory-management

> Revision:01

> Title:   An Inventory Management Model for Enterprise Networks

> Document date:   2023-02-10

> Group:Individual Submission

> Pages:28

> URL:https://www.ietf.org/archive/id/draft-wzwb-opsawg-network-

> inventory-management-01.txt

> Status: https://datatracker.ietf.org/doc/draft-wzwb-opsawg-network-

> inventory-management/

> Htmlized:   https://datatracker.ietf.org/doc/html/draft-wzwb-opsawg-

> network-inventory-management

> Diff:   https://author-tools.ietf.org/iddiff?url2=draft-wzwb-opsawg-

> network-inventory-management-01

>

> Abstract:

>This document defines a YANG model for network inventory management,

>which provides consistent representation and reporting of network

>nodes (including endpoints) inventory and enable a network

>orchestrator in the enterprise network to maintai

Re: [OPSAWG] New Version Notification for draft-wzwb-opsawg-network-inventory-management-01.txt

[Wubo (lana)]

Dear Opsawg, inventory colleges,

Based on the review comments from Marisol and authors of 
draft-ietf-ccamp-network-inventory-yang, we update the network inventory draft.

Compared with the network hardware inventory in CCAMP, this model has following 
consideration:
1) Augment RFC 8345, so that the logical L2 or L3 or TE network topology can 
have mapping association with underlying physical infrastructure inventory. 
Therefore, a new " network-inventory" network type has been defined.
2) More device and device component types are supported, such as device 
software component, virtual network devices and network endpoint devices.

Regarding licenses (or entitlements in draft-palmero-opsawg-dmlmo-09), some 
licenses may affect the functions of physical components or software 
components, though having removed from the current model, but we feel further 
discussion is needed.

Thanks,
Bo

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Friday, February 10, 2023 7:04 PM
To: Wubo (lana) ; Cheng Zhou 
; Mohamed Boucadair 
; Qin Wu ; Qin Wu 

Subject: New Version Notification for 
draft-wzwb-opsawg-network-inventory-management-01.txt


A new version of I-D, draft-wzwb-opsawg-network-inventory-management-01.txt
has been successfully submitted by Bo Wu and posted to the IETF repository.

Name:   draft-wzwb-opsawg-network-inventory-management
Revision:   01
Title:  An Inventory Management Model for Enterprise Networks
Document date:  2023-02-10
Group:  Individual Submission
Pages:  28
URL:
https://www.ietf.org/archive/id/draft-wzwb-opsawg-network-inventory-management-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-wzwb-opsawg-network-inventory-management/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wzwb-opsawg-network-inventory-management
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-wzwb-opsawg-network-inventory-management-01

Abstract:
   This document defines a YANG model for network inventory management,
   which provides consistent representation and reporting of network
   nodes (including endpoints) inventory and enable a network
   orchestrator in the enterprise network to maintain a centralized view
   of all the endpoint types across multiple domains of the underlying
   network to implement a coherent control strategy.


  


The IETF Secretariat



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

Re: [OPSAWG] Opsdir last call review of draft-ietf-opsawg-service-assurance-yang-09

[Wubo (lana)]

Hi Jean,

Thanks for addressing my comments. I am fine with the updates.

Regards,
Bo

-Original Message-
From: Jean Quilbeuf 
Sent: Monday, November 28, 2022 8:32 PM
To: Wubo (lana) ; ops-...@ietf.org
Cc: draft-ietf-opsawg-service-assurance-yang@ietf.org; last-c...@ietf.org; 
opsawg@ietf.org
Subject: RE: Opsdir last call review of 
draft-ietf-opsawg-service-assurance-yang-09

Hi Bo,
Thanks for your comments. Please find our answers inline.

The full diff is here:  
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-yang-10 

Best,
Jean


> -Original Message-
> From: Bo Wu via Datatracker [mailto:nore...@ietf.org]
> Sent: Monday 21 November 2022 15:15
> To: ops-...@ietf.org
> Cc: draft-ietf-opsawg-service-assurance-yang@ietf.org; 
> last-c...@ietf.org; opsawg@ietf.org
> Subject: Opsdir last call review of 
> draft-ietf-opsawg-service-assurance-yang-
> 09
> 
> 
> Nits/editorial comments:
> 
> 1.It would be better to add some text to explain why the agent list is 
> defined.
> Introduction says the module should be supported by an agent.
> 
Added the collector export use case:
   " The module is also intended to be exported by the SAIN collector which 
aggregates the output of several SAIN agents to provide the global assurance 
graph.
In that case, only the telemetry export use case is considered."

> 2. In section 3.2 and 3.4
> The "subservice" list contains all the subservice instances currently
>configured on the server.
> "server" is not defined in the document. Is it referring "SAIN agent"?

Changed to:
   "The "subservice" list contains all the subservice instances currently known 
by the server (i.e. SAIN agent or SAIN collector)."

> 3. Appendix C Example of YANG instances Paragraph 1 s/examples/example 
> since there is only one example.

Removed the plural, thanks.


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

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

[Wubo (lana)]

Hi Rob,

Sorry for the delay. Here is the update：
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-15

Thanks,
Bo

发件人: Rob Wilton (rwilton) 
发送时间: 2022年11月11日 10:37
收件人: Wubo (lana) ; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
抄送: adr...@olddog.co.uk; opsawg@ietf.org
主题: RE: New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

Hi Bo,

Just a quick reminder that you can post a -15 (which I don’t think that I have 
seen), and then I can approve this.

Regards,
Rob


From: Wubo (lana) mailto:lana.w...@huawei.com>>
Sent: 25 October 2022 08:26
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
Cc: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: RE: New Version Notification - 
draft-ietf-opsawg-yang-vpn-service-pm-14.txt

Hi Rob,

Many thanks for your suggestion. We will submit R-15 to fix this when the I-D 
submission reopen.

Thanks,
Bo

From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
Sent: Friday, October 21, 2022 6:06 PM
To: Wubo (lana) mailto:lana.w...@huawei.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
Cc: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: RE: New Version Notification - 
draft-ietf-opsawg-yang-vpn-service-pm-14.txt

Hi Bo,

I think that “limit-number” name makes more sense in the context of the other 
peer leaves around it when it is defined under “mac-addr-limit”, i.e., the 
“time-interval”, and what action is being taken.

My “no hats” opinion is that I would still go for consistency with the other 
counters under entry-summary.  E.g., using the same naming convention between 
the “maximum” and the “active”, and between v4, v6 and mac addresses.  If it 
helps you could also make the relationship to mac-policies/limit-number clear 
as part of the description.

But I’ll leave this entirely as the authors decision, this is just a minor 
non-blocking comment.

Regards,
Rob


From: Wubo (lana) mailto:lana.w...@huawei.com>>
Sent: 21 October 2022 10:41
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
Cc: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: RE: New Version Notification - 
draft-ietf-opsawg-yang-vpn-service-pm-14.txt


Hi Rob,



Thanks for the review and suggestion.



Per the naming of "mac-limit-number", we are considering to be consistent with 
L2NM definition:



https://datatracker.ietf.org/doc/html/rfc9291:

  | +--rw mac-policies

  | |  +--rw mac-addr-limit

  | |  |  +--rw limit-number?uint16

  | |  |  +--rw time-interval?   uint32

  | |  |  +--rw action?  Identityref



Do you think this makes sense?



Thanks,

Bo



-Original Message-
From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
Sent: Friday, October 21, 2022 5:31 PM
To: 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
Cc: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: RE: New Version Notification - 
draft-ietf-opsawg-yang-vpn-service-pm-14.txt



Hi authors, shepherd,



Thanks for quickly posting a new version of 
draft-ietf-opsawg-yang-vpn-service-pm addressing the AD comments during the 
IESG review.



The changes all look good to me, except that I question one of the changes that 
were made (in response to one of Eric's comments I think):



 augment /nw:networks/nw:network/nw:node:

   +--rw node-type?   identityref

   +--ro entry-summary

  +--ro ipv4-num

  |  +--ro maximum-routes?uint32

  |  +--ro total-active-routes?   uint32

  +--ro ipv6-num

  |  +--ro maximum-routes?uint32

  |  +--ro total-active-routes?   uint32

  +--ro mac-num

 +--ro mac-limit-number?   uint32

 +--ro total-active-mac-num?   uint32



mac-num-limit has been changed from mac-num-limit to max-limit-number, but I 
was wondering whether you considered trying to make the names for the mac entry 
limits more consistent with the names of the IP route limits.  E.g.,



 augment /nw:networks/nw:network/nw:node:

   +--rw node-type?   identityref

   +--ro entry-summary

  +--ro ipv4-num

  |  +--ro maximum-routes?uint32

  |  +--ro total-active-routes?   uint32

  +--ro ipv6-num

  |  +--ro maximum-routes?u

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

[Wubo (lana)]

Hi Rob,

Many thanks for your suggestion. We will submit R-15 to fix this when the I-D 
submission reopen.

Thanks,
Bo

From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
Sent: Friday, October 21, 2022 6:06 PM
To: Wubo (lana) ; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
Cc: adr...@olddog.co.uk; opsawg@ietf.org
Subject: RE: New Version Notification - 
draft-ietf-opsawg-yang-vpn-service-pm-14.txt

Hi Bo,

I think that “limit-number” name makes more sense in the context of the other 
peer leaves around it when it is defined under “mac-addr-limit”, i.e., the 
“time-interval”, and what action is being taken.

My “no hats” opinion is that I would still go for consistency with the other 
counters under entry-summary.  E.g., using the same naming convention between 
the “maximum” and the “active”, and between v4, v6 and mac addresses.  If it 
helps you could also make the relationship to mac-policies/limit-number clear 
as part of the description.

But I’ll leave this entirely as the authors decision, this is just a minor 
non-blocking comment.

Regards,
Rob


From: Wubo (lana) mailto:lana.w...@huawei.com>>
Sent: 21 October 2022 10:41
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
Cc: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: RE: New Version Notification - 
draft-ietf-opsawg-yang-vpn-service-pm-14.txt


Hi Rob,



Thanks for the review and suggestion.



Per the naming of "mac-limit-number", we are considering to be consistent with 
L2NM definition:



https://datatracker.ietf.org/doc/html/rfc9291:

  | +--rw mac-policies

  | |  +--rw mac-addr-limit

  | |  |  +--rw limit-number?uint16

  | |  |  +--rw time-interval?   uint32

  | |  |  +--rw action?  Identityref



Do you think this makes sense?



Thanks,

Bo



-Original Message-
From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
Sent: Friday, October 21, 2022 5:31 PM
To: 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
Cc: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: RE: New Version Notification - 
draft-ietf-opsawg-yang-vpn-service-pm-14.txt



Hi authors, shepherd,



Thanks for quickly posting a new version of 
draft-ietf-opsawg-yang-vpn-service-pm addressing the AD comments during the 
IESG review.



The changes all look good to me, except that I question one of the changes that 
were made (in response to one of Eric's comments I think):



 augment /nw:networks/nw:network/nw:node:

   +--rw node-type?   identityref

   +--ro entry-summary

  +--ro ipv4-num

  |  +--ro maximum-routes?uint32

  |  +--ro total-active-routes?   uint32

  +--ro ipv6-num

  |  +--ro maximum-routes?uint32

  |  +--ro total-active-routes?   uint32

  +--ro mac-num

 +--ro mac-limit-number?   uint32

 +--ro total-active-mac-num?   uint32



mac-num-limit has been changed from mac-num-limit to max-limit-number, but I 
was wondering whether you considered trying to make the names for the mac entry 
limits more consistent with the names of the IP route limits.  E.g.,



 augment /nw:networks/nw:network/nw:node:

   +--rw node-type?   identityref

   +--ro entry-summary

  +--ro ipv4-num

  |  +--ro maximum-routes?uint32

  |  +--ro total-active-routes?   uint32

  +--ro ipv6-num

  |  +--ro maximum-routes?uint32

  |  +--ro total-active-routes?   uint32

  +--ro mac-num

 +--ro maximum-mac-entries?   uint32

 +--ro total-active-mac-entries?   uint32



This is a just a suggestion.  Please let me know if you wish to make this 
change and post an updated draft, or whether you would like me to proceed with 
approving the -14 version.



Regards,

Rob





> -Original Message-

> From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
> mailto:internet-dra...@ietf.org>>

> Sent: 21 October 2022 09:37

> To: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; Rob Wilton (rwilton) 
> mailto:rwil...@cisco.com>>

> Subject: New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-

> 14.txt

>

>

> A new version (-14) has been submitted for draft-ietf-opsawg-yang-vpn-

> service-pm:

> https://www.ietf.org/archive/id/draft-ietf-opsawg-yang-vpn-service-pm-14.txt

>

> Sub state has been changed to AD Followup from Revised ID Needed

>

>

> The IETF datatracker page for this Internet-Draft is:

> https://d

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

[Wubo (lana)]

Hi Rob,



Thanks for the review and suggestion.



Per the naming of "mac-limit-number", we are considering to be consistent with 
L2NM definition:



https://datatracker.ietf.org/doc/html/rfc9291:

  | +--rw mac-policies

  | |  +--rw mac-addr-limit

  | |  |  +--rw limit-number?uint16

  | |  |  +--rw time-interval?   uint32

  | |  |  +--rw action?  Identityref



Do you think this makes sense?



Thanks,

Bo



-Original Message-
From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
Sent: Friday, October 21, 2022 5:31 PM
To: draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
Cc: adr...@olddog.co.uk; opsawg@ietf.org
Subject: RE: New Version Notification - 
draft-ietf-opsawg-yang-vpn-service-pm-14.txt



Hi authors, shepherd,



Thanks for quickly posting a new version of 
draft-ietf-opsawg-yang-vpn-service-pm addressing the AD comments during the 
IESG review.



The changes all look good to me, except that I question one of the changes that 
were made (in response to one of Eric's comments I think):



 augment /nw:networks/nw:network/nw:node:

   +--rw node-type?   identityref

   +--ro entry-summary

  +--ro ipv4-num

  |  +--ro maximum-routes?uint32

  |  +--ro total-active-routes?   uint32

  +--ro ipv6-num

  |  +--ro maximum-routes?uint32

  |  +--ro total-active-routes?   uint32

  +--ro mac-num

 +--ro mac-limit-number?   uint32

 +--ro total-active-mac-num?   uint32



mac-num-limit has been changed from mac-num-limit to max-limit-number, but I 
was wondering whether you considered trying to make the names for the mac entry 
limits more consistent with the names of the IP route limits.  E.g.,



 augment /nw:networks/nw:network/nw:node:

   +--rw node-type?   identityref

   +--ro entry-summary

  +--ro ipv4-num

  |  +--ro maximum-routes?uint32

  |  +--ro total-active-routes?   uint32

  +--ro ipv6-num

  |  +--ro maximum-routes?uint32

  |  +--ro total-active-routes?   uint32

  +--ro mac-num

 +--ro maximum-mac-entries?   uint32

 +--ro total-active-mac-entries?   uint32



This is a just a suggestion.  Please let me know if you wish to make this 
change and post an updated draft, or whether you would like me to proceed with 
approving the -14 version.



Regards,

Rob





> -Original Message-

> From: internet-dra...@ietf.org 
> mailto:internet-dra...@ietf.org>>

> Sent: 21 October 2022 09:37

> To: adr...@olddog.co.uk; Rob Wilton (rwilton) 
> mailto:rwil...@cisco.com>>

> Subject: New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-

> 14.txt

>

>

> A new version (-14) has been submitted for draft-ietf-opsawg-yang-vpn-

> service-pm:

> https://www.ietf.org/archive/id/draft-ietf-opsawg-yang-vpn-service-pm-14.txt

>

> Sub state has been changed to AD Followup from Revised ID Needed

>

>

> The IETF datatracker page for this Internet-Draft is:

> https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/

>

> Diff from previous version:

> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-14

>

> IETF Secretariat.

>


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

Re: [OPSAWG] Martin Duke's No Objection on draft-ietf-opsawg-yang-vpn-service-pm-13: (with COMMENT)

[Wubo (lana)]

Hi Martin,

Thanks for the helpful comments. Please see inline.

Regards,
Bo

-Original Message-
From: Martin Duke via Datatracker [mailto:nore...@ietf.org] 
Sent: Thursday, October 20, 2022 11:36 AM
To: The IESG 
Cc: draft-ietf-opsawg-yang-vpn-service...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; adr...@olddog.co.uk; adr...@olddog.co.uk
Subject: Martin Duke's No Objection on 
draft-ietf-opsawg-yang-vpn-service-pm-13: (with COMMENT)

Martin Duke has entered the following ballot position for
draft-ietf-opsawg-yang-vpn-service-pm-13: 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-yang-vpn-service-pm/



--
COMMENT:
--

Thanks to Bob Briscoe for the tsvart review.

- the Percentile definition sets fraction-digits to 3 but the description still
says it’s two decimal places.
[Bo Wu] Sorry for the mistake. Will fix in the next revision.

- Why not IOAM as a data source?
[Bo Wu] Thanks for pointing this out. We will add RFC9197 (Data Fields for In 
Situ Operations, Administration, and Maintenance (IOAM)) as suggested.




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

Re: [OPSAWG] Roman Danyliw's No Objection on draft-ietf-opsawg-yang-vpn-service-pm-13: (with COMMENT)

[Wubo (lana)]

Hi Roman,



Thanks for your helpful comments. Please see inline.



Regards,

Bo



-Original Message-
From: Roman Danyliw via Datatracker [mailto:nore...@ietf.org]
Sent: Wednesday, October 19, 2022 4:35 AM
To: The IESG 
Cc: draft-ietf-opsawg-yang-vpn-service...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; adr...@olddog.co.uk; adr...@olddog.co.uk
Subject: Roman Danyliw's No Objection on 
draft-ietf-opsawg-yang-vpn-service-pm-13: (with COMMENT)



Roman Danyliw has entered the following ballot position for

draft-ietf-opsawg-yang-vpn-service-pm-13: 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-yang-vpn-service-pm/







--

COMMENT:

--



Thank you to Daniel Migault for the SECDIR.



** Section 4.4. s/Lists p  erformance/Lists performance/



** Section 4.4. s/Last updatd/Last updated/



** Section 6.  Recommend being more descriptive in the impact.

OLD

   Write operations (e.g., edit-config)

   to these data nodes without proper protection can have a negative

   effect on network operations.



NEW

Write operations (e.g., edit-config) to these data nodes without proper

protection can have a negative effect on network operations.  These write

operates can lead to inaccurate or incomplete network measurements which case

impact the visibility and decisions this data would be used to inform.



[Bo Wu] Thanks for catching the above errors and good suggestion. Will update 
in the next revision.



** Section 6.  Thanks for the detailed table describing the impact of write

operations.  Since there is space to add a bit more descriptive language on the

page, consider:



“impact reporting” --> “impacts reporting cadence”

“impact monitoring” --> “impacts monitoring fidelity”



I don’t understand “render invalid”?  Does this combine the idea of “turning it

all off” and “making the data unusable”?  I’d recommend explaining the phrase

or use something different.

[Bo Wu] Thanks for your suggestion. I will change “render invalid” as the text 
you suggested.








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

Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-yang-vpn-service-pm-13: (with COMMENT)

[Wubo (lana)]

Hi Eric,

Thanks for your suggestion.  As OPSAWG also recommended that the model should 
be consistent with RFC 8343 (Interface YANG), we would like to use  separate 
multicast and broadcast counters as you suggested earlier and will update in 
the next revision.

Thanks,
Bo

From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com]
Sent: Tuesday, October 18, 2022 5:39 PM
To: Wubo (lana) ; mohamed.boucad...@orange.com; The IESG 

Cc: draft-ietf-opsawg-yang-vpn-service...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; adr...@olddog.co.uk
Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-opsawg-yang-vpn-service-pm-13: (with COMMENT)

Hello Bo,

Thanks for your reply, may I still wonder why not naming this leaf as 
``inbound-bum` ?

Again, nothing blocking, just trying to improve

Regards

-éric


From: "Wubo (lana)" mailto:lana.w...@huawei.com>>
Date: Tuesday, 18 October 2022 at 11:08
To: Eric Vyncke mailto:evyn...@cisco.com>>, 
"mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>" 
mailto:mohamed.boucad...@orange.com>>, The IESG 
mailto:i...@ietf.org>>
Cc: 
"draft-ietf-opsawg-yang-vpn-service...@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service...@ietf.org>"
 
mailto:draft-ietf-opsawg-yang-vpn-service...@ietf.org>>,
 "opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>" 
mailto:opsawg-cha...@ietf.org>>, 
"opsawg@ietf.org<mailto:opsawg@ietf.org>" 
mailto:opsawg@ietf.org>>, 
"adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>" 
mailto:adr...@olddog.co.uk>>
Subject: RE: Éric Vyncke's No Objection on 
draft-ietf-opsawg-yang-vpn-service-pm-13: (with COMMENT)


Hi Eric,



Thanks for the comments. Regarding the last issue, please see inline. I have 
removed the part that we agreed on.



Thanks,

Bo



-Original Message-

From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com]

Sent: Tuesday, October 18, 2022 3:23 PM

To: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>; The IESG 
mailto:i...@ietf.org>>

Cc: 
draft-ietf-opsawg-yang-vpn-service...@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service...@ietf.org>;
 opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>; 
adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>

Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-opsawg-yang-vpn-service-pm-13: (with COMMENT)



Hello Med,



Thank you for such a prompt reply.



While my comments were non-blocking, I really appreciate your time to reply. I 
agree with most of them, for the remaining look below for EV> (and feel free to 
ignore)



Regards



-éric





On 18/10/2022, 09:07, 
"mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>" 
mailto:mohamed.boucad...@orange.com>> wrote:



Hi Éric,



Thank you for the comments.



Please see inline.



I let my co-authors further comment as appropriate.



Cheers,

Med



... %< a lot of text elided 

>

> ### Section 4.4

>

> Would it be useful to split `inbound-non-unicast` into broadcast

> and multicast ?

>



[Med] This was raised also by Rob during his review 
(https://mailarchive.ietf.org/arch/msg/opsawg/bGqJ7V2EvVzJv7H-Xi2Y-jIOsKw/). 
Please search for "bum".



EV> still unsure though ;-)



[Bo Wu] This definition takes L2VPN into account, e.g. rfc7432 (BGP MPLS-Based 
Ethernet VPN) needs to Identify and process Broadcast, unknown unicast, or 
multicast (BUM) traffic. Hope this helps to clarify.


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

Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-yang-vpn-service-pm-13: (with COMMENT)

[Wubo (lana)]

Hi Eric,



Thanks for the comments. Regarding the last issue, please see inline. I have 
removed the part that we agreed on.



Thanks,

Bo



-Original Message-

From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com]

Sent: Tuesday, October 18, 2022 3:23 PM

To: mohamed.boucad...@orange.com; The IESG 

Cc: draft-ietf-opsawg-yang-vpn-service...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; adr...@olddog.co.uk

Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-opsawg-yang-vpn-service-pm-13: (with COMMENT)



Hello Med,



Thank you for such a prompt reply.



While my comments were non-blocking, I really appreciate your time to reply. I 
agree with most of them, for the remaining look below for EV> (and feel free to 
ignore)



Regards



-éric





On 18/10/2022, 09:07, "mohamed.boucad...@orange.com" 
 wrote:



Hi Éric,



Thank you for the comments.



Please see inline.



I let my co-authors further comment as appropriate.



Cheers,

Med



... %< a lot of text elided 

>

> ### Section 4.4

>

> Would it be useful to split `inbound-non-unicast` into broadcast

> and multicast ?

>



[Med] This was raised also by Rob during his review 
(https://mailarchive.ietf.org/arch/msg/opsawg/bGqJ7V2EvVzJv7H-Xi2Y-jIOsKw/). 
Please search for "bum".



EV> still unsure though ;-)



[Bo Wu] This definition takes L2VPN into account, e.g. rfc7432 (BGP MPLS-Based 
Ethernet VPN) needs to Identify and process Broadcast, unknown unicast, or 
multicast (BUM) traffic. Hope this helps to clarify.


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

Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-yang-vpn-service-pm-12

[Wubo (lana)]

Hi Elwyn,



Thanks for your review. Please find the replies inline.



Thanks,

Bo



-Original Message-
From: Elwyn Davies via Datatracker [mailto:nore...@ietf.org]
Sent: Monday, October 10, 2022 7:54 PM
To: gen-...@ietf.org
Cc: draft-ietf-opsawg-yang-vpn-service-pm@ietf.org; last-c...@ietf.org; 
opsawg@ietf.org
Subject: Genart last call review of draft-ietf-opsawg-yang-vpn-service-pm-12



Reviewer: Elwyn Davies

Review result: Ready with Nits



I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



.



Document: draft-ietf-opsawg-yang-vpn-service-pm-12

Reviewer: Elwyn Davies

Review Date: 2022-10-10

IETF LC End Date: 2022-10-04

IESG Telechat date: Not scheduled for a telechat



Summary:  Ready with a few minor nits.  Apologies for the rather late delivery.



Major issues:



Minor issues:



s4.4:  The following text appears in the section on 'Percentile Parameters':



  Setting a percentile to

  0.00 indicates the client is not interested in receiving

  particular percentile.



Given the discussion of configurable items in Section 6 it would be helpful to 
mention that these items and other items marked 'rw' and with names ending in 
'?' can be configured rather than just saying 'Setting'.

[Bo Wu] Thanks for the suggestion. How about the following changes?



Percentile parameters:  The module supports reporting delay and jitter metric 
by percentile values.

Three percentile values can be configured to define various percentile levels.

By default, low percentile (10th percentile), intermediate percentile (50th 
percentile),

high percentile (90th percentile) are used.

Configuring a percentile to 0.00 indicates the client is not interested in 
receiving particular percentile.







Nits/editorial comments:



General: The document contains a lot of VPN terminology and network types using

acronyms such as CE, PE etc.   Some of these are defined in Sections 2/2.1 but

a pointer to a document that defines the VPN technology (such as RFC 4026) 
would be helpful.



s1:  The abbreviations PE, CE and P are used here before their definitions in 
s2.  I guess they had better be expanded on first use.

[Bo Wu] OK. Fixed.



s2.1: The references for definitions of MPLS, OWAMP and TWAMP introduced in s3 
would be usefully noted here.

[Bo Wu] OK. Fixed.



s3, para 3: s/involved devices/devices involved/

[Bo Wu] Fixed.



s3.1, para 1: s/Some applications/Some applications,/

[Bo Wu] Fixed.



s4.1, para before Fig 4, sentence 1: s/VPN Network PM YANG module/the VPN 
Network PM YANG module/

[Bo Wu] Fixed.



s5: There are 3 instances of 'into 0.0' in the percentile definitions of 
augment "/nw:networks/nw:network/nt:link" that should be 'to 0.0'.

[Bo Wu] Fixed.








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

Re: [OPSAWG] Secdir last call review of draft-ietf-opsawg-yang-vpn-service-pm-12

[Wubo (lana)]

Hi Daniel,



Thank you for the review. Please see inline for the reply.



Thanks,

Bo



-Original Message-
From: Daniel Migault via Datatracker [mailto:nore...@ietf.org]
Sent: Saturday, October 8, 2022 3:55 AM
To: sec...@ietf.org
Cc: draft-ietf-opsawg-yang-vpn-service-pm@ietf.org; last-c...@ietf.org; 
opsawg@ietf.org
Subject: Secdir last call review of draft-ietf-opsawg-yang-vpn-service-pm-12



Reviewer: Daniel Migault

Review result: Ready



Hi,



I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written primarily for the benefit of the security area directors. 
 Document editors and WG chairs should treat these comments just like any other 
last call comments.



The summary of the review is Ready with nits, but I am not an expert in this 
area, so please take this comments as questions that came to me while reading 
the document.



Introduction:



[...]



   The performance of VPN services is associated with the performance

   changes of the underlay networks that carries VPN services.  For

   example, link delay between PE and P





It seems to me that is the first time these acronyms are introduced - same with 
CE. 

[Bo Wu] Thanks for the catching. Will expand on the first use.



   devices and packet loss status

   on Layer 2 and Layer 3 interfaces connecting PEs and CEs directly

   impact VPN service performance.  Additionally, the integration of

   Layer 2/Layer 3 VPN performance and network performance data enables

   the orchestrator to subscribe uniformly.





I do not understand "subscribe uniformly".

My impression is that here the orchestrator is responsible to enforce some 
network performances, and depending on the performance to meet, it will choose 
one configuration or the other. Does the use of one configuration versus the 
other is seen as a subscription ?  If that is correct, this sounds like a 
cooperation between various actor. If so, that surprises me. 

[Bo Wu] Thanks again for the catching. Agree that “subscribe uniformly” not 
accurate. The module is intended for the orchestrator to query or subscribe to 
the updates of the performance statistics. How about the following change?



For example, link delay between Provider Edge (PE) and Provider (P) devices and 
packet loss status on Layer 2 and Layer 3 interfaces connecting PEs and 
Customer Edge (CE) devices directly

   impact VPN service performance.  Additionally, the integration of

   Layer 2/Layer 3 VPN performance and network performance data enables

   the orchestrator to monitor consistently.

End



Therefore, this document

   defines a YANG module for both network and VPN service performance

   monitoring (PM).  The module can be used to monitor and manage

   network performance on the topology level or the service topology

   between VPN sites.



   This document defines a base YANG data model for monitoring of

   network performance and VPN service performance.



I have the impression the text above repeats the previous paragraph.



[Bo Wu] OK. Will remove the second one.



[...]



3.  Network and VPN Service Performance Monitoring Model Usage



   As shown in Figure 1, in the context of the layered model

   architecture described in [RFC8309], the network and VPN service

   performance monitoring (PM) model can be used to expose operational

   performance information to the layer above, e.g., to an orchestrator

   or other client application, via standard network management APIs.





I am wondering if the client application is related to the Customer.

I do not think so, but I might be wrong. I am wondering if that would make 
sense to have the client application being mentioned on the figure.



[Bo Wu] In the RFC 8309, the client application refers to BSS/OSS application, 
not customer. The intention here is to give an example architecture.

We suggest to replace the figure title to “An Example Architecture with a 
Service Orchestrator” and the following change:


The network and VPN service
   performance monitoring (PM) model can be used to expose operational
   performance information to the layer above, e.g., to an orchestrator
   or other BSS/OSS client application, via standard network management APIs.

   Figure 1 shows an example usage in an architecture described in [RFC 8309].




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

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

[Wubo (lana)]

Hi Bob,



Thank you for the detailed review and helpful comments. Please find the replies 
inline.



Thanks,

Bo



-Original Message-
From: Bob Briscoe via Datatracker [mailto:nore...@ietf.org]
Sent: Monday, September 26, 2022 6:53 PM
To: tsv-...@ietf.org
Cc: draft-ietf-opsawg-yang-vpn-service-pm@ietf.org; last-c...@ietf.org; 
opsawg@ietf.org
Subject: Tsvart last call review of draft-ietf-opsawg-yang-vpn-service-pm-11



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.

[Bo Wu] In the YANG model, the default interval is 60s. This Indicates the 
period of time that PM measurement tasks can be performed and results are 
collected, which we think is a reasonable unit.



 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).

[Bo Wu] OK with this one.



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.

[Bo Wu] These are configurable and can be changed to accommodate specific 
contexts. The current defaults are used to echo what was used in other RFCs 
such RFC9244.



==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.

[Bo Wu] In the draft, the current text does not make any assumption on the 
underlay. Per RFC8345, a network topology is a hierarchical structure, which 
could be VPN service topology, or L1, L2, L3, OSPF topology, and two networks 
can use “supporting-network” to show the interconnection. Therefore, we think 
this draft allow this and not sure this is representative enough to zoom into 
it.

https://www.rfc-editor.org/rfc/rfc8345.html



==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].

[Bo Wu] Agree the current text is not clear enough.



There could be three types of underlay networks for VPN services: L3 topology, 
L2 topology, and physical topology, or a combination of these topologies. As 
per RFC 8345, the network type of one particular 

Re: [OPSAWG] Last Call: (A YANG Model for Network and VPN Service Performance Monitoring) to Proposed Standard

[Wubo (lana)]

Hi Tom,



Thanks for your careful review. We have posted rev-11. Please see if this 
version addresses your comments.

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-11



Please also see inline for the detailed reply.

Thanks,

Bo



-Original Message-

From: tom petch [mailto:daedu...@btconnect.com]

Sent: Thursday, September 22, 2022 7:24 PM

To: last-c...@ietf.org

Cc: adr...@olddog.co.uk; opsawg@ietf.org; opsawg-cha...@ietf.org; 
draft-ietf-opsawg-yang-vpn-service...@ietf.org

Subject: Re: Last Call:  (A YANG 
Model for Network and VPN Service Performance Monitoring) to Proposed Standard



On 20/09/2022 17:24, The IESG wrote:

>

> The IESG has received a request from the Operations and Management

> Area Working Group WG (opsawg) to consider the following document: -

> 'A YANG Model for Network and VPN Service Performance Monitoring'

> as Proposed Standard





I struggled to understand what this I-D offered until the AD Review where the 
AD had issues similar to mine.  Even now, I am unclear if I understand it; the 
problem is wording and inconsistent use thereof.



In many places, the I-D says

'This document  defines a YANG module for performance monitoring (PM) of both 
underlay networks and overlay VPN services '

and it is that 'both' that I think starts to lead the reader, or at least me, 
up the garden path.



s.4.2 says

The model can be used for performance monitoring both for the

underlay network and the VPN services.  The two would be separate

entries in the network list [RFC8345].



and then talks of  the effect of the  "service" presence container being absent 
or present, which would doubtless twitch the nostrils of a YANG Doctor.



What it is saying, I think, is that the YANG module

- either provides data for PM of a VPN service

- or provides data for PM for the network itself but cannot do both, except in 
the sense that the YANG model in a node may contain multiple entries in the 
network list one or more of which is for a VPN service and one or more of which 
is for a network itself and that Netconf, e.g., can retrieve data for both in a 
single 'get'.  I think that the use of 'both' above is a stretch for that use 
of the word, more precisely it is either VPN service or network itself.



Bo: Thanks for the comments. But the module really covers the both, though the 
network or VPN service PM instances can be accessed through separate network 
list entries.



The rest of the I-D increases my confusion.



s.4

' The performance monitoring data augments the service topology as shown in 
Figure 2.'

Figure 2 has no mention of service.  Perhaps the reader must infer that what is 
meant is

The YANG module for performance monitoring data augments the YANG module for 
service topology - i.e. ietf-network, ietf-network-topology -



Bo: Thanks for pointing this out. Yes. Here is the change of new revision:

OLD:

   This document defines the YANG module, "ietf-network-vpn-pm", which

   is an augmentation to the "ietf-network" and "ietf-network-topology"

   modules.



   The performance monitoring data augments the service topology as

   shown in Figure 2.



NEW:

   This document defines the YANG module, "ietf-network-vpn-pm", which

   is an augmentation to the "ietf-network" and "ietf-network-topology"

   modules as shown in Figure 2.

END





The presence container alluded to above appears as

'  container service {

  presence

"Presence of the container indicates a service

 topology, absence of the container indicates an

 underlay network.";  '

The use of service topology here seems at odds with that in s.4.2 but later, in 
several places, there is

when '../nw:network-types/nvp:service' {

  description

"Augments only for VPN node attributes."; Well no, the augments 
only occurs when 'service' is present and that has just been defined as 
'Presence of the container indicates a service topology'; seems contradictory 
here and in several places.

Bo: Yes. I agree this is not clear enough. Fixed in the new revision.





Also, in most places, it is 'underlay tunnel' or 'underlay-tunnel'

whereas here it is 'underlay network' as it is in the Abstract and that, for 
me, again, leads the reader - me - astray.



Bo: Agree this is confusing. I have changed "underlay tunnel " to "vpn-tunnel" 
in most places and replaced one with underlay links.



In a similar vein, I see

  leaf start-time { type yang:date-and-time;

config false; description

  "The time that the current measurement started."; The YANG 
type is date and time so that is 'The date and time ..'.  I often see 
monitoring at the same time every day which is what the description might mean 
but does not.



Bo: Thanks. Fixed with "The date and time the measurement last started."



Likewise

  leaf unit-value {

  

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

[Wubo (lana)]

Hi Rob,



Thanks for your accurate summary and further review. Please see inline.



Best regards,

Bo



-Original Message-
From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
Sent: Friday, September 16, 2022 8:39 PM
To: adr...@olddog.co.uk; 'tom petch' ; Wubo (lana) 
; draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
Cc: opsawg@ietf.org
Subject: RE: [OPSAWG] AD review of draft-ietf-opsawg-yang-vpn-service-pm-09



My interpretation of the draft was basically this:



(1) The YANG topology model (rfc8345) can model both an underlay network and 
overlaying services.

(2) The base YANG topology model is missing some generic attributes to identify 
that a topology represents a service (e.g., service-type, vpn-id, 
vpn-service-topology).  I don't think that these attributes necessarily have 
anything to with PM, but they were added here because they were needed.  E.g., 
arguably they could have been put into a separate YANG module, but it would 
perhaps be too small to be worthwhile).

(3) The performance monitoring data can largely be gathered either at the 
network layer or at the service layer and this is really distinguished by which 
entry in the topology list the PM data nodes are being returned for.



Authors, is my understanding correct and accurate?



[Bo Wu] Thanks for the accurate summary.

On the second point, we agree that these VPN attributes are not PM data, but we 
think these are context information, for example, SLA requirements are 
different between hubs and between hub and spokes.



For (2), that does raise a further question:  In section 4.3, the "role" leaf 
has been placed under pm-attributes.  But again, I wonder whether this "role" 
is really just a generic description of the service endpoint.  Hence, would it 
be better to name this "vpn-service-role" and augment it directly under 
/nw:networks/nw:network/nw:node?  Possibly, it could be made conditional on 
/nw:networks/nw:network/nw:network-types/service/service-type



[Bo Wu] Thank you for pointing this out. Yes, we can take this out the PM 
attributes. How about we reconstructed YANG as follows:

  augment /nw:networks/nw:network/nw:node:

+--rw node-type?   identityref

+--ro entry-summary

   +--ro ipv4-num

   |  +--ro maximum-routes?uint32

   |  +--ro total-active-routes?   uint32

   +--ro ipv6-num

   |  +--ro maximum-routes?uint32

   |  +--ro total-active-routes?   uint32

   +--ro mac-num

  +--ro mac-num-limit?  uint32

  +--ro total-active-mac-num?   uint32

  augment /nw:networks/nw:network/nw:node:

+--rw role?   Identityref



For the complete change, please find at:

Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-10



Rob







> -Original Message-

> From: Adrian Farrel mailto:adr...@olddog.co.uk>>

> Sent: 16 September 2022 10:34

> To: 'tom petch' mailto:ie...@btconnect.com>>; Rob Wilton 
> (rwilton)

> mailto:rwil...@cisco.com>>; 'Wubo (lana)' 
> mailto:lana.w...@huawei.com>>; draft-ietf-

> opsawg-yang-vpn-service-pm@ietf.org<mailto:opsawg-yang-vpn-service-pm@ietf.org>

> Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>

> Subject: RE: [OPSAWG] AD review of draft-ietf-opsawg-yang-vpn-service-

> pm-09

>

> 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

&g

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

[Wubo (lana)]

Hi Adrian, all,



Many thanks for your shepherd. Please see inline.



Best regards,

Bo



-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Friday, September 16, 2022 5:34 PM
To: 'tom petch' ; 'Rob Wilton (rwilton)' 
; Wubo (lana) ; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
Cc: opsawg@ietf.org
Subject: RE: [OPSAWG] AD review of draft-ietf-opsawg-yang-vpn-service-pm-09



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.



[Bo Wu] Thanks for your good summary. This is the exact purpose of this model. 
To achieve this, we also consider the similar modeling method of RFC 8345, as 
both the underlay network and the overlay network share the same metrics and 
counters.



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.



Cheers,

Adrian



-Original Message-

From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of tom petch

Sent: 15 September 2022 11:37

To: Rob Wilton (rwilton) 
mailto:rwilton=40cisco@dmarc.ietf.org>>;
 Wubo (lana) mailto:lana.w...@huawei.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>

Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>

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



From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of Rob Wilton (rwilton) 
mailto:rwilton=40cisco@dmarc.ietf.org>>

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 separate RFC, banged 
together because they had some groupings in common, and I think that much of 
the discussion in this thread has revolved around that issue.  (It is a bit 
like YANG modules with masses of groupings which save the author repeating a 
few lines of YANG while making it harder for anyone else to follow, except more 
so).



So, I shall try to forget what I have learnt from this thread and read the 
revised I-D to see if I find it any clearer but will probably end up with the 
same conclusion, this is two separate RFC.



Tom Petch.



Regards,

Rob





From: Wubo (lana) mailto:lana.w...@huawei.com>>

Sent: 15 September 2022 03:17

To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>

Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>

Subject: Re: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09



Hi Rob,



Thank you for the review and helpful comments.



I copied your last comment here, since this is the last point to be discussed.



RW3:

Based on your additional information, then I think that saying that is does not 
allow the gathering of performance data simultaneously is somewhat confusing.  
E.g., you could mak

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

[Wubo (lana)]

Hi Tom,



Thanks for your comments. Please see inline.



Thanks,

Bo



-Original Message-

From: tom petch [mailto:ie...@btconnect.com]

Sent: Thursday, September 15, 2022 6:37 PM

To: Rob Wilton (rwilton) ; Wubo (lana) 
; draft-ietf-opsawg-yang-vpn-service-pm@ietf.org

Cc: opsawg@ietf.org

Subject: Re: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09



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 separate RFC, banged 
together because they had some groupings in common, and I think that much of 
the discussion in this thread has revolved around that issue.  (It is a bit 
like YANG modules with masses of groupings which save the author repeating a 
few lines of YANG while making it harder for anyone else to follow, except more 
so).



Bo: Thanks for the comments. The authors has designed this model with the 
following considerations:

1) This model is a complementary performance monitoring model for both 
RFC8345, and LxNM (e.g. RFC8299 L3NM ), not just for custom VPN service.

2) Following the design method of RFC8345, this model could be used for 
both underlay networks and overlay VPN networks.

3) The PM metrics and counters of the underlay network are the same as 
those of the VPN network, such as the delay, jitter, and loss of links or 
overlay links (tunnels) and the counters of physical interfaces or VPN access 
interfaces (e.g. VLAN interfaces).



We updated the draft to try to clarify the above, please see

Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-10



Thanks,

Bo



So, I shall try to forget what I have learnt from this thread and read the 
revised I-D to see if I find it any clearer but will probably end up with the 
same conclusion, this is two separate RFC.



Tom Petch.



Regards,

Rob





From: Wubo (lana) 

Sent: 15 September 2022 03:17

To: Rob Wilton (rwilton) ; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org

Cc: opsawg@ietf.org

Subject: Re: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09



Hi Rob,



Thank you for the review and helpful comments.



I copied your last comment here, since this is the last point to be discussed.



RW3:

Based on your additional information, then I think that saying that is does not 
allow the gathering of performance data simultaneously is somewhat confusing.  
E.g., you could make a get request that spanned over multiple network list 
entries, or similar for a subscription.



I think that probably nothing extra needs to be said at all.  But if you do 
want to add text here then I suggest that it clarifies that networks and VPNs 
would be separate entries in the network list, and the underlying network would 
not have the “service” container set, whereas the VPN network entries would.



Bo4: Thanks for the suggestion. How about the changes:



==



4.2.  Network Level







The model can be used for performance monitoring both for the network and the 
VPN services. However, the module does not allow to gather the performance 
monitoring data simultaneously for both cases. Concretely: The two would be 
separate entries in the network list. The differences are as follows:



* When the “service-type” presence container is absent, then it indicates



performance monitoring of the network itself.







* When the “service-type” presence container is present, then it indicates



performance monitoring of the VPN service specified by the “service-type”



leaf, e.g. , L3VPN or Virtual Private LAN Service (VPLS).  The values are taken



from [RFC9181].  When a network topology instance contains the L3VPN or



other L2VPN network type, it represents a VPN instance that can perform



performance monitoring.



==



Thanks,

Bo

发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]

发送时间: 2022年9月14日 22:53

收件人: Wubo (lana) mailto:lana.w...@huawei.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>

抄送: opsawg@ietf.org<mailto:opsawg@ietf.org>

主题: RE: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09



Hi Bo, authors,



Okay, thanks for the clarifications.  Please see inline …





From: Wubo (l

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

[Wubo (lana)]

Hi Rob,

Thank you for the review and helpful comments.

I copied your last comment here, since this is the last point to be discussed.

RW3:
Based on your additional information, then I think that saying that is does not 
allow the gathering of performance data simultaneously is somewhat confusing.  
E.g., you could make a get request that spanned over multiple network list 
entries, or similar for a subscription.

I think that probably nothing extra needs to be said at all.  But if you do 
want to add text here then I suggest that it clarifies that networks and VPNs 
would be separate entries in the network list, and the underlying network would 
not have the “service” container set, whereas the VPN network entries would.

Bo4: Thanks for the suggestion. How about the changes:

==

4.2.  Network Level



The model can be used for performance monitoring both for the network and the 
VPN services. However, the module does not allow to gather the performance 
monitoring data simultaneously for both cases. Concretely: The two would be 
separate entries in the network list. The differences are as follows:

* When the “service-type” presence container is absent, then it indicates

performance monitoring of the network itself.



* When the “service-type” presence container is present, then it indicates

performance monitoring of the VPN service specified by the “service-type”

leaf, e.g. , L3VPN or Virtual Private LAN Service (VPLS).  The values are taken

from [RFC9181].  When a network topology instance contains the L3VPN or

other L2VPN network type, it represents a VPN instance that can perform

performance monitoring.

==

Thanks,
Bo
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
发送时间: 2022年9月14日 22:53
收件人: Wubo (lana) ; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
抄送: opsawg@ietf.org
主题: RE: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

Hi Bo, authors,

Okay, thanks for the clarifications.  Please see inline …


From: Wubo (lana) mailto:lana.w...@huawei.com>>
Sent: 14 September 2022 15:31
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: Re: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

Hi Rob,

Thanks again for your review.  Please find our reply inline.

Thanks,
Bo

发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
发送时间: 2022年9月14日 17:18
收件人: Wubo (lana) mailto:lana.w...@huawei.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
抄送: opsawg@ietf.org<mailto:opsawg@ietf.org>
主题: RE: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

Hi Bo, authors,

Please see inline. Again, I have removed sections where we have agreement.  I 
think that there is just one area that I’m still slightly confused by relating 
to the network vs service PM, for which I’ve added some further questions 
inline.



From: Wubo (lana) mailto:lana.w...@huawei.com>>
Sent: 14 September 2022 09:25
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: 答复: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

Hi Rob,

Thank again for your deep review. Please find our response inline for the open 
points.

Best regards,
Bo


发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
发送时间: 2022年9月13日 17:24
收件人: Wubo (lana) mailto:lana.w...@huawei.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
抄送: opsawg@ietf.org<mailto:opsawg@ietf.org>
主题: RE: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

Hi Bo,

Thanks.  I’ve made some further comments for a few points inline.  I’ve snipped 
those that we already have agreement on.


From: Wubo (lana) mailto:lana.w...@huawei.com>>
Sent: 13 September 2022 07:38
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: 答复: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09


Hi Rob,



Many thanks for your thoughtful review. Please see inline.



Thanks,



Bo



-邮件原件-
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
发送时间: 2022年9月9日 18:43
收件人: 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
抄送: opsawg@ietf.org<mailto:opsawg@ietf.org>
主题: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09



Hi,



Here are my AD review comments for draft-ietf-opsawg-yang-vpn-service-pm-09, 
apologies for the delay.



I think that this document is in good shape and h

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

[Wubo (lana)]

Hi Rob,

Thanks again for your review.  Please find our reply inline.

Thanks,
Bo

发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
发送时间: 2022年9月14日 17:18
收件人: Wubo (lana) ; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
抄送: opsawg@ietf.org
主题: RE: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

Hi Bo, authors,

Please see inline. Again, I have removed sections where we have agreement.  I 
think that there is just one area that I’m still slightly confused by relating 
to the network vs service PM, for which I’ve added some further questions 
inline.



From: Wubo (lana) mailto:lana.w...@huawei.com>>
Sent: 14 September 2022 09:25
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: 答复: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

Hi Rob,

Thank again for your deep review. Please find our response inline for the open 
points.

Best regards,
Bo


发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
发送时间: 2022年9月13日 17:24
收件人: Wubo (lana) mailto:lana.w...@huawei.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
抄送: opsawg@ietf.org<mailto:opsawg@ietf.org>
主题: RE: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

Hi Bo,

Thanks.  I’ve made some further comments for a few points inline.  I’ve snipped 
those that we already have agreement on.


From: Wubo (lana) mailto:lana.w...@huawei.com>>
Sent: 13 September 2022 07:38
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: 答复: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09


Hi Rob,



Many thanks for your thoughtful review. Please see inline.



Thanks,



Bo



-邮件原件-
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
发送时间: 2022年9月9日 18:43
收件人: 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
抄送: opsawg@ietf.org<mailto:opsawg@ietf.org>
主题: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09



Hi,



Here are my AD review comments for draft-ietf-opsawg-yang-vpn-service-pm-09, 
apologies for the delay.



I think that this document is in good shape and hence most of my comments are 
only minor or nits.







(11) p 8, sec 4.2.  Network Level



   For network performance monitoring, the container of "networks" in

   [RFC8345] is not extended.



I'm confused by what this sentence is meant to convey - did you mean augmented? 
 In particular, it isn't clear to me how you express PM for the physical (or 
underlay networks).  Is what you are trying to express that the "service-type" 
container is present for VPN service performance monitoring and absence 
otherwise?  Probably more words required here, and in the YANG module.



Bo: Thanks for pointing this out. Your understanding is exactly what we're 
trying to convey. How about we change to



As VPN Network PM YANG module includes two types of PM augmentation, the 
underlay networks PM is augmented on [RFC8345] when the "service-type" presence 
container is not defined

, and the VPN PM is augmented on [RFC8345] when the "service-type" presence 
container is defined.



For the underlay network performance monitoring, the container of "networks" in

   [RFC8345] is not augmented.



I think that I would still find that slightly confusing.  Perhaps:



NEW:



4.2.  Network Level



The model can be used for performance monitoring both for the network and the 
VPN services.



When the “service-type” presence container is absent, then it indicates

performance monitoring of the network itself.



When the “service-type” presence container is present, then it indicates

performance monitoring of the VPN service specified by the “service-type”

leaf, e.g. , L3VPN or Virtual Private LAN Service (VPLS).  The values are taken

from [RFC9181].  When a network topology instance contains the L3VPN or

other L2VPN network type, it represents a VPN instance that can perform

performance monitoring.


Bo 2: Thanks for the good suggestion. The text looks good.



One extra question:



Does this model allow you to gather PM data from both the network and L2VPN 
services at the same time?  If so, is there, or should there be, any text is 
the document that describes how to do this?


Bo2: In the current model design, the underlay network and L2VPN are separate 
network instances and the PM data cannot be gathered at the same time.

RW2:
Okay.  I would like to dig into this one a bit more, to understand whether this 
is a real limitation or not, and to ensure that I understand the model 
correctly:

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

[Wubo (lana)]

Hi Rob,

Thank again for your deep review. Please find our response inline for the open 
points.

Best regards,
Bo


发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
发送时间: 2022年9月13日 17:24
收件人: Wubo (lana) ; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
抄送: opsawg@ietf.org
主题: RE: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

Hi Bo,

Thanks.  I’ve made some further comments for a few points inline.  I’ve snipped 
those that we already have agreement on.


From: Wubo (lana) mailto:lana.w...@huawei.com>>
Sent: 13 September 2022 07:38
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: 答复: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09


Hi Rob,



Many thanks for your thoughtful review. Please see inline.



Thanks,



Bo



-邮件原件-
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
发送时间: 2022年9月9日 18:43
收件人: 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
抄送: opsawg@ietf.org<mailto:opsawg@ietf.org>
主题: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09



Hi,



Here are my AD review comments for draft-ietf-opsawg-yang-vpn-service-pm-09, 
apologies for the delay.



I think that this document is in good shape and hence most of my comments are 
only minor or nits.





Minor level comments:



(1) p 0, sec



   The data model for network topologies defined in RFC 8345 introduces

   vertical layering relationships between networks that can be

   augmented to cover network and service topologies.  This document

   defines a YANG module for performance monitoring (PM) of both

  networks and VPN services that can be used to monitor and manage

   network performance on the topology at higher layer or the service

   topology between VPN sites.



"the topology at higher layer" doesn't scan particularly well to me, please can 
you tweak it.



Bo: Thanks for pointing this out. Is this better that we simply change to “the 
underlay topology”?



Yes, perhaps something like this:



NEW:

   The data model for network topologies defined in RFC 8345 introduces

   vertical layering relationships between networks that can be

   augmented to cover network and service topologies.  This document

   defines a YANG module for performance monitoring (PM) of both

   underlay networks and overlay VPN services that can be used to monitor

  and manage network performance on the topology of both layers.


Bo 2: Thanks for the good suggestion. We will update as you suggested.



(3) p 4, sec 3.  Network and VPN Service Performance Monitoring Model Usage



   As shown in Figure 1, in the context of the layering model

   architecture described in [RFC8309], the network and VPN service

   performance monitoring (PM) model can be used to expose a set of

   performance information to the above layer.  Such information can be

   used by an orchestrator to subscribe to performance data.



Perhaps rephase?  I.e., is it the performance data that is being used to create 
a subscription based on the performance data, or is it just that the model 
makes the performance data readily available, which can then be subscribed do?



Bo: Thanks for the suggestion. How about:

The model makes the performance data readily available, which can then be 
subscribed by the client application, such as an orchestrator.



I think that you can probably get away with deleting the last 2 sentences of 
that paragraph and rewording it slightly.  The document already talks more 
about the specifics in sections 3.1 and 3.2 anyway.  Hence, I propose:



OLD:



   As shown in Figure 1, in the context of the layering model

   architecture described in [RFC8309], the network and VPN service

   performance monitoring (PM) model can be used to expose a set of

   performance information to the above layer.  Such information can be

   used by an orchestrator to subscribe to performance data.  The

   network controller will then notify the orchestrator about

   corresponding parameter changes.



NEW:



As shown in Figure 1, in the context of the layering model

architecture described in [RFC8309], the network and VPN service

performance monitoring (PM) model can be used to expose operational

performance information to the layer above, e.g., to an orchestrator

or other client application, via standard network management APIs.


Bo 2: Thanks for the suggestion. The text looks good.





(6) p 5, sec 3.1.  Collecting Data via Pub/Sub Mechanism



  A periodic notification

   [RFC8641] can be specified to obtain real-time performance data, a

   replay notification defined in [RFC5277] or [RFC8639] can be

   specified to obtain historical data



If this data is coming from a device then ideally it would not hold on to much 
historical 

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

[Wubo (lana)]

Hi Rob,



Many thanks for your thoughtful review. Please see inline.



Thanks,



Bo



-邮件原件-
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
发送时间: 2022年9月9日 18:43
收件人: draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
抄送: opsawg@ietf.org
主题: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09



Hi,



Here are my AD review comments for draft-ietf-opsawg-yang-vpn-service-pm-09, 
apologies for the delay.



I think that this document is in good shape and hence most of my comments are 
only minor or nits.





Minor level comments:



(1) p 0, sec



   The data model for network topologies defined in RFC 8345 introduces

   vertical layering relationships between networks that can be

   augmented to cover network and service topologies.  This document

   defines a YANG module for performance monitoring (PM) of both

  networks and VPN services that can be used to monitor and manage

   network performance on the topology at higher layer or the service

   topology between VPN sites.



"the topology at higher layer" doesn't scan particularly well to me, please can 
you tweak it.



Bo: Thanks for pointing this out. Is this better that we simply change to “the 
underlay topology”?





(2) p 1, sec 1.  Introduction



   [RFC8969] describes a framework for automating service and network

   management with YANG [RFC6020] models.



Please update reference to RFC 7950 for YANG.



Bo: Thanks. Will do.



(3) p 4, sec 3.  Network and VPN Service Performance Monitoring Model Usage



   As shown in Figure 1, in the context of the layering model

   architecture described in [RFC8309], the network and VPN service

   performance monitoring (PM) model can be used to expose a set of

   performance information to the above layer.  Such information can be

   used by an orchestrator to subscribe to performance data.



Perhaps rephase?  I.e., is it the performance data that is being used to create 
a subscription based on the performance data, or is it just that the model 
makes the performance data readily available, which can then be subscribed do?



Bo: Thanks for the suggestion. How about:

The model makes the performance data readily available, which can then be 
subscribed by the client application, such as an orchestrator.





(4) p 4, sec 3.  Network and VPN Service Performance Monitoring Model Usage



   In addition, the amount of performance data collected from the

   devices can be huge.  To avoid receiving a large amount of

   operational data of VPN instances, VPN interfaces, or tunnels, the

   network controller can specifically subscribe to metric-specific data

   using the tagging methods defined in [I-D.ietf-netmod-node-tags].



At the moment, my reading of the ietf-netmod-node-tags draft is that it doesn't 
currently allow you do this.  I.e., you can't just make a subscription to all 
datanodes that have been tagged in a particular way.  Hence, I would suggest 
removing this paragraph, since it doesn't seem to be directly related to what 
is described in this model.



Bo: Thanks and agree with your suggestion. Will remove this paragraph.



(5) p 5, sec 3.1.  Collecting Data via Pub/Sub Mechanism



   Some applications such as service-assurance applications, which must

   maintain a continuous view of operational data and state, can use the

   subscription model specified in [RFC8641] to subscribe to the

   specific network performance data or VPN service performance data

   they are interested in, at the data source.  For example, network or

   VPN topology updates may be obtained through on-change notifications

   [RFC8641].  For dynamic PM data, various notifications can be

   specified to obtain more complete data.



Can you elaborate a bit on what is meant by dynamic PM data please.



Bo: Thanks for pointing this out. How about we change:

For dynamic PM data, e.g. VRF routes or MAC entries, link metrics, and 
interface metrics, various notifications can be specified to obtain more 
complete data.





(6) p 5, sec 3.1.  Collecting Data via Pub/Sub Mechanism



  A periodic notification

   [RFC8641] can be specified to obtain real-time performance data, a

   replay notification defined in [RFC5277] or [RFC8639] can be

   specified to obtain historical data



If this data is coming from a device then ideally it would not hold on to much 
historical data.

Bo: Is it better that we change to “can be specified to obtain historical data 
in a limited period of time.”? E.g. in some implementation, a controller can 
store PM data for a year?



(7) p 6, sec 4.1.  Layering Relationship between Multiple Layers of Topology



  Figure 3: Example of Topology Mapping Between VPN Service

   Topology and Underlying Network



Note, I don't find this diagram brilliantly clear, it is hard to see when the 
dotted lines go but the explanatory text is clear (and probably sufficient).



Bo: Thanks. We can remove the lines if it doesn't help.

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[Wubo (lana)]

Hi all,

I have read this draft and I think this draft is ready to progress. This YANG 
model is an important part of SAIN architecture.

Thanks,
Bo

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Wednesday, June 8, 2022 6:04 PM
To: opsawg@ietf.org
Subject: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi WG,

This mail we start a two weeks working group last call for 
draft-ietf-opsawg-service-assurance-yang-05.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Please send over your comments before June 22.
Please also indicate if you think this document is ready to progress.

Cheers,
Tianran, on behalf of chairs

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

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-architecture-03

[Wubo (lana)]

Hi all,

I have read rev-05 of the draft and I think this document is ready to progress. 
The draft defines a flexible service assurance architecture and provides some 
concrete examples to illustrate how to use it.

Just a few suggestions to improve readability:

1   The definition of 'service' seems not clear to me, e.g. 
Introduction refers the service module definition in RFC 8199, but Section 
3.7.
  Flexible Functional Architecture says the definition of service is very 
generic, and this is true that in the example the IS-IS, device and interface 
could also be service. I noticed Med also raised some questions on this. I hope 
this has been solved.

2   'metric engine' is defined in Terminology. It is not clear to me 
where is this function belonged to, is it part of  SAIN agent?

Thanks,
Bo
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Wednesday, June 8, 2022 6:00 PM
To: opsawg@ietf.org
Subject: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-architecture-03

Hi WG,

This mail we start a two weeks working group last call for 
draft-ietf-opsawg-service-assurance-architecture-03.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-architecture/
Please send over your comments before June 22.
Please also indicate if you think this document is ready to progress.

Cheers,
Tianran, on behalf of chairs
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] RtgDir Early review: draft-ietf-opsawg-yang-vpn-service-pm

[Wubo (lana)]

Hi Dhruv,

Thanks for the helpful review. The rev-09 has submitted to resolve your 
comments, please check whether you have further comments.
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-09

Please also see inline for the replies..

Thanks,
Bo

From: Dhruv Dhody [mailto:d...@dhruvdhody.com]
Sent: Thursday, May 12, 2022 1:12 PM
To: draft-ietf-opsawg-yang-vpn-service-pm@ietf.org; opsawg-cha...@ietf.org
Cc: opsawg@ietf.org; rtg-...@ietf.org
Subject: RtgDir Early review: draft-ietf-opsawg-yang-vpn-service-pm

Hello

I have been selected to do a routing directorate “early” review of this draft.

The routing directorate will, on request from the working group chair, perform 
an “early” review of a draft before it is submitted for publication to the 
IESG. The early review can be performed at any time during the draft’s lifetime 
as a working group document. The purpose of the early review depends on the 
stage that the document has reached.

As this document is post-working group last call, my focus for the review was 
to determine whether the document is ready to be published. Please consider my 
comments along with the other last call comments.

For more information about the Routing Directorate, please see 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-opsawg-yang-vpn-service-pm
Reviewer: Dhruv Dhody
Review Date: 2022-05-12
IETF LC End Date: Unknown
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be resolved 
before publication.

Comments:
The document is easy to read. The YANG model seems to be useful for VPN service 
assurance and is well-formatted.

Major Issues:
None

Minor Issues:
Earlier vpn-pm-type was a choice, it was changed in the -08 version and now 
both inter-vpn-access-interface and underlay-tunnel can be configured together. 
In the draft text, it states that "usually only one of the two methods is 
used". But the YANG allows both of them to be configured at the same time.

   +--rw vpn-pm-type
  +--rw inter-vpn-access-interface
  |  +--rw inter-vpn-access-interface?   empty
  +--rw underlay-tunnel!
 +--ro vpn-underlay-transport-type?   identityref

It is not clear to me how to interpret the measured PM delay value? Is it the 
VPN access interface or for the underlay tunnel? Maybe you should allow only 
one of them to be configured at a time?
[Bo Wu] We think both measurements are not conflicting and should allow.
How about adding a new read-only leaf "pm-type", that tells if the reported 
values are based on which pm-type.



Query:
The vpn-underlay-transport-type in underlay-tunnel identifies the type of 
underlay tunnel between the PEs. But isn't it possible to have multiple types 
of tunnels and even load balancing between them? Is the assumption that each 
instance of underlay tunnel would have its own link?
[Bo Wu] The assumption is the latter case. How about adding some text to 
clarify:
“In the case of multiple types of tunnels between a single pair of VPN nodes, a 
separate link for each type of tunnel can be created.”

Nits:
- Expand on first use: LMAP
- Section 1: s/to display the//
- Section 3.1: s/VPN service assurance model/VPN Service Performance Monitoring/
- Section 4.1: s/and node 3 (N3)5/and node 3 (N3)/
- Section 4.2: Is this text correct - "For network performance monitoring, the 
container of "networks" in 
[RFC8345]
 does not need to be extended."? Or is "not" there by mistake?
[Bo Wu] Thanks. All fixed.


YANG Model:
1)
  identity pe {
base node-type;
description
  "Provider Edge (PE) node type. A PE is the name of the device
   or set of devices at the edge of the provider network with the
   functionality that is needed to interface with the customer.";
  }

What do you mean by "the name of the device"?
[Bo Wu] Thanks, will remove “the name of”.

2) In the grouping entry-summary, the description says it for "VPN or network" 
but for all the leaves (maximum-routes, total-active-routes, mac-num etc) it 
says VPN only! Please update to "VPN or network".
[Bo Wu] Thanks. Fixed.


3)
  leaf packet-loss-count {
type yang:counter64;
description
  "Total received packet drops count.";
  }
Not sure about the description, it reads as if a packet is received but 
dropped, and I don't think that is what you mean?
[Bo Wu] How about “Total number of lost packets.”?



4)
leaf reference-time {
  type yang:date-and-time;
  config false;
  description
"Indicates the time when the statistics are collected.";
}
I am not sure what collected means here. Do you mean when the current counters 
were last updated? Or when it was last aggregated/filtered at the controller?
[Bo Wu] It means the former. How about replace the name to “last-updated”, and 
also the description 

Re: [OPSAWG] [ippm] Heads up on draft-ietf-opsawg-yang-vpn-service-pm

[Wubo (lana)]

Hi Greg,

Thanks for the comments. STAMP referenced as RFC 8762 has been added as one of 
PM measurement protocol.
Please be aware this model is a network model and does not specifies the 
details of STAMP.
Please check whether rev-08 addresses your concerns:
  https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-08

Thanks,
Bo
From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Wednesday, May 4, 2022 4:54 AM
To: Adrian Farrel 
Cc: IETF IPPM WG ; opsawg ; 
draft-ietf-opsawg-yang-vpn-service...@ietf.org
Subject: Re: [ippm] Heads up on draft-ietf-opsawg-yang-vpn-service-pm

Hi Adrian,
thank you for bringing this work to my attention. I've read and shared my 
comments earlier. The authors responded promptly and we've worked together to 
address my comments. After reading the current version I have a question about 
the importance of identifying the particular active measurement protocol used 
to measure the reported performance metrics. If reporting the protocol used for 
the performance measurement is deemed essential to characterize the accuracy of 
the measurement method, then I would propose to consider several additions to 
the model:
· adding STAMP described in RFCs 8762 and 8972 to the list of active 
measurement methods
· adding Error Estimate for Session-Sender and 
Session-Reciever/Session-Reflector for OWAMP, TWAMP, and STAMP
Thank you for your kind consideration.

Regards,
Greg

On Fri, Apr 29, 2022 at 2:48 PM Adrian Farrel 
mailto:adr...@olddog.co.uk>> wrote:
Hi,

I'm the document shepherd for draft-ietf-opsawg-yang-vpn-service-pm. It has
completed WG last call in the OPSAWG.

The work may be of interest to IPPM and you might want to watch out for the
IETF last call which will be along in due course.

But I'm sure that the authors would welcome any comments you have at any
time.

Best,
Adrian

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

Re: [OPSAWG] Yangdoctors last call review of draft-ietf-opsawg-yang-vpn-service-pm-07

[Wubo (lana)]

Hi Radek,

Thanks for your helpful comments. We agree with your analysis and suggestions. 
It is acceptable to configure both PM types, although using both PM types is 
redundant. 
We have updated the YANG model as you suggested. 
Please see the diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-08.

Thanks,
Bo
-Original Message-
From: Radek Krejčí via Datatracker [mailto:nore...@ietf.org] 
Sent: Wednesday, April 27, 2022 4:49 PM
To: yang-doct...@ietf.org
Cc: draft-ietf-opsawg-yang-vpn-service-pm@ietf.org; last-c...@ietf.org; 
opsawg@ietf.org
Subject: Yangdoctors last call review of 
draft-ietf-opsawg-yang-vpn-service-pm-07

Reviewer: Radek Krejčí
Review result: Ready with Nits

The draft addresses/fixes previous comments.

The draft, as well as the module, is well written and the only issue I've found 
is kind of unclear use for the 
/nw:networks/nw:network/nt:link/pm-attributes/vpn-pm-type choice. I don't 
understand the logic of having one case config true and the second one config 
false. Does it mean that the second one is the default? Then it should be 
stated in the choice. I'm not an expert in the area, but I understand the 
choice as a way for clients to select the type of performance monitoring. Then 
it is kind of confusing that I can actually select only one of the available 
types. What about having config true presence container in the second case and 
holding config false leaf(s) there, wouldn't it be more clear?


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

Re: [OPSAWG] Further small issue with draft-ietf-opsawg-yang-vpn-service-pm

[Wubo (lana)]

Hi Adrian,

Thanks for the review. 
We have submitted rev-08 to address this issue and also comments from YANG 
doctor Radek and Greg. 
Please see the 
diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-08.

Thanks,
Bo

-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk] 
Sent: Saturday, April 30, 2022 5:25 AM
To: draft-ietf-opsawg-yang-vpn-service...@ietf.org
Cc: 'opsawg' 
Subject: Further small issue with draft-ietf-opsawg-yang-vpn-service-pm

Hi,

Apologies for not catching this in the previous review.

I noted that the Security Considerations section (Section 6) doesn't match the 
text suggested (required?) at 
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
Is there a reason for this? Fixing it will remove one f the complaints from 
idnits.

Thanks,
Adrian





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

Re: [OPSAWG] Document shepherd review of draft-ietf-opsawg-yang-vpn-service-pm-06

[Wubo (lana)]

Hi Adrian,

About the issue on Normative Reference, RFC4026 as specific, the authors think 
this will cause downref since RFC4026 is an Informational draft. 
We still suggest RFC4026 as an informative reference because the model just 
references it as informational.

Thanks,
Bo

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Wubo (lana)
Sent: Monday, April 25, 2022 4:44 PM
To: adr...@olddog.co.uk; draft-ietf-opsawg-yang-vpn-service...@ietf.org
Cc: 'opsawg' 
Subject: Re: [OPSAWG] Document shepherd review of 
draft-ietf-opsawg-yang-vpn-service-pm-06

Hi Adrian,

Many thanks for your detailed review. We have released Rev-07 to address these 
issues, see if they are fully addressed.
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-07

Please also find some replies inline.

Thanks,
Bo

-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Saturday, April 23, 2022 12:35 AM
To: draft-ietf-opsawg-yang-vpn-service...@ietf.org
Cc: 'opsawg' 
Subject: Document shepherd review of draft-ietf-opsawg-yang-vpn-service-pm-06

Hi,

I'm the document shepherd for this document as it moves beyond the WG for 
requested publication as an RFC.

I reviewed the draft at -03 during WG last call, so my comments here are 
basically editorial with only a few small questions.

If the authors could produce a new revision, I will start work on the shepherd 
write-up.

One other point: can someone say whether this draft has been shared with the 
IPPM working group?

Thanks,
Adrian

===

Introduction.

First sentence could use a reference to RFC 6020.
[Bo Wu] Fixed.

---

Introduction

OLD
   It defines that the performance
   measurement telemetry model to be tied with the service, such as
   Layer 3 VPN and Layer 2 VPN, or network models to monitor the overall
   network performance or Service Level Agreement (SLA).
NEW
   It defines that the performance
   measurement telemetry model should be tied to the services (such as
   a Layer 3 VPN or Layer 2 VPN) or to the network models to monitor the
   overall network performance and the Service Level Agreements (SLAs).
END

 [Bo Wu] Fixed.
---

2.1

OLD
   SLA Service Level Agreements
NEW
   SLA Service Level Agreement
END

[Bo Wu] Fixed.
---

3.

   For example, the
   controller can use information from [RFC8345], [I-D.ietf-opsawg-sap]
   or VPN instances.

I think this is where there should be a reference to RFC 9182 and 
draft-ietf-opsawg-l2nm.

[Bo Wu] Fixed.
---

3.1

s/dynamic-changing/dynamic/
[Bo Wu] Fixed.

---

4.

OLD
   This document defines the YANG module, "ietf-network-vpn-pm", which
   is an augmentation to the "ietf-network" and "ietf-network-topology".
NEW
   This document defines the YANG module, "ietf-network-vpn-pm", which
   is an augmentation to the "ietf-network" and "ietf-network-topology"
   modules.
END

[Bo Wu] Fixed.
---

4.

Would it be more consistent if the box on the right of Figure 2 showed 
"ietf-network-vpn-pm"?
[Bo Wu] Fixed.

---

I think that Figure 3 could use a little tidying.
- Some gaps in lines
- A couple of lines slightly out of place
- S2A and S2B are confusinly places
- The cross-over of VN3-N2 and VN1-N1 is unclear
- Wording of the Legend a little unclear

How about...


 VPN 1   VPN 2
  ++   ++
 //   //
/ S1C_[VN3]:::   /   //
   / \   :  /   / S2A_[VN1][VN3]_S2B /
  /   \   :::  /   /  :  :  / Overlay
 / \  :  : /
/ S1B_[VN2][VN1]_S1A /   /   :   :/
   +-:---:--+   +---:-:--:---+
 ::    : :
 : :   :::
   Site-1A   :  +---:-:--:---:-+ Site-1C
 [CE1]___:_/___[N1]___[N2]___:/__[CE3]
 :/   / / \ _// :/
   [CE5]_:___/ /\ _/ /::/
 Site-2A/:/   \  /  /   :: /
   / :[N5] /  ::  / Underlay Network
  /   : /   __/ \__   / ::   /
 / :   /___/   \__   /::/
Site-1B /   : / ___/  \ /: /  Site-2B
[CE2]__/[N4]__[N3]/[CE4]
  /  /
 +--+

Legend:
N:Node   VN:VPN-Node  S:Site  CE:Customer Edge
__  Link within a network layer
:   Mapping between network layers

[Bo Wu] Fixed. Thanks for helping to correct the figure.
---

4.1

s/topologies are both built/topologies are 

Re: [OPSAWG] Document shepherd review of draft-ietf-opsawg-yang-vpn-service-pm-06

[Wubo (lana)]

Hi Adrian,

Many thanks for your detailed review. We have released Rev-07 to address these 
issues, see if they are fully addressed.
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-07

Please also find some replies inline.

Thanks,
Bo

-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk] 
Sent: Saturday, April 23, 2022 12:35 AM
To: draft-ietf-opsawg-yang-vpn-service...@ietf.org
Cc: 'opsawg' 
Subject: Document shepherd review of draft-ietf-opsawg-yang-vpn-service-pm-06

Hi,

I'm the document shepherd for this document as it moves beyond the WG for 
requested publication as an RFC.

I reviewed the draft at -03 during WG last call, so my comments here are 
basically editorial with only a few small questions.

If the authors could produce a new revision, I will start work on the shepherd 
write-up.

One other point: can someone say whether this draft has been shared with the 
IPPM working group?

Thanks,
Adrian

===

Introduction.

First sentence could use a reference to RFC 6020.
[Bo Wu] Fixed.

---

Introduction

OLD
   It defines that the performance
   measurement telemetry model to be tied with the service, such as
   Layer 3 VPN and Layer 2 VPN, or network models to monitor the overall
   network performance or Service Level Agreement (SLA).
NEW
   It defines that the performance
   measurement telemetry model should be tied to the services (such as
   a Layer 3 VPN or Layer 2 VPN) or to the network models to monitor the
   overall network performance and the Service Level Agreements (SLAs).
END

 [Bo Wu] Fixed.
---

2.1

OLD
   SLA Service Level Agreements
NEW
   SLA Service Level Agreement
END

[Bo Wu] Fixed.
---

3.

   For example, the
   controller can use information from [RFC8345], [I-D.ietf-opsawg-sap]
   or VPN instances.

I think this is where there should be a reference to RFC 9182 and 
draft-ietf-opsawg-l2nm.

[Bo Wu] Fixed.
---

3.1

s/dynamic-changing/dynamic/
[Bo Wu] Fixed.

---

4.

OLD
   This document defines the YANG module, "ietf-network-vpn-pm", which
   is an augmentation to the "ietf-network" and "ietf-network-topology".
NEW
   This document defines the YANG module, "ietf-network-vpn-pm", which
   is an augmentation to the "ietf-network" and "ietf-network-topology"
   modules.
END

[Bo Wu] Fixed.
---

4.

Would it be more consistent if the box on the right of Figure 2 showed 
"ietf-network-vpn-pm"?
[Bo Wu] Fixed.

---

I think that Figure 3 could use a little tidying.
- Some gaps in lines
- A couple of lines slightly out of place
- S2A and S2B are confusinly places
- The cross-over of VN3-N2 and VN1-N1 is unclear
- Wording of the Legend a little unclear

How about...


 VPN 1   VPN 2
  ++   ++
 //   //
/ S1C_[VN3]:::   /   //
   / \   :  /   / S2A_[VN1][VN3]_S2B /
  /   \   :::  /   /  :  :  / Overlay
 / \  :  : /
/ S1B_[VN2][VN1]_S1A /   /   :   :/
   +-:---:--+   +---:-:--:---+
 ::    : :
 : :   :::
   Site-1A   :  +---:-:--:---:-+ Site-1C
 [CE1]___:_/___[N1]___[N2]___:/__[CE3]
 :/   / / \ _// :/
   [CE5]_:___/ /\ _/ /::/
 Site-2A/:/   \  /  /   :: /
   / :[N5] /  ::  / Underlay Network
  /   : /   __/ \__   / ::   /
 / :   /___/   \__   /::/
Site-1B /   : / ___/  \ /: /  Site-2B
[CE2]__/[N4]__[N3]/[CE4]
  /  /
 +--+

Legend:
N:Node   VN:VPN-Node  S:Site  CE:Customer Edge
__  Link within a network layer
:   Mapping between network layers

[Bo Wu] Fixed. Thanks for helping to correct the figure.
---

4.1

s/topologies are both built/topologies are built/
[Bo Wu] Fixed.

---

The legend for Figure 4 should include "TP" (if TPs are actually relevant to 
the figure and aren't something you should remove - the text doesn't mention 
them, and they don't really seem to be important in Section 4.1).

Probably, TP should be added to the list in Section 2.1 with a reference to 
where TP is properly explained. 4.4 would then be able to lean on that 
definition.

[Bo Wu] Fixed. Thanks for catching this. The reference of TP has been added in 
Section 2.1.
---

4.1

s/VPN PM can provides/VPN PM can provide/

[Bo Wu] Fixed.
---

4.2

s/[RFC9181])./[RFC9181]./

[Bo Wu] Fixed.
---

4.2 etc.

Not sure why 'mac-num' 

Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-yang-vpn-service-pm-05

[Wubo (lana)]

Hi Lada,

Many thanks for your helpful review. We'll fix the errors in these examples in 
the next version. Please see inline for details.

Thanks,
Bo

-Original Message-
From: Ladislav Lhotka via Datatracker [mailto:nore...@ietf.org] 
Sent: Friday, April 8, 2022 8:31 PM
To: yang-doct...@ietf.org
Cc: draft-ietf-opsawg-yang-vpn-service-pm@ietf.org; opsawg@ietf.org
Subject: Yangdoctors early review of draft-ietf-opsawg-yang-vpn-service-pm-05

Reviewer: Ladislav Lhotka
Review result: Ready with Nits

 General comments

The Internet-Draft contains a large YANG module that augments the network 
topology model with L2/L3 VPN performance monitoring statistics. The module is 
well designed and documented, I found no issues in it.

Examples of JSON instance data are useful for readers of the I-D, but less so 
if they contain errors (see below). If possible, I'd suggest to validate the 
examples with appropriate tools, or at least carefully check after each change 
in the data model.

 Specific comments

* Section 5
- File name in  line should be ...@2022-04-08.yang
Bo Wu: Fixed.

* Appendix A.2
- module "ietf-network-topo" doesn't exist, should it be "ietf-network"?
Bo Wu: Yes. Thanks for pointing this out. 

* Appendix A.3
- leaf "middle-percentile" should probably be "intermediate-percentile".
- leaf "unit-values" should be "unit-value"
- The leaf "ietf-network-vpn-pm:inter-vpn-access-interface"
  is illegal (probably misplaced)
Bo Wu: Thanks for catching this. We sill fix these.

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

Re: [OPSAWG] WG LC: A YANG Model for Network and VPN Service Performance Monitoring

[Wubo (lana)]

Hi Tom,

Thanks for your helpful comments. We have submitted Rev-05 to address your 
comments: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-05.
Please see inline for the details.

Thanks,
Bo

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of tom petch
Sent: Wednesday, March 30, 2022 7:31 PM
To: Joe Clarke (jclarke) ; opsawg@ietf.org
Subject: Re: [OPSAWG] WG LC: A YANG Model for Network and VPN Service 
Performance Monitoring

From: OPSAWG  on behalf of Joe Clarke (jclarke) 

Sent: 28 March 2022 14:52

In preparing for IETF 113, I let the close of this slip, but that turns out to 
be a good thing.



Now I have lost my excuse for Last Call comments:-(

I do not understand how OWAMP is default.  AFAICT it is 'config false' so I do 
not understand 'default'
[Bo Wu] Thanks for catching this. We clean up the "default" description in the 
YANG model and add OWAMP, Y.1731, etc. as references.

YANG module references  11 RFC - two are not in the I-D References AFAICT and 
three are Informative - latter may be ok, former not
[Bo Wu] We have corrected this, adding two missing ones and move the three to 
formative.

SLA is not a starred abbreviation
[Bo Wu] Fixed. SLA has been added to the abbreviation.

one way measurement protocol (e.g. OWAMP) what others are there?
[Bo Wu] Y.1731 is also added for Ethernet VPN service.

delay is gauge64, jitter is gauge32; probably ok even if a ratio of 4B to one 
is unlikely
[Bo Wu] We have changed gauge32 to gauge64.

discards I am told are a sign of congestion which I always wonder about - I 
notice you do not mention that possibility!
[Bo Wu] Agree this is a common case. We has added this reason.

Overall, I have a disconnect between PM and topology.  Topology is relatively 
static, you get it or set it and that is that for the time being.  PM for me is 
not.  It changes every interval and I want the history or I want an alert when 
some value for an interval exceeds or falls below a threshold.  Adding a single 
set of values for a single interval seems unrelated to topology and I see 
nothing in the text related to that.
[Bo Wu] We add some new text to describe this in section 3.1. Collecting Data 
via Pub/Sub Mechanism. Please see whether it is clear.

Tom Petch

During her presentation, Bo called out the authors made a substantive change in 
the latest revision to introduce a choice for vpn-pm-type.
Therefore, we are extending LC for another week to close on Monday, April 4, 
2022.

Joe

On 2/28/22 18:05, Joe Clarke (jclarke) wrote:
> Ahead of IETF 113, we'd like to get working group consensus on 
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm
> /.  We are therefore conducting a two-week WG LC on this work.  I have 
> also requested reviews from Yang Docs, Ops, and Routing DIRs.
>
> Please share you comments and reviews on list.
>
> WG LC will end on March 14, 2022.
>
> Thanks.
>
> 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 mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-04.txt

[Wubo (lana)]

Hi all,

This version addresses the comments from Adrian, Qiufang, Joe, and Victor 
during WGLC. The major updates include:
1) Adds a new "choice" to cover 2 VPN PM types. Apart from existing underlay 
VPN PM, an inter-vpn-access-interface PM is added.
2) Adds "range '1..max' " statement of "measurement-interval" to fix definition 
ambiguity.
2) section 4.1. Adds text of network performance monitoring based on VPN 
layering.

Thanks,
Bo

> -邮件原件-
> 发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表
> internet-dra...@ietf.org
> 发送时间: 2022年3月21日 18:21
> 收件人: i-d-annou...@ietf.org
> 抄送: opsawg@ietf.org
> 主题: [OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-04.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   : A YANG Model for Network and VPN Service
> Performance Monitoring
> Authors : Bo Wu
>   Qin Wu
>   Mohamed Boucadair
>   Oscar Gonzalez de Dios
>   Bin Wen
>   Filename: draft-ietf-opsawg-yang-vpn-service-pm-04.txt
>   Pages   : 38
>   Date: 2022-03-21
> 
> Abstract:
>The data model for network topologies defined in RFC 8345 introduces
>vertical layering relationships between networks that can be
>augmented to cover network and service topologies.  This document
>defines a YANG module for performance monitoring (PM) of both
>networks and VPN services that can be used to monitor and manage
>network performance on the topology at higher layer or the service
>topology between VPN sites.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-yang-vpn-service-pm-0
> 4
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-04
> 
> 
> 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 LC: A YANG Model for Network and VPN Service Performance Monitoring

[Wubo (lana)]

Hi Joe,

Thanks for your helpful review. Please see inline.

Regards,
Bo

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2022年3月8日 1:13
收件人: Joe Clarke (jclarke) ; opsawg@ietf.org
主题: Re: [OPSAWG] WG LC: A YANG Model for Network and VPN Service Performance 
Monitoring

A few comments on -03.

Section 4.1

Overall, this section seems like it could use more grounding to this work.  It 
is a generic example of VPN layering.  What would be a nice addition is to 
markup points where performance monitoring would be helpful to illustrate how 
this work comes into play.
[Bo Wu] Thanks for the suggestion. How about adding the following text:
Apart from the association between the VPN topology and the underlay topology, 
VPN Network PM can also provide the performance status of the underlay network 
and VPN services. For example, network PM can provide link PM statistics and 
port statistics.  VPN PM can provides statistics on VPN access interfaces, the 
number of current VRF routes or L2VPN MAC entry of VPN nodes, and performance 
statistics  on the logical point-to-point link between source and destination 
VPN nodes or between  source and destination VPN access interfaces.


In the YANG module, I'm curious about two things:

First, why are inbound-discards a counter32 whereas outbound-discard a 
counter64?  I think both should be 64-bit, yes?
[Bo Wu] Yes. Thanks for catching this. We will fix.

Second, the description on inbound-nunicast is different than outbound-nunicast 
with the latter being more descriptive.  Can you do a pass to make sure these 
two sets of descriptions (inbound and outbond) align respective to their 
direction?
[Bo Wu] Sure. We will fix.



Thanks.

Joe
On 2/28/22 18:06, Joe Clarke (jclarke) wrote:

Ahead of IETF 113, we'd like to get working group consensus on

https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/.  We

are therefore conducting a two-week WG LC on this work.  I have also

requested reviews from Yang Docs, Ops, and Routing DIRs.



Please share you comments and reviews on list.



WG LC will end on March 14, 2022.



Thanks.



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

Re: [OPSAWG] WG LC: A YANG Model for Network and VPN Service Performance Monitoring

[Wubo (lana)]

Hi Adrian,



Thanks again for your helpful review. Please see in line with details.



Thanks,

Bo



> -邮件原件-

> 发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Adrian Farrel

> 发送时间: 2022年3月6日 21:57

> 收件人: 'Joe Clarke (jclarke)' ;

> opsawg@ietf.org

> 主题: Re: [OPSAWG] WG LC: A YANG Model for Network and VPN Service

> Performance Monitoring

>

> Hi,

>

> I reviewed this draft at -01 [1]. The authors proposed acceptable changes, and

> these have appeared in the subsequent revisions.

>

> As part of WG last call, I have done another quick review. Asides from a few

> trivial nits (below), I think this draft is ready for publication.

>

> Thanks,

> Adrian

>

> [1]

> https://mailarchive.ietf.org/arch/msg/opsawg/xcSMXTG8Pooi3ypLNyQWEKm7

> qgg/

>

> ==Nits==

>

> Section 1 para 1

>

> This document shouldn't "propose" anything. It should "define".

[Bo Wu] Thanks. Fixed.

>

> ---

>

> 2.1

>

> s/Service Level Agreements/Service Level Agreement/

[Bo Wu] Thanks. Fixed.



>

> ---

>

> 3.

>

> s/the context of layering/the context of the layering/

[Bo Wu] Thanks. Fixed.

>

> ---

>

> 3.1

>

> s/specified in[RFC8641]/specified in [RFC8641]/

[Bo Wu] Thanks. Fixed.

>

> ---

>

> Obviously, draft-ietf-opsawg-vpn-common is an RFC now.

> You can replace the reference and fix .

[Bo Wu] Thanks for catching this. We will fix.

>

> ---

>

>  leaf measurement-interval {

>type uint32;

>units "seconds";

>default "60";

>description

>  "Indicates the time interval to perform PM measurement.";

>  }

>

> Is a value of 0 supported? What does it mean?

[Bo Wu] Thanks for pointing this out. We will add a constraint of range 
"1..max" to the node.

>

> -Original Message-

> From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
> Behalf Of Joe Clarke (jclarke)

> Sent: 28 February 2022 23:05

> To: opsawg@ietf.org

> Subject: [OPSAWG] WG LC: A YANG Model for Network and VPN Service

> Performance Monitoring

>

> Ahead of IETF 113, we'd like to get working group consensus on

> https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/.  We

> are therefore conducting a two-week WG LC on this work.  I have also

> requested reviews from Yang Docs, Ops, and Routing DIRs.

>

> Please share you comments and reviews on list.

>

> WG LC will end on March 14, 2022.

>

> Thanks.

>

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

Re: [OPSAWG] Some Comments on draft-ietf-opsawg-yang-vpn-service-pm-03

[Wubo (lana)]

Hi Qiufang, all,

Thank you for the review and  comments. Please see in line with replies.

Given that the document is now in the WGLC, the authors discussed this and 
agreed to proceed with some changes.
 The candidate version can be accessed on the GitHub:
https://github.com/IETF-OPSAWG-WG/lxnm/blob/master/I-D-vpn-pm/draft-ietf-opsawg-yang-vpn-service-pm.txt

We would like to ask WG to look into these changes. If no objections, the 
changes will be implemented in the text version.

Thanks,
Bo

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 maqiufang (A)
发送时间: 2022年3月1日 17:17
收件人: draft-ietf-opsawg-yang-vpn-service...@ietf.org
抄送: opsawg@ietf.org
主题: [OPSAWG] Some Comments on draft-ietf-opsawg-yang-vpn-service-pm-03

Hi, all
I’ve reviewed draft-ietf-opsawg-yang-vpn-service-pm-03 today and I have some 
suggestions on the YANG model defined in this work. Hope this helps:

1)“vpn-summary-statistics” under “node” changes to 
“entries-summary”? so that global routing or MAC entries for L3 or L2 topology 
can also use this.
[WuBo] Thanks for the suggestions. We agree this is useful and will change as 
you suggested.


2)PM metrics for VPNs between access circuits (CE-PE links) be 
supported. Currently, the model only covers PM of VPN underlay tunnel.
[WuBo] OK. We agree that this PM method is also worth to include. We will add a 
choice to allows different methods.


3)It is recommended that the model can support on-demand link 
measurement instead of all links by default.
[WuBo] OK, We will some text to clarify this.


Best Regards,
Qiufang Ma
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Poll for IPR: draft-ietf-opsawg-yang-vpn-service-pm

[Wubo (lana)]

Hi Joe, all, 

No, I'm not aware of any IPR that applies to this draft.

Regards,
Bo

> -邮件原件-
> 发件人: Joe Clarke (jclarke) [mailto:jcla...@cisco.com]
> 发送时间: 2022年3月1日 7:11
> 收件人: Wubo (lana) ; Qin Wu
> ; mohamed.boucad...@orange.com; Oscar González de
> Dios ; Bin Wen
> 
> 主题: Poll for IPR: draft-ietf-opsawg-yang-vpn-service-pm
> 
> Authors and contributors, please respond on-list as to whether or not you are
> aware of any IPR that pertains to this work.
> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If you are aware of IPR, indicate whether or not this has been disclosed per 
> IETF
> IPR rules (see RFCs 3669, 5378, and 8179).
> 
> Joe

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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sap-00.txt (Bo's comment)

[Wubo (lana)]

Hi Med,

Thanks for taking my comments into consideration. This new node helps to 
identity the SAP type.

Best regards,
Bo

> -邮件原件-
> 发件人: mohamed.boucad...@orange.com
> [mailto:mohamed.boucad...@orange.com]
> 发送时间: 2022年2月11日 21:39
> 收件人: Wubo (lana) 
> 抄送: opsawg@ietf.org
> 主题: RE: I-D Action: draft-ietf-opsawg-sap-00.txt (Bo's comment)
> 
> Hi Bo,
> 
> A candidate version that takes into account your comment can be seen at:
> https://github.com/IETF-OPSAWG-WG/lxnm/blob/master/I-D-sap/draft-ietf-ops
> awg-sap.txt
> 
> As a reminder, your previous comment was:
> 
> ==
> I have one clarification comment. The introduction says that the SAP model can
> be used together with the service model to derive the interconnection points 
> in
> a multi-domain scenario. Are the interconnection points are also SAPs?
> ==
> 
> Interconnection points are also SAPs. We have now a more clean approach with
> a new data node "interface-role" that is used to indicate whether a SAP is for
> UNI or NNI. This new attribute is also useful if specific augmentations are
> needed in the future for NNIs.
> 
> We have already an example that show how that attribute is used for the uni
> case, but we are also considering inter-AS VPNs to illustrate the nni specific
> part. We may be adding an example in -01 or in -02.
> 
> Thank you.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : OPSAWG  De la part de
> > mohamed.boucad...@orange.com Envoyé : mardi 25 janvier 2022 13:20 À :
> > opsawg@ietf.org Cc : draft-ietf-ospawg-...@ietf.org Objet : Re:
> > [OPSAWG] I-D Action: draft-ietf-opsawg-sap-00.txt
> >
> > Hi all,
> >
> > This version does not address any of the comments raised during the
> > call for adoption. We are planning to do so in the coming weeks.
> >
> > The comments raised by Benoît, Daniel, Dhruv, and Bo are recorded at:
> > https://github.com/IETF-OPSAWG-WG/lxnm/issues?q=label%3AI-D.sap
> >
> > Please use that repo to flag your issues. Thanks.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : I-D-Announce  De la part de
> > > internet-dra...@ietf.org Envoyé : mardi 25 janvier 2022 13:02 À :
> > > i-d-annou...@ietf.org Cc : opsawg@ietf.org Objet : I-D Action:
> > > draft-ietf-opsawg-sap-00.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   : A Network YANG Model for Service
> Attachment
> > > Points
> > > Authors : Oscar Gonzalez de Dios
> > >   Samier Barguil
> > >   Qin Wu
> > >   Mohamed Boucadair
> > >   Victor Lopez
> > >   Filename: draft-ietf-opsawg-sap-00.txt
> > >   Pages   : 21
> > >   Date: 2022-01-25
> > >
> > > Abstract:
> > >This document defines a YANG data model for representing an
> > abstract
> > >view of the provider network topology containing the points from
> > >which its services can be attached (e.g., basic connectivity, VPN,
> > >network slices).  The data model augments the 'ietf-network' data
> > >model by adding the concept of service attachment points (SAPs).
> > The
> > >service attachment points are the points to which network services
> > >(such as L3VPN or L2VPN) can be attached.  The customer endpoint of
> > >an attachment circuits are not covered in the SAP network topology.
> > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-sap/
> > >
> > > There is also an htmlized version available at:
> > > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sap-00
> > >
> > >
> > > Internet-Drafts are also available by rsync at
> > > rsync.ietf.org::internet- drafts
> > >
> > >
> > > ___
> > > I-D-Announce mailing list
> > > i-d-annou...@ietf.org
> > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > Internet-Draft directories: http://www.ietf.org/shadow.html or
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> __

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-03.txt

[Wubo (lana)]

Hi WG,

This update addresses comments from Tom Petch on the WG mailing list. Many 
thanks to Tom.
Please see the diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-03.

We would appreciate moving this document to WG last call now. There is no 
pending issue.

Thanks,
Bo (on behalf of the co-authors)


> -邮件原件-
> 发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表
> internet-dra...@ietf.org
> 发送时间: 2022年1月29日 17:06
> 收件人: i-d-annou...@ietf.org
> 抄送: opsawg@ietf.org
> 主题: [OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-03.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   : A YANG Model for Network and VPN Service
> Performance Monitoring
> Authors : Bo Wu
>   Qin Wu
>   Mohamed Boucadair
>   Oscar Gonzalez de Dios
>   Bin Wen
>   Filename: draft-ietf-opsawg-yang-vpn-service-pm-03.txt
>   Pages   : 36
>   Date: 2022-01-29
> 
> Abstract:
>The data model for network topologies defined in RFC 8345 introduces
>vertical layering relationships between networks that can be
>augmented to cover network and service topologies.  This document
>defines a YANG module for performance monitoring (PM) of both
>networks and VPN services that can be used to monitor and manage
>network performance on the topology at higher layer or the service
>topology between VPN sites.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-yang-vpn-service-pm-0
> 3
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-02.txt

[Wubo (lana)]

Hi Tom,

Many thanks for your kindly help. Please see inline.

Best regards,
Bo

> -邮件原件-
> 发件人: tom petch [mailto:ie...@btconnect.com]
> 发送时间: 2022年1月26日 1:09
> 收件人: Wubo (lana) ; Wubo (lana)
> ; opsawg@ietf.org;
> draft-ietf-opsawg-yang-vpn-service...@ietf.org
> 主题: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-02.txt
> 
> From: Wubo (lana) 
> Sent: 25 January 2022 13:16
> 
> Hi Tom,
> 
> Thanks for the review and we will correct these issues in the next version.
> Please see inline.
> 
> < inline twice>
> 
> Best regards,
> Bo
> 
> > -邮件原件-
> > 发件人: tom petch [mailto:ie...@btconnect.com]
> > 发送时间: 2022年1月21日 20:30
> >
> > From: OPSAWG  on behalf of Wubo (lana)
> > 
> > Sent: 20 January 2022 03:24
> >
> >
> > percentile definition seems not quite right.  You are using a
> > percentage here but there is no requirement to do so - it can be an
> > integer count or any other measurement of a proportion
> [Bo Wu] We provide two options here, and some providers think percentile is
> also useful. I'm not sure the issue. Could you elaborate a little bit?
> 
> 
> Percentile is fine as a way of characterising  a distribution with a single 
> value.
> My comment is that for any percentile, be it 50-percentile, 95-percentile or
> whatever, then there is a value to go with that and that value can be anything
> that is a value - integer, percentage etc.  I think that the description here
> wants it to be a percentage which I think too limiting.
> 
[Bo Wu] Thanks for the explanation. How about the following change?
OLD:
 typedef percentile {
   type decimal64 {
 fraction-digits 5;
 range "1..100";
   }
   description
 "The percentile is a statistical value that indicates that a
  certain percentage of a set of data falls below it.";
 }
 
NEW:
 typedef percentile {
   type decimal64 {
 fraction-digits 2;
   range "0..100";
   }
   description
 "The percentile is a value between 0 and 100, e.g. 10, 99.9 ,99.99 
etc. . 
 For example, if the percentile is set to 95. For a given one-way delay 
measurement, 
 if the 95th percentile one-way delay is 2 milliseconds, then the 95 
percent of the sample value is less than or 
 equal to 2 milliseconds.";
 }
> >

> > 'middle-delay' I think confusing; sounds too much like it is the
> > median or mode; perhaps medium?
> [Bo Wu] Agree. rfc3393 uses median to indicate 50th percentile. so we change
> it to "median-delay"?
> 
> 
> Well no, it is median only when it is a 50-percentile which is only the 
> default
> here and if the user chose 90 instead, wanting the three percentiles to be 60,
> 90, 95, then I think median is misleading.
> 
> And RFC3393 says (along with defining ipdv:-) that the 50-percentile is the
> median which is correct.  Here you are defining low, something else, high and
> when something else is not 50, then it is not the median.  I am struggling 
> for a
> word that sits between low and high that does not have connotations of being
> the middle!  intermediate?

[Bo Wu]Got it. Thanks. We will change it to "intermediate" to avoid the 
confusion. 
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-02.txt

[Wubo (lana)]

Hi Tom,

Thanks for the review and we will correct these issues in the next version. 
Please see inline.

Best regards,
Bo

> -邮件原件-
> 发件人: tom petch [mailto:ie...@btconnect.com]
> 发送时间: 2022年1月21日 20:30
> 收件人: Wubo (lana) ;
> opsawg@ietf.org; draft-ietf-opsawg-yang-vpn-service...@ietf.org
> 主题: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-02.txt
> 
> From: OPSAWG  on behalf of Wubo (lana)
> 
> Sent: 20 January 2022 03:24
> 
> 
> Hi WG,
> 
> Many thanks to the WG for the discussion and valuable comments.
> 
> This update mainly reflects the discussion decision of the 112 meeting and 
> also
> the comments of Adrian and Greg on the mailing list.
> 
> 
> Some possible glitches for you.
> 
> Some of the lines in the YANG module are too long (they were ok in -01)
[Bo Wu] Thanks for catching this, will fix in the next revision.
> 
> You use  to refer to two different I-D (this was ok in -01)
[Bo Wu] Thanks. Fixed.
> 
> Abbreviations need expanding, perhaps in Terminology e.g. VPLS OWAMP
> L3VPN
[Bo Wu] OK. Thanks.
> 
> I want references in the YANG module for OWAMP IPDV P
[Bo Wu] OK.
> 
> ITU-T Y.1731 would benefit from a title and needs adding to the I-D References
[Bo Wu] OK.
> 
> five fraction digits for a percentile?  I note that the defaults have only two
> digits
[Bo Wu] Fixed.
> 
> /http:/https:/
> TLP is out of date
[Bo Wu] Fixed.
> 
> percentile definition seems not quite right.  You are using a percentage here
> but there is no requirement to do so - it can be an integer count or any other
> measurement of a proportion
[Bo Wu] We provide two options here, and some providers think percentile is 
also useful. I'm not sure the issue. Could you elaborate a little bit?
> 
[Bo Wu] Fixed.
> 'middle-delay' I think confusing; sounds too much like it is the median or 
> mode;
> perhaps medium?
[Bo Wu] Agree. rfc3393 uses median to indicate 50th percentile. so we change it 
to "median-delay"?
> 
> time when statistics are collected; start time, end time, duration of 
> interval?
[Bo Wu] OK, we will change "reference-time" to "start time" and "end time", but 
we like to keep " measurement-interval".
> 
> subnetwork (broadcast, multicast) I find unclear - sub which layer of our 
> current
> network many-layered stacks.
[Bo Wu] OK, we directly use IETF interface YANG description in this version. We 
will make this clearer. 
> 
> Tom Petch
> 
> The detailed changes are the following:
> 1. Adds modeling considerations to the introduction 2. Adds a reference to
> draft-ietf-netmod-node-tags 3. YANG: Replaces the type of "pm-source”:
> string' -> 'identity'
> 4. YANG: Adds "vpn-one-way-pm-statistics* [class-id]" to collect class-based
> VPN underlay tunnel statistics 5. YANG: Adds “vpn-network-access” specific
> counters under " termination-point"
> 6. YANG: Highlights the unidirectional link metrics with "
> one-way-pm-statistics"
> 7. Fixed a lot of editorial issues
> 
> Here is the diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-02.
> 
> Thanks,
> Bo
> 
> > -邮件原件-
> > 发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表
> > internet-dra...@ietf.org
> > 发送时间: 2022年1月20日 10:50
> > 收件人: i-d-annou...@ietf.org
> > 抄送: opsawg@ietf.org
> > 主题: [OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-02.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   : A YANG Model for Network and VPN Service
> > Performance Monitoring
> > Authors : Bo Wu
> >   Qin Wu
> >   Mohamed Boucadair
> >   Oscar Gonzalez de Dios
> >   Bin Wen
> >   Filename: draft-ietf-opsawg-yang-vpn-service-pm-02.txt
> >   Pages   : 35
> >   Date: 2022-01-19
> >
> > Ab
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] A review of draft-ietf-opsawg-yang-vpn-service-pm-01

[Wubo (lana)]

Hi Greg,

Thanks for the comments. But I am not sure I understand this question.

Assuming the question is about modelling consideration, we have added the 
following description to the new version:

The performance of VPN services is associated with the performance
   changes of the underlay network that carries VPN services, such as
   the delay of the underlay tunnels and the packet loss status of the
   device interfaces.  Additionally, the integration of Layer 2/Layer 3
   VPN performance and network performance data enables the orchestrator
   to subscribe to VPN service performance in a unified manner.
   Therefore, this document defines a YANG module for both network and
   VPN service performance monitoring (PM).  The module can be used to
   monitor and manage network performance on the topology level or the
   service topology between VPN sites, in particular

Hope this helps.

Thanks,
Bo

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Greg Mirsky
发送时间: 2022年1月17日 7:15
收件人: adr...@olddog.co.uk
抄送: opsawg@ietf.org; ippm-cha...@ietf.org; 
draft-ietf-opsawg-yang-vpn-service...@ietf.org; i...@ietf.org
主题: Re: [OPSAWG] A review of draft-ietf-opsawg-yang-vpn-service-pm-01

Hi Adrian, the Authors, and All,
thank you Adrian for reviewing the draft and inviting further discussion. I've 
commented on this work earlier suggesting considering the performance metrics 
listed in the STAMP YANG data model. I appreciate that the Authors have found 
them helpful and included them in this model. But I still wonder what, if 
anything, is special for a VPN service from a performance metrics perspective 
compared to, for example, an underlay? Would it be possible and simpler to have 
a single PM data model applicable to any underlay or overlay network?

Regards,
Greg

On Sun, Jan 16, 2022 at 8:16 AM Adrian Farrel 
mailto:adr...@olddog.co.uk>> wrote:
Hi authors,

This draft has been safely inside the OPSAWG for a while, so I though
it was probably due a review.

"The usual" two top-level issues:

- The draft expired earlier this month, so you need at a least a
  keep-alive version.

- The draft has more than five front-page authors so the AD or RFC
  Editor will object. It is probably best for you to resolve this issue
  sooner rather than later.

Otherwise, my comments are a collection of small nits and nothing
alarming.  Thanks for your work on this document.

Best,
Adrian

== Questions ==

Looking at Figure 1, an obvious question is why this model doesn't
augment the L2/L3NM or the common VPN model. It is OK (for me) that you
have chosen to augment the network topology model, but it is not clear
to the reader why you have done this.

---

I wonder whether the work in this document would benefit from using
data tags (draft-ietf-netmod-node-tags). I might be wrong, but it seems
particularly related and useful.

---

If, in Figure 3, VPN1 is configured as hub and spoke with S1A as the
hub, why is there a link in the virtual network between VN2 and VN3?

---

5.

General question about counters based on my memory of how we did MIBs
(So I am old! Quite possible that YANG does this differently.) Don't
you need something to handle resets? That is, to distinguish between
wrapping and resetting, we used to include a timestamp for when the
counters were last reset. Sometimes this was a timestamp per counter,
but usually enough for one timestamp across all counters.

(This probably makes a difference to the gauges and percentiles, too.)

Re-reading, it is possible that this is covered by 'reference-time' and
'measurement-interval'.  If so, this could be a lot clearer in 4.4.

---

5.

  leaf pm-source {
type string;
config false;
description
  "The OAM tool used to collect the PM data.";
  }

I'm not convinced that using a string here is helpful. How does the
device know what string to use to convey meaning to the application?

Or is the point that this is just printable information for display and
human consumption? If so, perhaps a note to this effect in Section 4.4.

== Nits ===

Abstract

It would be nice to say what the model in 8345 is. So...

   The data model for network topologies defined in RFC 8345 introduces
   vertical layering relationships between networks that can be
   augmented to cover network and service topologies.

---

Abstract

I think PM stands for 'performance monitoring' not 'network performance
monitoring', so for the avoidance of doubt...

   This document defines a YANG module for
   performance monitoring (PM) of both networks and VPN services that
   can be used to monitor and manage network performance on the topology
   at higher layer or the service topology between VPN sites.

---

2.

You have the BCP 14 boilerplate, but the uses of "should" and "must" in
the document are in lower case. There is one use of upper case "MAY" in
the Security Considerations which should be, I think, lower case since
it is a statement of fact not guidance to an 

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-02.txt

[Wubo (lana)]

Hi WG,

Many thanks to the WG for the discussion and valuable comments.

This update mainly reflects the discussion decision of the 112 meeting and also 
the comments of Adrian and Greg on the mailing list. 

The detailed changes are the following:
1. Adds modeling considerations to the introduction
2. Adds a reference to draft-ietf-netmod-node-tags
3. YANG: Replaces the type of "pm-source”: string' -> 'identity'
4. YANG: Adds "vpn-one-way-pm-statistics* [class-id]" to collect class-based 
VPN underlay tunnel statistics
5. YANG: Adds “vpn-network-access” specific counters under " termination-point"
6. YANG: Highlights the unidirectional link metrics with " 
one-way-pm-statistics"
7. Fixed a lot of editorial issues

Here is the diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-02.

Thanks,
Bo

> -邮件原件-
> 发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表
> internet-dra...@ietf.org
> 发送时间: 2022年1月20日 10:50
> 收件人: i-d-annou...@ietf.org
> 抄送: opsawg@ietf.org
> 主题: [OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-02.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   : A YANG Model for Network and VPN Service
> Performance Monitoring
> Authors : Bo Wu
>   Qin Wu
>   Mohamed Boucadair
>   Oscar Gonzalez de Dios
>   Bin Wen
>   Filename: draft-ietf-opsawg-yang-vpn-service-pm-02.txt
>   Pages   : 35
>   Date: 2022-01-19
> 
> Abstract:
>The data model for network topologies defined in RFC 8345 introduces
>vertical layering relationships between networks that can be
>augmented to cover network and service topologies.  This document
>defines a YANG module for performance monitoring (PM) of both
>networks and VPN services that can be used to monitor and manage
>network performance on the topology at higher layer or the service
>topology between VPN sites.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-yang-vpn-service-pm-0
> 2
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-02
> 
> 
> 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 Adoption Call for draft-dbwb-opsawg-sap-00

[Wubo (lana)]

Hi Tianran, all,

I support the adoption. I have read the draft. The draft is a necessary piece 
to realize L3SM, L2SM, and network slice services.

I have one clarification comment. The introduction says that the SAP model can 
be used together with the service model to derive the interconnection points in 
a multi-domain scenario. Are the interconnection points are also SAPs?

Best regards,
Bo
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2022年1月5日 10:12
收件人: opsawg@ietf.org
抄送: opsawg-cha...@ietf.org
主题: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi WG,

I assume most of you are back to work.
Hope you had a good holiday.

As a follow up action after IETF 111, this mail starts a working group adoption 
call for draft-dbwb-opsawg-sap-00.
https://datatracker.ietf.org/doc/draft-dbwb-opsawg-sap/

This document defines a YANG data model for representing an abstract view of 
the provider network topology containing the points from which its services can 
be attached (e.g., basic connectivity, VPN, network slices).

Please review and comment.
We will conclude this adoption call after two weeks.

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

Re: [OPSAWG] A review of draft-ietf-opsawg-yang-vpn-service-pm-01

[Wubo (lana)]

Hi Adrian,

Many thanks for your valuable and helpful review. Please see the reply inline.

Best regards,
Bo

> -邮件原件-
> 发件人: Adrian Farrel [mailto:adr...@olddog.co.uk]
> 发送时间: 2022年1月17日 0:16
> 收件人: draft-ietf-opsawg-yang-vpn-service...@ietf.org
> 抄送: opsawg@ietf.org
> 主题: A review of draft-ietf-opsawg-yang-vpn-service-pm-01
> 
> Hi authors,
> 
> This draft has been safely inside the OPSAWG for a while, so I though it was
> probably due a review.
> 
> "The usual" two top-level issues:
> 
> - The draft expired earlier this month, so you need at a least a
>   keep-alive version.
[Bo] Thanks for the kind reminder, the authors plan to submit a new version 
this week and will address your comments in this version.

> - The draft has more than five front-page authors so the AD or RFC
>   Editor will object. It is probably best for you to resolve this issue
>   sooner rather than later.
[Bo] Thank you. we will correct this in the new version.
> 
> Otherwise, my comments are a collection of small nits and nothing alarming.
> Thanks for your work on this document.
> 
> Best,
> Adrian
> 
> == Questions ==
> 
> Looking at Figure 1, an obvious question is why this model doesn't augment the
> L2/L3NM or the common VPN model. It is OK (for me) that you have chosen to
> augment the network topology model, but it is not clear to the reader why you
> have done this.
> 
[Bo]Thanks. We think it is useful to add some text to explain. How about adding 
some text like this:
The performance of VPN services is associated with the performance changes of 
the underlay network that carries VPN services, such as the delay of the 
underlay tunnels and the packet loss status of the device interfaces.
Additionally, the integration of Layer 2/Layer 3 VPN performance and network 
performance data enables the orchestrator to subscribe to VPN service 
performance in a unified manner. 
Therefore, this document defines a YANG module for both network and VPN service 
performance monitoring (PM).
> ---
> 
> I wonder whether the work in this document would benefit from using data
> tags (draft-ietf-netmod-node-tags). I might be wrong, but it seems 
> particularly
> related and useful.
> 
[Bo]Agree. We think draft-ietf-netmod-node-tags can helps PM accurately 
subscribe to metric-related data. How about the following text in section 3 
Network and VPN Service Performance Monitoring Model Usage:
VPN and network performance management focus on the performance metric data of 
network devices. To avoid receiving a large amount of operational data of VPN 
instances, VPN interfaces, or tunnels, 
The controller can specifically subscribe to metric-specific data using the 
methods defined in draft-ietf-netmod-node-tags.

> ---
> 
> If, in Figure 3, VPN1 is configured as hub and spoke with S1A as the hub, why 
> is
> there a link in the virtual network between VN2 and VN3?
> 
[Bo] Thank you for catching this. We will remove the link.
> ---
> 
> 5.
> 
> General question about counters based on my memory of how we did MIBs (So
> I am old! Quite possible that YANG does this differently.) Don't you need
> something to handle resets? That is, to distinguish between wrapping and
> resetting, we used to include a timestamp for when the counters were last
> reset. Sometimes this was a timestamp per counter, but usually enough for one
> timestamp across all counters.
> 
> (This probably makes a difference to the gauges and percentiles, too.)
> 
> Re-reading, it is possible that this is covered by 'reference-time' and
> 'measurement-interval'.  If so, this could be a lot clearer in 4.4.
> 
[Bo] Yes. Your understanding about 'reference-time' and 'measurement-interval' 
is correct. We will add text in 4.4 to make it clearer.
'reference-time': Indicates the start time of the performance measurement.
'measurement-interval' : Specifies the performance measurement interval, in 
seconds.
> ---
> 
> 5.
> 
>   leaf pm-source {
> type string;
> config false;
> description
>   "The OAM tool used to collect the PM data.";
>   }
> 
> I'm not convinced that using a string here is helpful. How does the device 
> know
> what string to use to convey meaning to the application?
> 
> Or is the point that this is just printable information for display and human
> consumption? If so, perhaps a note to this effect in Section 4.4.
> 
[Bo] This is a pending comment we have and, as discussed in the last IETF 
meeting, identities will be used instead.

> == Nits ===
> 
> Abstract
> 
> It would be nice to say what the model in 8345 is. So...
> 
>The data model for network topologies defined in RFC 8345 introduces
>vertical layering relationships between networks that can be
>augmented to cover network and service topologies.
> 
[Bo] Thanks. We will make the change you suggested.
> ---
> 
> Abstract
> 
> I think PM stands for 'performance monitoring' not 'network performance
> monitoring', so for the avoidance of doubt...
> 
>

Re: [OPSAWG] A question on the use of "direction" in draft-ietf-opsawg-yang-vpn-service-pm

[Wubo (lana)]

Hi Greg,

Thanks for the comments. Please see inline.

Thanks,
Bo

发件人: Greg Mirsky [mailto:gregimir...@gmail.com]
发送时间: 2021年11月4日 4:03
收件人: opsawg ; draft-ietf-opsawg-yang-vpn-service...@ietf.org
主题: A question on the use of "direction" in 
draft-ietf-opsawg-yang-vpn-service-pm

Dear Authors,
thank you for your work on this model. I read the document and have one 
question and a single suggestion for your consideration:

  *   I find the description of the "direction" somewhat confusing. Can you 
give an example when the "direction" is set to "two-way". In that case, how 
that affects the reported performance metrics. I can imagine that in some 
cases, a performance metric calculated using a round-trip measured value. In 
that case, it is helpful to indicate the source of the metric as RT/2 vs. 
one-way.
[Bo] Thanks. This makes sense.  Instead of “direction” definition, I suggest to 
directly define “ two-way-delay”, so when the “pm-source” uses two-way 
measurement, it is easier to read.
I may suggest changing default values for percentiles. Based on the feedback 
we've received, the STAMP YANG model uses p95, p99, and p99.9 as default values 
for low, middle, and high percentile respectively.
[Bo] Thanks for the suggestion. Looking at STAMP YANG, I can’t find the 
description on this. Could you elaborate on why these values are defined?
Regards,
Greg

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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-01.txt

[Wubo (lana)]

Hi all,

This revision has the following updates:
1. Clarified the scope to cover L2VPN performance monitoring.
2. Aligned terms with draft LxNM, using the definition of draft 
-ietf-opsawg-vpn-common.
3. Added reference to RFC 8309 as architecture context and corrected other 
references.
4. Revised the YANG model for better extension.

Here is the pointer for all addressed PM issues:
https://github.com/IETF-OPSAWG-WG/lxnm/issues?q=is%3Aissue+is%3Aclosed+label%3Aservice-pm

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-01


Thanks,
Bo

-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 internet-dra...@ietf.org
发送时间: 2021年7月7日 14:10
收件人: i-d-annou...@ietf.org
抄送: opsawg@ietf.org
主题: [OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-01.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   : A YANG Model for Network and VPN Service Performance 
Monitoring
Authors : Bo Wu
  Qin Wu
  Mohamed Boucadair
  Oscar Gonzalez de Dios
  Bin Wen
  Change Liu
  Honglei Xu
Filename: draft-ietf-opsawg-yang-vpn-service-pm-01.txt
Pages   : 32
Date: 2021-07-06

Abstract:
   The data model defined in RFC 8345 introduces vertical layering
   relationships between networks that can be augmented to cover network
   and service topologies.  This document defines a YANG module for both
   network performance monitoring (PM) and VPN service performance
   monitoring that can be used to monitor and manage network performance
   on the topology at higher layer or the service topology between VPN
   sites.

   The YANG model defined in this document is designed as an
   augmentation to the network topology YANG model defined in RFC 8345
   and draws on relevant YANG types defined in RFC 6991, RFC 8345, and
   RFC 8532.


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

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-yang-vpn-service-pm-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-01


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

Re: [OPSAWG] Call for presentation

[Wubo (lana)]

Hi Chairs,

I would like to request a slot for the updates of Network and VPN Service PM 
YANG draft:

https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/8 
minutes

Thanks,
Bo

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2021年7月1日 15:51
收件人: opsawg@ietf.org
抄送: opsawg-cha...@ietf.org
主题: [OPSAWG] Call for presentation

Hi WG,

The OPSAWG meeting is now in the preliminary 111 agenda at 16:00-18:00 Friday 
Session III.
We now open the call for presentation.
Please send over your request to the chairs.

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

Re: [OPSAWG] Roman Danyliw's No Objection on draft-ietf-opsawg-tacacs-yang-11: (with COMMENT)

[Wubo (lana)]

Hi all,
Thanks for the review and comments.
v-12 is posted to resolve the comments on the description for the "security" 
choice.
Please check the diff:  
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-yang-12

Thanks,
Bo

-邮件原件-
发件人: Roman Danyliw via Datatracker [mailto:nore...@ietf.org] 
发送时间: 2021年5月14日 3:18
收件人: The IESG 
抄送: draft-ietf-opsawg-tacacs-y...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; Joe Clarke ; jcla...@cisco.com
主题: Roman Danyliw's No Objection on draft-ietf-opsawg-tacacs-yang-11: (with 
COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-opsawg-tacacs-yang-11: 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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/



--
COMMENT:
--

Thank you to Yaron Sheffer for the SECDIR review, and for the changes in 
response.

Thanks for addressing my DISCUSS around compatibility with RFC8907 and the 
COMMENT feedback.

Per my DISCUSS on publishing this document as a proposed standard and 
characterizing it as new functionality that standardizes an API to an insecure 
protocol (that is itself has informational status), I will clear per the 
discussion had in the IESG:

-- I’m persuaded that with -11, the YANG module is feature equivalent to
RFC8907 (so there isn't any new functionality).  Surprisingly, despite this 
module being focused on RFC8907, it now foreshadows future changes in Section 4 
of the "choice security" with "... a future encryption mechanism will result in 
a non-backwards-compatible change" which suggests that this YANG module isn't 
tied solely to RFC8907.

-- As to the API mechanism being new functionality, I question the value of 
making it easier to manage a fundamentally insecure protocol with this new 
capability and whether publication of this document (unlike RFC8907) does 
provide the basis for future improvements.  Nevertheless, there are operational 
realities of how widely TACACS+ is already deployed that necessitate 
improvement management of the as-is infrastructure while an improved protocol 
is built.

-- As to the issue of the underlying protocol having a “lower” status 
(information for RFC8907) than the associated YANG module (PS for this 
document), I leave that to the convention of OPS area.



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

Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-yang-10: (with DISCUSS and COMMENT)

[Wubo (lana)]

Hi Roman, all,

Thank you all for the review and discussion. The new revision is just posted 
based on the comments, please see the diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-yang-11


Thanks,
Bo

-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Rob Wilton (rwilton)
发送时间: 2021年4月20日 17:19
收件人: Roman Danyliw ; The IESG 
抄送: opsawg@ietf.org; opsawg-cha...@ietf.org; 
draft-ietf-opsawg-tacacs-y...@ietf.org
主题: Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-yang-10: 
(with DISCUSS and COMMENT)

Hi Roman,

Thanks for the review.   I have chipped in a couple of comments on your discuss 
concerns below.


> -Original Message-
> From: iesg  On Behalf Of Roman Danyliw via 
> Datatracker
> Sent: 19 April 2021 23:08
> To: The IESG 
> Cc: opsawg@ietf.org; Joe Clarke (jclarke) ; opsawg- 
> cha...@ietf.org; draft-ietf-opsawg-tacacs-y...@ietf.org
> Subject: Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-yang-10:
> (with DISCUSS and COMMENT)
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-opsawg-tacacs-yang-10: Discuss
> 
> 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/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> ** RFC8907 was published with informational status and it contained 
> substantial caution in its security considerations that the protocol 
> was fundamentally insecure and would not “meet modern-day 
> requirements.”  This measured approach was taken to provide a stable 
> description of a widely deployed protocol and to serve as the basis 
> for future improvements.
> 
> The context for this follow-on, seemingly related work does not track 
> the situation around RFC8907 (as I remember it).  Specifically:
> 
> -- this functionality is new, and is not documenting the “as is” 
> deployed state

My understanding is that RFC8907 defines the current TACACS+ protocol as it 
stands, and that this draft is intended to document the YANG configuration data 
model that goes alongside RFC8907, and that these two documents act as a 
starting point for any future TACACS+ work in IETF.



> 
> -- this functionality is advocating for supporting an insecure 
> approach with proposed standard (rather than informational) status
[RW] 

The proposed standard status really comes from the fact that it is documenting 
a formal API (i.e., the YANG data model), and that this document should reflect 
IETF consensus on the data model for how TACACS+ is managed in YANG.  I also 
believe that the intention is that we can build on RFC8907 and this draft to 
improve the security aspects of the TACACS+ protocol over time and having the 
base YANG model draft being standards track is probably better to build on.

As a side note, a question from the routing ADs came up regarding what the 
status of documents containing YANG Modules should be (in that case for YANG 
models documenting experimental RFCs).  Perhaps it would help for me to write 
up some guidelines and to discuss those with the IESG?

> 
> ** Is this document intentionally breaking backward compatibility on the
> “shared-secret” size specified in RFC8907?
> 
> (a) Section 4.
>   case shared-secret {
> leaf shared-secret {
>   type string {
> length "16..max";
>   }
> 
> (b) Section 10.5.1 of RFC8907 says “TACACS+ server administrators SHOULD
> configure secret keys of a minimum of 16 characters in length.”
> 
> As (b) is not a MUST (a “secret key” shorter than 16 is possible), it
> would
> appear that (a) breaks compatibility.
[RW] 

Section 10.5.1 of RFC8907 also states:

   *  TACACS+ clients SHOULD NOT allow servers to be configured without
  a shared secret key or shared key that is less than 16 characters
  long.

Given that an implementation could use a YANG deviation to allow shorter 
shared-secrets, I think that having the standard IETF YANG model require shared 
keys to be at least 16 characters is the right choice.

If clients were currently using shared keys of less than 16 characters then 
they would need to change to longer secrets, but the YANG data model is 
defining a new API anyway, so a certain amount of migration would be expected 
anyway.

Does this help with your discuss concerns?

Regards,
Rob


> 
> 
> --
> COMMENT:
> --
> 
> 

Re: [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-tacacs-yang-10: (with DISCUSS)

[Wubo (lana)]

Hi Francesca,

Thank you for the review. I hope the IETF process can provide more guidance on 
your discuss issue.

Best regards,
Bo


-邮件原件-
发件人: Francesca Palombini via Datatracker [mailto:nore...@ietf.org] 
发送时间: 2021年4月22日 0:30
收件人: The IESG 
抄送: draft-ietf-opsawg-tacacs-y...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; Joe Clarke ; jcla...@cisco.com; 
l...@cisco.com
主题: Francesca Palombini's Discuss on draft-ietf-opsawg-tacacs-yang-10: (with 
DISCUSS)

Francesca Palombini has entered the following ballot position for
draft-ietf-opsawg-tacacs-yang-10: Discuss

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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/



--
DISCUSS:
--

Thank you for the work on this document.
This is a discuss DISCUSS - while reading this document and considering the 
normative downref to RFC 8907 TACACS+, which is informational, I agree with 
Elliot [1] that to me this document would make more sense as informational. I 
have followed the mail thread and saw the authors' responses, which quoted RFC
3967 :

   o  A standards document may need to refer to a proprietary protocol,
  and the IETF normally documents proprietary protocols using
  informational RFCs.

I am not convinced that this is one of the cases that this bullet was supposed 
to cover. Additionally, I could not find in meeting minutes that this was ever 
discussed in the wg, as was suggested in the mail thread [2]. I'd like to know 
if the resp AD is aware of any related discussion after this point was raised.

Another point the authors made in favor of keeping this std track was that they 
haven't seen any YANG data model published as informational. Again, I am not 
convinced that this is reason enough to progress this as std track.

I note that this was reported in the shepherd write up [3] and in the last call 
[4], so won't block progress after a discussion, but I do think it is worth 
talking about. Please let me know if I missed anything.

Thanks,
Francesca

[1] https://mailarchive.ietf.org/arch/msg/opsawg/2mRkaXy5M9XCPp4_wXNpQd9GLdk/
[2] https://mailarchive.ietf.org/arch/msg/opsawg/MOnCfYBS3j4wBnZWDjl_YQHfvzg/
[3]
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/shepherdwriteup/
[4] https://mailarchive.ietf.org/arch/msg/opsawg/FJmtUtB0x8tV0MUdO9Uhvc2e1p0/





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

Re: [OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-tacacs-yang-10: (with COMMENT)

[Wubo (lana)]

Hi Benjamin,

Thank you for the comments. Regarding the standards-track issue, I hope the 
IETF process can provide more guidance. For the rest, please see inline.

Best regards,
Bo

-邮件原件-
发件人: Benjamin Kaduk via Datatracker [mailto:nore...@ietf.org] 
发送时间: 2021年4月22日 13:16
收件人: The IESG 
抄送: draft-ietf-opsawg-tacacs-y...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; Joe Clarke ; jcla...@cisco.com
主题: Benjamin Kaduk's No Objection on draft-ietf-opsawg-tacacs-yang-10: (with 
COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsawg-tacacs-yang-10: 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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/



--
COMMENT:
--

I have very little to add that was not already mentioned by my colleagues (but 
I agree with Roman and Francesca that a compelling case for standards-track has 
not been visibly made).  These are basically nit-level comments.


Section 3

   authorization, and accounting servers.  Authentication is used to
   validate a user's username and password, authorization allows the
   user to access and execute commands at various command levels

I think that RFC 8907 uses the term "privilege level" for what is being 
referred to as "command level" here.
[Bo] Thanks for pointing this out. I will fix this.

Section 4

leaf timeout {
  type uint16 {
range "1..300";
  }

How was the maximum of 300 seconds chosen?
[Bo] This 5 minutes value comes from common practice. If you have other 
concerns, I will change the range to "1..max".


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

Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-tacacs-yang-10: (with COMMENT)

[Wubo (lana)]

Hi John,

Thank you for the helpful comments. I will update accordingly.

Best regards,
Bo

-邮件原件-
发件人: John Scudder via Datatracker [mailto:nore...@ietf.org] 
发送时间: 2021年4月21日 9:08
收件人: The IESG 
抄送: draft-ietf-opsawg-tacacs-y...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; Joe Clarke ; jcla...@cisco.com
主题: John Scudder's No Objection on draft-ietf-opsawg-tacacs-yang-10: (with 
COMMENT)

John Scudder has entered the following ballot position for
draft-ietf-opsawg-tacacs-yang-10: 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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/



--
COMMENT:
--

Below I've provided some small editorial suggestions in the form of a diff 
against the plain text version of the draft. You may choose to incorporate them 
in some way, or ignore them as you see fit. There is no need to let me know 
what you did with these suggestions.

--- draft-ietf-opsawg-tacacs-yang-10.txt2021-04-20 21:02:05.0
-0400 +++ draft-ietf-opsawg-tacacs-yang-10-jgs.txt2021-04-20
21:04:01.0 -0400 @@ -151,7 +151,7 @@

 3.  Design of the TACACS+ Data Model

-   This module is used to configure TACACS+ client on a device to
+   This module is used to configure a TACACS+ client on a device to
support deployment scenarios with centralized authentication,
authorization, and accounting servers.  Authentication is used to
validate a user's username and password, authorization allows the @@ -160,7 
+160,7 @@
user who has accessed the device.

The ietf-system-tacacs-plus module augments the "/sys:system" path
-   defined in the ietf-system module with the contents of the"tacacs-
+   defined in the ietf-system module with the contents of the "tacacs-
plus" grouping.  Therefore, a device can use local, RADIUS, or

@@ -416,7 +416,7 @@
 type yang:counter64;
 description
   "Number of aborted connections to the server. These do
-   not include connections that are close gracefully.";
+   not include connections that are closed gracefully.";
   }
   leaf connection-failures {
 type yang:counter64;
@@ -528,7 +528,7 @@
   description
 "The shared secret, which is known to both the
  TACACS+ client and server. TACACS+ server
- administrators should configure shared secret of
+ administrators should configure a shared secret of
  minimum 16 characters length.
  It is highly recommended that this shared secret is
  at least 32 characters long and sufficiently complex @@ 
-644,13 +644,13 @@

/system/tacacsplus/server:  This list contains the data nodes used to
   control the TACACS+ servers used by the device.  Unauthorized
-  access to this list could cause a complete control over the device
+  access to this list could enable an attacker to assume complete 
+ control
over the device
   by pointing to a compromised TACACS+ server.

/system/tacacsplus/server/shared-secret:  This leaf controls the key
   known to both the TACACS+ client and server.  Unauthorized access
   to this leaf could make the device vulnerable to attacks,
-  therefore has been restricted using the "default-deny-all" access
+  therefore it has been restricted using the "default-deny-all" 
+ access
   control defined in [RFC8341].  When setting, it is highly
   recommended that the leaf is at least 32 characters long and
   sufficiently complex with a mix of different character types i.e.



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

Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-yang-10: (with DISCUSS and COMMENT)

[Wubo (lana)]

Hi Roman,

Thanks you for your review. For the discussion part, please see Rob's reply. On 
your comment part, please see inline.

-邮件原件-
发件人: Roman Danyliw via Datatracker [mailto:nore...@ietf.org] 
发送时间: 2021年4月20日 6:08
收件人: The IESG 
抄送: draft-ietf-opsawg-tacacs-y...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; Joe Clarke ; jcla...@cisco.com
主题: Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-yang-10: (with DISCUSS 
and COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-opsawg-tacacs-yang-10: Discuss

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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/



--
DISCUSS:
--

** RFC8907 was published with informational status and it contained substantial 
caution in its security considerations that the protocol was fundamentally 
insecure and would not “meet modern-day requirements.”  This measured approach 
was taken to provide a stable description of a widely deployed protocol and to 
serve as the basis for future improvements.

The context for this follow-on, seemingly related work does not track the 
situation around RFC8907 (as I remember it).  Specifically:

-- this functionality is new, and is not documenting the “as is” deployed state

-- this functionality is advocating for supporting an insecure approach with 
proposed standard (rather than informational) status

** Is this document intentionally breaking backward compatibility on the 
“shared-secret” size specified in RFC8907?

(a) Section 4.
  case shared-secret {
leaf shared-secret {
  type string {
length "16..max";
  }

(b) Section 10.5.1 of RFC8907 says “TACACS+ server administrators SHOULD 
configure secret keys of a minimum of 16 characters in length.”

As (b) is not a MUST (a “secret key” shorter than 16 is possible), it would 
appear that (a) breaks compatibility.


--
COMMENT:
--

Thank you to Yaron Sheffer for the SECDIR review, and for the changes in 
response.

** Section 1.  Per “The System Management Model is augmented with TACACS+ YANG 
module … as an alternative to … local user configuration”, is “local user 
configuration” that same as  the “user authentication model” noted earlier in 
the text?  If so, it would be helpful to make that clearer.
[Bo]: Thanks the comments. We will remove " or local user configuration " to 
make this clear. Since TACACS+ is another centralized authentication.
About the question, "local user configuration” is not same as the “user 
authentication model”, because "user authentication model” of RFC 7317 defines 
both local user authentication and Radius authentication.

** Section 4.  choice encryption. Per the name of this YANG item and the 
description (“Encryption mechanism between TACACS+ client and server”), please 
follow the convention of Section 4.5 of RFC8907 of calling this “obfuscation”. 
[Bo]: The reason we define this "encryption" choice is that shared-secret leaf 
is mandatory per RFC8907, but future TACACS+ protocol may define encryption 
node to replace the shared-secret leaf.  Therefore, is it clearer to change 
"encryption" to " obfuscation-encryption"?

** Section 5.
/system/tacacsplus/server:  This list contains the data nodes used to
  control the TACACS+ servers used by the device.  Unauthorized
  access to this list could cause a complete control over the device
  by pointing to a compromised TACACS+ server.

Additional, outcomes also seem to be that modification of the counters could be 
used to hide attacks against the client
[Bo] Thanks. We will add this risk.

** Additional nits:
-- Section 4. Nit. s/TACAS server is providing/TACAS+ server is providing/

-- Section 5.  Wrong Section.  s/see Section 9 of TACACS+ Protocol [RFC8907]/ 
see Section 10 of TACACS+ Protocol [RFC8907]/

[Bo] Thanks. We will fix this.

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

Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-tacacs-yang-10: (with COMMENT)

[Wubo (lana)]

Hi Eric,

Thank you for your kindly response. 

Best regards,
Lana

-邮件原件-
发件人: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com] 
发送时间: 2021年4月16日 18:44
收件人: Wubo (lana) ; The IESG 
抄送: opsawg@ietf.org; Joe Clarke (jclarke) ; 
opsawg-cha...@ietf.org; draft-ietf-opsawg-tacacs-y...@ietf.org
主题: Re: Éric Vyncke's No Objection on draft-ietf-opsawg-tacacs-yang-10: (with 
COMMENT)

Lana,

[Sorry if I failed to spot your first name]

Thank you for your reply.

My first comment on the VRf was really an appreciation for your work, there is 
no action on the authors' side to modify the text.

Regards and thank you again for your work

-éric

-Original Message-
From: iesg  on behalf of "Wubo (lana)" 

Date: Friday, 16 April 2021 at 09:05
To: Eric Vyncke , The IESG 
Cc: "opsawg@ietf.org" , "Joe Clarke (jclarke)" 
, "opsawg-cha...@ietf.org" , 
"draft-ietf-opsawg-tacacs-y...@ietf.org" 

Subject: Re: Éric Vyncke's No Objection on draft-ietf-opsawg-tacacs-yang-10: 
(with COMMENT)

Hi Eric,

Thanks for your comments. See inline please.

-邮件原件-
发件人: Éric Vyncke via Datatracker [mailto:nore...@ietf.org] 
发送时间: 2021年4月12日 23:15
收件人: The IESG 
抄送: draft-ietf-opsawg-tacacs-y...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; Joe Clarke ; jcla...@cisco.com
主题: Éric Vyncke's No Objection on draft-ietf-opsawg-tacacs-yang-10: (with 
COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-opsawg-tacacs-yang-10: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/



--
COMMENT:
--

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be 
appreciated), and one nit.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

I like to be able to specify the VRF via vrf-instance as well as the 
source-interface, which is not the case of RFC 7317 (if not mistaken).
[Bo] Yes, RFC 7317 does not define VRF case for radius client. 
  About TACACS+ YANG, after checking the rfc8529 (YANG Data Model for 
Network Instances), I can't find a way to specify the VRF via interface.
Do you mean "source-interface" does not need "vrf-instance"? Could you give 
some suggestion here?

-- Section 4 --
Should the leaf "server-type" also be mandatory ?
[Bo] Yes, I think so. Will correct this.

== NITS ==

-- Section 2.1 --
s/Tree diagrams used/The tree diagram used/ as there is a single tree ;-)
[Bo] OK,Thanks.




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

Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-tacacs-yang-10: (with COMMENT)

[Wubo (lana)]

Hi Eric,

Thanks for your comments. See inline please.

-邮件原件-
发件人: Éric Vyncke via Datatracker [mailto:nore...@ietf.org] 
发送时间: 2021年4月12日 23:15
收件人: The IESG 
抄送: draft-ietf-opsawg-tacacs-y...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; Joe Clarke ; jcla...@cisco.com
主题: Éric Vyncke's No Objection on draft-ietf-opsawg-tacacs-yang-10: (with 
COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-opsawg-tacacs-yang-10: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/



--
COMMENT:
--

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be 
appreciated), and one nit.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

I like to be able to specify the VRF via vrf-instance as well as the 
source-interface, which is not the case of RFC 7317 (if not mistaken).
[Bo] Yes, RFC 7317 does not define VRF case for radius client. 
  About TACACS+ YANG, after checking the rfc8529 (YANG Data Model for Network 
Instances), I can't find a way to specify the VRF via interface.
Do you mean "source-interface" does not need "vrf-instance"? Could you give 
some suggestion here?

-- Section 4 --
Should the leaf "server-type" also be mandatory ?
[Bo] Yes, I think so. Will correct this.

== NITS ==

-- Section 2.1 --
s/Tree diagrams used/The tree diagram used/ as there is a single tree ;-)
[Bo] OK,Thanks.



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

Re: [OPSAWG] Last Call: (YANG Data Model for TACACS+) to Proposed Standard

[Wubo (lana)]

Hi Rob, all,

Thanks for your reminding. I just posted rev-10 to address the comment from Tom 
and Joe. Please see :
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-yang-10

Thanks,
Bo

-邮件原件-
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com] 
发送时间: 2021年4月7日 22:44
收件人: Wubo (lana) ; tom petch ; Joe 
Clarke (jclarke) 
抄送: opsawg@ietf.org; opsawg-cha...@ietf.org; 
draft-ietf-opsawg-tacacs-y...@ietf.org
主题: RE: [OPSAWG] Last Call:  (YANG Data 
Model for TACACS+) to Proposed Standard

Hi Bo,

Please can you post an updated version with the comments from Tom/Joe addressed 
and then I can get this onto the next Telechat in 2 weeks' time.

Regards,
Rob


> -Original Message-
> From: OPSAWG  On Behalf Of Wubo (lana)
> Sent: 23 March 2021 10:56
> To: tom petch ; Joe Clarke (jclarke) 
> 
> Cc: opsawg@ietf.org; opsawg-cha...@ietf.org; draft-ietf-opsawg-tacacs- 
> y...@ietf.org
> Subject: Re: [OPSAWG] Last Call: 
> 
> (YANG Data Model for TACACS+) to Proposed Standard
> 
> Hi Tom, Joe,
> 
> Thanks for your helpful comments. I will update the draft as you 
> suggested.
> 
> Best regards,
> Bo
> -邮件原件-
> 发件人: tom petch [mailto:ie...@btconnect.com]
> 发送时间: 2021年3月23日 0:42
> 收件人: Joe Clarke (jclarke) ; Wubo (lana) 
> 
> 抄送: opsawg@ietf.org; opsawg-cha...@ietf.org; draft-ietf-opsawg-tacacs- 
> y...@ietf.org
> 主题: Re: [OPSAWG] Last Call:  
> (YANG Data Model for TACACS+) to Proposed Standard
> 
> From: Joe Clarke (jclarke) 
> Sent: 22 March 2021 13:12
> 
> On 3/22/21 07:15, Wubo (lana) wrote:
> > Hi Tom, Joe,
> >
> > Thanks for your review and comments. The issues will fixed in the 
> > next
> revision.
> >
> > For 'leaf shared-secret', the following text will be added:
> > "It is highly recommended that shared keys are at least 32 
> > characters
> long and
> >   sufficiently complex with mixed different character types."
> 
> You're mixing "shared keys" and "shared secrets" again.  I think you 
> should stick with the latter.  And I think something like: "with a mix 
> of different character types" reads a bit better.  Perhaps Tom will 
> have a better way of stating that.
> 
> 
> 
> Not really!
> Perhaps
> ''... with a mix of different character types i.e. upper case, lower 
> case, numeric, punctuation"
> 
> That is the sort of terminology I see when being prompted to create a 
> password for a website.
> 
> Tom Petch
> 
> 
> Joe
> 
> >
> > Best regards,
> > Bo
> >
> > -邮件原件-
> > 发件人: tom petch [mailto:ie...@btconnect.com]
> > 发送时间: 2021年3月17日 19:00
> > 收件人: Joe Clarke (jclarke) 
> > 抄送: opsawg@ietf.org; opsawg-cha...@ietf.org; 
> > draft-ietf-opsawg-tacacs-y...@ietf.org
> > 主题: Re: [OPSAWG] Last Call: 
> > (YANG Data Model for TACACS+) to Proposed Standard
> >
> > From: Joe Clarke (jclarke) 
> > Sent: 16 March 2021 13:04
> > To: tom petch
> >
> > On 3/16/21 06:13, tom petch wrote:
> >> Some editorial quirks
> >>
> >> YANG
> >>  revision reference
> >> the text value is not quite the same as the title of the I-D; 
> >> perhaps both are not quite right
> > Good catch.  These two should be normalized.  Perhaps the better 
> > title
> is YANG module for TACACS+.
> > 
> > or else
> > A YANG Module for TACACS+
> > I like the indefinite article there but it is perhaps a matter of 
> > taste
> >
> >> leaf shared-secret
> >> /shared keys/shared secrets/
> > Yes, agreed.
> >
> >> should we recommend improving the entropy with mixed case, digits,
> punctuation?  I note that the example lacks punctuation.  A plus sign 
> might be appropriate!
> > Given the weakness, this couldn't hurt.  This could be called out in
> both Security Considerations as well as in the leaf description.  I 
> like the cheeky notion of a '+' in the example.
> >
> > 
> > Yes, probably both.  I have signed up to a lot of services in 
> > lockdown
> and have been exposed to a wide variety of rules about permissible 
> secrets.  One that caught my eye required nine characters while the 
> one that has stayed with me forbad the use of punctuation!  I do think 
> that for all the very clever things that come out of the IETF's 
> Security Area, better guidance on the basics, such as entropy, would 
> do a lot more to improve the Internet!
> >
> > Tom Petch
> > Joe
> >
> >> Tom Petch
> >>
> >> 
> >> From: OPSAWG  on behalf of The IESG 
> >>

Re: [OPSAWG] Last Call: (YANG Data Model for TACACS+) to Proposed Standard

[Wubo (lana)]

Hi Tom, Joe,

Thanks for your helpful comments. I will update the draft as you suggested.

Best regards,
Bo
-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com] 
发送时间: 2021年3月23日 0:42
收件人: Joe Clarke (jclarke) ; Wubo (lana) 

抄送: opsawg@ietf.org; opsawg-cha...@ietf.org; 
draft-ietf-opsawg-tacacs-y...@ietf.org
主题: Re: [OPSAWG] Last Call:  (YANG Data 
Model for TACACS+) to Proposed Standard

From: Joe Clarke (jclarke) 
Sent: 22 March 2021 13:12

On 3/22/21 07:15, Wubo (lana) wrote:
> Hi Tom, Joe,
>
> Thanks for your review and comments. The issues will fixed in the next 
> revision.
>
> For 'leaf shared-secret', the following text will be added:
> "It is highly recommended that shared keys are at least 32 characters long and
>   sufficiently complex with mixed different character types."

You're mixing "shared keys" and "shared secrets" again.  I think you should 
stick with the latter.  And I think something like: "with a mix of different 
character types" reads a bit better.  Perhaps Tom will have a better way of 
stating that.



Not really!
Perhaps
''... with a mix of different character types i.e. upper case, lower case, 
numeric, punctuation"

That is the sort of terminology I see when being prompted to create a password 
for a website.

Tom Petch


Joe

>
> Best regards,
> Bo
>
> -邮件原件-
> 发件人: tom petch [mailto:ie...@btconnect.com]
> 发送时间: 2021年3月17日 19:00
> 收件人: Joe Clarke (jclarke) 
> 抄送: opsawg@ietf.org; opsawg-cha...@ietf.org; 
> draft-ietf-opsawg-tacacs-y...@ietf.org
> 主题: Re: [OPSAWG] Last Call:  
> (YANG Data Model for TACACS+) to Proposed Standard
>
> From: Joe Clarke (jclarke) 
> Sent: 16 March 2021 13:04
> To: tom petch
>
> On 3/16/21 06:13, tom petch wrote:
>> Some editorial quirks
>>
>> YANG
>>  revision reference
>> the text value is not quite the same as the title of the I-D; perhaps 
>> both are not quite right
> Good catch.  These two should be normalized.  Perhaps the better title is 
> YANG module for TACACS+.
> 
> or else
> A YANG Module for TACACS+
> I like the indefinite article there but it is perhaps a matter of 
> taste
>
>> leaf shared-secret
>> /shared keys/shared secrets/
> Yes, agreed.
>
>> should we recommend improving the entropy with mixed case, digits, 
>> punctuation?  I note that the example lacks punctuation.  A plus sign might 
>> be appropriate!
> Given the weakness, this couldn't hurt.  This could be called out in both 
> Security Considerations as well as in the leaf description.  I like the 
> cheeky notion of a '+' in the example.
>
> 
> Yes, probably both.  I have signed up to a lot of services in lockdown and 
> have been exposed to a wide variety of rules about permissible secrets.  One 
> that caught my eye required nine characters while the one that has stayed 
> with me forbad the use of punctuation!  I do think that for all the very 
> clever things that come out of the IETF's Security Area, better guidance on 
> the basics, such as entropy, would do a lot more to improve the Internet!
>
> Tom Petch
> Joe
>
>> Tom Petch
>>
>> 
>> From: OPSAWG  on behalf of The IESG 
>> 
>> Sent: 15 March 2021 14:08
>> To: IETF-Announce
>> Cc: opsawg@ietf.org; opsawg-cha...@ietf.org; 
>> draft-ietf-opsawg-tacacs-y...@ietf.org
>> Subject: [OPSAWG] Last Call: 
>> (YANG Data Model for TACACS+) to Proposed Standard
>>
>>
>> The IESG has received a request from the Operations and Management 
>> Area Working Group WG (opsawg) to consider the following document: - 
>> 'YANG Data Model for TACACS+'
>>as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits 
>> final comments on this action. Please send substantive comments to 
>> the last-c...@ietf.org mailing lists by 2021-03-29. Exceptionally, 
>> comments may be sent to i...@ietf.org instead. In either case, please 
>> retain the beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>This document defines a TACACS+ client YANG module, that augments the
>>System Management data model, defined in RFC 7317, to allow devices
>>to make use of TACACS+ servers for centralized Authentication,
>>Authorization and Accounting.
>>
>>The YANG module in this document conforms to the Network Management
>>Datastore Architecture (NMDA) defined in RFC 8342.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-y

Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-tacacs-yang-09

[Wubo (lana)]

Hi Mohit,

Thanks for the review. I will fix the nits in the next revision.

Thanks,
Bo

-邮件原件-
发件人: Mohit Sethi via Datatracker [mailto:nore...@ietf.org] 
发送时间: 2021年3月20日 18:25
收件人: gen-...@ietf.org
抄送: draft-ietf-opsawg-tacacs-yang@ietf.org; last-c...@ietf.org; 
opsawg@ietf.org
主题: Genart last call review of draft-ietf-opsawg-tacacs-yang-09

Reviewer: Mohit Sethi
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-opsawg-tacacs-yang-09
Reviewer: Mohit Sethi
Review Date: 2021-03-20
IETF LC End Date: 2021-03-29
IESG Telechat date: Not scheduled for a telechat

Summary: This document defines a TACACS+ YANG module for configuring TACACS+ 
clients so that they can use TACACS+ servers as an alternative to RADIUS 
servers or local user configuration.

Major issues:

Minor issues:

Nits/editorial comments:
Perhaps expand TACACS+ on first usage. The same for FIB. Perhaps add the 
acronym AAA to the first usage of Authentication, Authorization and Accounting


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

Re: [OPSAWG] Last Call: (YANG Data Model for TACACS+) to Proposed Standard

[Wubo (lana)]

Hi Tom, Joe,

Thanks for your review and comments. The issues will fixed in the next revision.

For 'leaf shared-secret', the following text will be added:
"It is highly recommended that shared keys are at least 32 characters long and 
  sufficiently complex with mixed different character types."

Best regards,
Bo

-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com] 
发送时间: 2021年3月17日 19:00
收件人: Joe Clarke (jclarke) 
抄送: opsawg@ietf.org; opsawg-cha...@ietf.org; 
draft-ietf-opsawg-tacacs-y...@ietf.org
主题: Re: [OPSAWG] Last Call:  (YANG Data 
Model for TACACS+) to Proposed Standard

From: Joe Clarke (jclarke) 
Sent: 16 March 2021 13:04
To: tom petch

On 3/16/21 06:13, tom petch wrote:
> Some editorial quirks
>
> YANG
>  revision reference
> the text value is not quite the same as the title of the I-D; perhaps 
> both are not quite right

Good catch.  These two should be normalized.  Perhaps the better title is YANG 
module for TACACS+.

or else
A YANG Module for TACACS+
I like the indefinite article there but it is perhaps a matter of taste

> leaf shared-secret
> /shared keys/shared secrets/

Yes, agreed.

>
> should we recommend improving the entropy with mixed case, digits, 
> punctuation?  I note that the example lacks punctuation.  A plus sign might 
> be appropriate!

Given the weakness, this couldn't hurt.  This could be called out in both 
Security Considerations as well as in the leaf description.  I like the cheeky 
notion of a '+' in the example.


Yes, probably both.  I have signed up to a lot of services in lockdown and have 
been exposed to a wide variety of rules about permissible secrets.  One that 
caught my eye required nine characters while the one that has stayed with me 
forbad the use of punctuation!  I do think that for all the very clever things 
that come out of the IETF's Security Area, better guidance on the basics, such 
as entropy, would do a lot more to improve the Internet!

Tom Petch
Joe

>
> Tom Petch
>
> 
> From: OPSAWG  on behalf of The IESG 
> 
> Sent: 15 March 2021 14:08
> To: IETF-Announce
> Cc: opsawg@ietf.org; opsawg-cha...@ietf.org; 
> draft-ietf-opsawg-tacacs-y...@ietf.org
> Subject: [OPSAWG] Last Call:  
> (YANG Data Model for TACACS+) to Proposed Standard
>
>
> The IESG has received a request from the Operations and Management 
> Area Working Group WG (opsawg) to consider the following document: - 
> 'YANG Data Model for TACACS+'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits 
> final comments on this action. Please send substantive comments to the 
> last-c...@ietf.org mailing lists by 2021-03-29. Exceptionally, 
> comments may be sent to i...@ietf.org instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>This document defines a TACACS+ client YANG module, that augments the
>System Management data model, defined in RFC 7317, to allow devices
>to make use of TACACS+ servers for centralized Authentication,
>Authorization and Accounting.
>
>The YANG module in this document conforms to the Network Management
>Datastore Architecture (NMDA) defined in RFC 8342.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
> rfc8907: The Terminal Access Controller Access-Control System Plus 
> (TACACS+) Protocol (Informational - Internent Engineering Task Force 
> (IETF))
>
>
>
>
> ___
> 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 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)]

Hi Rob,

We have posted a -09 version that fixes the issues from you and Tom Petch. 
Please see below:
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-yang-09

Thanks,
Bo

-邮件原件-
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com] 
发送时间: 2021年3月11日 19:23
收件人: Wubo (lana) ; opsawg ; 
draft-ietf-opsawg-tacacs-yang@ietf.org
主题: RE: AD review of draft-ietf-opsawg-tacacs-yang-07

Thanks Bo.

Perhaps make the choice description:

 "Encryption mechanism between TACACS+ client and server".

Let me know when you are done, and I'll start the IETF LC.

Regards,
Rob


> -Original Message-
> From: Wubo (lana) 
> Sent: 11 March 2021 10:46
> To: Rob Wilton (rwilton) ; opsawg 
> ; draft-ietf-opsawg-tacacs-yang@ietf.org
> Subject: Re: AD review of draft-ietf-opsawg-tacacs-yang-07
> 
> Hi Rob,
> 
> Thanks for your comments. I will submit rev-09 to resolve the issues 
> below.
> For the "shared-secret", will change the leaf to:
> 
>   choice encryption {
>mandatory true;
>description
>  "A choice amongst available encryption types.";
>case shared-secret {
>leaf shared-secret {
> ...
>   }
> 
> Best regards,
> Bo
> 
> -邮件原件-
> 发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> 发送时间: 2021年3月10日 20:06
> 收件人: Wubo (lana) ; opsawg ; 
> draft-ietf-opsawg-tacacs-yang@ietf.org
> 主题: RE: AD review of draft-ietf-opsawg-tacacs-yang-07
> 
> Hi Bo,
> 
> Sorry, this doc slipped off my radar.
> 
> I've provided comments inline, but I think that it is only the 
> "shared- secret" part that needs to be resolved.
> 
> 
> 
> > -Original Message-
> > From: Wubo (lana) 
> > Sent: 19 September 2020 08:47
> > To: Rob Wilton (rwilton) ; opsawg 
> > ; draft-ietf-opsawg-tacacs-yang@ietf.org
> > Subject: Re: AD review of draft-ietf-opsawg-tacacs-yang-07
> >
> > Hi Rob,
> >
> > Thanks for the reply. Please see inline.
> >
> > Best regards,
> > Bo
> >
> > -邮件原件-
> > 发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > 发送时间: 2020年9月15日 18:53
> > 收件人: Wubo (lana) ; opsawg ; 
> > draft-ietf-opsawg-tacacs-yang@ietf.org
> > 主题: RE: AD review of draft-ietf-opsawg-tacacs-yang-07
> >
> > Hi Bo,
> >
> > Thanks for addressing my previous comments.
> >
> > Please see inline ...
> >
> > > -Original Message-
> > > From: Wubo (lana) 
> > > Sent: 29 August 2020 09:40
> > > To: Rob Wilton (rwilton) ; opsawg 
> > > ; draft-ietf-opsawg-tacacs-yang@ietf.org
> > > Subject: Re: AD review of draft-ietf-opsawg-tacacs-yang-07
> > >
> > > Hi Rob,
> > >
> > > v-08 is posted, to address most of the your comments in the two AD 
> > > reviews.
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-yang-08
> > >
> > > There are still some comments to confirm with you.
> > >
> > > 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?
> > > [Bo] This issue has been discussed in WG before, and it was 
> > > recommended that the module be updated when the new TACACS+ 
> > > protocol defined. What's your opinion?
> > [RW]
> >
> > I'm not sure I entirely follow.
> >
> > By "be updated when the new TACACS+ protocol defined", do you mean:
> > https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-11, or 
> > something else?
> >
> > If it is this draft, then this is a normative reference and will be 
> > published shortly.  I had presumed that this model covered the 
> > client functionality from draft-ietf-opsawg-tacacs-11?
> >
> > [Bo] Yes, this model is defined to cover the client functionality 
> > from
> > draft-ietf-opsawg-tacacs-11 or the latest version.
> > "shared-secret" is used to encrypt the TACACS+ packet body, and is 
> > the only body encryption method defined in the TACACS+ protocol.
> > During WG discussion, a similar issue has been discussed and it was 
> > suggested that in future an augmented model to be defined to reflect 
> > alternative methods, such as TLS encryption.
> [RW]
> 
> So, the problem that I see is that the shared-secret leaf is mandatory.
> I.e., even if an alternative method was specified then a shared-secret 
> would still always need to be specified.  I don't know whether 

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

[Wubo (lana)]

Hi Rob,

Thanks for your comments. I will submit rev-09 to resolve the issues below. 
For the "shared-secret", will change the leaf to:

choice encryption {
   mandatory true;
   description
 "A choice amongst available encryption types.";
   case shared-secret {  
 leaf shared-secret {
...
  } 

Best regards,
Bo

-邮件原件-
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com] 
发送时间: 2021年3月10日 20:06
收件人: Wubo (lana) ; opsawg ; 
draft-ietf-opsawg-tacacs-yang@ietf.org
主题: RE: AD review of draft-ietf-opsawg-tacacs-yang-07

Hi Bo,

Sorry, this doc slipped off my radar.

I've provided comments inline, but I think that it is only the "shared-secret" 
part that needs to be resolved.



> -----Original Message-
> From: Wubo (lana) 
> Sent: 19 September 2020 08:47
> To: Rob Wilton (rwilton) ; opsawg 
> ; draft-ietf-opsawg-tacacs-yang@ietf.org
> Subject: Re: AD review of draft-ietf-opsawg-tacacs-yang-07
> 
> Hi Rob,
> 
> Thanks for the reply. Please see inline.
> 
> Best regards,
> Bo
> 
> -邮件原件-
> 发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> 发送时间: 2020年9月15日 18:53
> 收件人: Wubo (lana) ; opsawg ; 
> draft-ietf-opsawg-tacacs-yang@ietf.org
> 主题: RE: AD review of draft-ietf-opsawg-tacacs-yang-07
> 
> Hi Bo,
> 
> Thanks for addressing my previous comments.
> 
> Please see inline ...
> 
> > -Original Message-
> > From: Wubo (lana) 
> > Sent: 29 August 2020 09:40
> > To: Rob Wilton (rwilton) ; opsawg 
> > ; draft-ietf-opsawg-tacacs-yang@ietf.org
> > Subject: Re: AD review of draft-ietf-opsawg-tacacs-yang-07
> >
> > Hi Rob,
> >
> > v-08 is posted, to address most of the your comments in the two AD 
> > reviews.
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-yang-08
> >
> > There are still some comments to confirm with you.
> >
> > 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?
> > [Bo] This issue has been discussed in WG before, and it was 
> > recommended that the module be updated when the new TACACS+ protocol 
> > defined. What's your opinion?
> [RW]
> 
> I'm not sure I entirely follow.
> 
> By "be updated when the new TACACS+ protocol defined", do you mean:
> https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-11, or something 
> else?
> 
> If it is this draft, then this is a normative reference and will be 
> published shortly.  I had presumed that this model covered the client 
> functionality from draft-ietf-opsawg-tacacs-11?
> 
> [Bo] Yes, this model is defined to cover the client functionality from
> draft-ietf-opsawg-tacacs-11 or the latest version.
> "shared-secret" is used to encrypt the TACACS+ packet body, and is the 
> only body encryption method defined in the TACACS+ protocol.
> During WG discussion, a similar issue has been discussed and it was 
> suggested that in future an augmented model to be defined to reflect 
> alternative methods, such as TLS encryption.
[RW] 

So, the problem that I see is that the shared-secret leaf is mandatory.  I.e., 
even if an alternative method was specified then a shared-secret would still 
always need to be specified.  I don't know whether that it is a reasonable 
constraint to put on the model.

If there will always be a shared secret then your augmentation approach should 
be fine.

But, if it is plausible or likely that a shared-secret would not always be 
required then I would be better to have a mandatory choice statement with 
shared-secret as one of the choices.



> 
> >
> >
> > 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?
> > [Bo]Yes, tcsplus-server-type indicates what type the server is. But 
> > I don't quite understand this comment.
> [RW]
> 
> The distinction that I was trying to make is:
> 
> Server 'S', might have the capabilities of an authentication and 
> accounting server, but Network Device 'D', that is making use of 
> Server 'S', might only be making use of its authentication 
> capabilities.  In this scenario, do the configuration bits on device 
> 'D' list Server 'S' as supporting authentication and accounting (since 
> that is what the server
> supports) or do they only list Server 'S' capabilities as "authentication"
> (since that is what is being used by 'D

Re: [OPSAWG] CALL FOR ADOPTION: draft-www-opsawg-yang-vpn-service-pm

[Wubo (lana)]

Hi Dhruv,

Thanks for the detailed review, please see inline.

Best regards,
Bo

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Dhruv Dhody
发送时间: 2021年2月4日 18:13
收件人: Joe Clarke (jclarke) 
抄送: opsawg@ietf.org
主题: Re: [OPSAWG] CALL FOR ADOPTION: draft-www-opsawg-yang-vpn-service-pm

Hi,

The work seems to be quite useful. I support adoption by the WG.

A few comments -

(1) If the model supports L2VPN, I think we need to add the L2-level counters 
in the vpn-summary-statistics. Currently we only have IPv4 and IPv6 routes.
[Bo] Thanks, will add MAC-address-limit counters for L2VPN.


(2) Section 3

   The performance monitoring information reflecting the quality of the
   Network or VPN service such as end to end network performance data
   between source node and destination node in the network or between
   VPN sites can be aggregated or calculated using, for example, PCEP
   solution [RFC8233] [RFC7471] [RFC8570] [RFC8571] or LMAP [RFC8194].

I suggest changing "PCEP" to more generic term "Traffic Engineering Database 
(TED)".
[Bo] OK, will update.


(3) Section 3.2

3.2.  On demand Retrieval via RPC Model

   To obtain a snapshot of a large amount of performance data from a
   network element (including network controllers), service-assurance
   applications may use polling-based methods such as RPC model to fetch
   performance data on demand.

Do you mean the usual Netconf ? Not sure about the term "RPC model". Maybe 
refer to it as just polling mechanism.
[Bo] Yes. Thanks for pointing this out, will fix this to refer to the polling 
mechanism.


(4) Section 4.1

I am not sure about the depiction of how PE map to CE and further map to Nodes 
in the underlying network in Figure 3.

In the YANG we have node-type that can be PE, CE, or P and this figure does not 
help. Its possible I might be seeing it wrong :)

Also the mapping in the figure and the text for Node 3 and 4 don't match.

In "Site-2 A and B play the role of hub while Site-2 C plays the role of 
spoke.", did you intend to have 2 hub and 1 spoke?
[Bo] Thanks for catching this. Will fix the figure the text.



(5) Section 4.2

   For network performance monitoring, the attributes of "Network Level"
   that defined in [RFC8345] do not need to be extended.

[RFC8345] does not use the term "Network Level". I am wondering if we should 
use the full path /nw:networks/nw:network/ or container name instead...

Also applicable to 4.3

The "vpn-id" is just a string and would also depend on the network-service-type 
(L3VPN, L2VPN); IMHO some text to describe this is needed.

[Bo] Will update as you suggested.

(6) Section 4.3

Not clear on why node-type is marked as (Attribute) but site-id and site-role 
are (Constraint).

Can you expand on "site-id", is this matching with L3SM site-id or L3NM's 
vpn-network-access?

The type should be yang:counter32 instead of uint32 for -

   +--rw vpn-summary-statistics
  +--rw ipv4
  |  +--rw total-routes?  uint32
  |  +--rw total-active-routes?   uint32
  +--rw ipv6
 +--rw total-routes?  uint32
 +--rw total-active-routes?   uint32

[Bo] Thanks for catching the errors. “Constraint” will be corrected to 
”Attribute“.

For the “site-id”, in most cases, it refers to L3NM's ne-id. In the case of 
provider-managed CE, it may refers to L3SM site-id.


(7) Section 7

(a)

  identity link-type {
base vpn-common:protocol-type;
description
  "Base identity for link type, e.g.,GRE, MPLS TE, VXLAN.";
  }

  identity VXLAN {
base link-type;
description
  "Base identity for VXLAN Tunnel.";
  }

  identity ip-in-ip {
base link-type;
description
  "Base identity for IP in IP Tunnel.";
  }

What is the benefit of creating link-type as an identity? Can VXLAN and 
ip-in-ip directly use vpn-common:protocol-type as a base?
[Bo] Thanks for the suggestion. We can directly use vpn-common:protocol-type as 
the tunnel encapsulation type.


(b)

leaf outbound-qlen {
  type uint32;
  description
" Length of the queue of the interface from where
  the packet is forwarded out.  The queue depth could
   be the current number of memory buffers used by the
  queue and a packet can consume one or more memory buffers
  thus constituting device-level information.";
}
description
  "Grouping for interface service telemetry.";
  }

Since these are abstract nodes how do we know this information?
[Bo] We will remove this. This is from the initial discussion on  
rfc8532(Generic YANG Data Model for the Management of OAM Protocols That Use 
Connectionless Communications) . But the published RFC has removed this 
definition.


(c)

leaf reference-time {
  type yang:date-and-time;
  description
"The time that the current Measurement Interval started.";
}

Shouldn't this be config false?
[Bo] Agree. Thanks, will update.



==

Suggestion:

Can we add an example 

Re: [OPSAWG] CALL FOR ADOPTION: draft-www-opsawg-yang-vpn-service-pm

[Wubo (lana)]

Hi Adrian,

Thanks for your review and comments. Please see inline.

Thanks,
Bo

-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Adrian Farrel
发送时间: 2021年2月3日 7:09
收件人: 'Joe Clarke (jclarke)' ; 
opsawg@ietf.org
主题: Re: [OPSAWG] CALL FOR ADOPTION: draft-www-opsawg-yang-vpn-service-pm

Hi Joe,

I think this document fills a hole in the set of YANG models we have for 
managing and operating services over our network, and I'd like the WG to pick 
it up and polish it.

I commit to doing a review or two as the draft advances. To kick that off there 
are a few comments below. None of these needs to be addressed before adoption.

Best,
Adrian

---

It is unclear to me from Section 1 whether this document is intended to be 
limited to L3VPNs or applies to all VPNs. The very first sentence gives a 
strong hint that the scope is restricted to L3VPN, but I think that is not the 
intention.
[Bo]Thanks for pointing this out. The intention is to support both L3VPN and 
L2VPN, and we will fix section 1 to reflect this.
---

Maybe Figure 1 should be set in the context of RFC 8309. In particular, 
s/Service Network Models/Network Service Models/ But it might also be nice to 
include a reference to 8309 to help give meaning to the figure.
[Bo] Thanks, will add RFC 8309 as the context.

---

Looking at...
  +--ro inbound-octets? yang:counter64
  +--ro inbound-unicast?yang:counter64
  +--ro inbound-nunicast?   yang:counter64
  +--ro inbound-discards?   yang:counter32
  +--ro inbound-errors? yang:counter32
  +--ro inbound-unknown-protocol?   yang:counter32
  +--ro outbound-octets?yang:counter64
  +--ro outbound-unicast?   yang:counter64
  +--ro outbound-nunicast?  yang:counter64
  +--ro outbound-discards?  yang:counter32
  +--ro outbound-errors?yang:counter32

I tend to agree that there are likely to be an order of magnitude fewer 
discards and errors than legitimate packets, but I can also consider times 
(such as during attacks) then every packet is in error or is discarded. I think 
it would be wise (and possibly helpful) to have all of the counters at 64bits.

This would also mean that the four counters under loss-statistics should also 
be counter64.
[Bo] The counters currently follow the definition of ietf-interfaces YANG. Your 
suggestion to consider additional use case also makes sense, we will expand 
those counters.


-Original Message-
From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: 29 January 2021 14:18
To: opsawg@ietf.org
Subject: [OPSAWG] CALL FOR ADOPTION: draft-www-opsawg-yang-vpn-service-pm

Hello, WG.  The draft-www-opsawg-yang-vpn-service-pm (A YANG Model for Network 
and VPN Service Performance Monitoring) work has been steadily progressing with 
the other VPN network model work.  This was presented last at IETF 109 
(https://datatracker.ietf.org/doc/slides-109-opsawg-a-yang-model-for-network
-and-vpn-service-performance-monitoring/),
and there has been some recent discussion on list that has been addressed by 
the authors.  We would like to know if the working group wants to formally 
adopt this work.

Please respond with your comments and thoughts on the draft.  We will conduct a 
two week CFA, concluding on February 12, 2021.

Joe (on behalf of co-chairs)

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

Re: [OPSAWG]  WG Adoption Call on draft-richardson-opsawg-mud-iot-dns-considerations-03

[Wubo (lana)]

I have read the draft and I support the adoption.

Thanks,
Bo

-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Henk Birkholz
发送时间: 2021年1月5日 2:04
收件人: opsawg 
主题: [OPSAWG]  WG Adoption Call on 
draft-richardson-opsawg-mud-iot-dns-considerations-03

Dear OPSAWG members,

this starts a call for Working Group Adoption on
https://tools.ietf.org/html/draft-richardson-opsawg-mud-iot-dns-considerations-03
ending on Monday, January 25.

As a reminder, this I-D describes potential issues and concerns regarding the 
use of DNS names and IP addressed with RFC8520 Manufacturer Usage Description 
(MUD) in support of device access.

Please reply with your support and especially any substantive comments you may 
have.


For the OPSAWG co-chairs,

Henk

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

Re: [OPSAWG]  WG Adoption Call on draft-lear-opsawg-sbom-access-00

[Wubo (lana)]

I have read the draft and I support the adoption.

Thanks,
Bo

-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Henk Birkholz
发送时间: 2021年1月5日 0:10
收件人: opsawg 
主题: [OPSAWG]  WG Adoption Call on draft-lear-opsawg-sbom-access-00

Dear OPSAWG members,

this starts a call for Working Group Adoption on
https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00 ending on Monday, 
January 25.

As a reminder, this I-D describes different ways to acquire Software Bills of 
Material (SBOM) about distinguishable managed entities. The work was updated by 
the authors on October 13th and now elaborates on three ways SBOM can be found, 
including a MUD URI as one of the options.

Please reply with your support and especially any substantive comments you may 
have.


For the OPSAWG co-chairs,

Henk

___
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] New Version Notification for draft-www-opsawg-yang-vpn-service-pm-03.txt

[Wubo (lana)]

Dear chairs,

The authors believe the VPN service performance monitoring YANG draft is ready 
to be adopted as the WG document.
https://tools.ietf.org/html/draft-www-opsawg-yang-vpn-service-pm-03

The new revision has addressed the comments from the WG mailing list:
1.Added text to clarify the “percentile” parameters descriptions
2.Fixed the counters and percentile definition to be alignment with 
ietf-interface and ietf-stamp

The authors would like to request WG adoption of the draft.

Thanks,
Bo on behalf of all the co-authors

-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
发送时间: 2021年1月22日 11:15
收件人: Bin Wen ; Wubo (lana) ; Chang 
Liu ; Change Liu ; Honglei Xu 
; Mohamed Boucadair ; 
Oscar Gonzalez de Dios ; Oscar de Dios 
; Qin Wu ; Qin Wu 

主题: New Version Notification for draft-www-opsawg-yang-vpn-service-pm-03.txt


A new version of I-D, draft-www-opsawg-yang-vpn-service-pm-03.txt
has been successfully submitted by Bo Wu and posted to the IETF repository.

Name:   draft-www-opsawg-yang-vpn-service-pm
Revision:   03
Title:  A YANG Model for Network and VPN Service Performance Monitoring
Document date:  2021-01-21
Group:  Individual Submission
Pages:  31
URL:
https://www.ietf.org/archive/id/draft-www-opsawg-yang-vpn-service-pm-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-www-opsawg-yang-vpn-service-pm/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-www-opsawg-yang-vpn-service-pm
Htmlized:   
https://tools.ietf.org/html/draft-www-opsawg-yang-vpn-service-pm-03
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-www-opsawg-yang-vpn-service-pm-03

Abstract:
   The data model defined in RFC8345 introduces vertical layering
   relationships between networks that can be augmented to cover
   network/service topologies.  This document defines a YANG model for
   both Network Performance Monitoring and VPN Service Performance
   Monitoring that can be used to monitor and manage network performance
   on the topology at higher layer or the service topology between VPN
   sites.

   This document does not define metrics for network performance or
   mechanisms for measuring network performance.  The YANG model defined
   in this document is designed as an augmentation to the network
   topology YANG model defined in RFC 8345 and draws on relevant YANG
   types defined in RFC 6991, RFC 8299, RFC 8345, and RFC 8532.


  


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.

The IETF Secretariat


___
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)]

Hi Rob,

Thanks for the reply. Please see inline.

Best regards,
Bo

-邮件原件-
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com] 
发送时间: 2020年9月15日 18:53
收件人: Wubo (lana) ; opsawg ; 
draft-ietf-opsawg-tacacs-yang@ietf.org
主题: RE: AD review of draft-ietf-opsawg-tacacs-yang-07

Hi Bo,

Thanks for addressing my previous comments.

Please see inline ...

> -Original Message-
> From: Wubo (lana) 
> Sent: 29 August 2020 09:40
> To: Rob Wilton (rwilton) ; opsawg 
> ; draft-ietf-opsawg-tacacs-yang@ietf.org
> Subject: Re: AD review of draft-ietf-opsawg-tacacs-yang-07
> 
> Hi Rob,
> 
> v-08 is posted, to address most of the your comments in the two AD 
> reviews.
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-yang-08
> 
> There are still some comments to confirm with you.
> 
> 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?
> [Bo] This issue has been discussed in WG before, and it was 
> recommended that the module be updated when the new TACACS+ protocol 
> defined. What's your opinion?
[RW] 

I'm not sure I entirely follow.

By "be updated when the new TACACS+ protocol defined", do you mean: 
https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-11, or something else?

If it is this draft, then this is a normative reference and will be published 
shortly.  I had presumed that this model covered the client functionality from 
draft-ietf-opsawg-tacacs-11?

[Bo] Yes, this model is defined to cover the client functionality from 
draft-ietf-opsawg-tacacs-11 or the latest version. 
"shared-secret" is used to encrypt the TACACS+ packet body, and is the only 
body encryption method defined in the TACACS+ protocol.
During WG discussion, a similar issue has been discussed and it was suggested 
that in future an augmented model to be defined to reflect alternative methods, 
such as TLS encryption.

> 
> 
> 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?
> [Bo]Yes, tcsplus-server-type indicates what type the server is. But I 
> don't quite understand this comment.
[RW] 

The distinction that I was trying to make is:

Server 'S', might have the capabilities of an authentication and accounting 
server, but Network Device 'D', that is making use of Server 'S', might only be 
making use of its authentication capabilities.  In this scenario, do the 
configuration bits on device 'D' list Server 'S' as supporting authentication 
and accounting (since that is what the server supports) or do they only list 
Server 'S' capabilities as "authentication" (since that is what is being used 
by 'D')?

If the intended behaviour is the latter, then I think that we should tweak the 
descriptions to be clear.

[Bo] Yes, the intention is the latter.
Perhaps you mean the YANG descriptions of 'tcsplus-server-type' are not clear 
enough. Please let us know if this addresses your concerns or if there is 
anything else.

  typedef tacacs-plus-server-type {
type bits {
  bit authentication {
description
  "When set, the server is an authentication server."
 ->
  "When set, the device use the server for authentication 
service.";  
  
  }
...
}
description
  "tacacs-plus-server-type can be set to
   authentication/authorization/accounting
   or any combination of the three types. When all three types are
   supported, all the three bits are set.";
 ->
 "When all the three bits are set, the device use all available 
services on the server.";  
  }

> 
> 
> 6. Should there be a limit on the length of a server name?
> [Bo]The TACACS+ protocol does not have any restrictions, and I also 
> think this model could follow current ietf-system model, since this 
> module is the augmentation of the system model and there is no 
> restriction on the RADIUS server name in the ietf-system model.
> How do you think?
[RW] 

I agree that being consistent with ietf-system is a good choice.

I do wonder more generally if this will mean that different vendors will impose 
different limits using deviations, which would effectively make interop harder. 
 But that doesn't need to be solved here/now.

[Bo]Thanks for the suggestion.


> 
> 
> 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.
> [Bo] 

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

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]
>
>

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

[Wubo (lana)]

Hi Rob,

v-08 is posted, to address most of the your comments in the two AD reviews. 
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-yang-08

There are still some comments to confirm with you.

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?
[Bo] This issue has been discussed in WG before, and it was recommended that 
the module be updated when the new TACACS+ protocol defined. What's your 
opinion?


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?
[Bo]Yes, tcsplus-server-type indicates what type the server is. But I don't 
quite understand this comment.


6. Should there be a limit on the length of a server name?
[Bo]The TACACS+ protocol does not have any restrictions, and I also think this 
model could follow current ietf-system model, since this module is the 
augmentation of the system model and there is no restriction on the RADIUS 
server name in the ietf-system model. 
How do you think?


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.
[Bo] Thanks. Agree that the must statement does not prohibit accounting or 
authorization TACACS+ server configuration.
I updated the must statement with authentication server type validation.

Thanks,
Bo

-邮件原件-
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com] 
发送时间: 2020年8月20日 18:38
收件人: opsawg ; draft-ietf-opsawg-tacacs-yang@ietf.org
主题: RE: AD review of draft-ietf-opsawg-tacacs-yang-07

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 
> 

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

[Wubo (lana)]

Hi Rob,

Many thanks for your another thorough AD review, and I will consider these 
comments along with previous ones.

Regards,
Bo

-邮件原件-
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com] 
发送时间: 2020年8月20日 18:38
收件人: opsawg ; draft-ietf-opsawg-tacacs-yang@ietf.org
主题: RE: AD review of draft-ietf-opsawg-tacacs-yang-07

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]
> 
>->
> 
>TACACS+ [I-D.ietf-opsawg-tacacs] provides Device Administration for
>routers, network access servers and other networked computing devices
>via one or more centralized servers.
> 
> 7. o  User Authentication Model: Defines a list of usernames and
>   passwords and control the order in which 

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

[Wubo (lana)]

Hi Rob,

Thanks a lot for your detailed review and valuable comments. 

We will post -08 revision to address all the comments:
1. Change "tacacsplus" to "tacacs-plus" for the entire draft. Joe made the 
comments before but we missed them.
2. Revise all the editorial comments you have suggested. 

Please also see the replies in-line below for some comments to be confirmed.

Thanks,
Bo

-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Rob Wilton (rwilton)
发送时间: 2020年7月11日 0:53
收件人: draft-ietf-opsawg-tacacs-yang@ietf.org
抄送: opsawg 
主题: [OPSAWG] AD review of draft-ietf-opsawg-tacacs-yang-07

Apologies for the delay, but please find my AD review of the TACACS+ YANG 
module draft.

I would like to thank the authors for their work on this document, and the WG 
for providing reviews and input in this document.

I believe that the document is in good shape but propose some minor changes to 
some of the wording in places.

One particular question that I would like to pull to the top is the naming of 
the module and identifiers:
These generally use "tacacsplus", but I think that "tacacs-plus" might be 
better and more readable.


Full comments are inline in the document below (marked as #)


   The YANG model can be used with network management protocols such as
   NETCONF[RFC6241] to install, manipulate, and delete the configuration
   of network devices.
   
Abstract

   This document defines a YANG module that augment the System  
   Management data model defined in the RFC 7317 with TACACS+ client
   model.  The data model of Terminal Access Controller Access Control
   System Plus (TACACS+) client allows the configuration of TACACS+
   servers for centralized Authentication, Authorization and Accounting.

#
Perhaps tweak the first paragraph of the abstract slightly to:

This document defines a TACACS+ client YANG module, that augments the System 
Management data model, defined in RFC 7317, to allow devices to make use of 
TACACS+ servers for centralized Authentication, Authorization and Accounting.


   This document defines a YANG module that augment the System
   Management data model defined in the [RFC7317] with TACACS+ client
   model.
# augment -> augments
# with TACACS+ client -> to support the configuration and management of TACACS+ 
clients.

   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]
# TACACS+ provides -> "TACACS+ [I-D.ietf-opsawg-tacacs] provides" [and remove 
the reference at the end of the paragraph].
# networked computing devices -> networked devices # centralized servers which 
... -> delete from which ... to the end of the sentence.

   The System Management Model [RFC7317] defines two YANG features to
   support local or RADIUS authentication:
#two YANG features -> separate functionality #or -> and

   o  User Authentication Model: Defines a list of usernames and
  passwords and control the order in which local or RADIUS
  authentication is used.
# I suggest modifying this to ->
o  User Authentication Model: Defines a list of usernames with associated
   passwords and a configuration leaf to decide the order in which local or 
RADIUS
   authentication is used.

   o  RADIUS Client Model: Defines a list of RADIUS servers that a
  device uses.
# device uses. -> devices uses to manage users.

   Since TACACS+ is also used for device management and the feature is
   not contained in the System Management model, this document defines a
   YANG data model that allows users to configure TACACS+ client
   functions on a device for centralized Authentication, Authorization
   and Accounting provided by TACACS+ servers.
# I suggest rewording this paragraph to something like:
The System Management Model is augmented with the TACACS+ YANG module defined 
in this document to allow the use of TACACS+ servers as an alternative to 
RADIUS servers or local user configuration.


Zheng, et al.   Expires December 22, 2020   [Page 2]
Internet-Draft TACACS+ YANG model  June 2020

   The YANG model can be used with network management protocols such as
   NETCONF[RFC6241] to install, manipulate, and delete the configuration
   of network devices.
# I would suggest deleting "to install ..." to the end.

   The ietf-system-tacacsplus module is intended to augment the
   "/sys:system" path defined in the ietf-system module with the
   contents of the"tacacsplus" grouping.  Therefore, a device can use
   local, Remote Authentication Dial In User Service (RADIUS), or
   Terminal Access Controller Access Control System Plus (TACACS+) to
   validate users who attempt to access the router by several
   mechanisms, 

Re: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm

[Wubo (lana)]

Hi,

I support the WG adoption of the draft.
I have read the draft, and believe it is a useful piece to L2VPN service 
management automation.

Best regards,
Bo

-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2020年6月16日 22:18
收件人: opsawg 
主题: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm

Hello, opsawg.  I hope everyone is doing well.

This starts a two-week poll for adoption of the L2 network module document.  
There does seem to be interest in this work, and it is progressing nicely in 
GitHub with side meetings.  There appears to be questions on what will be 
broken out into commonality between this module and the L3NM (work which is 
also underway).  So while we anticipate changes to this draft, the chairs think 
it’s reached a point where we’d like to see if the WG wants to formally adopt 
the work.

Please reply on-list with your comments on the draft and whether or not you 
support its WG adoption.  We will conclude this call on June 30, 2020.

Thanks.

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

Re: [OPSAWG] example in tacacs yang was Re: Shepherd review of draft-ietf-opsawg-tacacs-yang

[Wubo (lana)]

Hi Joe, Tom,

Thanks for the review. I will fix it in the next revision.

Best regards,
Bo

-邮件原件-
发件人: Joe Clarke (jclarke) [mailto:jcla...@cisco.com] 
发送时间: 2020年6月19日 1:16
收件人: tom petch 
抄送: opsawg ; draft-ietf-opsawg-tacacs-y...@ietf.org
主题: Re: example in tacacs yang was Re: Shepherd review of 
draft-ietf-opsawg-tacacs-yang



> On Jun 18, 2020, at 12:01, tom petch  wrote:
> 
> From: OPSAWG  on behalf of Joe Clarke (jclarke) 
> 
> Sent: 28 May 2020 15:52
> To: opsawg
> 
> 
> Looking at the example in tacacs-yang-06  I see it uses an address of 
> 10.10..10.x. I think that this should be an address reserved for 
> documentation 192.0.2 if I recall.

Yep, good catch.  Authors, can you update to something in 192.0.2.0/24?  Thanks.

Joe

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

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

[Wubo (lana)]

Hi Joe,

Many thanks for the review.
I will correct the errors in the -06 revision.

Thanks,
Bo
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2020年5月28日 22:52
收件人: opsawg 
主题: [OPSAWG] Shepherd review of draft-ietf-opsawg-tacacs-yang

I have completed my first draft of the shepherd write-up of this document.  In 
the abstract I noticed it says that this document defines “YANG modules” when 
it only defines “a YANG module” now.  Can text referring to the plural modules 
be updated?

Also, any other review of the write-up would be appreciated.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/shepherdwriteup/

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

Re: [OPSAWG] WG LC close on draft-ietf-opsawg-tacacs-yang

[Wubo (lana)]

Hi Joe,

Thanks for shepherd. Yes, I will submit the revision 05 next week.

Regards,
Bo

-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2020年5月15日 1:57
收件人: Joe Clarke (jclarke) 
抄送: opsawg 
主题: Re: [OPSAWG] WG LC close on draft-ietf-opsawg-tacacs-yang

Seems like we don’t have any volunteers for shepherd.  I’ll start a write-up.  
Bo, I assume you have a -05 in the works to address the recent LC comments?

Joe

> On May 11, 2020, at 09:30, Joe Clarke (jclarke) 
>  wrote:
> 
> We got some good comments and reviews during WGLC of this draft, and the 
> authors have created a -04 and working on a -05.  We noted nothing that would 
> prevent it from moving forward to the IESG, so we are closing WGLC.
> 
> Is there someone who like to act as shepherd for this document?
> 
> 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 mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Last-Call] Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03

[Wubo (lana)]

Hi John,

Currently, the accounting and authorization methods are not defined in System 
model. Therefore, although Tacacs+ defines accounting and authorization type, 
there is no way to use it. 

Regards,
Bo

-邮件原件-
发件人: john heasley [mailto:h...@shrubbery.net] 
发送时间: 2020年5月11日 13:42
收件人: Wubo (lana) 
抄送: john heasley ; Ladislav Lhotka 
; tom petch ; Joe Clarke (jclarke) 
; yang-doct...@ietf.org; opsawg@ietf.org; 
draft-ietf-opsawg-tacacs-yang@ietf.org; last-c...@ietf.org
主题: Re: [Last-Call] Yangdoctors last call review of 
draft-ietf-opsawg-tacacs-yang-03

Fri, May 08, 2020 at 09:45:51AM +, Wubo (lana):
> I'll have to look at the model again; i do not recall if the model allows for 
> particular accounting types w/o augmentation.
> 
> [Bo]  The accounting type you mentioned, I understand, is that the System 
> model needs to be augmented. Currently, the System model only defines 
> authentication.

Hey.  System model has no accounting that I see.  what am i missing; where are 
the accounting types defined?

> About the model, do you think the "all" bit is still necessary?

I am not advocating for nor against; only trying to explain how 'accounting'
type might be used, which seemed to be misunderstood.
[Bo] OK
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Secdir last call review of draft-ietf-opsawg-tacacs-yang-03

[Wubo (lana)]

Hi Yaron,

Thanks for the review. Please see inline.

Regards,
Bo

-邮件原件-
发件人: Yaron Sheffer via Datatracker [mailto:nore...@ietf.org] 
发送时间: 2020年5月9日 1:08
收件人: sec...@ietf.org
抄送: opsawg@ietf.org; draft-ietf-opsawg-tacacs-yang@ietf.org; 
last-c...@ietf.org
主题: Secdir last call review of draft-ietf-opsawg-tacacs-yang-03

Reviewer: Yaron Sheffer
Review result: Has Nits

This document defines a YANG module for the configuration of TACACS+ clients.

The document is short and straightforward, and I only have one significant 
comment.

* I am not familiar with common security practices for the devices covered by 
this protocol. But I am wondering, should the "shared-secret" field be made 
optional, so that it can be entered "out of band" in applications that prefer 
not to keep it stored in the YANG configuration store and available to network 
management tools?
[Bo] The "shared-secret" node is indeed sensitive. But there are two main 
reasons for defining as mandatory. 1) The TACACS+ protocol requires that the 
secret must be configured.  
2) YANG model can use NACM (RFC8341) to ensure node security. The 
"shared-secret" adds security tagging "nacm:default-deny-all" to restrict only 
initial device access and some recovery session.

Additionally, the definition follows the current System model (RFC7317) , as 
TACACS+ model is an augmentation of the System model. The definition of the 
"shared-secret" in the RADIUS authentication of the System model is mandatory 
and YANG extension "nacm:default-deny-all" is used to protect. 

Perhaps some addition text could help:
/system/tacacsplus/server/shared-secret:  Access to this node is considered 
sensitive and therefore has been restricted using the "default-deny-all" access 
control defined in [RFC8341].


* Not a security comment: the YANG module includes a reference to 
draft-ietf-opsawg-tacacs-18, but I assume that you'll want to replace it with 
the RFC number for that draft once it is published. Yet I don't see an RFC 
Editor note mentioning that.
[Bo] OK, will add in the next revision.

* It is confusing that "messages-received" is for messages received by the 
server, and "errors-received" is for errors received *from* the server.
[Bo] Thanks, will correct to "from" the server to keep consistency. 

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

Re: [OPSAWG] [Last-Call] Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03

[Wubo (lana)]

Hi John,

Thanks for the review. Please see inline.

Regards,
Bo
-邮件原件-
发件人: john heasley [mailto:h...@shrubbery.net] 
发送时间: 2020年5月8日 2:10
收件人: Ladislav Lhotka 
抄送: tom petch ; Wubo (lana) ; Joe 
Clarke (jclarke) ; yang-doct...@ietf.org; opsawg@ietf.org; 
draft-ietf-opsawg-tacacs-yang@ietf.org; last-c...@ietf.org
主题: Re: [Last-Call] Yangdoctors last call review of 
draft-ietf-opsawg-tacacs-yang-03

Thu, May 07, 2020 at 03:02:24PM +0200, Ladislav Lhotka:
> > [Bo] Please see if the definition below is correct:
> >   typedef tcsplus-server-type {
> >type bits {
> >  bit authentication {
> >description
> >  "When set, the server is an authentication server.";
> >  }
> >  bit authorization {
> >description
> >  "When set, the server is an authorization server.";
> >  }
> >  bit accounting {
> >description
> >  "When set, the server is an accounting server.";
> >  }
> >  bit all {
> >description
> >  "When set, the server can be all types of TACACS+ servers.";
> >  }
> > 
> >}
> >description
> >  "server-type can be set to authentication/authorization/accounting 
> > or any combination of the three types.
> >   When all three types are supported, either "all" or the three 
> > bits setting can be used;
> >  }
> > 
> > 
> > I would drop the all.   I know that I suggested it, or an asterisk, but I 
> > was thinking that this was a common  case.  Joe suggests that no accounting 
> > is the commoner - I do not have sufficient exposure to know - in which case 
> > I would not bother with 'all'.  Whether or not to make auth/auth  the 
> > default I have no particular view on - as I say, I lack the exposure to be 
> > confident about that.
> > 
> > Having 'all' adds complexity, two ways to something, while making a small 
> > saving in message size - on balance, not worth it.
> 
> Agreed. Lada

Note that enabling certain types of accounting is rare, at least in my opinion. 
 eg: enabling login accounting is not rare, while command accounting is rare 
because it is expensive esp. on some particular devices.

Also, rare or not, enabling it for a tacacs server is sort of orthogonal.
it will not be used for that purpose unless some form of accounting is enabled.

I'll have to look at the model again; i do not recall if the model allows for 
particular accounting types w/o augmentation.

[Bo]  The accounting type you mentioned, I understand, is that the System model 
needs to be augmented. Currently, the System model only defines authentication.
About the model, do you think the "all" bit is still necessary?

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

Re: [OPSAWG] Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03

[Wubo (lana)]

Hi Lada,

Many thanks for the suggestion. Understood, will remove the "case".

Thanks,
Bo

-邮件原件-
发件人: Ladislav Lhotka [mailto:ladislav.lho...@nic.cz] 
发送时间: 2020年5月7日 14:56
收件人: Wubo (lana) ; yang-doct...@ietf.org
抄送: last-c...@ietf.org; draft-ietf-opsawg-tacacs-yang@ietf.org; 
opsawg@ietf.org
主题: Re: Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03

"Wubo (lana)"  writes:
>
> - The "case" statements in ietf-system-tacacsplus:tacacsplus/source-type are 
> unnecessary because each contains only one leaf of the same name; I suggest 
> to remove them.
> [Bo] I need to wait for the further guidance from WG. The "choice case" is 
> added based on the email discussion of the WG, which provides some 
> flexibility in specifying the IP address for server communication. Some 
> vendors prefer IP addresses, and some vendors derive IP addresses through 
> interfaces.

I am not suggesting to remove this choice, this is of course not YANG Doctor's 
business. My comment is related exclusively to YANG syntax: if you have a 
"case" statement containing only one data node, then the "case" statement can 
be omitted, see sec. 7.9.2 in RFC 7950. Such a shorthand is IMO preferable 
(less clutter), unless you want to leave the possibility of augmenting the case 
node later - I don't think though it is an option here.

Thanks, Lada

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03

[Wubo (lana)]

Hi Lada, Joe,

Thanks for the guidance, please see inline.

Thanks,
Bo

-邮件原件-
发件人: Ladislav Lhotka [mailto:ladislav.lho...@nic.cz] 
发送时间: 2020年5月7日 14:38
收件人: Joe Clarke (jclarke) ; Wubo (lana) 

抄送: yang-doct...@ietf.org; last-c...@ietf.org; 
draft-ietf-opsawg-tacacs-yang@ietf.org; opsawg@ietf.org
主题: Re: Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03

"Joe Clarke (jclarke)"  writes:

>> - Is it correct that the server type may be either one of "authentication", 
>> "authorization" or "accounting", or all of them? Is it impossible for a 
>> server to be authentication & authorization but not accounting? Such a 
>> variant cannot be configured.
>> [Bo] OK, will correct when the final guidance on this issue is received.
>
> Lada replied yesterday to say that the bit string is likely preferred similar 
> to access-operations in ietf-netconf-acm.  I might personally discourage the 
> use of ‘*’ for this given that there are only three types, but that’s just my 
> individual thought.

+1

I think it is better to have all three types explicitly in the value. Perhaps 
this could also be the default?

Lada
[Bo] Please see if the definition below is correct:
  typedef tcsplus-server-type {
   type bits {
 bit authentication {
   description
 "When set, the server is an authentication server.";
 }
 bit authorization {
   description
 "When set, the server is an authorization server.";
 }
 bit accounting {
   description
 "When set, the server is an accounting server.";
 }
 bit all {
   description
 "When set, the server can be all types of TACACS+ servers.";
 }   
 
   }
   description
 "server-type can be set to authentication/authorization/accounting or 
any combination of the three types. 
  When all three types are supported, either "all" or the three bits 
setting can be used;
 }

>
> Joe
>

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03

[Wubo (lana)]

Hi Lada,

Thanks for the review. Please see the response inline.

Regards,
Bo

-邮件原件-
发件人: Ladislav Lhotka via Datatracker [mailto:nore...@ietf.org] 
发送时间: 2020年5月4日 21:17
收件人: yang-doct...@ietf.org
抄送: last-c...@ietf.org; draft-ietf-opsawg-tacacs-yang@ietf.org; 
opsawg@ietf.org
主题: Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03

Reviewer: Ladislav Lhotka
Review result: Ready with Nits

The YANG module specified in this I-D defines a relatively simple augmentation 
of the "ietf-system" module that enables configuration of TACACS+ 
authentication. The ietf-system-tacacsplus module is in a good shape, I found 
no substantial problems.

 Comments

- In sec. 3, the text says: 'The ietf-system-tacacsplus module is intended to 
augment the "/sys:system" path defined in the ietf-system module with 
"tacacsplus" grouping.' It would be more precise to say '... with the contents 
of the "tacacsplus" grouping.'
[Bo] OK, I will change as suggested.

- Description of the leaf
/ietf-system-tacacsplus:tacacsplus/statistics/sessions is cryptic and unclear.
[Bo] OK, I will change as follows:
"Number of sessions completed with the server. If the Single Connection Mode 
was not enabled, the number of sessions is the same as the number of connection 
opens. 
If the Mode was enabled, a single TCP connection may contain multiple TACACS+ 
sessions."

- Typo in error-message of
/ietf-system:system/ietf-system-tacacsplus:tacacsplus: s/sysytem/system/
[Bo] OK, will correct.

- Is it correct that the server type may be either one of "authentication", 
"authorization" or "accounting", or all of them? Is it impossible for a server 
to be authentication & authorization but not accounting? Such a variant cannot 
be configured.
[Bo] OK, will correct when the final guidance on this issue is received.

- The "case" statements in ietf-system-tacacsplus:tacacsplus/source-type are 
unnecessary because each contains only one leaf of the same name; I suggest to 
remove them.
[Bo] I need to wait for the further guidance from WG. The "choice case" is 
added based on the email discussion of the WG, which provides some flexibility 
in specifying the IP address for server communication. Some vendors prefer IP 
addresses, and some vendors derive IP addresses through interfaces.

- Security Considerations should specifically address the "shared-secret" leaf.
[Bo] OK, will add this and also some other nodes as Tom Petch commented.

- The purpose of Appendix A is unclear, the information it provides is (or 
should be) in the previous text, the YANG module, and RFC 7317. Instead, it 
would be useful to provide an example of TACACS+ configuration, e.g. in JSON 
representation.
[Bo] OK, will change Appendix A into an example of TACACS+ configuration. 


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

Re: [OPSAWG] WG LC: draft-ietf-opsawg-tacacs-yang-03

[Wubo (lana)]

Hi Tom and Joe,

Many thanks for your comments and discussions. Both of you have suggested 
better approach.

I will update the model when the YANG Doctor has a final suggestion.

Regards,
Bo

-邮件原件-
发件人: Joe Clarke (jclarke) [mailto:jcla...@cisco.com] 
发送时间: 2020年4月25日 21:36
收件人: tom petch 
抄送: Wubo (lana) ; opsawg 
主题: Re: WG LC: draft-ietf-opsawg-tacacs-yang-03



> On Apr 25, 2020, at 06:44, tom petch  wrote:
> 
> From: Joe Clarke (jclarke) 
> Sent: 24 April 2020 17:42
> On Apr 24, 2020, at 11:37, tom petch  wrote:
>> 
>> From: Joe Clarke (jclarke) 
>> Sent: 24 April 2020 14:24
>> 
>> [Bo] You are correct, and I think this model should not exclude this cases.
>> I am considering of two possible approach: one way is to modify enumeration 
>> to leaf-list, the other is that 'server' list uses both 'name' and 
>> server-type' as key values.
>> What do you think?
>> 
>> 
>> I am not sure I understand.  I think of the traditional approach of an int 
>> range 0..7 with 1, 2, 4 representing the three alternatives so one digit 
>> represents any possible combination but that is Unix and not really YANG.
>> I see it as attractive to have one value meaning all three (which 7 would do 
>> above) as that is a common case but I think you are suggesting a leaf-list 
>> of one or two or three entries which works, but is a bit clumsy.  Ditto 
>> server-type as key, would you not end up with three entries in the list for 
>> a full function server?
>> 
>> Why is leaf-list clumsy?  To me that seems like the right approach here.  
>> The chmod-like bit string seems less obvious in this case.  This seems akin 
>> to the feature leaf-list in ietf-yang-library and I can see this working 
>> where there is a server-type-identifier typedef that is an enum of the types 
>> currently present in the module.  Then you’d like instance data like:
>> 
>> authentication
>> authorization
>> accounting
>> 
>> This is more self-describing than the bit string.  I wouldn’t add 
>> server-type as a key, though.  I would think that the name alone would still 
>> work.
>> 
>> 
>> I did say it was more Unix than YANG:-) I use 'clumsy' to mean that 
>> in order to show support for all three options, which I suspect will be the 
>> commonest case, you have to set three objects whereas ideally you would set 
>> just the one meaning all three.  I would also use clumsy to describe 
>> introducing a fourth option to mean all three.
>> At present, I cannot think of a less clumsy way in YANG.  Thus, I do not see 
>> a bit string as any more attractive.
> 
> JMC>
> Agreed, I don’t see the bstring as more attractive.  Yes, the explicit 
> enumeration is more verbose, but it is more self-describing.  I would opt for 
> that vs. an “all” that doesn’t tell me anything unless I read the module.
> 
> 
> Joe
> 
> I had a look at the NACM RFC to see how Andy handled the case of the 
> five possible actions, CRUDX, of which zero to five are possible and 
> he uses bit string, which suggests to me that there is no better way, except 
> that for NACM the commonest case is likely just 'Read' so that is nice and 
> compact to specify.  I notice elsewhere that he has a list of type string for 
> users or groups thereof but does allow '*' to mean all, which I like and 
> think self-explanatory.  I would expect users here to know of the three 
> options and expect them all to be present in most cases and so would realise 
> the meaning of asterisk.  We could have choice  case select
> bit string
> /* one or two services*/
> case all
>(asterisk)
> /* all three*/
> Is it worth the complexity?  Up to you:-)
> 
> We could draw the attention of a Yang Doctor review to this.

JMC>
As a contributor (and all of my comments on this thread have been) I still 
prefer the leaf-list.  Privileges are different than server types, and in a 
number of cases, I just configure authn and authz alone (so I don’t think ‘*’ 
would be as prevalent).

Still, I agree with this last comment of yours, and I will flag this to the 
YANG doc.  

Thanks for your reviews, as always, Tom.  The discussions are very valuable.

Joe

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

Re: [OPSAWG] WG LC: draft-ietf-opsawg-tacacs-yang-03

[Wubo (lana)]

-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com] 
发送时间: 2020年4月23日 23:42
收件人: Wubo (lana) ; Joe Clarke (jclarke) 
; opsawg 
主题: Re: WG LC: draft-ietf-opsawg-tacacs-yang-03

From: Wubo (lana) 
Sent: 23 April 2020 12:53

Hi Tom,

Thanks for pointing this out, please see the reply below.

Regards,
Bo

-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com]
发送时间: 2020年4月22日 23:34

One point inline

From: Wubo (lana) 
Sent: 22 April 2020 04:54

Hi Tom,

Thanks for the comments, please see reply inline below.

Regards,
Bo

-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 tom petch
发送时间: 2020年4月21日 17:09

I think that more is needed for security.

Security Considerations does not list any sensitive nodes.  I see 'secret' as 
an obvious candidate with its nacm:deny-all and perhaps the list of servers and 
their addresses.
[Bo] OK. I will list these nodes to the Security Considerations section.

The model allows for accounting or authorisation or authentication or all three 
but not two out of three; I do not know if this is a use case.
[Bo] Two out the three configurations can be supported by configuring any of 
the two. "all three" is intended to be consistent with most implementations.


I do not see it; AFAIK an enumeration can only be configured with one value 
which then can only be one of the four specified in the model.  Other data 
types do allow combinations - bit strings for examp[e - but not I think 
enumeration.  Whether or not this is worth including, I do not know - as you 
say, all three is the common case.

Tom Petch
[Bo] You are correct, and I think this model should not exclude this cases.
 I am considering of two possible approach: one way is to modify enumeration to 
leaf-list, the other is that 'server' list uses both 'name' and server-type' as 
key values.
 What do you think?


I am not sure I understand.  I think of the traditional approach of an int 
range 0..7 with 1, 2, 4 representing the three alternatives so one digit 
represents any possible combination but that is Unix and not really YANG.
I see it as attractive to have one value meaning all three (which 7 would do 
above) as that is a common case but I think you are suggesting a leaf-list of 
one or two or three entries which works, but is a bit clumsy.  Ditto 
server-type as key, would you not end up with three entries in the list for a 
full function server?

Tom Petch
[Bo] Many thanks for your suggestion. The other two methods are indeed clumsy.  
Please see if the following modification are as you suggested.
leaf server-type {
  type int8 {
range "1..7";
  } 
  description
"The value indicates different server types or combinations,
and the meanings are as follows: 
1The server is an authentication server 
2The server is an authorization server 
4The server is an accounting server
7The group of all types of TACACS+ servers
 3The server is an authentication and authorization server
etc. ";
}

Bo

opsawg-tacacs says secret must be 16  preferably 32; YANG can enforce the 
former and recommend the latter [Bo] OK, I will add 'length "16..max" ' and 
'description: as specified by Tdraft-ietf-opsawg-tacacs : TACACS+ servers and 
clients MUST support shared keys that are at
   least 32 characters long '
   But I'm not sure about the 'length', vendors may use different restrictions.

server name is unrestricted in length or character set; is this desirable (YANG 
has a type for identifiers limited to the usual A-Z 0-9 plus some punctuation)?
[Bo] I think I can add, but System model (RFC 7317) does not have this 
restriction, and vendors may use different ones.

Overall I was expecting more but that said I cannot think of what to add!

Tom Petch



From: OPSAWG  on behalf of Joe Clarke (jclarke) 

Sent: 20 April 2020 14:23

Hello, opsawg.  As we stated in the April 7 virtual interim, this draft has 
reached a point where current WG feedback has been incorporated, and the larger 
TACACS+ is progressing through the IESG.  We are opening a two week last call 
for this draft.

Please comment as to whether or not you feel it is ready and what additional 
changes are required by May 3, 2020.

Thanks.

Joe and Tianran

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

Re: [OPSAWG] WG LC: draft-ietf-opsawg-tacacs-yang-03

[Wubo (lana)]

Hi Tom,

Thanks for pointing this out, please see the reply below.

Regards,
Bo

-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com] 
发送时间: 2020年4月22日 23:34
收件人: Wubo (lana) ; Joe Clarke (jclarke) 
; opsawg 
主题: Re: WG LC: draft-ietf-opsawg-tacacs-yang-03

One point inline

From: Wubo (lana) 
Sent: 22 April 2020 04:54

Hi Tom,

Thanks for the comments, please see reply inline below.

Regards,
Bo

-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 tom petch
发送时间: 2020年4月21日 17:09

I think that more is needed for security.

Security Considerations does not list any sensitive nodes.  I see 'secret' as 
an obvious candidate with its nacm:deny-all and perhaps the list of servers and 
their addresses.
[Bo] OK. I will list these nodes to the Security Considerations section.

The model allows for accounting or authorisation or authentication or all three 
but not two out of three; I do not know if this is a use case.
[Bo] Two out the three configurations can be supported by configuring any of 
the two. "all three" is intended to be consistent with most implementations.


I do not see it; AFAIK an enumeration can only be configured with one value 
which then can only be one of the four specified in the model.  Other data 
types do allow combinations - bit strings for examp[e - but not I think 
enumeration.  Whether or not this is worth including, I do not know - as you 
say, all three is the common case.

Tom Petch
[Bo] You are correct, and I think this model should not exclude this cases.
 I am considering of two possible approach: one way is to modify enumeration to 
leaf-list, the other is that 'server' list uses both 'name' and server-type' as 
key values.
 What do you think?
Bo

opsawg-tacacs says secret must be 16  preferably 32; YANG can enforce the 
former and recommend the latter [Bo] OK, I will add 'length "16..max" ' and 
'description: as specified by Tdraft-ietf-opsawg-tacacs : TACACS+ servers and 
clients MUST support shared keys that are at
   least 32 characters long '
   But I'm not sure about the 'length', vendors may use different restrictions.

server name is unrestricted in length or character set; is this desirable (YANG 
has a type for identifiers limited to the usual A-Z 0-9 plus some punctuation)?
[Bo] I think I can add, but System model (RFC 7317) does not have this 
restriction, and vendors may use different ones.

Overall I was expecting more but that said I cannot think of what to add!

Tom Petch



From: OPSAWG  on behalf of Joe Clarke (jclarke) 

Sent: 20 April 2020 14:23

Hello, opsawg.  As we stated in the April 7 virtual interim, this draft has 
reached a point where current WG feedback has been incorporated, and the larger 
TACACS+ is progressing through the IESG.  We are opening a two week last call 
for this draft.

Please comment as to whether or not you feel it is ready and what additional 
changes are required by May 3, 2020.

Thanks.

Joe and Tianran

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

Re: [OPSAWG] WG LC: draft-ietf-opsawg-tacacs-yang-03

[Wubo (lana)]

Hi Tom,

Thanks for the comments, please see reply inline below.

Regards,
Bo

-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 tom petch
发送时间: 2020年4月21日 17:09
收件人: Joe Clarke (jclarke) ; opsawg 

主题: Re: [OPSAWG] WG LC: draft-ietf-opsawg-tacacs-yang-03

I think that more is needed for security.

Security Considerations does not list any sensitive nodes.  I see 'secret' as 
an obvious candidate with its nacm:deny-all and perhaps the list of servers and 
their addresses.
[Bo] OK. I will list these nodes to the Security Considerations section.

The model allows for accounting or authorisation or authentication or all three 
but not two out of three; I do not know if this is a use case.
[Bo] Two out the three configurations can be supported by configuring any of 
the two. "all three" is intended to be consistent with most implementations.

opsawg-tacacs says secret must be 16  preferably 32; YANG can enforce the 
former and recommend the latter
[Bo] OK, I will add 'length "16..max" ' and 'description: as specified by 
Tdraft-ietf-opsawg-tacacs : TACACS+ servers and clients MUST support shared 
keys that are at
   least 32 characters long '
   But I'm not sure about the 'length', vendors may use different restrictions. 

server name is unrestricted in length or character set; is this desirable (YANG 
has a type for identifiers limited to the usual A-Z 0-9 plus some punctuation)?
[Bo] I think I can add, but System model (RFC 7317) does not have this 
restriction, and vendors may use different ones.

Overall I was expecting more but that said I cannot think of what to add!

Tom Petch



From: OPSAWG  on behalf of Joe Clarke (jclarke) 

Sent: 20 April 2020 14:23
To: opsawg
Subject: [OPSAWG] WG LC: draft-ietf-opsawg-tacacs-yang-03

Hello, opsawg.  As we stated in the April 7 virtual interim, this draft has 
reached a point where current WG feedback has been incorporated, and the larger 
TACACS+ is progressing through the IESG.  We are opening a two week last call 
for this draft.

Please comment as to whether or not you feel it is ready and what additional 
changes are required by May 3, 2020.

Thanks.

Joe and Tianran

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

Re: [OPSAWG] WG LC: draft-ietf-opsawg-tacacs-yang-03

[Wubo (lana)]

Hi chairs,

Thanks for the suggestion. We will add the example in the next revision.

Thanks,
Bo

-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2020年4月20日 21:26
收件人: Joe Clarke (jclarke) 
抄送: opsawg 
主题: Re: [OPSAWG] WG LC: draft-ietf-opsawg-tacacs-yang-03

Hello, authors.  Tianran and I were chatting over email, and he had a good 
suggestion.  Could you add an example to this draft showing off how to use the 
model?

Joe

> On Apr 20, 2020, at 09:23, Joe Clarke (jclarke) 
>  wrote:
> 
> Hello, opsawg.  As we stated in the April 7 virtual interim, this draft has 
> reached a point where current WG feedback has been incorporated, and the 
> larger TACACS+ is progressing through the IESG.  We are opening a two week 
> last call for this draft.
> 
> Please comment as to whether or not you feel it is ready and what additional 
> changes are required by May 3, 2020.
> 
> Thanks.
> 
> Joe and Tianran
> 
> 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 mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] re opsawg-tacacs-yang & ietf-system user-authen-order

[Wubo (lana)]

Hi Joe,

Thanks for the suggestion and also the guidance from Lada and other YANG 
doctors.


With this ‘ietf-system-tacacsplus’ module level ‘must-statement’, rather than 
the system level, I will update the TACACS+ YANG draft in next release.

Thanks,
Bo

发件人: Joe Clarke (jclarke) [mailto:jcla...@cisco.com]
发送时间: 2019年11月20日 13:30
收件人: john heasley ; Wubo (lana) 
抄送: opsawg 
主题: Re: [OPSAWG] re opsawg-tacacs-yang & ietf-system user-authen-order




On Nov 19, 2019, at 22:17, john heasley 
mailto:h...@shrubbery.net>> wrote:

Regarding the question, on the second to last page of the opsawg-tacacs-yang
presentation slides, about the must in model ietf-system, which I believe was
whether to add a must for tacacs, remove the must for radius, or do nothing;
that must seems wrong to me.

I would expect the system to react no differently to missing sever
configuration than to a list of servers that all fail to respond.  Some
vendors have done this historically in cli.

Whether ietf-system should be changed, I do not know it is worth the effort.
If the WG agrees that its existence is wrong, that might be another question
for yang doctors.

Lada replied on YANG docs with a suggestion for the T+ module authors.  While 
we can’t affect the authentication-order node, the tacacsplus container could 
be defined like:

augment "/sys:system" {
 container tacacs {
   must "not(derived-from-or-self("
  + "../sys:authentication/sys:user-authentication-order, 'tacacs')"
  + "or server";
   list server {
  ...
   }
 }
}

In this manner, T+ can provide enforcement.  Lada also mentioned that this 
would have been a better way of handling RADIUS in ietf-system.  Certainly this 
could be an item for a .bis, but not sure if this alone is worth taking on that 
work.

Joe


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

Re: [OPSAWG] WG adoption call for draft-wu-model-driven-management-virtualization-07

[Wubo (lana)]

Hi,

I support the adoption.
I think this draft helps to understand the YANG models scattered across 
different WGs and the role of these models in network automation management. 

Thanks,
Bo


-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2019年10月29日 9:44
收件人: opsawg@ietf.org
抄送: draft-wu-model-driven-management-virtualization.auth...@ietf.org; 
opsawg-cha...@ietf.org
主题: [OPSAWG] WG adoption call for 
draft-wu-model-driven-management-virtualization-07

Hi WG,

This email starts a 2 weeks working group adoption call for 
draft-wu-model-driven-management-virtualization-07.
https://datatracker.ietf.org/doc/draft-wu-model-driven-management-virtualization/
This document provides a framework that describes and discusses an architecture 
for service and network management automation that takes advantage of YANG 
modeling technologies.

If you support adopting this document please say so, and please give an 
indication of why you think it is important. Also please say if you will be 
willing to review and help the draft.
If you do not support adopting this document as a starting point for work on 
this topic, please say why.
This poll will run until Nov 11.
 
Thanks,
Tianran and 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

Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02

[Wubo (lana)]

Thank Joe and Eliot for the comments and suggestions, I will specify these two 
points for discussion in my slides.

Thanks,
Bo

发件人: Joe Clarke (jclarke) [mailto:jcla...@cisco.com]
发送时间: 2019年7月9日 23:15
收件人: Eliot Lear 
抄送: Wubo (lana) ; Qin Wu ; Tianran 
Zhou ; opsawg@ietf.org; OpsAWG Chairs 

主题: Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02




On Jul 9, 2019, at 05:35, Eliot Lear mailto:l...@cisco.com>> 
wrote:




On 9 Jul 2019, at 08:59, Wubo (lana) 
mailto:lana.w...@huawei.com>> wrote:

Thank Eliot for pointing out these questions. I share a similar view with Qin, 
and I suggest to make the following changes in the next version:

1. draft-ietf-opsawg-tacacs will be changed as a normative reference according 
to RFC3967.

Several points: please take into account that RFC 8067 updates RFC 3967.  What 
this means is that you should probably have a brief chat with the chairs and 
Ignas on this point to see what he wants.  It may also be worth a little bit of 
discussion time.

Agreed on your points here.  I do think this should be a standards track 
document, and I think a downref would be acceptable in this case.  But this is 
worth addressing as an issue for your draft in your slot.




2. For the second point, I think your concern may be whether the TACACS + YANG 
model is flexible enough to accommodate the TACACS advanced features.

I think the augmentation is exactly what you want to do for this sort of thing.

This was also my thinking.  If/when a T+/TLS draft comes out and additional 
configuration is required, that could be an augmentation or even a bis to this 
model.  From a YANG versioning standpoint, we want models to evolve.

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

Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02

[Wubo (lana)]

Thank Eliot for pointing out these questions. I share a similar view with Qin, 
and I suggest to make the following changes in the next version:

1. draft-ietf-opsawg-tacacs will be changed as a normative reference according 
to RFC3967.

2. For the second point, I think your concern may be whether the TACACS + YANG 
model is flexible enough to accommodate the TACACS advanced features.
The current TACACS + YANG architecture is designed with per-server 
configuration and statistics methods. Each server is configured with a TCP port 
and a shared key.
These nodes may change to use a "choice" statement. If the TACACS++ extends to 
use TLS protocol, the transport extensions can be added as new "case" 
statements.

Thanks,
Bo
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Qin Wu
发送时间: 2019年7月9日 11:20
收件人: Tianran Zhou ; Eliot Lear 
抄送: opsawg@ietf.org; OpsAWG Chairs 
主题: Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02

A few thoughts on Eliot’s two questions:

1.   Do we have YANG data model draft developed by IETF published as 
informational RFC? I haven’t seen one.

2.   This model uses system management YANG data model defined in RFC7317 
as base model and augment it with TACACS+ specifics, and RFC7317 is standard 
track RFC.

3.   Downref is allowed in some circumstance, See RFC3967 section 2, first 
two bullets.

4.   TACACS+ protocol has been moved for publication. Whether or not 
TACACS++ comes later, TACACS+ will be basis for any advanced features. So 
timing is perfect.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2019年7月9日 10:35
收件人: Eliot Lear mailto:l...@cisco.com>>
抄送: opsawg@ietf.org; OpsAWG Chairs 
mailto:opsawg-cha...@ietf.org>>
主题: Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02

Hi Eliot,

Thanks for your suggestions. Please see inline.

Tianran

From: Eliot Lear [mailto:l...@cisco.com]
Sent: Monday, July 08, 2019 8:13 PM
To: Tianran Zhou mailto:zhoutian...@huawei.com>>
Cc: opsawg@ietf.org; OpsAWG Chairs 
mailto:opsawg-cha...@ietf.org>>
Subject: Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02

Hi Tianran,

I have two concerns about this draft.  First is the intended status of this 
document.  It currently calls out draft-ietf-opsawg-tacacs as an informational 
reference.  I think the question here is really whether this draft should also 
be informational.  As a practical matter you really do need to have implemented 
the other draft for this one to be implemented.  And that means that really it 
should be a normative reference.  But it would be a downref.  To address this, 
I suggest just making this document an informational draft, rather than 
targeting for standards, and make the reference normative.

[Tianran] Yes, I have the same concern. You provided a good approach. On the 
other hand, I think RFC3967 described this case.
“2.  The Need for Downward References
…
   o  A standards document may need to refer to a proprietary protocol,
  and the IETF normally documents proprietary protocols using
  informational RFCs.”

In addition, I have another question.  Is there interest or appetite for 
creating a standardized and more version of T+?  If so, is the timing of a 
standardized YANG model appropriate?

[Tianran] I would like to see how the WG would like to approach.

Eliot


On 7 Jul 2019, at 09:58, Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:

Hi WG,

This document was presented in Prague. The authors have addressed all the 
comments and believe it’s ready for further working group discussion.
https://tools.ietf.org/html/draft-zheng-opsawg-tacacs-yang-02


This email starts a two weeks poll for adoption.
If you support adopting this document please say so, and please give an 
indication of why you think it is important. Also please say if you will be 
willing to review and help the draft.
If you do not support adopting this document as a starting point for work on 
this topic, please say why..
This poll will run until 22nd July.

Regards,
Tianran & 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

Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02

[Wubo (lana)]

Support as a co-author.

Thanks,
Bo

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2019年7月7日 15:59
收件人: opsawg@ietf.org
抄送: OpsAWG Chairs 
主题: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02


Hi WG,



This document was presented in Prague. The authors have addressed all the 
comments and believe it’s ready for further working group discussion.

https://tools.ietf.org/html/draft-zheng-opsawg-tacacs-yang-02





This email starts a two weeks poll for adoption.

If you support adopting this document please say so, and please give an 
indication of why you think it is important. Also please say if you will be 
willing to review and help the draft.

If you do not support adopting this document as a starting point for work on 
this topic, please say why..

This poll will run until 22nd July.



Regards,

Tianran & Joe

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