Re: [OPSAWG] side meeting #119: Power Metrics: concrete usage example

[Rob Wilton (rwilton)]

Hi Jari,

Thanks for your comments and offer to help, it will be greatly received!  We 
are in the process of setting up the open mailing list.  Once that has been 
created, and advertised, then I will move discussion on the BOF and WG charter 
discussion there.

Ack, on whether a BOF is needed or not.  In the past, when I was an AD, I 
generally favoured chartering WGs directly, e.g., for IOTOPS, IVY, NMOP, but 
I’ll defer to Mahesh & the IESG to consider which may be the best path here.  
Either, way I think that the key part of this work is really defining the 
charter for that WG.

I’m also in complete agreement with you on a very tightly scoped, short lived, 
WG.  In particular, I believe that it should be for work that is broadly 
understood and that can be achieved in a short time frame.

Regards,
Rob


From: Jari Arkko 
Date: Wednesday, 27 March 2024 at 00:09
To: Rob Wilton (rwilton) 
Cc: Carlos Pignataro , Marisol Palmero Amador (mpalmero) 
, opsawg@ietf.org , 
e-imp...@ietf.org , inventory-y...@ietf.org 
, Alexander Clemm , Alberto 
Rodriguez-Natal (natal) , Ron Bonica , 
Mahesh Jethanandani , Ali Rezaki (Nokia) 
, Suresh Krishnan (sureshk) 
Subject: Re: [OPSAWG] side meeting #119: Power Metrics: concrete usage example
Rob,

One of the challenges we appear to be having is that the working groups that 
should potentially care about some of the metrics work for instance are busy. I 
find that somewhat unfortunate, but it may be what it is. The IAB program is 
not a place for us to standardize protocols or data models, though of course it 
can be a place to discuss what work is happening in the IETF or is not but 
should.  So if the WGs like OPSAWG or IVY have little bandwidth for the the 
work that needs to happen, then new IETF activities should be created for it.

I have two comments to consider though:

1. Sometimes if the work is clear enough but no room in an existing working 
group, WGs can also created directly. Not sure if this is feasible in this case.

2. I’d be happy to contribute to a BoF personally. But it is *very* important 
that it be scoped extremely tightly. This is a topic where we can easily 
attract any level of discussion, and BoF proposals with clear, concrete goals 
(”add this YANG thing”) succeed, whereas proposals with vague or unclear or 
debated scopes may not proceed as fast or at all.

Jari


Rob Wilton (rwilton)  kirjoitti 26.3.2024 kello 0.48:

Hi Carlos,

During IETF 119, I had a couple of discussions with Suresh and Mahesh regarding 
how we actual get some of the short term “green” related work happening in IETF 
to get critical mass and cross review and get published in the short term.  
This seemed to somewhat culminate during the Power Metrics side meeting where 
it is clear that:

· Various folks, representing different organizations, have various 
drafts related to Green networking.

· Currently these drafts are spread out to different working groups, 
have various amounts of overlap, and it is unclear that they currently have a 
good homes and sufficient traction in IETF to progress effectively.

· There was support in the meeting to target a WG forming BOF for IETF 
120 to create a new WG with a limited targeted charter.

Hence the proposal from Suresh and I was to try and help coordinate for a WG 
forming BOF for IETF 120 scoped specifically to work on items that are 
understood and achievable in the short term.  E.g., roughly, I currently think 
of this work scope as being: e.g., energy related terminology and definitions 
(that should try and leverage and reference existing definitions from existing 
published sources), reporting energy and sustainability at the device and 
network layer via operational YANG models, and to facilitate configuration or 
YANG RPCs to influence and optimise power usage on network devices.  Longer 
term energy efficiency and Green networking goals are intended to be out of 
scope for the proposed WG’s initial charter, and should continue to be 
discussed as part of the E-Impact IAB program.  The exact scope of the charter 
would be worked out between the interested parties in the coming weeks.
I’m happy to try and help this work gain traction within the IETF.  I 
appreciate that several of the proponents for this work are also from Cisco, 
but I have no vested interest other than trying to help the industry take small 
steps that may help improve energy efficiency in networks (e.g., reporting 
power usage, and as Tony suggests by selectively powering off ports or 
linecards) to try and help mitigate some of the impacts of the Internet on 
climate change.

To that end the proposed next steps from that side meeting were:

1.  For me to request the creation of new open “green-bof” mailing list 
from Mahesh (hopefully should be done over the next few days).

2.  I asked for, and received, permission to subscribe those who attended 
the side meeting, but once created, I also intended to circu

Re: [OPSAWG] side meeting #119: Power Metrics: concrete usage example

[Rob Wilton (rwilton)]

Hi Michael,

On 26/03/2024, 10:02, "Michael Richardson"  wrote:

Rob Wilton \(rwilton\) 
mailto:40cisco@dmarc.ietf.org>> wrote:
> 1.  For me to request the creation of new open “green-bof” mailing list
> from Mahesh (hopefully should be done over the next few days).

Getting Rid of Energy Eating Networks = GREEN :-)
(I admit that I was slightly inspired by Calvin and Hobbes club)

I think that there are plenty of good opportunities for a backronym.

> 3.  To create a github location where we can reference drafts and
> collecting work on a BOF proposal and draft charter for the WG (which
> as I stated above, should be narrowly scoped to only the work that is
> well understood and achievable in the short term).  If I can get this
> under the IETF github space, great, otherwise I can host a personal
> github.  I’m already checking with Mahesh on the feasibility of the
> github location being IETF hosted.

You just create or ask secretariat to create IETF-WG-GREEN organization.
(If they do it, then they set some defaults and arrange backups)

It sounds like you've become a BOF co-chair.
Was that intended?

Nope, chairing the BOF is not my plan ;-).  But I am happy to try and help 
corral folks, do some BOF prefer, and help draft a charter.

Regards,
Rob



--
Michael Richardson mailto:mcr+i...@sandelman.ca>>, 
Sandelman Software Works
-= IPv6 IoT consulting =-  *I*LIKE*TRAINS*




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

Re: [OPSAWG] side meeting #119: Power Metrics: concrete usage example

[Rob Wilton (rwilton)]

Hi Carlos,

Thanks for the comments.  I’ve provided some comments (RW) inline …

From: Carlos Pignataro 
Date: Monday, 25 March 2024 at 21:09
To: Rob Wilton (rwilton) 
Cc: Marisol Palmero Amador (mpalmero) , 
Ops Area WG , E-Impact IETF , 
inventory-y...@ietf.org , Alexander Clemm 
, Alberto Rodriguez-Natal (natal) , Ronald 
Bonica , Mahesh Jethanandani , 
Ali Rezaki (Nokia) , Suresh Krishnan (sureshk) 
, Jari Arkko 
Subject: Re: [OPSAWG] side meeting #119: Power Metrics: concrete usage example
Hi, Rob,

Thanks for the comprehensive email, and for your desire to support the industry 
towards improved energy efficiency!

RW: Great!  I think that at least our broader goals are aligned here, although 
you seem to disagree on the particular path that I’m pushing for.  I’m hoping 
that we can manage to get alignment, working towards the common good.


My first reaction is that this direction seems counter to and in conflict with 
the conclusion and decisions from the IAB Program eimpact “interim” from just a 
month before:
· See Chair 
Slides<https://datatracker.ietf.org/meeting/interim-2024-eimpact-02/materials/slides-interim-2024-eimpact-02-sessa-chair-slides-01>,
 that codified: "Metrics – Push through the WGs” (etc. etc.)
· See 
Minutes<https://datatracker.ietf.org/meeting/interim-2024-eimpact-02/materials/minutes-interim-2024-eimpact-02-202402161500-00>,
 that captured: "Suresh agreed and mentioned that the reason for having the 
drafts here is that people to get higher level view since all working groups 
need to have a sustainability angle"
RW: Sorry, I had a conflict and couldn’t attend the e-impact interim.  My 
previous understanding was based on when this was discussed between the IESG 
and IAB retreat last summer was that the IAB program was for more future 
looking working, and incubating ideas that were not yet ready to be 
standardized but any actual work would happen in IETF WGs.

A second thought is that, while on the surface getting a couple of document 
with ‘green metrics’ is useful and might seem net-positive, knee-jerk reacting 
on tactics misaligned with strategy can further fragment the Eimpact work 
(which already can be characterized as ‘having a hard time finding itself’ with 
work from 2022 and no output).

RW: Sorry, but I don’t really follow.  Why would standardizing metrics and 
power controls now impact the overall strategy?  This is perhaps where I see 
things quite differently.  I see this as a simple split between what we can 
standardize now, relatively quickly, starting to reap the benefits now vs 
spending a long time discussing what we plan to do before taking any action.


There are clear risks like (1) believing that metrics/models are the ultimate 
goal of “eimpact/green’ work, while (as mentioned on eimpact) there’s no 
analysis of the most useful focus area, and (2) forgetting what Suresh wrote 
that many WGs need ‘green’, and this would separate work in a corner, as 
opposed to embedding and integrating it.

RW: I don’t believe that metrics/models are the ultimate goal at all, but they 
do seem like a useful first step.  Further, the purpose of this proposed WG 
isn’t really to create new work, but to better corral the existing work that 
folks are already trying to get started within the IETF now, and as I see it, 
struggling to get traction.


A third thought is that we had asked for a (broader and more e-impactful) WG a 
year ago, and that was shot down in favor of this IAB Program :-|

RW: When I was an AD, both in the previous side meetings and in the IESG/IAB 
retreat I was also a vocal proponent for creating a WG, and yes, the agreement 
at that time (9-10 months ago) that we should start with the IAB e-Impact 
program, and that the work could proceed in existing WGs.  However, I’ve since 
seen “green” related drafts being presented in OPSAWG, within IVY and it was on 
the agenda for NETMOD.  I.e., it looks to me like there is work ready to 
progress now but looking for a good home.  The issue here is that this work 
isn’t obviously and clearly in charter for any of these WGs except maybe 
OPSAWG.  IVY is meant to be specifically focussed on a base inventory YANG 
model and should concentrating on that task until it is complete. Alas, one of 
the downsides of OPSAWG is that it’s made up of different groups of individuals 
working on their own topics and lacks the cohesiveness and collective direction 
that a dedicate WG could provide.


Fourth, ‘green-bof’ is very very broad, while I understood your desired scope 
to be narrow. This would eclipse eimpact as the shinny new ball, and would 
potentially confuse people on where to participate (outside the lucky ones that 
attended a side meeting)

RW: green-bof is just a list name.  I don’t really care what the BOF or WG is 
called.  My intention is that the scope of the WG that I’m trying to create is 
that it will be narrow to the work items that are achievable in 

Re: [OPSAWG] side meeting #119: Power Metrics: concrete usage example

[Rob Wilton (rwilton)]

Hi Carlos,

During IETF 119, I had a couple of discussions with Suresh and Mahesh regarding 
how we actual get some of the short term “green” related work happening in IETF 
to get critical mass and cross review and get published in the short term.  
This seemed to somewhat culminate during the Power Metrics side meeting where 
it is clear that:

  *   Various folks, representing different organizations, have various drafts 
related to Green networking.
  *   Currently these drafts are spread out to different working groups, have 
various amounts of overlap, and it is unclear that they currently have a good 
homes and sufficient traction in IETF to progress effectively.
  *   There was support in the meeting to target a WG forming BOF for IETF 120 
to create a new WG with a limited targeted charter.

Hence the proposal from Suresh and I was to try and help coordinate for a WG 
forming BOF for IETF 120 scoped specifically to work on items that are 
understood and achievable in the short term.  E.g., roughly, I currently think 
of this work scope as being: e.g., energy related terminology and definitions 
(that should try and leverage and reference existing definitions from existing 
published sources), reporting energy and sustainability at the device and 
network layer via operational YANG models, and to facilitate configuration or 
YANG RPCs to influence and optimise power usage on network devices.  Longer 
term energy efficiency and Green networking goals are intended to be out of 
scope for the proposed WG’s initial charter, and should continue to be 
discussed as part of the E-Impact IAB program.  The exact scope of the charter 
would be worked out between the interested parties in the coming weeks.

I’m happy to try and help this work gain traction within the IETF.  I 
appreciate that several of the proponents for this work are also from Cisco, 
but I have no vested interest other than trying to help the industry take small 
steps that may help improve energy efficiency in networks (e.g., reporting 
power usage, and as Tony suggests by selectively powering off ports or 
linecards) to try and help mitigate some of the impacts of the Internet on 
climate change.

To that end the proposed next steps from that side meeting were:


  1.  For me to request the creation of new open “green-bof” mailing list from 
Mahesh (hopefully should be done over the next few days).
  2.  I asked for, and received, permission to subscribe those who attended the 
side meeting, but once created, I also intended to circulate the existence of 
the mailing list to e-impact, and other places where related discussions have 
been taking place, so that others can join.
  3.  To create a github location where we can reference drafts and collecting 
work on a BOF proposal and draft charter for the WG (which as I stated above, 
should be narrowly scoped to only the work that is well understood and 
achievable in the short term).  If I can get this under the IETF github space, 
great, otherwise I can host a personal github.  I’m already checking with 
Mahesh on the feasibility of the github location being IETF hosted.
  4.  Once the mailing list is up and running, the next step is to arrange a 
few virtual meetings to try and gain consensus on the proposed initial scope of 
the WG, and to start reviewing and pulling together the BOF proposal, and 
charter text.
  5.  To submit a BOF request for IETF 120.  The key dates being:
 *   Warn the IESG and Secretariat that we are hoping for a BOF by 22nd 
April (note Mahesh is already aware and this has already been informally 
flagged to the IESG)
 *   Get the initial BOF submission in before 5th May
 *   Refine the BOF proposal based on feedback received, and update by 7th 
June
 *   14th June, we hear back whether the BOF has been approved for IETF 120
 *   Continue prepping slides, etc, for the BOF, running up to early July
  6.  In my experience, despite it being 4 months between IETF meetings, the 
time invariably disappears quickly, so I think that we need to frontload the 
BOF preparation effort to achieve consensus at IETF 120 for creating a working 
group.

Anyone else in the side meeting, please feel free to add anything that I have 
missed, or correct me, if I have misrepresented anything.

Carlos, hopefully you are also interested in participating in these efforts.  
If you have any feedback on the planned approach I would be glad to hear it.

Regards,
Rob


From: OPSAWG  on behalf of Carlos Pignataro 

Date: Monday, 25 March 2024 at 12:01
To: Marisol Palmero Amador (mpalmero) 
Cc: opsawg@ietf.org , e-imp...@ietf.org , 
inventory-y...@ietf.org , Alexander Clemm 
, Alberto Rodriguez-Natal (natal) , Ron Bonica 
, Mahesh Jethanandani , Ali 
Rezaki (Nokia) , Suresh Krishnan (sureshk) 
, Jari Arkko 
Subject: Re: [OPSAWG] side meeting #119: Power Metrics: concrete usage example
+Jari

Hello,

Suresh, Jari,

I'm confused by this bullet point:
•  next 

[OPSAWG] Change in OPSAWG chairs appointments

[Rob Wilton (rwilton)]

Hi OPSAWG,

In consultation with Mahesh, I have decided to revert OPSAWG back to two 
chairs.  I originally increased it to three chairs to give chairing opportunity 
and experience to a new individual, but my general view is that most WGs, 
except for the largest, function better with two chairs.  In addition, there 
has been some general feedback from the community that there should be more 
evolution in the WG chairing positions to give more opportunities for newcomers 
to try chairing and gain more leadership experience.

The chairs for OPSAWG going forward will be Joe Clarke and Henk Birkholz.

Thus, I would like to personally thank Tianran for his many years of service 
chairing the OPSAWG WG during my time as AD and his efforts and guidance of the 
OPSAWG WG have been appreciated.

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

Re: [OPSAWG] Paul Wouters' No Objection on draft-ietf-opsawg-9092-update-11: (with COMMENT)

[Rob Wilton (rwilton)]

Paul has cleared his discuss, and I have just approved -11.

Thanks all for their work on this document.

Regards,
Rob


From: iesg  on behalf of Randy Bush 
Date: Friday, 23 February 2024 at 15:18
To: Paul Wouters via Datatracker 
Cc: The IESG , draft-ietf-opsawg-9092-upd...@ietf.org 
, opsawg-cha...@ietf.org 
, opsawg@ietf.org , 
mcr+i...@sandelman.ca 
Subject: Re: Paul Wouters' No Objection on draft-ietf-opsawg-9092-update-11: 
(with COMMENT)
paul

you may, or may not, like -11.  we tried to clarify some things a bit
better,

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

Re: [OPSAWG] [Technical Errata Reported] RFC8520 (7819)

[Rob Wilton (rwilton)]

I also agree.  I have marked it as verified.

Regards,
Rob


From: Eliot Lear 
Date: Friday, 23 February 2024 at 17:51
To: Russ Housley 
Cc: Ralph Droms , droma...@gmail.com , 
war...@kumari.net , Rob Wilton (rwilton) 
, Henk Birkholz , Joe 
Clarke (jclarke) , zhoutian...@huawei.com 
, opsawg@ietf.org 
Subject: Re: [Technical Errata Reported] RFC8520 (7819)
I agree.  This erratum should be verified.

> On Feb 23, 2024, at 18:48, RFC Errata System  
> wrote:
>
> The following errata report has been submitted for RFC8520,
> "Manufacturer Usage Description Specification".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7819
>
> --
> Type: Technical
> Reported by: Russ Housley 
>
> Section: 13.1
>
> Original Text
> -
> Note: A MUD file may need to be re-signed if the signature expires.
>
> Corrected Text
> --
> Note: A MUD file may need to be re-signed if the certificate needed
> to validate the signature expires.
>
> Notes
> -
> The signature does not expire, but the certificate does.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --
> RFC8520 (draft-ietf-opsawg-mud-25)
> --
> Title   : Manufacturer Usage Description Specification
> Publication Date: March 2019
> Author(s)   : E. Lear, R. Droms, D. Romascanu
> Category: PROPOSED STANDARD
> Source  : Operations and Management Area Working Group
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Adoption Call for draft-feng-opsawg-incident-management-04

[Rob Wilton (rwilton)]

Hi authors, OPSAWG, WG chairs,

I appreciate that the timing isn’t ideal, but given that NMOP has just been 
successfully chartered, and Incident Management is one of the current topics of 
focus for that WG, then I think that it would be better for this document to be 
discussed, and potentially adopted, within that WG.  I.e., so that all the 
incident management related drafts and discussions are kept to one place.

I appreciate that this will potentially slow the adoption a bit, since I think 
that NMOP should meet first, and this draft should then be presented in NMOP, 
but hopefully it would only slow the adoption call by a few months.

Note – this doesn’t stop interested parties showing their interest in this 
work, reviewing the draft and providing comments now.  And of course, that 
discussion can also happen on the NMOP list.

Regards,
Rob



From: OPSAWG  on behalf of Alex Huang Feng 

Date: Tuesday, 13 February 2024 at 05:25
To: Henk Birkholz 
Cc: OPSAWG 
Subject: Re: [OPSAWG]  WG Adoption Call for 
draft-feng-opsawg-incident-management-04
Dear OPSAWG,

I support the progress of this document.

I only have a comment. Since the creation of the new NMOP WG, I wonder if this 
draft should be discussed in that WG too. There is “incident management” in the 
charter.
Some of the related work such as 
https://datatracker.ietf.org/doc/draft-davis-nmop-incident-terminology/ is 
planned to be discussed there.
Just wondering.

Regards,
Alex


On 9 Feb 2024, at 00:44, Henk Birkholz  wrote:

Dear OPSAWG members,

this email starts a call for Working Group Adoption of


https://www.ietf.org/archive/id/draft-feng-opsawg-incident-management-04.html

ending on Thursday, February 22nd.

As a reminder, this I-D specifies a YANG Module for Incident Management. 
Incidents in this context are scoped to unexpected yet quantifiable adverse 
effects detected in a network service. The majority of the document provides 
background and motivation for the structure of the YANG Module that is in 
support of reporting, diagnosing, and mitigating the detected adverse effects.

The chairs acknowledge some positive feedback on the list and a positive poll 
result at IETF118. We would like to gather feedback from the WG if there is 
interest to further contribute and review.

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] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08

[Rob Wilton (rwilton)]

Hi Michael,

The TD;LR is I think that your latest changes are good and I’ll send -12 to 
IETF LC.

When checking the changes, diff, 3 minor nits:

  1.  “a IP address literal in the URL” to “an IP …


  1.  I still think “inprotocol” should be something else, perhaps “within the 
protocol”.


  1.  The final part of the sentence, from list all of … doesn’t scan very well 
to me.
} In some cases, a complete set of geographically distributed servers
} is known at ahead of time, and the firmware vendor can list all of
} those addresses DNS for the the name that it lists in the MUD file.

I think that you have already addressed some comments from Mahesh, but at this 
stage, please treat and of Mahesh’s remaining comments as you would for any 
others received during IETF LC.

I’ve also put a few comments inline (but highlighted the actions above), to 
close out the review.


On 08/02/2024, 19:56, "Michael Richardson"  wrote:

{noting that you reviewed -08, and we are up to -10 since, so some of
your comments/text are no longer applicable}

Rob Wilton (rwilton) mailto:rwil...@cisco.com>> wrote:
> I’ve just re-reviewed -10.I still think that the English to be cleaned
> up further.  I know that the RFC editor would likely find and fix most

okay.

> Minor level comments:



> (1) p 2, sec 1.  Introduction
>[RFC8520] provides a standardized way to describe how a specific
>purpose device makes use of Internet resources.  Access Control
> Lists
>(ACLs) can be defined in an RFC8520 Manufacturer Usage Description
>(MUD) file that permit a device to access Internet resources by DNS
>name.

> "specific purpose device" sounds like slight strange phrasing to me.

As previously discussed for acceptable-urls, this comes from RFC8520,
although that document does not use those exact words.  I'd sure like a
comment from Eliot about whether this is the way to explain MUD.

It is fine to leave it as is.  This isn’t a hill that I’m willing to die on ;-)

> (2) p 2, sec 1.  Introduction
>Use of a DNS name rather than IP address in the ACL has many
>advantages: not only does the layer of indirection permit the
> mapping
>of name to IP address to be changed over time, it also generalizes
>automatically to IPv4 and IPv6 addresses, as well as permitting
>loading balancing of traffic by many different common ways,
> including
>multi-CDN deployments wherein load balancing can account for
>geography and load.


> "many different common ways" sounds like strange phrasing to me.  How
> can something be both different and common, which do you mean?

rewritten to:

} generalizes automatically to IPv4 and IPv6 addresses, as well as
} permitting a variety of load balancing strategies, including multi-CDN
} deployments wherein load balancing can account for geography and
} load.

Thanks.

> (3) p 2, sec 1.  Introduction
>At the MUD policy enforcement point -- the firewall -- there is a
>problem.  The firewall has only access to the layer-3 headers of the
>packet.  This includes the source and destination IP address, and if
>not encrypted by IPsec, the destination UDP or TCP port number
>present in the transport header.  The DNS name is not present!

> "önly access" -> "äccess only"

fixed.


> (4) p 2, sec 1.  Introduction
>It has been suggested that one answer to this problem is to provide
> a
>forced intermediate for the TLS connections.  This could in theory
> be
>done for TLS 1.2 connections.  The MUD policy enforcement point
> could
>observe the Server Name Identifier (SNI) [RFC6066].  Some
> Enterprises
>do this already.  But, as this involves active termination of the
> TCP
>connection (a forced circuit proxy) in order to see enough of the
>traffic, it requires significant effort.


> "This could in theory be done" => "In theory, this could be done", or
> "This could, in theory, be done".

fixed.


> (5) p 3, sec 1.  Introduction
>The second section of this document details how common manufacturer
>anti-patterns get in the way of this mapping.
>The third section of this document details how current trends in DNS
>resolution such as public DNS servers, DNS over TLS (DoT), DNS over
>QUIC (DoQ), and DNS over HTTPS (DoH) cause problems for the
>strategies employed.  Poor interactions with content-distribution
>networks is a frequent pathology that can result.

> Do you really mean pathology here?

"the scientific study of disease" or "a dise

Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-acceptable-urls-09

[Rob Wilton (rwilton)]

Hi Michael,

Thanks for the updates.

Changes look good, and I’ll initiated IETF LC on -09, but there are a couple of 
remaining nits, please see inline. below.  You can either just fix them in your 
editors copy or post a new revision if you prefer, either works.

Anyway, this completes my AD review.  I may be able to get this on the 
2024-03-07 telechat, but it may end up with too many pages, in which case it 
will end up on the first one after IETF 119 with Mahesh progressing it.

Regards,
Rob


From: OPSAWG  on behalf of Michael Richardson 

Date: Wednesday, 7 February 2024 at 01:26
To: Rob Wilton (rwilton) 
Cc: draft-ietf-opsawg-mud-acceptable-urls@ietf.org 
, opsawg@ietf.org 
, Mahesh Jethanandani 
Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-acceptable-urls-09

version -10 is posted, diff is at:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-mud-acceptable-urls-09=draft-ietf-opsawg-mud-acceptable-urls-10=--html


Rob Wilton \(rwilton\)  wrote:
> I think that the document is fine and reasonably clear but could do
> with a bit of language clean up and clarity in a few places.  I’ve
> included my review comments below and also some grammar nits from a
> grammar tool at the end.

> Moderate level comments:

> (1) p 2, sec 3.  Updating the MUD files in place

> Would it a better title for this section be: "Possible issues with
> updating MUD files in place"?

okay.

> Minor level comments:
> (2) p 1, sec 1.  Introduction


>[RFC8520] provides a standardized way to describe how a specific
>purpose device makes use of Internet resources and associated
>suggested network behavior.  The behaviors are described in a MUD
>file hosted in its manufacturer's server.  The device provides a MUD
>URL to the network manager, which can locate this MUD file and
>determine the required network authorization of the device.

> "specific purpose device" sounds like slight strange phrasing to me.

RFC8520 says:
These devices, which this memo refers to as Things, have a
specific purpose.

the key point is that they are not, "general purpose devices" (like laptops,
and smartphones).  I'm not sure what to do with your comment; I'd like to
keep this connection to 8520, but maybe the phrase can be changed in some
useful way.
Okay.  Leave it as is.  I don’t think that it is wrong, it just sounds strange 
to me.  Perhaps other reviews or the RFC editor will have a better suggestion.


> (3) p 2, sec 1.  Introduction

>[RFC8520] does not specify how MUD controllers establish their trust
>in the manufacturers' signing key: there are many possible solutions
>from manual configuration of trust anchors, some kind of automatic
>configuration during onboarding, but also including to Trust on
> First
>Use (TOFU).  How this initial trust is established is not important
>for this document, it is sufficient that some satisfactory initial
>trust is established.

> "but also including to" doesn't scan well to me.

Changed to:
  or a Trust on First Use (TOFU) mechanism that accepts the signer on first use.

Okay.

> (4) p 3, sec 3.1.  Adding capabilities

>While there is an argument that old firmware was insecure and should
>be replaced, it is often the case that the upgrade process involves
>downtime, or can introduce risks due to needed evaluations not
> having
>been completed yet.  As an example: moving vehicles (cars,
> airplanes,
>etc.) should not perform upgrades while in motion!  It is probably
>undesirable to perform any upgrade to an airplane outside of its
>service facility.  A vehicle owner may desire only to perform
>software upgrades when they are at their residence.  Should there be
>a problem, they could make alternate arrangements for
> transportation.
>This is constrasted with the situation when the vehicle is parked
> at,
>for instance, a remote cabin.  The situation for upgrades of medical
>devices has even more considerations involving regulatory
> compliance.



> Perhaps change: This is contrasted with ... => This contrasts this with
> an alternative situation where the vehicle is parked at, for instance,
> a remote cabin, where an upgrade failure could cause a much greater
> inconvenience.

Changed to:

} A vehicle owner may desire only to perform software upgrades when they are
} at their residence.   Should there be a problem, they could make alternate
} arrangements for transportation.
} This contrasts with an alternative situation where the vehicle is parked
} at, for instance, a remote ca

Re: [OPSAWG] [radext] [Technical Errata Reported] RFC2865 (6915)

[Rob Wilton (rwilton)]

Hi Alan,

Thanks for your help.  I’ve marked this as HFDU.

Regards,
Rob


From: radext  on behalf of Alan DeKok 

Date: Monday, 15 January 2024 at 14:20
To: Rob Wilton (rwilton) 
Cc: RFC Errata System , war...@kumari.net 
, opsawg@ietf.org , rad...@ietf.org 
, Paul Wouters 
Subject: Re: [radext] [OPSAWG] [Technical Errata Reported] RFC2865 (6915)
On Jan 15, 2024, at 7:14 AM, Rob Wilton (rwilton) 
 wrote:
> Hi RFC 2865 authors, OPSAWG,

  I've CC'd RADEXT, as that WG is currently active.  I've also removed the 2865 
authors email addresses.  I believe those became inactive decades ago.

> I think that this errata may be valid, but given the age of the RADIUS 
> protocol, and the fact that I'm not familiar with it and this is a change to 
> the protocol, then I'm somewhat concerned with verifying this errata, and 
> hence I propose to move it to "Held for Document Update".
>
> Does anyone have any comments on this proposed resolution?

  I think "hold for document update" is best.

  We've covered these issues in RFC 8044, which defines data types for RADIUS 
(octets, printable text, IPs, integers, etc).  There are no data types which 
permit zero-length values.

  The variable-length data types defined in Section 3.4 (printable strings) and 
3.5 (binary data) both say:

  Strings of length zero (0) MUST NOT be sent; omit the entire attribute 
instead.

 There is no _general_ prohibition on attributes having zero length values.  
But it is not currently permitted to define an attribute which has a 
zero-length value.

  As such, "hold for document update" is the reasonable conclusion.

   Alan DeKok.

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

Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08

[Rob Wilton (rwilton)]

ot;.
Suggested change:  "GitHub"

Section: 3.1.4, draft text:
Instead a wildcard exists to answer all potential names: requests are routed 
appropriate once they are received.
Warning:  A comma may be missing after the conjunctive/linking adverb 'Instead'.
Suggested change:  "Instead,"

Section: 3.2, draft text:
The MUD controller and the device get a matching set, and the ACLs that are 
setup cover all possibilities.
Warning:  The verb 'set up' is spelled as two words. The noun 'setup' is 
spelled as one.
Suggested change:  "set up"

Section: 3.2, draft text:
The simplest is when the round robin does not return all addresses.
Warning:  This word is normally spelled with a hyphen.
Suggested change:  "round-robin"

Section: 4.1, draft text:
A common pattern for a number of devices is to look for firmware updates in a 
two step process.
Warning:  This word is normally spelled with a hyphen.
Suggested change:  "two-step"

Section: 4.1, draft text:
An initial query is made (often over HTTPS, sometimes with a POST, but the 
method is immaterial) to a vendor system that knows whether or not an update is 
required.
Warning:  Consider shortening this phrase to just 'whether', unless you mean 
'regardless of whether'.
Suggested change:  "whether"

Section: 4.1, draft text:
The current firmware model of the device is sometimes provided and then the 
authoritative server provides a determination if a new version is required, and 
if so, what version.
Warning:  Use a comma before "and" if it connects two independent clauses 
(unless they are closely connected and short).
Suggested change:  ", and"

Section: 4.2, draft text:
Even if the content provider chosen names are deterministic they may change at 
a rate much faster then MUD files can be updated.
Warning:  Did you mean faster than?
Suggested change:  "faster than"

Section: 4.2, draft text:
This use of two addresses is ripe for confusion however.
Warning:  Consider inserting a comma before 'however'.
Suggested change:  ", however"

Section: 4.3, draft text:
Exactly what the risk is depends upon what the other customers are doing: it 
could be limited to simply causing a distributed denial of service attack 
resulting in high costs to those customers, or such an attack could potentially 
include writing content.
Warning:  It appears that hyphens are missing.
Suggested change:  "denial-of-service"

Section: 6, draft text:
It can even be done without code changes via the use of a QR code affixed to 
the packaging (see [RFC9238].
Warning:  Unpaired symbol: ')' seems to be missing

Section: 6.2, draft text:
While it used to be costly to have a large number of aliases in a web server 
certificate, this is no longer the case.
Warning:  Specify a number, remove phrase, or simply use many or numerous
Suggested change:  "many"

Section: 6.5, draft text:
The ADD WG has written [I-D.ietf-add-dnr] and [I-D.ietf-add-ddr] to provided.
Warning:  The verb after "to" should be in the base form.
Suggested change:  "provide"

Section: 7, draft text:
The use of unencrypted (Do53) requests to a local DNS server exposes the list 
to any internal passive eavesdroppers, and for some situations that may be 
significant, particularly if unencrypted WiFi is used.
Warning:  Did you mean Wi-Fi? (This is the officially approved term by the 
Wi-Fi Alliance.)
Suggested change:  "Wi-Fi"

Regards,
Rob





From: Toerless Eckert 
Date: Thursday, 26 October 2023 at 23:21
To: Michael Richardson 
Cc: Eliot Lear , Rob Wilton (rwilton) , 
opsawg@ietf.org , 
draft-ietf-opsawg-mud-iot-dns-considerati...@ietf.org 

Subject: Re: [OPSAWG] AD review of 
draft-ietf-opsawg-mud-iot-dns-considerations-08
On Thu, Oct 26, 2023 at 05:49:08PM -0400, Michael Richardson wrote:
> > Sure, but that DNSSEC issue equally applies to TLS proxies, right ?
> > DNSSEC is not mentioned in the docs paragraphs discussing TLS.
>
> TLS proxies do not change/break DNS(SEC).
> They "attack" at the TCP layer (in the same way NAT44 does), forcing traffic
> through their engine.

If they do, sure. I don't think that there is an actual definition that
says so, and i thought i've seen different ones as well.

> The TLS validation step is really a separate thing, and with what you
> suggested, an IP address per destination, and a circuit-layer forward proxy,
> then the device would actually be connected (at layer-4) to the real target.
> So whatever TLS certificate validation they do would just continue to work.

That was the idea. Obvious the experience from BRSKI proxy popped up reading 
this
thread..

> > Of course, one could always extend MUD to explicitly allow clients
> > to look for local-domain domain names to explicitly support TCP/UDP or 
> TLS
> > proxies in case such proxies are desired. 

[OPSAWG] AD review of draft-ietf-opsawg-mud-acceptable-urls-09

[Rob Wilton (rwilton)]

Hi authors, WG,

Here is my AD review of draft-ietf-opsawg-mud-acceptable-urls-09.

I reviewed this doc slightly out of sequence because it was related to other 
MUD files that I was reviewing and also my recent discuss on 
draft-ietf-suit-mud-07.

I think that the document is fine and reasonably clear but could do with a bit 
of language clean up and clarity in a few places.  I’ve included my review 
comments below and also some grammar nits from a grammar tool at the end.


I think that these updates should be pretty easy to do, so if you are able to 
act on them and preferably get a revised ID by this Thursday, then it increases 
the chance that I can get this processed through the IESG evaluation before 
Mahesh takes over.



Moderate level comments:



(1) p 2, sec 3.  Updating the MUD files in place



Would it a better title for this section be: "Possible issues with updating MUD 
files in place"?







Minor level comments:



(2) p 1, sec 1.  Introduction



   [RFC8520] provides a standardized way to describe how a specific

   purpose device makes use of Internet resources and associated

   suggested network behavior.  The behaviors are described in a MUD

   file hosted in its manufacturer's server.  The device provides a MUD

   URL to the network manager, which can locate this MUD file and

   determine the required network authorization of the device.



"specific purpose device" sounds like slight strange phrasing to me.





(3) p 2, sec 1.  Introduction



   [RFC8520] does not specify how MUD controllers establish their trust

   in the manufacturers' signing key: there are many possible solutions

   from manual configuration of trust anchors, some kind of automatic

   configuration during onboarding, but also including to Trust on First

   Use (TOFU).  How this initial trust is established is not important

   for this document, it is sufficient that some satisfactory initial

   trust is established.



"but also including to" doesn't scan well to me.





(4) p 3, sec 3.1.  Adding capabilities



   While there is an argument that old firmware was insecure and should

   be replaced, it is often the case that the upgrade process involves

   downtime, or can introduce risks due to needed evaluations not having

   been completed yet.  As an example: moving vehicles (cars, airplanes,

   etc.) should not perform upgrades while in motion!  It is probably

   undesirable to perform any upgrade to an airplane outside of its

   service facility.  A vehicle owner may desire only to perform

   software upgrades when they are at their residence.  Should there be

   a problem, they could make alternate arrangements for transportation.

   This is constrasted with the situation when the vehicle is parked at,

   for instance, a remote cabin.  The situation for upgrades of medical

   devices has even more considerations involving regulatory compliance.



Perhaps change: This is contrasted with ... => This contrasts this with an 
alternative situation where the vehicle is parked at, for instance, a remote 
cabin, where an upgrade failure could cause a much greater inconvenience.





(5) p 5, sec 4.  Updating the MUD URLs



   The QRcode mechanism is usually done via paper/stickers, and is

   typically not under the control of the device itself at all.

   However, being applied by a human and not easily changed, a MUD URL

   obtained in this fashion is likely trustworthy.  (It may not, due to

   mixups in labeling represent the correct device, but this is a human

   coordination issue, and is out of scope for this document.)



Is this definitely trustworthy?  E.g., we have a spate of scams in the UK where 
folks put new QR codes on the parking machines directly folks to pay at 
fraudulent websites instead.  This scenario is obviously different, but would 
presunably still allow a supply-chain attack to occur?





(6) p 6, sec 4.2.  Concerns about same-signer mechanism



   This works as long as manufacturers use a single key to sign all

   products.  Some manufacturers could sign each product with a

   different key.  Going logically down this path, if all these product

   keys are collected into a single PKI, signed by a common

   certification authority.



The second sentence doesn't make sense to me.  Or otherwise, as a paragraph it 
is incomplete.





(7) p 6, sec 5.  Proposed mechanism



Perhaps rename this section to "Proposed mechanism for updating MUD URLs"?





(8) p 7, sec 5.  Proposed mechanism



   Once the new MUD file is accepted, then it becomes the new "root" MUD

   file, and any subsequent updates MUST be relative to the MUD-URL in

   the new file.



When could this actually change?  I.e., if it only accepts MUD files with the 
same base URL then, by definition, they must all be peers of each other, right? 
 Ah, the MUD-URL in the new MUD file can be used to give a new canonical path 
of where 

Re: [OPSAWG] AD review of draft-ietf-opsawg-9092-update-08

[Rob Wilton (rwilton)]

Hi Randy,

Please see inline …

From: Randy Bush 
Date: Thursday, 18 January 2024 at 19:45
To: Rob Wilton (rwilton) 
Cc: draft-ietf-opsawg-9092-update@ietf.org 
, Mahesh Jethanandani 
, Ops Area WG 
Subject: Re: AD review of draft-ietf-opsawg-9092-update-08
hi rob,

thanks for review.  appreciated.

No problem.


> (1) p 4, sec 3.  inetnum: Class
>
>Any particular inetnum: object SHOULD have, at most, one geofeed
>reference, whether a remarks: or a proper geofeed: attribute when it
>is implemented.  If there is more than one, the geofeed: attribute
>SHOULD be used.
>
> I don't find this text as clear as it could be.  Given the
> recommendation is to have a single geofeed reference, then I think
> that it would be helpful to provide guidance as to what format that
> geofeed reference should take.  I.e., I presume that the geofeed
> reference SHOULD also use the geofeed: attribute format if the RIR
> supports it or the remarks attribute otherwise?

Any particular inetnum: object SHOULD have, at most, one geofeed
reference, whether a remarks: or a proper geofeed: attribute
when it is implemented.  A geofeed: attribute is preferred, of
course, if the RIR supports it.  If there is more than one type
of attribute in the intetnum: object, the geofeed: attribute
SHOULD be used.

LGTM.


> (2) p 9, sec 6.  Operational Considerations
>
>The geofeed files MUST be published via and fetched using HTTPS
>[RFC9110].
>
> Also note you have a similiar RFC 2119 statement in section 4, and I
> wonder whether it would be clearer to only have the formal requirement
> listed in one place and referenced from the other place?

sure.  removed the one in §4

Thanks.



> (3) p 9, sec 6.  Operational Considerations
>
>The geofeed files MUST be published via and fetched using HTTPS
>[RFC9110].
>
> It is interesting that the geofeed files MUST be fetched using HTTPS,
> but earlier the RIR's FTP SHOULD be used to gather the geofeed
> references.  Presumably if the RIR data was available via HTTPS that
> could also be used?

this refers to RIRs providing *bulk* ftp, i.e. get the whole shebang in
one slurp.  can not do that for the geofeed files that are referenced.
xref GEOFEED-FINDER does provide bulk retrieval of the geofeed files.

Ack.  Okay.


> (4) p 11, sec 9.  Security Considerations
>
>The consumer of geofeed data SHOULD fetch and process the data
>themselves.  Importing datasets produced and/or processed by a third-
>party places ill-advised trust in the third-party.
>
> This feels like quite a strong statement to make, and I wonder whether
> it won't be better to just point out the risks of using a third-party
> and then allow the reader to decide whether to accept that risk?

that is why it is SHOULD not MUST, tempting though a MUST may be.  there
is a general problem of lack of understanding of trust boundaries in a
lot of these ops data.  if you do not mind, i think we would leave it
in.

Okay.


> (5) p 7, sec 5.  Authenticating Geofeed Data (Optional)
>
>Identifying the private key associated with the certificate and
>getting the department that controls the private key (which might be
>stored in a Hardware Security Module (HSM)) to generate the CMS
>signature is left as an exercise for the implementor.  On the other
>hand, verifying the signature has no similar complexity; the
>certificate, which is validated in the public RPKI, contains the
>needed public key.  The RPKI trust anchors for the RIRs are expected
>to already be available to the party performing signature validation.
>Validation of the CMS signature over the geofeed file involves:
>
> involves: => "involves the following steps:", or you need to change
> back Obtain ... => Obtaining ..., etc.

sharp eye there.  i went with obtaining; gerundification :)

Okay.  You obviously need to change the tense of the action verb in the rest of 
the list.


want me to push this as a -09, or let it mellow?

Please push -09, and I’ll push to the IETF LC.

Regards,
Rob


again, thanks.

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

[OPSAWG] AD review of draft-ietf-opsawg-9092-update-08

[Rob Wilton (rwilton)]

Hi Authors, OPSAWG,


Please see my AD review comments for draft-ietf-opsawg-9092-update-08.  My 
focus was on the diff between the latest draft and RFC 9092.  I only have some 
relatively minor comments.

Minor level comments:



(1) p 4, sec 3.  inetnum: Class



   Any particular inetnum: object SHOULD have, at most, one geofeed

   reference, whether a remarks: or a proper geofeed: attribute when it

   is implemented.  If there is more than one, the geofeed: attribute

   SHOULD be used.



I don't find this text as clear as it could be.  Given the recommendation is to 
have a single geofeed reference, then I think that it would be helpful to 
provide guidance as to what format that geofeed reference should take.  I.e., I 
presume that the geofeed reference SHOULD also use the geofeed: attribute 
format if the RIR supports it or the remarks attribute otherwise?





(2) p 9, sec 6.  Operational Considerations



   The geofeed files MUST be published via and fetched using HTTPS

   [RFC9110].



Also note you have a similiar RFC 2119 statement in section 4, and I wonder 
whether it would be clearer to only have the formal requirement listed in one 
place and referenced from the other place?





(3) p 9, sec 6.  Operational Considerations



   The geofeed files MUST be published via and fetched using HTTPS

   [RFC9110].



It is interesting that the geofeed files MUST be fetched using HTTPS, but 
earlier the RIR's FTP SHOULD be used to gather the geofeed references.  
Presumably if the RIR data was available via HTTPS that could also be used?





(4) p 11, sec 9.  Security Considerations



   The consumer of geofeed data SHOULD fetch and process the data

   themselves.  Importing datasets produced and/or processed by a third-

   party places ill-advised trust in the third-party.



This feels like quite a strong statement to make, and I wonder whether it won't 
be better to just point out the risks of using a third-party and then allow the 
reader to decide whether to accept that risk?







Nit level comments:



(5) p 7, sec 5.  Authenticating Geofeed Data (Optional)



   Identifying the private key associated with the certificate and

   getting the department that controls the private key (which might be

   stored in a Hardware Security Module (HSM)) to generate the CMS

   signature is left as an exercise for the implementor.  On the other

   hand, verifying the signature has no similar complexity; the

   certificate, which is validated in the public RPKI, contains the

   needed public key.  The RPKI trust anchors for the RIRs are expected

   to already be available to the party performing signature validation.

   Validation of the CMS signature over the geofeed file involves:



involves: => "involves the following steps:", or you need to change back Obtain 
... => Obtaining ..., etc.

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

Re: [OPSAWG] [Technical Errata Reported] RFC2865 (6915)

[Rob Wilton (rwilton)]

Hi RFC 2865 authors, OPSAWG, 

I think that this errata may be valid, but given the age of the RADIUS 
protocol, and the fact that I'm not familiar with it and this is a change to 
the protocol, then I'm somewhat concerned with verifying this errata, and hence 
I propose to move it to "Held for Document Update".

Does anyone have any comments on this proposed resolution?

Regards,
Rob


> -Original Message-
> From: RFC Errata System 
> Sent: Saturday, April 2, 2022 6:23 PM
> To: c...@telemancy.com; a...@merit.edu; wsimp...@greendragon.com;
> st...@livingston.com; war...@kumari.net; Rob Wilton (rwilton)
> 
> Cc: olegpekar2...@gmail.com; rfc-edi...@rfc-editor.org
> Subject: [Technical Errata Reported] RFC2865 (6915)
> 
> The following errata report has been submitted for RFC2865,
> "Remote Authentication Dial In User Service (RADIUS)".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6915
> 
> --
> Type: Technical
> Reported by: Oleg Pekar 
> 
> Section: 5
> 
> Original Text
> -
>   The Value field is zero or more octets and contains information
>   specific to the Attribute.
> 
> Corrected Text
> --
>   The Value field is one or more octets and contains information
>   specific to the Attribute.
> 
> Notes
> -
> Section "5. Attributes" is ambiguous when it talks about the attribute value
> size:
> 
> First it says: "The Value field is zero or more octets", then it provides 5
> possible value data types none of which allows a zero length value. For 'text'
> type it says: "Text of length zero (0) MUST NOT be sent; omit the entire
> attribute instead" and the same for 'string' type.
> 
> Section "5.26. Vendor-Specific" also says about the value of a vendor-specific
> attribute "The String field is one or more octets".
> 
> Thus the RFC allows empty values for attributes in general but prohibits for
> any declared types of the attributes.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --
> RFC2865 (draft-ietf-radius-radius-v2-06)
> --
> Title   : Remote Authentication Dial In User Service (RADIUS)
> Publication Date: June 2000
> Author(s)   : C. Rigney, S. Willens, A. Rubens, W. Simpson
> Category: DRAFT STANDARD
> Source  : Remote Authentication Dial-In User Service
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Editorial Errata Reported] RFC8907 (7754)

[Rob Wilton (rwilton)]

Hi Rebecca, authors, OPSAWG,

I think that this errata is valid for both 5.1 and 6.1.  I also noted a similar 
bug for 5.3 for the user_msg_len field.  I’ve updated the errata report to also 
cover this.  My intent is verify this errata.

Authors, OPSAWG, please let me know if you have any opinion on this.

Regards,
Rob



From: Rebecca VanRheenen 
Date: Wednesday, 10 January 2024 at 17:34
To: Rob Wilton (rwilton) 
Cc: jpaul...@gmail.com , thorstend...@google.com 
, and...@ota.si , Douglas Gash 
(dcmgash) , car...@ipsec.org , 
lol.gr...@gmail.com , opsawg@ietf.org , 
RFC Editor 
Subject: Re: [Editorial Errata Reported] RFC8907 (7754)
Hi Robert,

We are unable to verify this erratum that the submitter marked as editorial, so 
we changed the Type to “Technical”. As Stream Approver, please review and set 
the Status and Type accordingly (see the definitions at 
https://www.rfc-editor.org/errata-definitions/).

Note: A similar issue appears in Section 5.1 (perhaps “user field” here should 
also read “rem_addr” field):

  The rem_addr_len indicates the length of the user
  field, in bytes.

You may review the report at:
https://www.rfc-editor.org/errata/eid7754

Information on how to verify errata reports can be found at:
https://www.rfc-editor.org/how-to-verify/

Further information on errata can be found at:
https://www.rfc-editor.org/errata.php

Thank you.

RFC Editor/rv


> On Jan 10, 2024, at 4:36 AM, RFC Errata System  
> wrote:
>
> The following errata report has been submitted for RFC8907,
> "The Terminal Access Controller Access-Control System Plus (TACACS+) 
> Protocol".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7754
>
> --
> Type: Editorial
> Reported by: Joao Fracarolli 
>
> Section: 6.1
>
> Original Text
> -
> The rem_addr_len indicates the length of the port field, in bytes.
>
> Corrected Text
> --
> The rem_addr_len indicates the length of the rem_addr field, in bytes.
>
> Notes
> -
> Substitute "port field" with "rem_addr field"
>
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --
> RFC8907 (draft-ietf-opsawg-tacacs-18)
> --
> Title   : The Terminal Access Controller Access-Control System 
> Plus (TACACS+) Protocol
> Publication Date: September 2020
> Author(s)   : T. Dahm, A. Ota, D.C. Medway Gash, D. Carrel, L. Grant
> Category: INFORMATIONAL
> Source  : Operations and Management Area Working Group
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update

[Rob Wilton (rwilton)]

Hi Joe,

They should be flagged at last-call, and normally I think that the tooling 
should spot these and flag these automatically.

If you can remind me after the AD review and perhaps put them in the shepherd 
writeup (whoever the shepherd is) that would help me check that they are listed 
correctly for this bis document.

I have to confess that I'm not completely bought in to the necessity/merit of 
calling out these down refs at last call in that I'm convinced that anyone 
really cares ... but thanks for checking.

Thanks,
Rob


From: Joe Clarke (jclarke) 
Sent: Thursday, November 30, 2023 2:31 PM
To: Michael Richardson ; mohamed.boucad...@orange.com; 
Rob Wilton (rwilton) 
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update

Rob, can you comment on this with respect to 9092 and the intent for this bis?

Thanks.

Joe

On 11/30/23, 09:24, "Michael Richardson" 
mailto:mcr+i...@sandelman.ca>> wrote:

mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote:
> I guess Rob has to call this out in the last call; please see RFC8067:

>   For Standards Track or BCP documents requiring normative
> reference to documents of lower maturity, the normal IETF Last Call
> procedure will be issued, with the need for the downward reference
> explicitly documented in the Last Call itself.  Any community comments
> on the appropriateness of downward references will be considered by the
> IESG as part of its deliberations.

Yes, but it seems that this didn't happen when RFC9092 went through Last Call, 
and some of
those references are occuring again.

--
Michael Richardson mailto:mcr+i...@sandelman.ca>>, 
Sandelman Software Works
-= IPv6 IoT consulting =-  *I*LIKE*TRAINS*




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

[OPSAWG] Aiming to charter a new "Network Management Operations" WG

[Rob Wilton (rwilton)]

Hi,

I just wanted to let everyone know that I'm trying to charter a new "Network 
Management Operations" WG.  We are in the process of discussing the charter 
scope, WG name, and initial work, currently on the ne...@ietf.org open mailing 
list.  I'm hoping to get put a draft version of the charter in the Datatracker 
by this Thursday so that it can be considered by the IESG next Thursday.

Please join this list if you are potentially interested in the new work 
(although, it seems fairly likely that the working group will get chartered 
with a different name and email address).

If you would like to see what has been discussed so far, then please look at 
the archives here: https://mailarchive.ietf.org/arch/browse/netmo/, and in 
particular the outline of my plan here: 
https://mailarchive.ietf.org/arch/msg/netmo/xgkZ1hqYnndqlIYFMXmk6pn_l_s/, and 
details of the initial charter here: 
https://mailarchive.ietf.org/arch/msg/netmo/i9d4SqPtbGJmU0KZtauC3YTJFbE/

Regards,
Rob

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

Re: [OPSAWG] [Technical Errata Reported] RFC3413 (7694)

[Rob Wilton (rwilton)]

Hi Blake,

Thanks for the extra context.  Generally, IETF has a high bar for what it will 
accept as errata, particularly if it looks like it could have a high impact, 
and particularly when the RFC in question is now so old, and I generally err on 
the side of caution!

For me to mark this errata as verified then I need to determine that this is a 
mistake or omission and that the text that you suggest is what the WG intended 
and had consensus for at the time when the draft was approved for publication.  
If there is doubt or ambiguity then another choice is “hold for document 
update” which effectively says that this should be considered for a future 
revision of this RFC, if that occurs.  The third choice is that the errata is 
rejected, which would occur if the consensus was that the current text is 
correct.

Regards,
Rob


From: Nemura, Blake 
Sent: Thursday, November 2, 2023 2:57 PM
To: Rob Wilton (rwilton) ; mu...@tislabs.com; 
d...@enterasys.com; opsawg@ietf.org; Jürgen Schönwälder 
; Randy Presuhn 

Subject: RE: [Technical Errata Reported] RFC3413 (7694)

I went through entire STD 62 to try to determine how notInView case is supposed 
to be handled, and this seemed to me (and my team implementing SNMPv3 in our 
products), based on the combination of multiple related RFCs referenced, to be 
the most appropriate and logical choice.

However, the main point of this erratum is just that it is not clear; the 
notInView error case handling is not defined.

If the authors/experts feel a different error-status or handling is more 
appropriate, such as to explicitly add it into the otherError case and result 
in a genErr error-status, that could be okay too. Although that would seem to 
conflict with RFC3416 4.2.5 (1), and otherwise the only explicit noAccess 
error-status case is in usmUserOwnAuth/PrivKeyChange descriptions.

Thank you for your consideration of this report.

Best,
Blake

From: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>
Sent: Thursday, November 02, 2023 5:47 AM
To: mu...@tislabs.com<mailto:mu...@tislabs.com>; 
d...@enterasys.com<mailto:d...@enterasys.com>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>; Jürgen Schönwälder 
mailto:jschoenwaelder@constructor.university>>;
 Randy Presuhn 
mailto:randy_pres...@alumni.stanford.edu>>
Cc: Nemura, Blake mailto:bnem...@zebra.com>>
Subject: RE: [Technical Errata Reported] RFC3413 (7694)

Hi, I would appreciate input from the authors, and SNMP experts on how they 
think this errata should be processed please. I've looked at the appropriate 
sections of the RFC, but it isn't clear to me whether this errata is valid or 
not and I'm
ZjQcmQRYFpfptBannerStart
External Sender
This message came from outside our organization. Please use caution before 
acting on the message.
ZjQcmQRYFpfptBannerEnd

Hi,



I would appreciate input from the authors, and SNMP experts on how they think 
this errata should be processed please.  I've looked at the appropriate 
sections of the RFC, but it isn't clear to me whether this errata is valid or 
not and I'm slightly nervous of making what could amount to quite a significant 
change to the external API.



Regards,

Rob





-Original Message-

From: RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>>

Sent: Thursday, November 2, 2023 4:53 AM

To: war...@kumari.net<mailto:war...@kumari.net>; Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>>; 
mu...@tislabs.com<mailto:mu...@tislabs.com>; 
d...@enterasys.com<mailto:d...@enterasys.com>

Cc: bnem...@zebra.com<mailto:bnem...@zebra.com>; 
rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>

Subject: [Technical Errata Reported] RFC3413 (7694)



The following errata report has been submitted for RFC3413,

"Simple Network Management Protocol (SNMP) Applications".



--

You may review the report below and at:

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_errata_eid7694=DwIGaQ=Qwsh1H-X9ypOoLLEcAIltRyC0Dw0FG3Mmyd56ahml5w=lPfzzfb7P6JnRX7KHetEnJUQ73Ip0b_Gi7F4Es-CoMM=XArDtevwDu4lwoJL71VdxN4YHBEPEAvGTIXqiqw5T7-iSHPtALuezSsr8ZeqYVoH=T_Fz_YiP1BwpFqeQ7SJnmPMbef3POGY0UxjzXGRq9Gs=



--

Type: Technical

Reported by: Blake Nemura mailto:bnem...@zebra.com>>



Section: 3.2



Original Text

-

   - If the isAccessAllowed ASI returns a noSuchView, noAccessEntry,

 or noGroupName error, processing of the management operation is

 halted, a PDU value is constructed using the values from the

 originally received PDU, but replacing the error-status with an

 authorizationError code, and error-index value of 0, and

 control is passed to step (6) below.



   - If the isAccessAllowed ASI returns an otherError, processing of

 the management operation is halted, a different PDU value is

 constructed using t

Re: [OPSAWG] [Technical Errata Reported] RFC3413 (7694)

[Rob Wilton (rwilton)]

Hi,

I would appreciate input from the authors, and SNMP experts on how they think 
this errata should be processed please.  I've looked at the appropriate 
sections of the RFC, but it isn't clear to me whether this errata is valid or 
not and I'm slightly nervous of making what could amount to quite a significant 
change to the external API.

Regards,
Rob


-Original Message-
From: RFC Errata System  
Sent: Thursday, November 2, 2023 4:53 AM
To: war...@kumari.net; Rob Wilton (rwilton) ; 
mu...@tislabs.com; d...@enterasys.com
Cc: bnem...@zebra.com; rfc-edi...@rfc-editor.org
Subject: [Technical Errata Reported] RFC3413 (7694)

The following errata report has been submitted for RFC3413,
"Simple Network Management Protocol (SNMP) Applications".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7694

--
Type: Technical
Reported by: Blake Nemura 

Section: 3.2

Original Text
-
   - If the isAccessAllowed ASI returns a noSuchView, noAccessEntry,
 or noGroupName error, processing of the management operation is
 halted, a PDU value is constructed using the values from the
 originally received PDU, but replacing the error-status with an
 authorizationError code, and error-index value of 0, and
 control is passed to step (6) below.

   - If the isAccessAllowed ASI returns an otherError, processing of
 the management operation is halted, a different PDU value is
 constructed using the values from the originally received PDU,
 but replacing the error-status with a genError code and the
 error-index with the index of the failed variable binding, and
 control is passed to step (6) below.

Corrected Text
--
   - If the isAccessAllowed ASI returns a notInView error for a
 Write-Class viewType (e.g. for a SetRequest-PDU), processing
 of the management operation is halted, a different PDU value is
 constructed using the values from the originally received PDU,
 but replacing the error-status with a noAccess code and the
 error-index with the index of the failed variable binding, and
 control is passed to step (6) below.

   - If the isAccessAllowed ASI returns a noSuchView, noAccessEntry,
 or noGroupName error, processing of the management operation is
 halted, a PDU value is constructed using the values from the
 originally received PDU, but replacing the error-status with an
 authorizationError code, and error-index value of 0, and
 control is passed to step (6) below.

   - If the isAccessAllowed ASI returns an otherError, processing of
 the management operation is halted, a different PDU value is
 constructed using the values from the originally received PDU,
 but replacing the error-status with a genError code and the
 error-index with the index of the failed variable binding, and
 control is passed to step (6) below.

Notes
-
RFC3415, Section 3, defines 6 distinct errorIndication types for the 
isAccessAllowed ASI: notInView, noSuchView, noSuchContext, noGroupName, 
noAccessEntry, and otherError.

Whereas RFC3413 does not define handling of the notInView error. Whereby one 
might, presumably mistakenly, assume that notInView should be handled as "an 
otherError". However otherError is a distinct errorIndication for "undefined 
error" (presumably as a catch-all for possible implementation-level errors), 
whereas notInView is a defined error.

Additionally, RFC3416, Section 4.2.5, and only for SetRequest-PDU, clearly 
defines noAccess error-status as the first-priority validation check for 
"not...in the appropriate MIB view" case:
   (1)   If the variable binding's name specifies an existing or non-
 existent variable to which this request is/would be denied
 access because it is/would not be in the appropriate MIB view,
 then the value of the Response-PDU's error-status field is set
 to "noAccess", and the value of its error-index field is set to
 the index of the failed variable binding.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC3413 (draft-ietf-snmpv3-appl-v3-01)
--
Title   : Simple Network Management Protocol (SNMP) Applications
Publication Date: December 2002
Author(s)   : D. Levi, P. Meyer, B. Stewart
Category: INTERNET STANDARD

Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08

[Rob Wilton (rwilton)]

Hi Michael,

A few comments/clarifications inline ...

> -Original Message-
> From: Michael Richardson 
> Sent: Wednesday, October 18, 2023 4:37 PM
> To: Rob Wilton (rwilton) 
> Cc: opsawg@ietf.org; draft-ietf-opsawg-mud-iot-dns-considerati...@ietf.org
> Subject: Re: AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08
> 
> 
> > (10) p 12, sec 7.  Privacy Considerations
> 
> > The use of DoT and DoH eliminates the minimizes threat from passive
> > eavesdropped, but still exposes the list to the operator of the DoT
> > or DoH server.  There are additional methods, such as described by
> > [I-D.pauly-dprive-oblivious-doh].
> > The use of unencrypted (Do53) requests to a local DNS server exposes
> > the list to any internal passive eavesdroppers, and for some
> > situations that may be significant, particularly if unencrypted WiFi
> > is used.  Use of Encrypted DNS connection to a local DNS recursive
> > resolver is a preferred choice, assuming that the trust anchor for
> > the local DNS server can be obtained, such as via
> > [I-D.reddy-add-iot-byod-bootstrap].
> 
> > Presumably there should also be a recommendation to use encrypted WiFi
> too.
> 
> Well, I want to push back here on what we suggest and where.
> We can make all sorts of security suggestions, but this document is about
> DNS, not general network security.  And actually unencrypted WiFi is not a
> problem if you are using DoT/DoH!"Encrypted" Wifi through coffee-shop
> WPA-PSK is subject to trivial on-path attacks that allow for active
> eavesdropping.  I don't think this document should go there.
[Rob Wilton (rwilton)] 
Okay.


> 
> > (11) p 12, sec 7.  Privacy Considerations
> 
> > While possession of a Large (Kitchen) Appliance at a residence may be
> > uninteresting to most, possession of intimate personal devices (e.g.,
> > "sex toys") may be a cause for embarrassment.
> 
> > Not sure whether the example is needed here, but don't object if you
> > want to keep it.  I would change "Large (Kitchen) Appliance" to just
> > "kitchen appliance".
> 
> I said large for a reason: refridgerators do not move, while a small
> counter-top coffee maker might be loaned to neighbours or taken to/from
> office.
[Rob Wilton (rwilton)] 
Okay.


> 
> > (12) p 13, sec 8.  Security Considerations
> 
> > This document takes the view that the two requirements do not need to
> > be in conflict, but resolving the conflict requires some advance
> > planning by all parties.
> 
> > Rather than "requires some advance planning by all parties", perhaps
> > "requires careful planning on how the DNS can be safely and effectively
> > used by MUD controllers and IOT devices."
> 
> I'm using your text, but the reason I said "advance" is that it the situation
> needs to be considered when writing the code, planning the software updates,
> and exactly how DNS names are going to be used.   This needs to be done by
> the IoT vendor.
[Rob Wilton (rwilton)] 
Okay.  Maybe "careful design and planning on how"?

> 
> > (14) p 4, sec 3.1.1.  Too slow
> 
> > While subsequent connections to the same site (and subsequent packets
> > in the same flow) will not be affected if the results are cached, the
> > effects will be felt.  The ACL results can be cached for a period of
> > time given by the TTL of the DNS results, but the lookup must be
> > performed again in a number of hours to days.
> 
> > hours to days => hours or days.
> 
> No, it's not hours or days, it's >hours  (Also: it's mutually exclusive: hours xor days)
> I think that my text is correct.
[Rob Wilton (rwilton)] 
I think that your text is hard to comprehend, as is your explanation ;-)

You first comment seems to suggest that the range is between 1 hours and 23 
hours, but your second comment suggests it can be X hours or Y days.



> 
> > (24) p 8, sec 4.1.  Use of IP address literals in-protocol
> 
> > Third-party content-distribution networks (CDN) tend to use DNS names
> > in order to isolate the content-owner from changes to the
> > distribution network.
> 
> > I suggest "Finally, Third-party content-distribution ..."
> 
> fixed.
> upper-case Third? I don't think so.
[Rob Wilton (rwilton)] 
Yes, "Finally, third-party ..."

> 
> > (34) p 13, sec 8.  Security Considerations
> 
> > This document deals with conflicting Security requirements:
> 
>  

[OPSAWG] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08

[Rob Wilton (rwilton)]

Hi,

Here is my AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08.

I found quite a few cases where the grammar is incorrect, which I find somewhat 
distracting and makes the document harder to review for technical 
content/correctness.  I've flagged as many of these that I can in my review 
(and some other questions).  I've also run the text through a grammar checker 
which may highlight potential additional changes, but can also have some false 
positives (MCR, please can you check these).  Please can you post an updated 
version and then I may give it a second read before starting IETF LC.

Minor level comments:

(1) p 2, sec 1.  Introduction

 In TLS 1.3 with or without
   the use of ECH, middlebox cannot rely on SNI inspection because a
   malware could lie about the SNI and middlebox without acting as a TLS
   proxy does not have visibility into the server certificate.

I find it very hard to read/understand this sentence.

Did you mean something like:

   In TLS 1.3, with or without the use of ECH, middleboxes cannot rely on
   SNI inspection because malware could lie about the SNI.  In addition,
   middleboxes do not have visibility into the server certificate unless
   they are acting as TLS proxies.


(2) p 3, sec 1.  Introduction

   The fourth section of this document makes a series of recommendations
   ("best current practices") for manufacturers on how to use DNS, and
   IP addresses with specific purpose IoT devices.

DNS, and => DNS and


(3) p 5, sec 3.1.4.  Names can have wildcards

   github would be unable to provision all infinity of possible names
   into the PTR records.

This sentence is somewhat unclear.


(4) p 8, sec 4.1.  Use of IP address literals in-protocol

   And with any non-determistic name or address that is returned, the
   MUD controller is not challenged to validate the transaction, as it
   can not see into the communication.

I'm not sure that I understand what this paragraph is trying to convey.


(5) p 9, sec 4.2.  Use of non-deterministic DNS names in-protocol

   This in particular may apply to the location where firmware updates
   may be retrieved.

Would it be worth more explicitly stating what the proposed alternative is 
here.  I.e., to use stable URLs at well known stable domains?


(6) p 9, sec 4.3.  Use of a too inclusive DNS name

Rather than "too inclusive" perhaps consider "too generic"?


(7) p 11, sec 6.5.  Prefer DNS servers learnt from DHCP/Route Advertisements

   IoT Devices should prefer doing DNS to the network provided DNS
   servers.  Whether this is restricted to Classic DNS (Do53) or also
   includes using DoT/DoH is a local decision, but a locally provided
   DoT server SHOULD be used, as recommended by
   [I-D.reddy-add-iot-byod-bootstrap].

Should it be DoT/DoH server SHOULD be used, or do you mean to specifically 
recommend DoT over DoH here?


(8) p 11, sec 7.  Privacy Considerations

   The use of DoT and DoH eliminates the minimizes threat from passive
   eavesdropped, but still exposes the list to the operator of the DoT
   or DoH server.  There are additional methods, such as described by
   [I-D.pauly-dprive-oblivious-doh].

This reference can be updated to RFC 9230.


(9) p 11, sec 7.  Privacy Considerations

   The use of DoT and DoH eliminates the minimizes threat from passive
   eavesdropped, but still exposes the list to the operator of the DoT
   or DoH server.  There are additional methods, such as described by
   [I-D.pauly-dprive-oblivious-doh].

"... eliminates the threat from passive eavesdroppers, ..."


(10) p 12, sec 7.  Privacy Considerations

   The use of DoT and DoH eliminates the minimizes threat from passive
   eavesdropped, but still exposes the list to the operator of the DoT
   or DoH server.  There are additional methods, such as described by
   [I-D.pauly-dprive-oblivious-doh].
   The use of unencrypted (Do53) requests to a local DNS server exposes
   the list to any internal passive eavesdroppers, and for some
   situations that may be significant, particularly if unencrypted WiFi
   is used.  Use of Encrypted DNS connection to a local DNS recursive
   resolver is a preferred choice, assuming that the trust anchor for
   the local DNS server can be obtained, such as via
   [I-D.reddy-add-iot-byod-bootstrap].

Presumably there should also be a recommendation to use encrypted WiFi too.


(11) p 12, sec 7.  Privacy Considerations

   While possession of a Large (Kitchen) Appliance at a residence may be
   uninteresting to most, possession of intimate personal devices (e.g.,
   "sex toys") may be a cause for embarrassment.

Not sure whether the example is needed here, but don't object if you want to 
keep it.  I would change "Large (Kitchen) Appliance" to just "kitchen 
appliance".


(12) p 13, sec 8.  Security Considerations

   This document takes the view that the two requirements do not need to
   be in conflict, but resolving the conflict requires some advance
   planning by all 

Re: [OPSAWG] AD review of draft-ietf-opsawg-rfc7125-update-03

[Rob Wilton (rwilton)]

Hi Med,



I think this is pretty much good to go except for some funny line wrapping and 
indentation.  It is probably worth fixing that in a -05 and then I'll kick off 
IETF LC.


I.e.



Note also that [TCP-FLAGS] indexes the bit offset from the

  most-significant



  bit of octet 12 to the least-significant bit of octet 13 in the

  TCP header,



Boucadair Expires 14 April 2024 [Page 4]

Internet-DrafttcpControlBits IPFIX  October 2023



  but the tcpControlBits is encoded as a regular unsigned 16 bit

  integer.  For example, a tcpControlBits Information Element set to

 0x90 is used to report TCP control bits for a segment that has

 CWR (Congestion Window Reduced) and ACK flag bits set (that is,

 bit offset positions 8 and 11).



 MSB   LSB

  1

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 |0|0|0|0|0|0|0|0|1|0|0|1|0|0|0|0|

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thanks,

Rob





-Original Message-
From: mohamed.boucad...@orange.com 
Sent: Thursday, October 12, 2023 1:40 PM
To: Rob Wilton (rwilton) ; opsawg@ietf.org; 
draft-ietf-opsawg-rfc7125-update@ietf.org
Subject: RE: AD review of draft-ietf-opsawg-rfc7125-update-03



Hi Rob,



Thanks for the follow up.



Looks good to me. This is now fixed in draft-ietf-opsawg-rfc7125-update-04 
which is available online.



Thanks.



Cheers,

Med



> -Message d'origine-

> De : Rob Wilton (rwilton) mailto:rwil...@cisco.com>>

> Envoyé : jeudi 12 octobre 2023 12:53

> À : BOUCADAIR Mohamed INNOV/NET 
> mailto:mohamed.boucad...@orange.com>>;

> opsawg@ietf.org<mailto:opsawg@ietf.org>; 
> draft-ietf-opsawg-rfc7125-update@ietf.org<mailto:draft-ietf-opsawg-rfc7125-update@ietf.org>

> Objet : RE: AD review of draft-ietf-opsawg-rfc7125-update-03

>

> Hi Med,

>

> I still think that there needs to be a more explicit statement.  E.g.,

> the description of the tcpControlBits talks about setting it to one if

> the bit is set, and then references the "TCP Header Flags".  So I

> think that you should add something like the following:

> "Note, the TCP-FLAGs registry indexes the bit offset from the most-

> significant-bit of octet 12 to the least-significant bit of octet 13

> in the TCP header, but the tcpControlBits are encoded as a regular

> unsigned 16 bit integer"  ... then you could include your example.

> ... I think that it would also be helpful for you example to indicate

> what value would actually be seen on the wire in the IPFIX export for

> the example that you give.

>

> Thanks,

> Rob

>

>

> -Original Message-

> From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
> mailto:mohamed.boucad...@orange.com>>

> Sent: Wednesday, October 11, 2023 5:07 PM

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

> ietf-opsawg-rfc7125-update@ietf.org<mailto:ietf-opsawg-rfc7125-update@ietf.org>

> Subject: RE: AD review of draft-ietf-opsawg-rfc7125-update-03

>

> Hi Rob,

>

> Thanks for the review.

>

> I agree having an example is useful to avoid that bit offset is

> interpreted as bit value.

>

> We do having the following in the introduction to basically say that

> we are echoing what is in RFC9293 about the meaning of offet:

>

>Also, Section 6 of [RFC9293] introduces

>"Bit Offset" to ease referencing each header flag's offset within

> the

>16-bit aligned view of the TCP header (Figure 1 of [RFC9293]).

>

> A PR to take into account your review can be seen at:

> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith

> ub.com%2Fboucadair%2F-ipfix-rfc7125-

> update%2Fpull%2F4%2Ffiles=05%7C01%7Cmohamed.boucadair%40orange.co

> m%7C57ac4a1dc23840a993b508dbcb11670b%7C90c7a20af34b40bfbc48b9253b6f5d2

> 0%7C0%7C0%7C638327047822387444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA

> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C

> ata=9Q8QZr9caqNRiFtQgHLNHazvlgx0hJ9fyCZnGUndMCg%3D=0. Please

> let me know if any further change is needed.

>

> Cheers,

> Med

>

> > -Message d'origine-

> > De : Rob Wilton (rwilton) mailto:rwil...@cisco.com>> 
> > Envoyé : mercredi 11

> > octobre 2023 16:39 À : opsawg@ietf.org<mailto:opsawg@ietf.org>;

> > draft-ietf-opsawg-rfc7125-update@ietf.org<mailto:draft-ietf-opsawg-rfc7125-update@ietf.org>

>

Re: [OPSAWG] AD review of draft-ietf-opsawg-rfc7125-update-03

[Rob Wilton (rwilton)]

Hi Med,

I still think that there needs to be a more explicit statement.  E.g., the 
description of the tcpControlBits talks about setting it to one if the bit is 
set, and then references the "TCP Header Flags".  So I think that you should 
add something like the following:
"Note, the TCP-FLAGs registry indexes the bit offset from the 
most-significant-bit of octet 12 to the least-significant bit of octet 13 in 
the TCP header, but the tcpControlBits are encoded as a regular unsigned 16 bit 
integer"  ... then you could include your example.
... I think that it would also be helpful for you example to indicate what 
value would actually be seen on the wire in the IPFIX export for the example 
that you give.

Thanks,
Rob


-Original Message-
From: mohamed.boucad...@orange.com  
Sent: Wednesday, October 11, 2023 5:07 PM
To: Rob Wilton (rwilton) ; opsawg@ietf.org; 
draft-ietf-opsawg-rfc7125-update@ietf.org
Subject: RE: AD review of draft-ietf-opsawg-rfc7125-update-03

Hi Rob, 

Thanks for the review. 

I agree having an example is useful to avoid that bit offset is interpreted as 
bit value. 

We do having the following in the introduction to basically say that we are 
echoing what is in RFC9293 about the meaning of offet: 

   Also, Section 6 of [RFC9293] introduces
   "Bit Offset" to ease referencing each header flag's offset within the
   16-bit aligned view of the TCP header (Figure 1 of [RFC9293]).

A PR to take into account your review can be seen at: 
https://github.com/boucadair/-ipfix-rfc7125-update/pull/4/files. Please let me 
know if any further change is needed.

Cheers,
Med

> -----Message d'origine-
> De : Rob Wilton (rwilton) 
> Envoyé : mercredi 11 octobre 2023 16:39
> À : opsawg@ietf.org; draft-ietf-opsawg-rfc7125-update@ietf.org
> Objet : AD review of draft-ietf-opsawg-rfc7125-update-03
> 
> Hi Med, WG,
> 
> Here is my AD review of draft-ietf-opsawg-rfc7125-update-03.
> 
> Moderate level comments:
> 
> (1) p 3, sec 3.  The tcpControlBits Information Element
> 
>   If exported as a single octet with reduced-size encoding, this
>   Information Element covers the low-order octet of this field
>   (i.e., bit offset positions 8 to 15) [TCP-FLAGS].  A collector
>   receiving this Information Element with reduced-size encoding
> must
>   not assume anything about the content of the four bits with bit
>   offset positions 4 to 7.
> 
> I find that I'm somewhat confused as to which octet is low-order or
> high-order and whether the actual TCP flags are indexed from 0 to 7 or
> 8 to 15, and hence what actual bit order the fields are within the
> exported IPFIX field.  I think that it would be very helpful, possibly
> by an example, to ensure that no-one can interpret this the wrong way.
> E.g.,
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ibm.com%2Fdocs%2Fen%2Fnpi%2F1.3.0%3Ftopic%3Dversions-ipfix-
> information-
> elements=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb6a953e85efa4
> 074878808dbca67cfdc%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63832
> 6319436299870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Ya911%2BVKxHs
> NYQRvDhVrlN3IpoLbcmI56et409w%2F0sA%3D=0, indexes FIN as
> having bit value 0x0001, but the TCP Header Flags registry indicates
> that the Bit Offset is 15, so I would naturally assume that it has the
> value 1 << 15 ...  Would having some text to clarify this help?  And
> perhaps a concrete example of what would be exported, to illustrate
> the point?
> 
> 
> 
> Minor level comments:
> 
> (2) p 0, sec
> 
>RFC 7125 revised the tcpControlBits IP Flow Information Export
>(IPFIX) Information Element that was originally defined in RFC 5102
>to reflect changes to the TCP header control bits since RFC 793.
>However, that update is still problematic for interoperability
>because some flag values were deprecated since then.
> 
> Suggest: "... because some flag values have subsequently been
> deprecated."
> 
> 
> 
> Nit level comments:
> 
> (3) p 0, sec
> 
>This document removes stale information from the IPFIX registry and
>avoiding future conflicts with the authoritative TCP Header Flags
>registry.
> 
> I suggest s/avoiding/avoids/
> 
> Regards,
> Rob


Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messa

[OPSAWG] AD review of draft-ietf-opsawg-rfc7125-update-03

[Rob Wilton (rwilton)]

Hi Med, WG,

Here is my AD review of draft-ietf-opsawg-rfc7125-update-03.

Moderate level comments:

(1) p 3, sec 3.  The tcpControlBits Information Element

  If exported as a single octet with reduced-size encoding, this
  Information Element covers the low-order octet of this field
  (i.e., bit offset positions 8 to 15) [TCP-FLAGS].  A collector
  receiving this Information Element with reduced-size encoding must
  not assume anything about the content of the four bits with bit
  offset positions 4 to 7.

I find that I'm somewhat confused as to which octet is low-order or high-order 
and whether the actual TCP flags are indexed from 0 to 7 or 8 to 15, and hence 
what actual bit order the fields are within the exported IPFIX field.  I think 
that it would be very helpful, possibly by an example, to ensure that no-one 
can interpret this the wrong way.  E.g., 
https://www.ibm.com/docs/en/npi/1.3.0?topic=versions-ipfix-information-elements,
 indexes FIN as having bit value 0x0001, but the TCP Header Flags registry 
indicates that the Bit Offset is 15, so I would naturally assume that it has 
the value 1 << 15 ...  Would having some text to clarify this help?  And 
perhaps a concrete example of what would be exported, to illustrate the point?




 



 
Minor level comments:   


 



 
(2) p 0, sec


 



 
   RFC 7125 revised the tcpControlBits IP Flow Information Export   


 
   (IPFIX) Information Element that was originally defined in RFC 5102  


 
   to reflect changes to the TCP header control bits since RFC 793. 


 
   However, that update is still problematic for interoperability   


 
   because some flag values were deprecated since then. 


 



 
Suggest: "... because some flag values have subsequently been deprecated."  


 



 

 

Re: [OPSAWG] Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: (with DISCUSS)

[Rob Wilton (rwilton)]

Hi Med,

Thanks for this.

Okay, so it is plausible that we could take the paragraph from 
draft-ietf-opsawg-ipfix-srv6-srh-13, and generalize it to describe how IPFIX 
can export multiple instances of the same EH, if they were to ever occur?

This would satisfy my desire to ensure that IPFIX can accurately exporting what 
it sees in the packet, regardless of whether those headers should really be 
there or not.

Regards,
Rob


From: mohamed.boucad...@orange.com 
Sent: 25 May 2023 19:11
To: Rob Wilton (rwilton) ; Andrew Alston - IETF 
; John Scudder 
Cc: The IESG ; draft-ietf-opsawg-ipfix-srv6-...@ietf.org; 
opsawg-cha...@ietf.org; opsawg@ietf.org
Subject: RE: Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: 
(with DISCUSS)

Hi Rob,

I fully agree with your analysis.

The good news is that the WG still have the opportunity to address the multiple 
EH occurrences case, and not specifically for the SRH case. FWIW, 
https://www.ietf.org/archive/id/draft-boucadair-opsawg-ipfix-tcpo-v6eh-02.txt 
defines this NEW IE:

==
3.2.  ipv6ExtensionHeaderCount Information Element

   Name:  ipv6ExtensionHeaderCount

   ElementID:  TBD2

   Description:  As per [RFC8200], IPv6 nodes must accept and attempt to
  process extension headers in occurring any number of times in the
  same packet.  This Information Element echoes the number of
  occurrences of the same EH instance in an IPv6 packet.  EH Type
  values are taken from [IPv6-EH].
==

The occurrences are displayed per EH Type (aggregated) in the current version 
of the I-D. We will discuss in the WG whether/how we will export also the 
observed occurrences of Routing Types. Of course, we will send a note to 6man 
on this.

Cheers,
Med

De : Rob Wilton (rwilton) mailto:rwil...@cisco.com>>
Envoyé : jeudi 25 mai 2023 18:31
À : Andrew Alston - IETF 
mailto:andrew-ietf=40liquid.t...@dmarc.ietf.org>>;
 John Scudder mailto:j...@juniper.net>>; BOUCADAIR Mohamed 
INNOV/NET mailto:mohamed.boucad...@orange.com>>
Cc : The IESG mailto:i...@ietf.org>>; 
draft-ietf-opsawg-ipfix-srv6-...@ietf.org<mailto:draft-ietf-opsawg-ipfix-srv6-...@ietf.org>;
 opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>
Objet : RE: Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: 
(with DISCUSS)

Hi,

I don't think that John's example is quite the same.  The IPv6 packet header 
format only has a space for a single source address and it is 16 bytes long.  
Two source addresses or a 20-byte address is clearly an invalid IPv6 packet 
because it doesn't match the IPv6 packet format.

But I don't think that this is quite true for IPv6 extension headers, where the 
text states:

   Each extension header should occur at most once, except for the
   Destination Options header, which should occur at most twice (once
   before a Routing header and once before the upper-layer header).

But it also states in the same section:


   IPv6 nodes must accept and attempt to process extension headers in

   any order and occurring any number of times in the same packet,

   except for the Hop-by-Hop Options header, which is restricted to

   appear immediately after an IPv6 header only.  Nonetheless, it is

   strongly advised that sources of IPv6 packets adhere to the above

   recommended order until and unless subsequent specifications revise

   that recommendation.

This second paragraph, which is just as normative as the first, seems to 
clearly indicate that IPv6 nodes are expected to handle and process extension 
headers occurring multiple times, implying that they could occur.

Hence, I suspect that it is this second paragraph as to why Thomas was trying 
to define how IPFIX works if this scenario is encountered in the wild.  E.g., 
operationally, it is better to report what you actually see rather report what 
the operator/client ideally wants to believe is in the packet.  I.e., if your 
IPv6 node does receive a packet with two SRv6 headers (which I still believe 
RFC 8200 allows for), and modulo Jim's argument that this is invalid, then I 
would still argue that it is more helpful to report that they are both there 
than just reporting the first one and ignoring the second.  YANG NMDA, RFC 8342 
is designed similarly.  Even if a YANG list states that it can only contain 2 
elements, but due to some (presumably buggy) reason, the device actually has 3, 
it is better to report all three than just pretend that there are only 2 
elements, because it helps the operator debug that something is going wrong 
(section 5.3).

I would argue that Jim's argument that another SRv6 related RFC (I don't know 
which one) clearly indicates that a v6 header can only ever contain a single 
SRH header holds a little more sway and is perhaps more relevant.

Having said all that, I think that point is somewhat moot because I think that 
the authors have agreed to remove this paragraph anyway - ev

Re: [OPSAWG] Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: (with DISCUSS)

[Rob Wilton (rwilton)]

Hi,

I don't think that John's example is quite the same.  The IPv6 packet header 
format only has a space for a single source address and it is 16 bytes long.  
Two source addresses or a 20-byte address is clearly an invalid IPv6 packet 
because it doesn't match the IPv6 packet format.

But I don't think that this is quite true for IPv6 extension headers, where the 
text states:

   Each extension header should occur at most once, except for the
   Destination Options header, which should occur at most twice (once
   before a Routing header and once before the upper-layer header).

But it also states in the same section:


   IPv6 nodes must accept and attempt to process extension headers in

   any order and occurring any number of times in the same packet,

   except for the Hop-by-Hop Options header, which is restricted to

   appear immediately after an IPv6 header only.  Nonetheless, it is

   strongly advised that sources of IPv6 packets adhere to the above

   recommended order until and unless subsequent specifications revise

   that recommendation.

This second paragraph, which is just as normative as the first, seems to 
clearly indicate that IPv6 nodes are expected to handle and process extension 
headers occurring multiple times, implying that they could occur.

Hence, I suspect that it is this second paragraph as to why Thomas was trying 
to define how IPFIX works if this scenario is encountered in the wild.  E.g., 
operationally, it is better to report what you actually see rather report what 
the operator/client ideally wants to believe is in the packet.  I.e., if your 
IPv6 node does receive a packet with two SRv6 headers (which I still believe 
RFC 8200 allows for), and modulo Jim's argument that this is invalid, then I 
would still argue that it is more helpful to report that they are both there 
than just reporting the first one and ignoring the second.  YANG NMDA, RFC 8342 
is designed similarly.  Even if a YANG list states that it can only contain 2 
elements, but due to some (presumably buggy) reason, the device actually has 3, 
it is better to report all three than just pretend that there are only 2 
elements, because it helps the operator debug that something is going wrong 
(section 5.3).

I would argue that Jim's argument that another SRv6 related RFC (I don't know 
which one) clearly indicates that a v6 header can only ever contain a single 
SRH header holds a little more sway and is perhaps more relevant.

Having said all that, I think that point is somewhat moot because I think that 
the authors have agreed to remove this paragraph anyway - even if IMO it 
possibly makes the spec a bit less robust/helpful.

Regards,
Rob


From: iesg  On Behalf Of Andrew Alston - IETF
Sent: 25 May 2023 16:54
To: John Scudder ; mohamed.boucad...@orange.com
Cc: The IESG ; draft-ietf-opsawg-ipfix-srv6-...@ietf.org; 
opsawg-cha...@ietf.org; opsawg@ietf.org
Subject: Re: Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: 
(with DISCUSS)

Hi Med,

Firstly - I need to second what John said below.  Secondly, while we can agree 
that IPFIX supporting this doesn't violate the RFC - what it does do - is cater 
explicitly for what I believe is a violation of RFC8200, and that is where I 
have a problem.

While there could be *many* things that are done out of spec - unless there is 
a very specific and solid reason to cater for such out of spec behavior, this 
doesn't make sense to pick and choose the out of spec we are agreeing to 
suddenly cater for.

Thanks

Andrew


From: John Scudder mailto:j...@juniper.net>>
Date: Thursday, 25 May 2023 at 16:33
To: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Cc: Andrew Alston - IETF 
mailto:andrew-i...@liquid.tech>>, The IESG 
mailto:i...@ietf.org>>, 
draft-ietf-opsawg-ipfix-srv6-...@ietf.org
 
mailto:draft-ietf-opsawg-ipfix-srv6-...@ietf.org>>,
 opsawg-cha...@ietf.org 
mailto:opsawg-cha...@ietf.org>>, 
opsawg@ietf.org 
mailto:opsawg@ietf.org>>
Subject: Re: Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: 
(with DISCUSS)
Hi Med,

Not my DISCUSS, but... I did take a look at that thread earlier and found it 
somewhat unsatisfying. In particular, I find it a little odd that we feel the 
need to cover this particular out-of-spec behavior with IPFIX but not others - 
to take some extreme examples, how would IPFIX handle a packet with two source 
addresses? A packet with a 20-byte destination address? You can tell me that 
these aren't possible so it doesn't need to handle them, but that's the point 
(as I understand it).

$0.02,

-John

> On May 25, 2023, at 9:14 AM, 
> mohamed.boucad...@orange.com wrote:
>
> Hi Andrew,
>
> (replying as the doc shepherd)
>
> Éric raised a similar comment. I shared already some context about that 
> section: 

Re: [OPSAWG] AD review for draft-ietf-opsawg-ipfix-srv6-srh-07

[Rob Wilton (rwilton)]

Hi Benoit, authors,

Thanks for the updates - they look good to me.  I've requested IETF last call 
on -08.

Regards,
Rob


-Original Message-
From: Benoit Claise  
Sent: 27 March 2023 01:45
To: Rob Wilton (rwilton) ; 
draft-ietf-opsawg-ipfix-srv6-srh@ietf.org; opsawg@ietf.org
Subject: Re: AD review for draft-ietf-opsawg-ipfix-srv6-srh-07

Hi Rob,

Thanks for your review. We posted a new draft version.

Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh
Diff:https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-08

See inline for some replies.

Regards, Benoit on behalf of the authors.
On 3/22/2023 6:55 PM, Rob Wilton (rwilton) wrote:
> Hi,
>
> Thanks for this document.  Here are my AD review comments for 
> draft-ietf-opsawg-ipfix-srv6-srh-07.  There is an obvious disclaimer here 
> that I'm not an IPFIX expert, and I appreciate that one of the authors is ;-).
>
>   
> Moderate level comments:
>   
>   
>   
> 
> (1) p 4, sec 3.  IPFIX Information Elements
>   
>   
>   
> 
> srhIPv6Section
>Exposes the SRH and its TLVs as specified in Section 2 of
>[RFC8754] as series of n octets in IPFIX.
>   
>   
>   
> 
> It isn't clear to me exactly what this is?  Does this cover the whole SRH, or 
> just the "SRH TLVs" section?  From looking at the examples, I think that this 
> exposes the whole SRH, in which case, I think that the description could be 
> clearer.
Right, we added  a reference RFC 8754 section 2.1, next to 2.
> Please can you also update the description in the IANA section.
>   
>   
>   
> 
>   
>   
>   
> 
> (2) p 12, sec 5.11.  srhSegmentIPv6EndpointBehavior
>
> ElementID:  TBD11
> Description:  The 16-bit SRv6 Endpoint behavior.  Assigned values and
>their meanings are provided in the "SRV6 Endpoint Behavior" IANA
>registry [IANA-IPFIX].
>
> Is this linking to the right reference?  It looks like this should be the 
> SRv6 IANA registry rather than the IPFIX registry.
Good catch. You are right.
To be consistent with 
https://datatracker.ietf.org/doc/draft-boucla-opsawg-ipfix-fixes/, we 
changed it to.

srhSegmentIPv6EndpointBehavior

ElementID:  TBD11
Description:  The 16-bit SRv6 Endpoint behavior. Assigned values and their
   meanings are provided in the "SRV6 Endpoint Behavior" registry.

Abstract Data Type:  unsigned16

Data Type Semantics:  identifier

Additional Information:  See the "SRV6 Endpoint Behavior" registry at
   
https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#srv6-endpoint-behaviors.
   Section 4 of RFC8986.


> Minor level comments:
>
> (3) p 4, sec 3.  IPFIX Information Elements
>
> srhSegmentIPv6BasicList
>Ordered basicList [RFC6313] of zero or more 128-bit IPv6 addresses
>in the SRH that represents the SRv6 segment list.  As specified in
>Section 2 of [RFC8754], the Segment List is encoded starting from
>the last segment of the SR Policy.  That is, the first element of
>the Segment List (Segment List[0]) contains the last segment of
>the SR Policy, the second element contains the penultimate segment
>of the SR Policy, and so on.
>
> In terms of naming, I note that the "IPv6" seems to turn up in difference 
> places in the IEs defined in this draft.  It might be awkward to change, but 
> wouldn't the names be more consistent (e.g., with RFC8754), if they put IPv6 
> all in the same place?  

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

[Rob Wilton (rwilton)]

Hi Ken, Joe, OPSAWG,

Thank you all for your work and reviews of this document.

This document has now been approved and moves on to the RFC editor queue.

Regards,
Rob


From: Kenneth Vaughn 
Sent: 31 March 2023 00:33
To: opsawg@ietf.org; Joe Clarke (jclarke) ; Rob Wilton 
(rwilton) 
Cc: i-d-annou...@ietf.org; Amanda Baber via RT 
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-14.txt

I believe this version of the document addresses all concerns. The approach 
taken to reference the registry was accepted as is, so the only changes in this 
version was to convert textual references to RFC 8446 and RFC9150 to xref links 
and to add RFC 9150 to the list of informative references at the end of the 
document.

The document should be ready to submit back to IANA for their approval; I've 
included Amanda on the email, but I assume the formal release needs to come 
from Joe (or perhaps Rob since the web site shows him as the action owner).

Regards,
Ken Vaughn

Trevilon LLC
1060 S Hwy 107
Del Rio, TN 37727
+1-571-331-5670 cell
kvau...@trevilon.com<mailto:kvau...@trevilon.com>
www.trevilon.com<http://www.trevilon.com>


On Mar 30, 2023, at 7:18 PM, 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Operations and
Management Area Working Group (OPSAWG) WG of the IETF.

  Title   : Updates to the TLS Transport Model for SNMP
  Author  : Kenneth Vaughn
  Filename: draft-ietf-opsawg-tlstm-update-14.txt
  Pages   : 34
  Date: 2023-03-30

Abstract:
  This document updates RFC 6353 "Transport Layer Security (TLS)
  Transport Model for the Simple Network Management Protocol (SNMP)",
  to reflect changes necessary to support Transport Layer Security
  Version 1.3 (TLS 1.3) and Datagram Transport Layer Security Version
  1.3 (DTLS 1.3), which are jointly known as "(D)TLS 1.3".  This
  document is compatible with (D)TLS 1.2 and is intended to be
  compatible with future versions of SNMP and (D)TLS.

  This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tlstm-update/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-14.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tlstm-update-14

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

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

[OPSAWG] AD review for draft-ietf-opsawg-ipfix-srv6-srh-07

[Rob Wilton (rwilton)]

Hi,

Thanks for this document.  Here are my AD review comments for 
draft-ietf-opsawg-ipfix-srv6-srh-07.  There is an obvious disclaimer here that 
I'm not an IPFIX expert, and I appreciate that one of the authors is ;-).

 
Moderate level comments:


 



 
(1) p 4, sec 3.  IPFIX Information Elements 


 



 
   srhIPv6Section   


 
  Exposes the SRH and its TLVs as specified in Section 2 of 


 
  [RFC8754] as series of n octets in IPFIX. 


 



 
It isn't clear to me exactly what this is?  Does this cover the whole SRH, or 
just the "SRH TLVs" section?  From looking at the examples, I think that this 
exposes the whole SRH, in which case, I think that the description could be 
clearer.

Please can you also update the description in the IANA section. 


 



 



 
(2) p 12, sec 5.11.  srhSegmentIPv6EndpointBehavior 


 

   ElementID:  TBD11
   Description:  The 16-bit SRv6 Endpoint behavior.  Assigned values and
  their meanings are provided in the "SRV6 Endpoint Behavior" IANA
  registry [IANA-IPFIX].

Is this linking to the right reference?  It looks like this should be the SRv6 
IANA registry rather than the IPFIX registry.



Minor level comments:

(3) p 4, sec 3.  IPFIX Information Elements

   srhSegmentIPv6BasicList
  Ordered basicList [RFC6313] of zero or more 128-bit IPv6 addresses
  in the SRH that represents the SRv6 segment list.  As specified in
  Section 2 of [RFC8754], the Segment List is encoded starting from
  the last segment of the SR Policy.  That is, the first element of
  the Segment List (Segment List[0]) contains the last segment of
  the SR Policy, the second element contains the penultimate segment
  of the SR Policy, and so on.

In terms of naming, I note that the "IPv6" seems to turn up in difference 
places in the IEs defined in this draft.  It might be awkward to change, but 
wouldn't the names be more consistent (e.g., with RFC8754), if they put IPv6 
all in the same place?  I was going to suggest putting them at the start (e.g., 
ipv6srh...), but looking at https://www.iana.org/assignments/ipfix/ipfix.xhtml, 
it looks like the "IPv6" is often put at the end of the name.

E.g., srhSegmentIPv6BasicList -> srhSegmentBasicListIPv6, etc.

Note, I'm happy to defer to 

Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12

[Rob Wilton (rwilton)]

Hi Eliot,

I see that mostly the security section is really about the sensitivity of the 
data fields in the data model, and also whether those fields have default 
deny-all NACM rules.  How the data is accessed shouldn’t really matter so much 
since the same principles should apply.

However, generally for YANG documents, framing that in the context of 
NETCONF/RESTCONF and NACM makes sense, at least to me :-)

Regards,
Rob

From: Eliot Lear 
Sent: 27 February 2023 14:29
To: Rob Wilton (rwilton) ; 
draft-ietf-opsawg-sbom-access@ietf.org
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12


I do think it's worth having a broader conversation about security 
considerations of YANG models, because the very idea that YANG is tied to 
NETCONF/RESTCONF means that either we end up in these sorts of silly situations 
in which the security considerations are largely inapplicable OR we end up 
having to reinvent/tranliterate models into other languages.

Eliot
On 27.02.23 14:48, Rob Wilton (rwilton) wrote:
Hi Eliot,

Thanks.  I’ll initiate IETF LC on -14.  It is possible that the “necessarily” 
may mean that the SEC ADs will want more of the regular YANG security 
considerations to be included, but we can cross that bridge during the IESG 
review, if needed.

Regards,
Rob


From: Eliot Lear <mailto:l...@lear.ch>
Sent: 27 February 2023 13:25
To: Rob Wilton (rwilton) <mailto:rwil...@cisco.com>; 
draft-ietf-opsawg-sbom-access@ietf.org<mailto:draft-ietf-opsawg-sbom-access@ietf.org>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12


Rob:

I think it's appropriate to accept all of your proposed changes with one caveat:
On 07.02.23 14:50, Rob Wilton (rwilton) wrote:

Hi Eliot,



The only thing that I think that we need to tweak is the security section, 
where I think that we need to be more explicit that this module is not designed 
to be used by NETCONF/RESTCONF specifically to exempt you for needing regular 
YANG security considerations template text (which you don't have).



Possibly, something like this:



OLD:



   This document describes a schema for discovering the location of

   information relating to software transparency, and does not specify

   the access model for the information itself.



NEW:



   This document describes a schema for discovering the location of

   information relating to software transparency, and does not specify

   the access model for the information itself.  In particular, the YANG

   module specified in this document is not necessarily intended to be accessed 
via

   regular network management protocols, such as the NETCONF

   [RFC6241] or RESTCONF [RFC8040], and hence the regular security

   considerations for such usage are not considered here.



That is, if someone wants to play around with this with NETCONF/RESTCONF, 
there's nothing there to stop them.  Your point about intent is key, tho.

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

Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12

[Rob Wilton (rwilton)]

Hi Eliot,

Thanks.  I’ll initiate IETF LC on -14.  It is possible that the “necessarily” 
may mean that the SEC ADs will want more of the regular YANG security 
considerations to be included, but we can cross that bridge during the IESG 
review, if needed.

Regards,
Rob


From: Eliot Lear 
Sent: 27 February 2023 13:25
To: Rob Wilton (rwilton) ; 
draft-ietf-opsawg-sbom-access@ietf.org
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12


Rob:

I think it's appropriate to accept all of your proposed changes with one caveat:
On 07.02.23 14:50, Rob Wilton (rwilton) wrote:

Hi Eliot,



The only thing that I think that we need to tweak is the security section, 
where I think that we need to be more explicit that this module is not designed 
to be used by NETCONF/RESTCONF specifically to exempt you for needing regular 
YANG security considerations template text (which you don't have).



Possibly, something like this:



OLD:



   This document describes a schema for discovering the location of

   information relating to software transparency, and does not specify

   the access model for the information itself.



NEW:



   This document describes a schema for discovering the location of

   information relating to software transparency, and does not specify

   the access model for the information itself.  In particular, the YANG

   module specified in this document is not necessarily intended to be accessed 
via

   regular network management protocols, such as the NETCONF

   [RFC6241] or RESTCONF [RFC8040], and hence the regular security

   considerations for such usage are not considered here.



That is, if someone wants to play around with this with NETCONF/RESTCONF, 
there's nothing there to stop them.  Your point about intent is key, tho.

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

Re: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07

[Rob Wilton (rwilton)]

Hi Med, Alan,

Thanks.  I've requested LC on -09.

Regards,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 09 February 2023 10:32
> To: Rob Wilton (rwilton) ; Alan DeKok
> 
> Cc: draft-ietf-opsawg-add-encrypted-dns@ietf.org; opsawg@ietf.org
> Subject: RE: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07
> 
> Re-,
> 
> Thanks Rob for the follow-up.
> 
> A new version with the proposed changes is now online: https://author-
> tools.ietf.org/iddiff?url2=draft-ietf-opsawg-add-encrypted-dns-09.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) 
> > Envoyé : jeudi 9 février 2023 11:04
> > À : BOUCADAIR Mohamed INNOV/NET
> ;
> > Alan DeKok 
> > Cc : draft-ietf-opsawg-add-encrypted-dns@ietf.org;
> > opsawg@ietf.org
> > Objet : RE: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-
> > dns-07
> >
> > Hi Med, Alan,
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > 
> > > Sent: 09 February 2023 09:02
> > > To: Rob Wilton (rwilton) ; Alan DeKok
> > > 
> > > Cc: draft-ietf-opsawg-add-encrypted-dns@ietf.org;
> > opsawg@ietf.org
> > > Subject: RE: [OPSAWG] AD review of
> > > draft-ietf-opsawg-add-encrypted-dns-07
> > >
> > > Hi Rob, all,
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : Rob Wilton (rwilton)  Envoyé :
> > mercredi 8
> > > > février 2023 20:39 À : Alan DeKok 
> > Cc :
> > > > draft-ietf-opsawg-add-encrypted-dns@ietf.org;
> > > > opsawg@ietf.org
> > > > Objet : RE: [OPSAWG] AD review of draft-ietf-opsawg-add-
> > encrypted-
> > > > dns-07
> > > >
> > > > Hi Alan,
> > > >
> > > > Sorry for the delay.  Please see inline ...
> > > >
> > > > > -Original Message-
> > > > > From: Alan DeKok 
> > > > > Sent: 19 December 2022 17:13
> > > > > To: Rob Wilton (rwilton) 
> > > > > Cc: draft-ietf-opsawg-add-encrypted-dns@ietf.org;
> > > > opsawg@ietf.org
> > > > > Subject: Re: [OPSAWG] AD review of
> > > > > draft-ietf-opsawg-add-encrypted-dns-07
> > > > >
> > > > > On Dec 19, 2022, at 11:53 AM, Rob Wilton (rwilton)
> > > > >  wrote:
> > > > > > It isn't really clear to me why some of the registries are
> > > > needed,
> > > > > > specifically
> > > > > the ones in 8.4.1 and 8.4.2.  Why not allow any v4 or v6
> > DHCP
> > > > > attribute to be carried within the DHCPv6-Options or DHCPv4-
> > > > Options field?
> > > > >
> > > > >   The original intent of the document was to define a
> > limited
> > > > set of
> > > > > DHCP options which could be carried in RADIUS.  i.e. option
> > X
> > > > would
> > > > > map to RADIUS attribute Y.  After some discussion, this was
> > > > deemed to
> > > > > be unworkable, and changed to the current method.
> > > > >
> > > > >   The previous limitations were still kept, however.
> > > > >
> > > > >   While it is useful, I could see issues with allowing any
> > DHCP
> > > > option
> > > > > to be transported in RADIUS.  I'll have to dig deeper to get
> > > > into details.
> > > > [Rob Wilton (rwilton)]
> > > >
> > > > Okay.
> > > >
> > > > >
> > > > > >
> > > > > > (2) p 4, sec 3.  DHCP Options RADIUS Attributes
> > > > > >
> > > > > >   Absent any explicit configuration on the DHCP server,
> > RADIUS
> > > > supplied
> > > > > >   data by means of DHCP*-Options Attributes take
> > precedence
> > > > over any
> > > > > >   local configuration.
> > > > > >
> > > > > > This point may be worth discussing.  Naturally, I would
> > > > explicit
> > > > > > configuration
> > > > > to a network device to generally take precedent over
> > implicitly
> > > > > learned configuration from the network.
> > > > >
> > > > >  I'm

Re: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07

[Rob Wilton (rwilton)]

Hi Med, Alan,

> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 09 February 2023 09:02
> To: Rob Wilton (rwilton) ; Alan DeKok
> 
> Cc: draft-ietf-opsawg-add-encrypted-dns@ietf.org; opsawg@ietf.org
> Subject: RE: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07
> 
> Hi Rob, all,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-
> > De : Rob Wilton (rwilton) 
> > Envoyé : mercredi 8 février 2023 20:39
> > À : Alan DeKok 
> > Cc : draft-ietf-opsawg-add-encrypted-dns@ietf.org;
> > opsawg@ietf.org
> > Objet : RE: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-
> > dns-07
> >
> > Hi Alan,
> >
> > Sorry for the delay.  Please see inline ...
> >
> > > -Original Message-
> > > From: Alan DeKok 
> > > Sent: 19 December 2022 17:13
> > > To: Rob Wilton (rwilton) 
> > > Cc: draft-ietf-opsawg-add-encrypted-dns....@ietf.org;
> > opsawg@ietf.org
> > > Subject: Re: [OPSAWG] AD review of
> > > draft-ietf-opsawg-add-encrypted-dns-07
> > >
> > > On Dec 19, 2022, at 11:53 AM, Rob Wilton (rwilton)
> > >  wrote:
> > > > It isn't really clear to me why some of the registries are
> > needed,
> > > > specifically
> > > the ones in 8.4.1 and 8.4.2.  Why not allow any v4 or v6 DHCP
> > > attribute to be carried within the DHCPv6-Options or DHCPv4-
> > Options field?
> > >
> > >   The original intent of the document was to define a limited
> > set of
> > > DHCP options which could be carried in RADIUS.  i.e. option X
> > would
> > > map to RADIUS attribute Y.  After some discussion, this was
> > deemed to
> > > be unworkable, and changed to the current method.
> > >
> > >   The previous limitations were still kept, however.
> > >
> > >   While it is useful, I could see issues with allowing any DHCP
> > option
> > > to be transported in RADIUS.  I'll have to dig deeper to get
> > into details.
> > [Rob Wilton (rwilton)]
> >
> > Okay.
> >
> > >
> > > >
> > > > (2) p 4, sec 3.  DHCP Options RADIUS Attributes
> > > >
> > > >   Absent any explicit configuration on the DHCP server, RADIUS
> > supplied
> > > >   data by means of DHCP*-Options Attributes take precedence
> > over any
> > > >   local configuration.
> > > >
> > > > This point may be worth discussing.  Naturally, I would
> > explicit
> > > > configuration
> > > to a network device to generally take precedent over implicitly
> > > learned configuration from the network.
> > >
> > >  I'm not sure which options are "implicitly learned" from the
> > network.
> > > One set is configured in the device, and another is configured
> > on a
> > > per-user / per- session basis.  This allows for sane defaults,
> > with
> > > specific over-rides where those are needed.
> > >
> > >   If the options configured on the device always take precedence
> > over
> > > the per- session options (via RADIUS), then there isn't much
> > point in
> > > sending per-session options.
> > [Rob Wilton (rwilton)]
> > To give a regular configuration example, if you were to enable the
> > Ethernet auto-negotiation protocol but also explicitly configure
> > an 10/100/1000 Ethernet interface to run at 100 Mb/s then I would
> > expect the explicit client provided configuration to take
> > precedence over negotiating the speed value.
> >
> > It sounds like, in what you describe, the configuration is
> > effectively hierarchical.  I.e., it is really because the RADIUS
> > supplied configuration is more-specific that it takes precedence
> > over the local configuration.  If so, that is expected, but I
> > think that it would be helpful to clarify the description to make
> > that clear.
> >
> 
> [Med] OK. We can make this change:
> 
> OLD:
>Absent any explicit configuration on the DHCP server, RADIUS
>supplied data by means of DHCP*-Options Attributes take precedence
>over any local configuration.
> 
> NEW:
>RADIUS supplied data is specific configuration data that is
>returned as a function of authentication and authorization checks.
>As such, absent any explicit configuration on the DHCP server, RADIUS
>supplied data by means of DHCP*-Options Attributes take precedence
>over any lo

Re: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07

[Rob Wilton (rwilton)]

Hi Alan,

Sorry for the delay.  Please see inline ...

> -Original Message-
> From: Alan DeKok 
> Sent: 19 December 2022 17:13
> To: Rob Wilton (rwilton) 
> Cc: draft-ietf-opsawg-add-encrypted-dns@ietf.org; opsawg@ietf.org
> Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07
> 
> On Dec 19, 2022, at 11:53 AM, Rob Wilton (rwilton)
>  wrote:
> > It isn't really clear to me why some of the registries are needed, 
> > specifically
> the ones in 8.4.1 and 8.4.2.  Why not allow any v4 or v6 DHCP attribute to be
> carried within the DHCPv6-Options or DHCPv4-Options field?
> 
>   The original intent of the document was to define a limited set of DHCP
> options which could be carried in RADIUS.  i.e. option X would map to RADIUS
> attribute Y.  After some discussion, this was deemed to be unworkable, and
> changed to the current method.
> 
>   The previous limitations were still kept, however.
> 
>   While it is useful, I could see issues with allowing any DHCP option to be
> transported in RADIUS.  I'll have to dig deeper to get into details.
[Rob Wilton (rwilton)] 

Okay.

> 
> >
> > (2) p 4, sec 3.  DHCP Options RADIUS Attributes
> >
> >   Absent any explicit configuration on the DHCP server, RADIUS supplied
> >   data by means of DHCP*-Options Attributes take precedence over any
> >   local configuration.
> >
> > This point may be worth discussing.  Naturally, I would explicit 
> > configuration
> to a network device to generally take precedent over implicitly learned
> configuration from the network.
> 
>  I'm not sure which options are "implicitly learned" from the network.  One 
> set
> is configured in the device, and another is configured on a per-user / per-
> session basis.  This allows for sane defaults, with specific over-rides where
> those are needed.
> 
>   If the options configured on the device always take precedence over the per-
> session options (via RADIUS), then there isn't much point in sending 
> per-session
> options.
[Rob Wilton (rwilton)] 
To give a regular configuration example, if you were to enable the Ethernet 
auto-negotiation protocol but also explicitly configure an 10/100/1000 Ethernet 
interface to run at 100 Mb/s then I would expect the explicit client provided 
configuration to take precedence over negotiating the speed value.

It sounds like, in what you describe, the configuration is effectively 
hierarchical.  I.e., it is really because the RADIUS supplied configuration is 
more-specific that it takes precedence over the local configuration.  If so, 
that is expected, but I think that it would be helpful to clarify the 
description to make that clear.


> 
> > (3) p 6, sec 3.2.  DHCPv4-Options Attribute
> >
> >  Permitted DHCPv4 options in the DHCPv4-Options Attribute are
> >  maintained by IANA in the registry created in Section 8.4.2.
> >
> > Comparing this text to the description for v6, this description is silent on
> whether multiple instances of the same DHCPv4 option MAY be included.
> Should that be specified here?
> 
>   Likely, yes.  The RADIUS attributes are simply carrying DHCP options, as if 
> they
> were in a DHCP packet.  So all of the DHCP rules about option handling should
> apply here.
[Rob Wilton (rwilton)] 
Okay.

> 
> >
> > (4) p 10, sec 7.  Table of Attributes
> >
> >   The following table provides a guide as what type of RADIUS packets
> >   that may contain these attributes, and in what quantity.
> >
> > Am I right that this is just a duplication of what is described in section 
> > 3?  If
> so, perhaps change "guide" to "informative guide" and include text to refer
> back to the  canonical definition in section 3.
> 
>   Sure.  This table is traditional in RADIUS RFCs, so the text here mirrors
> previous RADIUS RFCs.
[Rob Wilton (rwilton)] 
Okay.


> 
> > (8) p 3, sec 3.  DHCP Options RADIUS Attributes
> >
> >   These attributes use the "Long Extended Type" format in order to
> >   permit the transport of attributes encapsulating more than 253 octets
> >   of data.  DHCP options that can be included in the DHCP*-Options
> >   RADIUS attributes are limited by the maximum packet size of 4096
> >   bytes.  In order to accommodate deployments with large options,
> >   implementations are RECOMMENDED to support a packet size up to 65535
> >   bytes.
> >
> > I didn't find this text clear.  E.g., limit is 4k but should support up to 
> > 64K.
> Which implementations should support larger packet sizes?  Is this RADIUS
> implementations?
> 
>   It's a limitation of RADIUS.  Everything 

Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12

[Rob Wilton (rwilton)]

Hi Eliot,

The only thing that I think that we need to tweak is the security section, 
where I think that we need to be more explicit that this module is not designed 
to be used by NETCONF/RESTCONF specifically to exempt you for needing regular 
YANG security considerations template text (which you don't have).

Possibly, something like this:

OLD:

   This document describes a schema for discovering the location of
   information relating to software transparency, and does not specify
   the access model for the information itself.

NEW:

   This document describes a schema for discovering the location of
   information relating to software transparency, and does not specify
   the access model for the information itself.  In particular, the YANG
   module specified in this document is not intended to be accessed via
   regular network management protocols, such as the NETCONF
   [RFC6241] or RESTCONF [RFC8040], and hence the regular security
   considerations for such usage are not considered here.
 
I also think that this paragraph can probably just be deleted, since there are 
no paths listed (and it also talks about edit-config, a NETCONF operation):

   There are a number of data nodes defined in this YANG module that are
   writable/creatable/deletable (i.e., config true, which is the
   default).  Write operations (e.g., edit-config) to these data nodes
   without proper protection can have a negative effect on network
   operations.  These are the subtrees and data nodes and their
   sensitivity/vulnerability:

Again, I'm not sure that we should have this paragraph since it doesn't list 
any paths, and also implies that NETCONF operations may be used:

   Some readable data nodes in this YANG module may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control read access (e.g., via get, get-config, or
   notification) to these data nodes.

Regards,
Rob

  
> >> The YANG module specified in this document defines a schema for data
> >> that is designed to be accessed via network management protocols
> >> such
> >> as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF
> >> layer
> >> is the secure transport layer, and the mandatory-to-implement secure
> >> transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF
> >> layer
> >> is HTTPS, and the mandatory-to-implement secure transport is TLS
> >> [RFC8446].



> -----Original Message-
> From: Eliot Lear 
> Sent: 12 January 2023 14:24
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-sbom-
> access@ietf.org
> Cc: opsawg@ietf.org
> Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12
> 
> Ok, this is now posted as -13.
> 
> On 06.01.23 16:28, Eliot Lear wrote:
> > Hi Rob,
> >
> > On 19.12.22 17:25, Rob Wilton (rwilton) wrote:
> >> Hi Eliot, Scott,
> >>
> >> Thanks for this document.  Here is my AD review for
> >> draft-ietf-opsawg-sbom-access-12.
> >>
> >>
> >> Moderate level comments:
> >>
> >> (1) p 3, sec 1.  Introduction
> >>
> >>     To enable application-layer discovery, this memo defines a
> >> well-known
> >>     URI [RFC8615].  Management or orchestration tools can query this
> >>     well-known URI to retrieve a system's SBOM or vulnerability
> >>     information.  Further queries may be necessary based on the content
> >>     and structure of the response.
> >>
> >> It looks like the .wellknown URI can only be used to retrieve SBOM
> >> information and not vulnerability information (unless I am missing
> >> something).
> >
> > Sorry- that's an artifact of an earlier rev.  Corrected.
> >
> >
> >>
> >>
> >> (2) p 15, sec 6.  Security Considerations
> >>
> >>     The YANG module specified in this document defines a schema for data
> >>     that is designed to be accessed via network management protocols
> >> such
> >>     as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF
> >> layer
> >>     is the secure transport layer, and the mandatory-to-implement secure
> >>     transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF
> >> layer
> >>     is HTTPS, and the mandatory-to-implement secure transport is TLS
> >>     [RFC8446].
> >>
> >> This text looks to be inconsistent with earlier parts of the
> >> document, specifically, I didn't think that the intent was to fetch
> >> this information using NETCONF or RESTCONF, but the early part of
> >> this document states that it contains groupings, which p

Re: [OPSAWG] AD review of draft-ietf-opsawg-tlstm-update-10

[Rob Wilton (rwilton)]

Hi Kenneth,

Apologies for the delay in progressing this. -11 is fine.

Just closing off a couple of questions inline below.


From: Kenneth Vaughn 
Sent: 23 December 2022 15:13
To: Rob Wilton (rwilton) 
Cc: draft-ietf-opsawg-tlstm-update@ietf.org; opsawg@ietf.org
Subject: Re: AD review of draft-ietf-opsawg-tlstm-update-10

Rob,

Thank you for your detailed comments. Please see my detailed responses inline 
below.

In general, I accepted the comments and reflected the changes in -11; the only 
two exceptions are that I did not add any requirements regarding the usage of 
hash algorithms based on prior WG discussions and I am unclear what issue you 
had with the editor's address field.

Regards,
Ken Vaughn

Trevilon LLC
1060 S Hwy 107
Del Rio, TN 37727
+1-571-331-5670 cell
kvau...@trevilon.com<mailto:kvau...@trevilon.com>
www.trevilon.com<http://www.trevilon.com>


On Dec 19, 2022, at 11:09 AM, Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:

(1) p 4, sec 2.3.  TLS Version

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

It wasn't clear to me exactly what is meant by TLSTMv1.3, and this is the only 
use of this term.  Could you be more specific here please?
I removed the "v1.3", which was erroneous text from a previous draft.


(2) p 6, sec 4.  MIB Module Definition

  Redistribution and use in source and binary forms, with or
  without modification, is permitted pursuant to, and subject
  to the license terms contained in, the Revised BSD License
  set forth in Section 4.c of the IETF Trust's Legal Provisions
  Relating to IETF Documents
  (http://trustee.ietf.org/license-info)."

Please add the RFC 2119 boilerplate text to this MIB.  E.g.,

The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Done


(3) p 9, sec 4.  MIB Module Definition

 An SnmpTLSFingerprint value is composed of a 1-octet hashing
 algorithm ...

This description somewhat mixes the definition of what the field is, along with 
some historical context.  Hence, I suggest that it might be helpful to split 
the description between what the field is now vs how is was derived.
Change made


It also wasn't clear to me whether there is a restriction that only versions of 
(D)TLS greater than 1.3 may use an algorithm value greater than 8, and whether 
that restriction must be stated here.
The WG expressed that the hash algorithm used by the fingerprint did not have 
to track the (D)TLS usage and the selection is manufacturer specific. Thus, it 
would seem as if we should remain silent on this issue.

[Rob Wilton (rwilton)]
Okay, makes sense.



Nit level comments:

(4) p 8, sec 4.  MIB Module Definition

Typo, potenitally -> potentially
Corrected


(5) p 15, sec 4.  MIB Module Definition

  certificate, then additional rows MUST be searched looking

Extra line break in the description above?
Corrected


(6) p 27, sec 5.  Security Considerations

  SNMP versions prior to SNMPv3 did not include adequate security.
  Even if the network itself is secure (for example, by using IPsec),
  even then, there is no control as to who on the secure network is
  allowed to access and GET/SET (read/change/create/delete) the objects
  in this MIB module.

Suggest eliding the "even then" since the sentence starts with "Even ..."
Corrected by deleting the "even then"


(7) p 31, sec 8.2.  Informative References

  Kenneth Vaughn (editor)
  Trevilon LLC
  1060 Highway 107 South
  Del Rio, TN 37727
  United States of America
  Phone: +1 571 331 5670
  Email: kvau...@trevilon.com<mailto:kvau...@trevilon.com>
Unclear what the comment is

[Rob Wilton (rwilton)]
Sorry, an unfortunately artifact from my comment script, you can ignore it.

Regards,
Rob



Grammar nits from an automated tool:
Grammar Warnings:
Section: 3.2, draft text:
This document does not specify an application profile, hence all of the 
compliance requirements in [RFC8446] apply.
Warning:  Consider using all the.
Suggested change:  "all the"
Corrected



Section: 6, draft text:
IANA is asked to create a new registry called the SNMP-TLSTM HashAlgorithm 
Registry in the Structure of Management Information (SMI) Numbers (MIB Module 
Registrations) Group and to update the proposed URL reference in the above MIB 
( listed as "https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml; 
under SnmpTLSFingerprint), if needed, to accurately reflect its location.
Warning:  Don't put a space after the opening parenthesis.
Suggested change:  "("
Corrected



Regards,
Rob

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

[OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07

[Rob Wilton (rwilton)]

Hi,

Thanks for this document.  Here are my AD review comments for 
draft-ietf-opsawg-add-encrypted-dns-07

Moderate level comments:

(1) p 2, sec 1.  Introduction

   This document specifies two new RADIUS attributes: DHCPv6-Options
   (Section 3.1) and DHCPv4-Options (Section 3.2) Attributes.  These
   attributes can include DHCP options that are listed under the IANA
   registries that are created in Sections 8.4.1 and 8.4.1.  These two
   attributes are specified in order to accommodate both IPv4 and IPv6
   deployment contexts while taking into account the constraints in
   Section 3.4 of [RFC6158].

It isn't really clear to me why some of the registries are needed, specifically 
the ones in 8.4.1 and 8.4.2.  Why not allow any v4 or v6 DHCP attribute to be 
carried within the DHCPv6-Options or DHCPv4-Options field?


(2) p 4, sec 3.  DHCP Options RADIUS Attributes

   Absent any explicit configuration on the DHCP server, RADIUS supplied
   data by means of DHCP*-Options Attributes take precedence over any
   local configuration.

This point may be worth discussing.  Naturally, I would explicit configuration 
to a network device to generally take precedent over implicitly learned 
configuration from the network.


(3) p 6, sec 3.2.  DHCPv4-Options Attribute

  Permitted DHCPv4 options in the DHCPv4-Options Attribute are
  maintained by IANA in the registry created in Section 8.4.2.

Comparing this text to the description for v6, this description is silent on 
whether multiple instances of the same DHCPv4 option MAY be included.  Should 
that be specified here?


(4) p 10, sec 7.  Table of Attributes

   The following table provides a guide as what type of RADIUS packets
   that may contain these attributes, and in what quantity.

Am I right that this is just a duplication of what is described in section 3?  
If so, perhaps change "guide" to "informative guide" and include text to refer 
back to the  canonical definition in section 3.


(5) p 13, sec 8.4.3.  Guidelines for the Designated Experts

   Registration requests that are undetermined for a period longer than
   28 days can be brought to the IESG's attention for resolution.

I'm wondering whether we need the process related text in this document at all, 
or whether we let IANA apply their standard policies?  I may be misinformed, 
but I'm not aware of many *-review mailing lists.


(6) p 15, sec 10.2.  Informative References

   [I-D.ietf-add-dnr]
  Boucadair, M., Reddy, T., Wing, D., Cook, N., and T.
  Jensen, "DHCP and Router Advertisement Options for the
  Discovery of Network-designated Resolvers (DNR)", Work in
  Progress, Internet-Draft, draft-ietf-add-dnr-13, 13 August
  2022, .

Should this be a normative reference?  E.g., if feels like the IANA registry 
values are bound to whatever is published in ietf-add-dnr.



Minor level comments:

(7) p 2, sec 1.  Introduction

   With the advent of encrypted DNS (e.g., DNS-over-HTTPS (DoH)
   [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS-over-QUIC (DoQ)
   [RFC9250]), additional means are required to provision hosts with
   network-designated encrypted DNS.  To fill that void,
   [I-D.ietf-add-dnr] leverages existing protocols such as DHCP and IPv6
   Router Advertisement to provide hosts with the required information
   to connect to an encrypted DNS resolver.  However, there are no
   RADIUS attributes that can be used to populate the discovery messages
   discussed in [I-D.ietf-add-dnr].  The same concern is likely to be
   encountered for future services that are configured using DHCP.

>From this introduction, I thought that this would be covering options for both 
>DHCP and ND, but it looks like only DHCP is covered.  Perhaps this 
>introduction text could be tweaked slightly to make this clearer?


(8) p 3, sec 3.  DHCP Options RADIUS Attributes

   These attributes use the "Long Extended Type" format in order to
   permit the transport of attributes encapsulating more than 253 octets
   of data.  DHCP options that can be included in the DHCP*-Options
   RADIUS attributes are limited by the maximum packet size of 4096
   bytes.  In order to accommodate deployments with large options,
   implementations are RECOMMENDED to support a packet size up to 65535
   bytes.

I didn't find this text clear.  E.g., limit is 4k but should support up to 64K. 
 Which implementations should support larger packet sizes?  Is this RADIUS 
implementations?


(9) p 5, sec 3.1.  DHCPv6-Options Attribute

  This field contains a list of DHCPv6 options.  Multiple instances
  of the same DHCPv6 option MAY be included.  Consistent with
  Section 17 of [RFC7227], this document does not impose any option
  order when multiple options are present.

Is there any requirement to merge multiple instances of options together, 
presumably they are logically just 

[OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12

[Rob Wilton (rwilton)]

Hi Eliot, Scott,

Thanks for this document.  Here is my AD review for 
draft-ietf-opsawg-sbom-access-12.


Moderate level comments:

(1) p 3, sec 1.  Introduction

   To enable application-layer discovery, this memo defines a well-known
   URI [RFC8615].  Management or orchestration tools can query this
   well-known URI to retrieve a system's SBOM or vulnerability
   information.  Further queries may be necessary based on the content
   and structure of the response.

It looks like the .wellknown URI can only be used to retrieve SBOM information 
and not vulnerability information (unless I am missing something).


(2) p 15, sec 6.  Security Considerations

   The YANG module specified in this document defines a schema for data
   that is designed to be accessed via network management protocols such
   as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
   is the secure transport layer, and the mandatory-to-implement secure
   transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure transport is TLS
   [RFC8446].

This text looks to be inconsistent with earlier parts of the document, 
specifically, I didn't think that the intent was to fetch this information 
using NETCONF or RESTCONF, but the early part of this document states that it 
contains groupings, which presumably could be used in any YANG model, and hence 
security considerations would apply.

I would suggest that you split the security considerations into two separate 
sub-sections:

i. The security considerations as this document applies to documenting SBOMs as 
part of the MUD file.  Which I think is most of the text that you have below.  
As per above I think that it is this section that should be updated to comment 
on the use of the insecure version of http and coap.

ii. A separate sub-section that only applies if the groupings are being used in 
regular YANG modules accessed via NETCONF/RESTCONF and that follows the 
standard YANG security template.



Minor level comments:

(3) p 0, sec 

   Discovering and Retrieving Software Transparency and Vulnerability
  Information
draft-ietf-opsawg-sbom-access-12

It wasn't obvious to me why this is called "transparency", is this is a 
standard term of art for SBOMs?


(4) p 4, sec 1.1.  How This Information Is Retrieved

   Note that vulnerability and SBOM information is likely to change at
   different rates.  MUD's cache-validity node provides a way for
   manufacturers to control how often tooling should check for those
   changes through the cache-validity node.

Just for my understanding: Is there any mechanism for clients to register for 
notification of changes rather than polling?


(5) p 4, sec 2.  The well-known transparency endpoint set

   Two well known endpoint is defined:

"Two" => "a", and well known => well-known?


(6) p 7, sec 4.  The mud-sbom augmentation to the MUD YANG model

 identity http {
   base mudtx:local-type;
   description
 "Use http (insecure) to retrieve SBOM information.  This
   method is NOT RECOMMENDED, but may be unavoidable for
   certain classes of deployment, where TLS has not or
   cannot be implemented";
 }

I'm okay with this and coap (from a pragmatism POV).  But I think that the 
security section should talk about this: I.e., emphasize that secure versions 
MUST be used in preference, if available, and highlight the risks if insecure 
protocols are used.


(7) p 7, sec 4.  The mud-sbom augmentation to the MUD YANG model

 identity coaps {
   base mudtx:local-type;
   description
 "Use COAPS (secure) to retrieve SBOM";
 }

Possibly add YANG reference statements to point to the latest http, https, 
coap, and coaps specifications?


(8) p 8, sec 4.  The mud-sbom augmentation to the MUD YANG model

 choice sbom-retrieval-method {
   description
 "How to find SBOM information";
   case cloud {
 list sboms {
   key "version-info";
   description
 "A list of SBOMs tied to different software
  or hardware versions.";
   leaf version-info {
 type string;
 description
   "The version to which this SBOM refers.";
   }
   leaf sbom-url {
 type inet:uri;
 description
   "A statically located URL.";
   }

Should any URI be allowed here, or should it be pattern restricted to http(s) 
or coap(s)?


(9) p 8, sec 4.  The mud-sbom augmentation to the MUD YANG model

 leaf archive-list {
   type inet:uri;
   description
 "This URI returns a JSON list of URLs that consist of
 SBOMs that were previously published for this
 device.  Publication dates can 

[OPSAWG] AD review of draft-ietf-opsawg-tlstm-update-10

[Rob Wilton (rwilton)]

Hi Kevin,

Sorry for the delay.  Here are my AD review comments for 
draft-ietf-opsawg-tlstm-update-10.  All my comments are pretty minor.  Please 
let me know if you have any questions/comments, or otherwise can just post an 
updated version which I can then send off for IETF LC.

Minor level comments:

(1) p 4, sec 2.3.  TLS Version

   [RFC6353] states that TLSTM clients and servers MUST NOT request,
   offer, or use SSL 2.0.  [RFC8996] prohibits the use of (D)TLS
   versions prior to version 1.2.  TLSTMv1.3 MUST only be used with
   (D)TLS version 1.2 and later.

It wasn't clear to me exactly what is meant by TLSTMv1.3, and this is the only 
use of this term.  Could you be more specific here please?


(2) p 6, sec 4.  MIB Module Definition

   Redistribution and use in source and binary forms, with or
   without modification, is permitted pursuant to, and subject
   to the license terms contained in, the Revised BSD License
   set forth in Section 4.c of the IETF Trust's Legal Provisions
   Relating to IETF Documents
   (http://trustee.ietf.org/license-info)."

Please add the RFC 2119 boilerplate text to this MIB.  E.g.,

 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
 'MAY', and 'OPTIONAL' in this document are to be interpreted as
 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
 they appear in all capitals, as shown here.


(3) p 9, sec 4.  MIB Module Definition

  An SnmpTLSFingerprint value is composed of a 1-octet hashing
  algorithm identifier followed by the fingerprint value.  The
  1-octet identifier value encoded is based on the IANA TLS
  HashAlgorithm Registry (RFC 5246); however, this registry is
  only applicable to (D)TLS protocol versions prior to 1.3,
  which are now designated as obsolete and are not expected to
  ever support additional values. To allow the fingerprint
  algorithm to support additional hashing algorithms that might
  be used by later versions of (D)TLS, the octet value encoded
  is taken from IANA SNMP-TLSTM HashAlgorithm Registry. The
  initial values within this registry are identical to the
  values in the TLS HashAlgorithm registry but can be extended
  to support new hashing algorithms as needed. The remaining
  octets of the SnmpTLSFingerprint value are filled using the
  results of the hashing algorithm.

This description somewhat mixes the definition of what the field is, along with 
some historical context.  Hence, I suggest that it might be helpful to split 
the description between what the field is now vs how is was derived.  E.g., 
perhaps something like:

  An SnmpTLSFingerprint value is composed of a 1-octet hashing
  algorithm identifier followed by the fingerprint value:
  
  The 1-octet identifier value encoded is taken from the 
  IANA SNMP-TLSTM HashAlgorithm Registry.

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

  Historically, this field was based on the IANA TLS
  HashAlgorithm Registry (RFC 5246); however, this registry is
  only applicable to (D)TLS protocol versions prior to 1.3,
  which are now designated as obsolete and are not expected to
  ever support additional values. To allow the fingerprint
  algorithm to support additional hashing algorithms that might
  be used by later versions of (D)TLS, the octet value encoded
  is now taken from IANA SNMP-TLSTM HashAlgorithm Registry. The
  initial values within this registry are identical to the
  values in the TLS HashAlgorithm registry but can be extended
  to support new hashing algorithms as needed. The remaining
  octets of the SnmpTLSFingerprint value are filled using the
  results of the hashing algorithm.

It also wasn't clear to me whether there is a restriction that only versions of 
(D)TLS greater than 1.3 may use an algorithm value greater than 8, and whether 
that restriction must be stated here.



Nit level comments:

(4) p 8, sec 4.  MIB Module Definition

   Values of this textual convention are not guaranteed to be
   directly usable as transport layer addressing information,
   potenitally requiring additional processing, such as run-time
   resolution.  As such, applications that write them MUST be
   prepared for handling errors if such values are not
   supported, or cannot be resolved (if resolution occurs at the
   time of the management operation).

Typo, potenitally -> potentially


(5) p 15, sec 4.  MIB Module Definition

   certificate, then additional rows MUST be searched looking

Extra line break 

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

[Rob Wilton (rwilton)]

Hi Med,

Great, thanks.  I've request IETF LC on -12.

If any clarifications or changes are required based on the question raised by 
Tom then please can you resolve that as part of the IETF LC.

Regards,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com 
> Sent: 16 December 2022 14:17
> To: Rob Wilton (rwilton) 
> Cc: draft-ietf-opsawg-sap@ietf.org; opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-sap-09
> 
> Hi Rob,
> 
> The proposed edits look good to me. These are now implemented in the public -
> 12. Thanks.
> 
> cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) 
> > Envoyé : vendredi 16 décembre 2022 12:11
> > À : BOUCADAIR Mohamed INNOV/NET 
> > Cc : draft-ietf-opsawg-sap@ietf.org; opsawg@ietf.org
> > Objet : RE: AD review of draft-ietf-opsawg-sap-09
> >
> > Hi Med,
> >
> > Thanks for persevering, I think that we are pretty much there.
> >
> > I've have proposed some minor tweaks the description and YANG leaf
> > descriptions that I think may improve clarity, but I'll leave it
> > to you to decide whether it would be helpful to incorporate these.
> > Please either merge/some all of these and post an updated version
> > or indicate whether you would like to stick with -11, and then I
> > can kick off the IETF LC.
> >
> > OLD:
> >'service-status':  Indicates the administrative and operational
> >   status of the service for a given SAP.  This information is
> >   particularly useful when many services are enabled for the
> > same
> >   SAP, but only a subset of these services are activated.  As
> > such,
> >   the administrative 'service-status' MUST NOT be influenced
> > by the
> >   value of the 'sap-status'.
> >
> >   The service 'oper-status' reflects the service operational
> > status
> >   as observed for a specific SAP, not the status that is
> > determined
> >   at the network level for a service that involves many SAPs.
> > That
> >   network level status can be retrieved using specific network
> >   models, e.g., Section 7.3 of [RFC9182] or Section 7.3 of
> >   [RFC9291].
> >
> >   In order to assess the service delivery status for a given
> > SAP, it
> >   is recommended to check both the administrative and
> > operational
> >   service status ('service-status') in addition to the 'sap-
> > status'.
> >   In doing so, a network controller (or an operator) can
> > detect
> >   anomalies.  For example, if a service is administratively
> > enabled
> >   for a SAP and the 'sap-status' of that SAP is reported as
> > being
> >   down, the service 'oper-status' is also expected to be down.
> >   Retrieving a distinct service operational status under these
> >   conditions can be used as a trigger to detect an anomaly.
> >   Likewise, administrative status and operational status can
> > be used
> >   as a trigger to detect service-specific SAP activation
> > anomalies.
> >   For example, a service that is administratively declared as
> >   inactive for a SAP but reported as operationally active for
> > that
> >   SAP is an indication that some service provision actions are
> >   needed to align the observed service status with the
> > expected
> >   service status.
> >
> > NEW:
> >   'service-status':  Indicates the administrative and
> > operational
> >   status of the service for a given SAP.  This information is
> >   particularly useful when many services are provisioned for
> > the same
> >   SAP, but only a subset of these services are activated.  As
> > such,
> >   the administrative 'service-status' MUST NOT be influenced
> > by the
> >   value of the operational 'sap-status'.
> >
> >   The service 'oper-status' reflects the operational status of
> > the
> >   service only as observed at a specific SAP, not the overall
> >   network level status of the service connecting many SAPs.
> > The
> >   network level service status can be retrieved using specific
> >   network models, e.g., Section 7.3 of [RFC9182] or Section
> > 7.3 of
> >   [RFC9291].
> >
> >   In order to assess the service delivery status for a given
> > SAP, it
> >   is recommended to check both the administrative and
> > operational
> >   service status ('service-status') in addition to the 'sa

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

[Rob Wilton (rwilton)]

Hi Tom,

My understanding is that service is the top list (i.e., node/service) and the 
saps are in the per service child list:

augment /nw:networks/nw:network/nw:node:
  +--rw service* [service-type]
 +--rw service-type   identityref
 +--rw sap* [sap-id]

The text is section 5 states:

   'sap-id':  Includes an identifier that uniquely identifies a SAP
  within a node.

  The same SAP may appear under distinct service types.  In such a
  case, the same identifier is used for these service types in
  association.

So, I think that the answer is yes, the same SAP can support multiple services, 
but they are keyed by service then sap, rather than the other way round, and 
some presumably common SAP properties will appear duplicated per service.  For 
SAP properties that must be common across all services on the same SAP then I 
think that the authors and WG considered have a separate per node SAP list but 
presumably decided that aligning this under the service made the model easier 
to use, particularly in the case where there is only a single service per SAP.

Regards,
Rob


> -Original Message-
> From: tom petch 
> Sent: 19 December 2022 12:19
> To: mohamed.boucad...@orange.com; Rob Wilton (rwilton)
> 
> Cc: draft-ietf-opsawg-sap@ietf.org; opsawg@ietf.org
> Subject: Re: AD review of draft-ietf-opsawg-sap-09
> 
> From: OPSAWG  on behalf of
> mohamed.boucad...@orange.com 
> Sent: 12 December 2022 12:52
> 
> Hi Rob,
> 
> Thanks for the follow-up.
> 
> After rereading the initial proposed updated text, I think that you have a 
> valid
> point about the need for more clarity when describing the relationship between
> the various status data nodes. I released -11 with an attempt to make that
> better. Both the data nodes description and the examples are updated to
> reflect the intent. The relationship (including what should be considered as
> anomalies) are also described.
> 
> The new text also clarifies that the per-SAP service status should not be
> confused with the global service status (which may involved more than one
> SAP). Adrian's comment that a SAP failure does not imply a service failure is
> true for that global service status, not for the (per-SAP) service status 
> included
> in the SAP.
> 
> 
> I do not know if my confusion is along the same lines as his but..
> I am left wondering if a SAP instance is limited to one service e.g. L2VPN or
> whether a SAP instance can support more than one e.g. both L2VPN and EVPN.
> 
> The YANG module implies only the one.  sap-list is a list of SAP with a single
> container oper-status which is the 'Operational status of the service...'
> i.e. a SAP has only one service status so a SAP has only one service
> If there were more than one then oper-status would be a list keyed on service
> 
> In passing /povider/provider/
> 
> Tom Petch
> 
> The new text is available at:
> 
> URL:https://www.ietf.org/archive/id/draft-ietf-opsawg-sap-11.txt
> Diff:   
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-sap-11
> 
> Hope this is better. Thanks.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) 
> > Envoyé : vendredi 9 décembre 2022 15:22
> > À : BOUCADAIR Mohamed INNOV/NET ;
> > draft-ietf-opsawg-sap@ietf.org; opsawg@ietf.org
> > Objet : RE: AD review of draft-ietf-opsawg-sap-09
> >
> > Hi Med,
> >
> > Sorry, still not clear (in my head) on the exact differentiation
> > between sap-status and service-status.
> >
> > Also, a few other nits that I spotted:
> > s/is capable to host/is capable of hosting/ (two places) s/ that
> > uniquely identifies SAP/ that uniquely identifies a SAP/ s/ are
> > tagged as ready to host/ are tagged as being capable of hosting/
> >
> > Please see inline ...
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > 
> > > Sent: 09 November 2022 15:11
> > > To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> > > sap@ietf.org; opsawg@ietf.org
> > > Subject: RE: AD review of draft-ietf-opsawg-sap-09
> > >
> > > > > >
> > > > > > But how do you distinguish between a SAP that hasn't been
> > > > > > provisioned yet to a service vs a SAP that has been
> > provisioned
> > > > > > but the service is down?  E.g., trying to find a free SAP
> > just
> > > > > > by looking for a SAP with a service-status of op-down
> > doesn't
> > > > > > appear to be sufficient on its own.
> >

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

[Rob Wilton (rwilton)]

   uses vpn-common:oper-status-timestamp;
   }
 }
   }
 }

Regards,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com 
> Sent: 12 December 2022 12:53
> To: Rob Wilton (rwilton) 
> Cc: draft-ietf-opsawg-sap@ietf.org; opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-sap-09
> 
> Hi Rob,
> 
> Thanks for the follow-up.
> 
> After rereading the initial proposed updated text, I think that you have a 
> valid
> point about the need for more clarity when describing the relationship between
> the various status data nodes. I released -11 with an attempt to make that
> better. Both the data nodes description and the examples are updated to
> reflect the intent. The relationship (including what should be considered as
> anomalies) are also described.
> 
> The new text also clarifies that the per-SAP service status should not be
> confused with the global service status (which may involved more than one
> SAP). Adrian's comment that a SAP failure does not imply a service failure is
> true for that global service status, not for the (per-SAP) service status 
> included
> in the SAP.
> 
> The new text is available at:
> 
> URL:https://www.ietf.org/archive/id/draft-ietf-opsawg-sap-11.txt
> Diff:   
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-sap-11
> 
> Hope this is better. Thanks.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) 
> > Envoyé : vendredi 9 décembre 2022 15:22
> > À : BOUCADAIR Mohamed INNOV/NET ;
> > draft-ietf-opsawg-sap@ietf.org; opsawg@ietf.org
> > Objet : RE: AD review of draft-ietf-opsawg-sap-09
> >
> > Hi Med,
> >
> > Sorry, still not clear (in my head) on the exact differentiation
> > between sap-status and service-status.
> >
> > Also, a few other nits that I spotted:
> > s/is capable to host/is capable of hosting/ (two places) s/ that
> > uniquely identifies SAP/ that uniquely identifies a SAP/ s/ are
> > tagged as ready to host/ are tagged as being capable of hosting/
> >
> > Please see inline ...
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > 
> > > Sent: 09 November 2022 15:11
> > > To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> > > sap@ietf.org; opsawg@ietf.org
> > > Subject: RE: AD review of draft-ietf-opsawg-sap-09
> > >
> > > > > >
> > > > > > But how do you distinguish between a SAP that hasn't been
> > > > > > provisioned yet to a service vs a SAP that has been
> > provisioned
> > > > > > but the service is down?  E.g., trying to find a free SAP
> > just
> > > > > > by looking for a SAP with a service-status of op-down
> > doesn't
> > > > > > appear to be sufficient on its own.
> > > > >
> > > > > [Med] A SAP that is not provisioned yet will have a
> > > > > sap-status=down,
> > > > while
> > > > > the one that is provision but the service is not activated
> > will
> > > > > have
> > > > sap-
> > > > > status=up and service-status=down. Isn't that sufficient?
> > > >
> > > > I would have assumed:
> > > >  - If sap-status is down then the service-status must also be
> > down,
> > > > right?
> > >
> > > [Med] Actually, no. The service status indicates whether a
> > service is
> > > associated with the SAP. Added both the admin and op status of
> > the
> > > service status and added this NEW text:
> > >
> > > "This data node indicates whether a service is bound to this SAP
> > and,
> > > as such, it is not influenced by the value of the 'sap-status'."
> > [Rob Wilton (rwilton)]
> >
> > " 'service-status':  Reports the status of the service for a given
> > SAP. ...".  This states that it is reporting the status of the
> > service for a given SAP.
> >
> > For the service-status/admin-status I can see how the service can
> > be admin-up for a SAP that is down (e.g., perhaps there is a
> > broken fiber such that the physical interface or sub-interface is
> > down).  But I would still find it confusing to say that the
> > service at the SAP is operationally up on a SAP that is down.
> >
> > Specifically, if a customer was to ask whether there are able to
> > get service at a particular SAP, is it sufficient for the operator
> > to check service-status/ope

Re: [OPSAWG]  WG LC: Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)

[Rob Wilton (rwilton)]

Hi Benoit,

Yes, that is fine with me.

Regards,
Rob


From: Benoit Claise 
Sent: 16 December 2022 10:13
To: Joe Clarke (jclarke) ; opsawg@ietf.org; 
Rob Wilton (rwilton) 
Subject: Re: [OPSAWG]  WG LC: Export of Segment Routing over IPv6 Information 
in IP Flow Information Export (IPFIX)

Hi Rob,

Do we get the green light to request the IANA early allocation 
[https://datatracker.ietf.org/doc/html/rfc7120#section-2] since there are 
multiple implementations already?

Regards, Benoit
On 12/15/2022 9:32 PM, Joe Clarke (jclarke) wrote:
Closing this WG LC out.  A great deal of support has been expressed for this 
work, and the chairs appreciate the attention to not only IANA but working 
implementations.

This draft will move forward to the IESG.  However, we NEED a shepherd.  I 
personally don’t feel comfortable shepherding this (nor do I really have the 
bandwidth at the moment).  Is there someone – perhaps someone that expressed 
their support – that would be willing to shepherd?

Joe

From: Joe Clarke (jclarke) <mailto:jcla...@cisco.com>
Date: Wednesday, November 30, 2022 at 08:53
To: opsawg@ietf.org<mailto:opsawg@ietf.org> 
<mailto:opsawg@ietf.org>
Subject:  WG LC: Export of Segment Routing over IPv6 Information in IP Flow 
Information Export (IPFIX)
Hello, WG.  As discussed at IETF 115, we want to conduct a WG LC for 
draft-ietf-opsawg-ipfix-srv6-srh.  The authors believe this work is stable and 
moreover used the 115 hackathon to develop a interoperable implementations 
(linked in Data Tracker) .  Additionally, IANA has already weighed in on this 
work and agree with the considerations approach.

Therefore, we are calling for a two week LC.  We will conclude on December 14.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/

Please review the current -04 draft, post your comments and/or your thoughts on 
the current text.

Thanks.

Joe



___

OPSAWG mailing list

OPSAWG@ietf.org<mailto: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-sap-09

[Rob Wilton (rwilton)]

Hi Med,

Sorry, still not clear (in my head) on the exact differentiation between 
sap-status and service-status.

Also, a few other nits that I spotted:
s/is capable to host/is capable of hosting/ (two places)
s/ that uniquely identifies SAP/ that uniquely identifies a SAP/
s/ are tagged as ready to host/ are tagged as being capable of hosting/

Please see inline ...

> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 09 November 2022 15:11
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> sap@ietf.org; opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-sap-09
> 
> > > >
> > > > But how do you distinguish between a SAP that hasn't been
> > > > provisioned yet to a service vs a SAP that has been provisioned
> > > > but the service is down?  E.g., trying to find a free SAP just by
> > > > looking for a SAP with a service-status of op-down doesn't appear
> > > > to be sufficient on its own.
> > >
> > > [Med] A SAP that is not provisioned yet will have a sap-status=down,
> > while
> > > the one that is provision but the service is not activated will have
> > sap-
> > > status=up and service-status=down. Isn't that sufficient?
> >
> > I would have assumed:
> >  - If sap-status is down then the service-status must also be down,
> > right?
> 
> [Med] Actually, no. The service status indicates whether a service is 
> associated
> with the SAP. Added both the admin and op status of the service status and
> added this NEW text:
> 
> "This data node indicates whether a service is bound to this SAP and, as such,
> it is not influenced by the value of the 'sap-status'."
[Rob Wilton (rwilton)] 

" 'service-status':  Reports the status of the service for a given SAP. ...".  
This states that it is reporting the status of the service for a given SAP.

For the service-status/admin-status I can see how the service can be admin-up 
for a SAP that is down (e.g., perhaps there is a broken fiber such that the 
physical interface or sub-interface is down).  But I would still find it 
confusing to say that the service at the SAP is operationally up on a SAP that 
is down.

Specifically, if a customer was to ask whether there are able to get service at 
a particular SAP, is it sufficient for the operator to check 
service-status/oper-status on the SAP, or must they check both 
service-status/oper-status and service-status/sap-status to know whether or not 
they will be receiving service at a particular SAP?

If the draft description, and perhaps even more critically, the YANG model 
description, can be really clear on this, I think that will help implementors 
and users.

Regards,
Rob

___
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

[Rob Wilton (rwilton)]

Hi Bo,

Thanks, and no worries.

Document has been approved.  I would like to thank the authors, WG, and doc 
shepherd for their work on this draft.

Regards,
Rob


From: Wubo (lana) 
Sent: 11 November 2022 11:00
To: Rob Wilton (rwilton) ; 
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 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) mailto:rwil...@cisco.com>>
发送时间: 2022年11月11日 10:37
收件人: 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>
抄送: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 
opsawg@ietf.org<mailto: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-nu

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

[Rob Wilton (rwilton)]

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) 
Sent: 25 October 2022 08:26
To: Rob Wilton (rwilton) ; 
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 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?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: a

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

[Rob Wilton (rwilton)]

Hi Jean,

Thanks.  I've requested IETF LC on the --09 version.

Regards,
Rob


> -Original Message-
> From: Jean Quilbeuf 
> Sent: 07 November 2022 14:51
> To: Rob Wilton (rwilton) ; opsawg@ietf.org; draft-ietf-
> opsawg-service-assurance-yang@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-service-assurance-yang-07
> 
> Hi Rob,
> 
> Indeed, my assumption was that the value on the wire is the same as the
> value passed as substatement on enum. That is indeed to the case, the value
> on the wire is the name of the enum.
> 
> I pushed  a -09 version where the range is extended to -1 to 100 and the
> description states that -1 means health-score is not available:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-yang-
> 09
> 
> Thanks,
> Jean
> 
> > -Original Message-
> > From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > Sent: Sunday 6 November 2022 16:12
> > To: Jean Quilbeuf ; opsawg@ietf.org; draft-
> > ietf-opsawg-service-assurance-yang@ietf.org
> > Subject: RE: AD review of draft-ietf-opsawg-service-assurance-yang-07
> >
> > Hi Jean,
> >
> > Sorry for coming back, but I'm still not 100% sure that we are in sync.
> Please
> > see further comment and clarification inline ...
> >
> > > -Original Message-
> > > From: Jean Quilbeuf 
> > > Sent: 06 November 2022 15:47
> > > To: Rob Wilton (rwilton) ; opsawg@ietf.org;
> > > draft-ietf- opsawg-service-assurance-yang@ietf.org
> > > Subject: RE: AD review of draft-ietf-opsawg-service-assurance-yang-07
> > >
> > > Hi Rob,
> > > Thanks for the answers.
> > >
> > > I think we agree on the final goal and as I understand it is what we
> > > have in - 08, so let’s go with that version. More details below.
> > >
> > > Thanks,
> > > Jean
> > >
> > > > -Original Message-
> > > > From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > > > Sent: Sunday 6 November 2022 15:22
> > > > To: Jean Quilbeuf ; opsawg@ietf.org;
> > > > draft- ietf-opsawg-service-assurance-yang@ietf.org
> > > > Subject: RE: AD review of
> > > > draft-ietf-opsawg-service-assurance-yang-07
> > > >
> > > > Hi Jean,
> > > >
> > > > Just one further question inline ...
> > > >
> > > > > -Original Message-
> > > > > From: Jean Quilbeuf 
> > > > > Sent: 19 October 2022 01:10
> > > > > To: Rob Wilton (rwilton) ; opsawg@ietf.org;
> > > > > draft-ietf- opsawg-service-assurance-yang@ietf.org
> > > > > Subject: RE: AD review of
> > > > > draft-ietf-opsawg-service-assurance-yang-07
> > > > >
> > > > > Hi Rob,
> > > > > Thank you very much for you detailed review.
> > > > >
> > > > > The latest version should address most of the comments. The diff is
> > here:
> > > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assura
> > > > > nce-
> > > > > yang-
> > > > > 08
> > > > >
> > > > > Answers to some unanswered or added details are inline below.
> > > > >
> > > > > Thanks Again
> > > > > Best,
> > > > > Jean
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > > > > > Sent: Monday 17 October 2022 13:06
> > > > > > To: opsawg@ietf.org;
> > > > > > draft-ietf-opsawg-service-assurance-yang@ietf.org
> > > > > > Subject: AD review of
> > > > > > draft-ietf-opsawg-service-assurance-yang-07
> > > > > >
> > > > > > Dear authors,
> > > > > >
> > > > > > And here is my corresponding AD review of
> > > > > > draft-ietf-opsawg-service- assurance-yang-07.  Again, I found
> > > > > > the document to be well-written, with mostly minor
> > > > > > comments/suggestions, bar one question about the
> > > > > symptom
> > > > > > reference.
> > > > > >
> > > > > >
> > > > > > (12) p 6, sec 3.2.  Tree View
> > > > > >
> > > > > >The "health-score" contains a value normally between 0 and 1

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

[Rob Wilton (rwilton)]

Hi Med,

Apologies for the delay.  The behaviour is still not entirely clear to me.  
Please see inline ...

> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 29 September 2022 15:18
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> sap@ietf.org; opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-sap-09
> 
> Hi Rob,
> 
> Thanks for the follow-up.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) 
> > Envoyé : jeudi 29 septembre 2022 15:24
> > À : BOUCADAIR Mohamed INNOV/NET
> ;
> > draft-ietf-opsawg-sap@ietf.org; opsawg@ietf.org
> > Objet : RE: AD review of draft-ietf-opsawg-sap-09
> >
> > Hi Med,
> >
> > Comments inline below ...
> >
> > I've snipped out anything that we have already reached agreement
> > on.
> >
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > 
> > > Sent: 23 September 2022 14:04
> > > To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> > > sap@ietf.org; opsawg@ietf.org
> > > Subject: RE: AD review of draft-ietf-opsawg-sap-09
> > >
> > > Hi Rob,
> > >
> > > Thank you for the review. The changes can be tracked at:
> > > https://tinyurl.com/sap-latest
> > >
> > > Please note that I made a change to better allow for reuse of
> > the SAP
> > > information in other modules (this can be tracked here:
> > > https://github.com/IETF-OPSAWG-
> > > WG/lxnm/commit/e8b406d7fad5225dd84ad7ff03f6da446eae6736).
> >
> > Okay.
> >
> >
> > >
> > > Please see inline for more context.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : Rob Wilton (rwilton)  Envoyé :
> > vendredi 23
> > > > septembre 2022 14:01 À : draft-ietf-opsawg-sap@ietf.org;
> > > > opsawg@ietf.org Objet : AD review of draft-ietf-opsawg-sap-09
> > > >
> > > > Hi authors, WG,
> > > >
> > > > Thank you for this document.  I also think that this document
> > is
> > > > well written and in good shape, and I mostly found the
> > explanations
> > > > and examples clear.  There were two specific points that I
> > found
> > > > slightly confusing related to differentiating between SAPs in
> > use,
> > > > and those that are not, and also parent interfaces also be
> > listed as
> > > > SAPs, details below.
> > >
> > > [Med] Thanks
> > >
> > > >
> > > > Moderate level comments:
> > > >
> > > > (1) p 10, sec 5.  SAP Module Tree Structure
> > > >
> > > >   SAPs that are associated with the interfaces that are
> > directly
> > > >   hosting services, interfaces that are ready to host per-
> > > > service
> > > >   sub-interfaces (but not yet activated), or service that
> > are
> > > >   already instantiated on sub-interfaces are listed as
> > SAPs.
> > > >
> > > > >From the model, is isn't clear to me how different
> > differentiates
> > > > between a SAP that has been pre-provisioned to potentially be
> > used
> > > > for a service in future, v.s., one is that is actively
> > provisioned.
> > >
> > > [Med] This is inferred from the service-status=down for these
> > SAPs.
> >
> > So, thinking of this at device level configuration there is
> > effectively 3 levels of configuration/activation (at least for
> > L2VPNs):
> >
> > (1) A sub-interface is configured, but without any IP address or
> > VRF (for L3VPN), or without being attached to an L2VPN or Bridge
> > Domain (for L2VPNs).  I.e., the sub-interface isn't connected
> > anyway.
> > (2) The sub-interface is configured and connected into a bridge
> > domain or P2P L2VPN but that service is down (e.g., perhaps
> > because the AC at the remote end of the L2VPN is physically down).
> > (3) The sub-interface is configured and connected into a bridge
> > domain or P2P L2VPN and that service is up.
> >
> > I think that you are saying that you regard that both (1) and (2)
> > would be indicated by service-status=down?  Would it be worth
> > expanding the description at all to make this more explicit?
> 
> [Med] The implicit model has some limitations, indeed. Glad to see that we
>

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

[Rob Wilton (rwilton)]

Hi Jean,

Sorry for coming back, but I'm still not 100% sure that we are in sync.  Please 
see further comment and clarification inline ...

> -Original Message-
> From: Jean Quilbeuf 
> Sent: 06 November 2022 15:47
> To: Rob Wilton (rwilton) ; opsawg@ietf.org; draft-ietf-
> opsawg-service-assurance-yang@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-service-assurance-yang-07
> 
> Hi Rob,
> Thanks for the answers.
> 
> I think we agree on the final goal and as I understand it is what we have in -
> 08, so let’s go with that version. More details below.
> 
> Thanks,
> Jean
> 
> > -----Original Message-
> > From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > Sent: Sunday 6 November 2022 15:22
> > To: Jean Quilbeuf ; opsawg@ietf.org; draft-
> > ietf-opsawg-service-assurance-yang@ietf.org
> > Subject: RE: AD review of draft-ietf-opsawg-service-assurance-yang-07
> >
> > Hi Jean,
> >
> > Just one further question inline ...
> >
> > > -Original Message-
> > > From: Jean Quilbeuf 
> > > Sent: 19 October 2022 01:10
> > > To: Rob Wilton (rwilton) ; opsawg@ietf.org;
> > > draft-ietf- opsawg-service-assurance-yang@ietf.org
> > > Subject: RE: AD review of draft-ietf-opsawg-service-assurance-yang-07
> > >
> > > Hi Rob,
> > > Thank you very much for you detailed review.
> > >
> > > The latest version should address most of the comments. The diff is here:
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-
> > > yang-
> > > 08
> > >
> > > Answers to some unanswered or added details are inline below.
> > >
> > > Thanks Again
> > > Best,
> > > Jean
> > >
> > >
> > > > -Original Message-
> > > > From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > > > Sent: Monday 17 October 2022 13:06
> > > > To: opsawg@ietf.org;
> > > > draft-ietf-opsawg-service-assurance-yang@ietf.org
> > > > Subject: AD review of draft-ietf-opsawg-service-assurance-yang-07
> > > >
> > > > Dear authors,
> > > >
> > > > And here is my corresponding AD review of draft-ietf-opsawg-service-
> > > > assurance-yang-07.  Again, I found the document to be well-written,
> > > > with mostly minor comments/suggestions, bar one question about the
> > > symptom
> > > > reference.
> > > >
> > > >
> > > > (12) p 6, sec 3.2.  Tree View
> > > >
> > > >The "health-score" contains a value normally between 0 and 100
> > > >indicating how healthy the subservice is.  The special value -1 can
> > > >be used to specify that no value could be computed for that health-
> > > >score, for instance if some metric needed for that computation could
> > > >not be collected.
> > > >
> > > > Because this is an enum, this would often/normally be encoded as the
> > > string
> > > > "missing" rather than as -1.
> > >
> > > I am hoping that YANG-aware deserialization will replace the value -1
> > > by the enum name, i.e. "missing" when targeting a human. The reason to
> > > use a number is for homogeneity with the health score, thinking of
> > > time series databases which fail if a time series changes type (int ->
> > > string for instance) over time.
> >
> > This is okay, but it does mean that the deserialization code will need to
> > potentially spot that it may be the string value "missing" and then decide
> to
> > convert that a reserved integer, presumably -1.  E.g., it feels like the 
> > union
> > type of integer + string just means that you probably need slightly more
> code
> > when streaming it into a time series database?
> >
> > Given that this leaf is marked as being optional in the schema, then it
> could
> > just be represented as the range 0 to 100, and if the server doesn't know
> the
> > value then it doesn't provide any value at all.
> > Or alternatively, it could be modelled as a (perhaps mandatory true) leaf,
> > with the range -1 to 100, with a default value of -1, and an explanation in
> the
> > description that the value -1 is used to indicate that no health score is
> being
> > provided.
> >
> > But there are pretty minor comments on the encoding.  Please let me know
> > if you would like to change this and post a -09, o

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

[Rob Wilton (rwilton)]

Hi Jean,

Just one further question inline ...

> -Original Message-
> From: Jean Quilbeuf 
> Sent: 19 October 2022 01:10
> To: Rob Wilton (rwilton) ; opsawg@ietf.org; draft-ietf-
> opsawg-service-assurance-yang@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-service-assurance-yang-07
> 
> Hi Rob,
> Thank you very much for you detailed review.
> 
> The latest version should address most of the comments. The diff is here:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-yang-
> 08
> 
> Answers to some unanswered or added details are inline below.
> 
> Thanks Again
> Best,
> Jean
> 
> 
> > -Original Message-
> > From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > Sent: Monday 17 October 2022 13:06
> > To: opsawg@ietf.org; draft-ietf-opsawg-service-assurance-yang@ietf.org
> > Subject: AD review of draft-ietf-opsawg-service-assurance-yang-07
> >
> > Dear authors,
> >
> > And here is my corresponding AD review of draft-ietf-opsawg-service-
> > assurance-yang-07.  Again, I found the document to be well-written, with
> > mostly minor comments/suggestions, bar one question about the
> symptom
> > reference.
> >
> >
> > Moderate level comments:
> >
> > (1) p 11, sec 3.3.  YANG Module
> >
> >   grouping symptom {
> > description
> >   "A grouping for the symptoms for a specific subservice.";
> > leaf symptom-id {
> >   type leafref {
> > path "/agents/symptoms-description/symptom-id";
> >   }
> >   description
> > "Identifier of the symptom, to be interpreted according
> >  to the agent identified by the agent-id.";
> > }
> >
> > Should this path be constrained to the specific agent instance identified by
> > agent-id?  E.g., similar to how the 'id' path is constrained in subservice-
> > reference below.
> >
> 
> Indeed that was a mistake, it's fixed now.
> 
> >
> > (4) p 5, sec 3.2.  Tree View
> >
> >module: ietf-service-assurance
> >  +--ro assurance-graph-last-changeyang:date-and-time
> >  +--rw subservices
> >  |  +--rw subservice* [type id]
> >  | +--rw typeidentityref
> >  | +--rw id  string
> >
> > I don't really like to mess with the structure of YANG modules during AD
> (or
> > IESG) review, but I wonder whether having type as part of the subservice
> > key doesn't end up making it more cumbersome to refer to subservices,
> and
> > whether a flat id space might be better (i.e., removing 'type' from the
> > subservice list keys).  But I also don't mind if the author/WG do not want
> to
> > change the structure at this stage.
> >
> 
> I decided not to change it at the moment.
> 
> >
> > (8) p 5, sec 3.2.  Tree View
> >
> >+--ro subservices* [type id]
> >   +--ro type-> /subservices/subservice/type
> >   +--ro id  leafref
> >
> > A couple more consistency questions:
> > 1) I note that subservices has been put into a container, but that agents,
> > assured-services are not.
> > 2) The "subservice" list is the singular tense (presumably because it is
> under a
> > container), but agents, assured-services and subservices are not.  I know
> that
> > you have to optimize for XML or JSON readability.
> >
> 
> According to https://datatracker.ietf.org/doc/html/rfc8407#section-4.14.2 ,
> top level lists with large number of nodes should be avoided. So I have
> wrapped them into containers.

Okay.


> 
> >
> > (9) p 6, sec 3.2.  Tree View
> >
> >+--ro subservices* [type id]
> >   +--ro type-> /subservices/subservice/type
> >   +--ro id  leafref
> >The date of last change "assurance-graph-last-change" is read only.
> >It must be updated each time the graph structure is changed by
> >addition or deletion of subservices, dependencies or modification of
> >their configurable attributes.  Such modifications correspond to a
> >structural change in the graph.  The date of last change is useful
> >for a client to quickly check if there is a need to update the graph
> >structure.  A change in the health-score or symptoms associated to a
> >service or subservice does not change the structure of the graph and
> >thus has no effect on the date of last cha

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

[Rob Wilton (rwilton)]

Hi Jean,

Thanks for the updates.  I've requested IETF LC.

Regards,
Rob


-Original Message-
From: OPSAWG  On Behalf Of Jean Quilbeuf
Sent: 18 October 2022 15:12
To: opsawg@ietf.org
Subject: Re: [OPSAWG] I-D Action: 
draft-ietf-opsawg-service-assurance-architecture-11.txt

Dear All,
The version -10 addresses the comments from Rob Wilton and the version 11 is 
just adding a reference to draft-ietf-opsawg-yang-vpn-service-pm as suggested 
by Med.

Best,
Jean

> -Original Message-
> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of internet-
> dra...@ietf.org
> Sent: Tuesday 18 October 2022 15:08
> To: i-d-annou...@ietf.org
> Cc: opsawg@ietf.org
> Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-service-assurance-
> architecture-11.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Operations and Management Area Working
> Group WG of the IETF.
> 
> Title   : Service Assurance for Intent-based Networking 
> Architecture
> Authors : Benoit Claise
>   Jean Quilbeuf
>   Diego R. Lopez
>   Dan Voyer
>   Thangam Arumugam
>   Filename: draft-ietf-opsawg-service-assurance-architecture-11.txt
>   Pages   : 27
>   Date: 2022-10-18
> 
> Abstract:
>This document describes an architecture that aims at assuring that
>service instances are running as expected.  As services rely upon
>multiple sub-services provided by a variety of elements including the
>underlying network devices and functions, getting the assurance of a
>healthy service is only possible with a holistic view of all involved
>elements.  This architecture not only helps to correlate the service
>degradation with symptoms of a specific network component but also to
>list the services impacted by the failure or degradation of a
>specific network component.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-
> architecture/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-assurance-
> architecture-11
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-
> architecture-11
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

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

___
OPSAWG 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

[Rob Wilton (rwilton)]

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) 
Sent: 21 October 2022 10:41
To: Rob Wilton (rwilton) ; 
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 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://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] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

[Rob Wilton (rwilton)]

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 
> Sent: 21 October 2022 09:37
> To: adr...@olddog.co.uk; Rob Wilton (rwilton) 
> 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

[OPSAWG] AD review of draft-ietf-opsawg-service-assurance-yang-07

[Rob Wilton (rwilton)]

Dear authors,

And here is my corresponding AD review of 
draft-ietf-opsawg-service-assurance-yang-07.  Again, I found the document to be 
well-written, with mostly minor comments/suggestions, bar one question about 
the symptom reference.


Moderate level comments:

(1) p 11, sec 3.3.  YANG Module

  grouping symptom {
description
  "A grouping for the symptoms for a specific subservice.";
leaf symptom-id {
  type leafref {
path "/agents/symptoms-description/symptom-id";
  }
  description
"Identifier of the symptom, to be interpreted according
 to the agent identified by the agent-id.";
}

Should this path be constrained to the specific agent instance identified by 
agent-id?  E.g., similar to how the 'id' path is constrained in 
subservice-reference below.



Minor level comments:

(2) p 2, sec 1.  Introduction

   *  augmentable

Perhaps tie this back to Figure 1 in the SAIN Architecture, which highlights 
the APIs that are documented as YANG modules.


(3) p 4, sec 3.1.  Concepts

   The dependencies are modelled as an adjacency list, in the sense that
   each subservice contains a list of pointers to its dependencies.
   That list can be empty if the subservice instance does not have any
   dependencies.

Perhaps 'references' would be better than 'pointers'.


(4) p 5, sec 3.2.  Tree View

   module: ietf-service-assurance
 +--ro assurance-graph-last-changeyang:date-and-time
 +--rw subservices
 |  +--rw subservice* [type id]
 | +--rw typeidentityref
 | +--rw id  string

I don't really like to mess with the structure of YANG modules during AD (or 
IESG) review, but I wonder whether having type as part of the subservice key 
doesn't end up making it more cumbersome to refer to subservices, and whether a 
flat id space might be better (i.e., removing 'type' from the subservice list 
keys).  But I also don't mind if the author/WG do not want to change the 
structure at this stage.


(5) p 5, sec 3.2.  Tree View

 | +--ro last-change?yang:date-and-time
 | +--ro label?  string
 | +--rw maintenance-contact?string
 | +--rw (parameter)
 | |  +--:(service-instance-parameter)
 | | +--rw service-instance-parameter
 | |+--rw service  string
 | |+--rw instance-namestring
 | +--ro health-score?   union
 | +--ro symptoms-history-start? yang:date-and-time
 | +--ro symptoms
 | |  +--ro symptom* [start-date-time agent-id symptom-id]
 | | +--ro symptom-id
 | | |   -> /agents/symptoms-description/symptom-id
 | | +--ro agent-id   -> /agents/agent-id
 | | +--ro health-score-weight?   uint8
 | | +--ro start-date-timeyang:date-and-time
 | | +--ro stop-date-time?yang:date-and-time
 | +--rw dependencies
 |+--rw dependency* [type id]
 |   +--rw type
 |   |   -> /subservices/subservice/type
 |   +--rw id leafref
 |   +--rw dependency-type?   identityref
 +--ro agents* [agent-id]
 |  +--ro agent-idstring

As a consistency nit, I note that you use "agent-id" here and just "id" under 
subservice.  Possibly using "id" here would be more consistent.  Same comment 
applies to "symptom-id" below.


(6) p 5, sec 3.2.  Tree View

 |  +--ro symptoms-description* [symptom-id]
 | +--ro symptom-id string
 | +--ro descriptionstring

Similar comment as above, did you consider just calling the list "symptoms", 
and the 'symptom-id' just 'id'


(7) p 5, sec 3.2.  Tree View

 +--ro assured-services* [service]
+--ro service  leafref
+--ro instances* [instance-name]
   +--ro instance-nameleafref

Same comment as above, possibly "name" would be sufficient rather than 
"instance-name".


(8) p 5, sec 3.2.  Tree View

   +--ro subservices* [type id]
  +--ro type-> /subservices/subservice/type
  +--ro id  leafref

A couple more consistency questions:
1) I note that subservices has been put into a container, but that agents, 
assured-services are not.
2) The "subservice" list is the singular tense (presumably because it is under 
a container), but agents, assured-services and subservices are not.  I know 
that you have to optimize for XML or JSON readability.


(9) p 6, sec 3.2.  Tree View

   +--ro subservices* [type id]
  +--ro type-> /subservices/subservice/type
  +--ro id  leafref
   The date of last change "assurance-graph-last-change" is read only.
   It must be updated each time the graph structure is changed by
   addition 

[OPSAWG] AD Review of draft-ietf-opsawg-service-assurance-architecture-09

[Rob Wilton (rwilton)]

Hi authors,

Here is my AD review of draft-ietf-opsawg-service-assurance-architecture-09.  I 
would like to thank you and the WG for this document.  I believe that this 
architecture document, and the corresponding YANG document, offer a good 
flexible basis to help with the full lifecycle monitoring of deployed services.

Here are my comments which may help improve the document.


Minor level comments:

(1) p 3, sec 1.  Introduction

   The assurance graph of a service is decomposed into components, which
   are then assured independently.  The root of the assurance graph
   represents the service to assure, and its children represent
   components identified as its direct dependencies; each component can
   have dependencies as well.  Components involved in the assurance
   graph of a service are called subservices.  The SAIN orchestrator
   updates automatically the assurance graph when services are modified.

I was wondering if you meant services or subservices in the last sentence?


(2) p 3, sec 1.  Introduction

   When a service is degraded, the SAIN architecture will highlight
   where in the assurance service graph to look, as opposed to going hop
   by hop to troubleshoot the issue.  More precisely, the SAIN
   architecture will associate to each service a list of symptoms
   originating from specific subservices, corresponding to components of
   the network.  These components are good candidates for explaining the
   source of a service degradation.  Not only can this architecture help
   to correlate service degradation with network root cause/symptoms,
   but it can deduce from the assurance graph the number and type of
   services impacted by a component degradation/failure.  This added
   value informs the operational team where to focus its attention for
   maximum return.  Indeed, the operational team should focus his
   priority on the degrading/failing components impacting the highest
   number customers, especially the ones with the SLA contracts
   involving penalties in case of failure.

Rather than "should focus", perhaps "may focus" or "are likely to focus".  
Also, his => their, number customers -> number of customers


(3) p 4, sec 2.  Terminology

   SAIN agent: A functional component that communicates with a device, a
   set of devices, or another agent to build an expression graph from a
   received assurance graph and perform the corresponding computation of
   the health status and symptoms.

Perhaps consider whether stating that the SAIN agent could run directly on the 
device?  Although I noted that this is described later in the document anyway.


(4) p 5, sec 2.  Terminology

   Metric: An information retrieved from the network running the assured
   service.

Suggest An item of information retrieved, or a piece of data retrieved.


(5) p 5, sec 2.  Terminology

   Health score: Integer ranging from 0 to 100 indicating the health of
   a subservice.  A score of 0 means that the subservice is broken, a
   score of 100 means that the subservice in question is operating as
   expected.

I noted that neither the architecture nor the YANG talk about mapping discrete 
properties (e.g., interface up/down). I would intuitively think that these 
would map to a value of 100 and 0 respectively.  Would it be helpful to add any 
text to describe how binary properties are handled?


(6) p 6, sec 3.  A Functional Architecture

   The goal of SAIN is to assure that service instances are operating as
   expected (i.e. the observed service is matching the expected service)
   and if not, to pinpoint what is wrong.  More precisely, SAIN computes
   a score for each service instance and outputs symptoms explaining
   that score.  Symptoms explain the score.  The only valid situation
   where no symptoms are returned is when the score is maximal,
   indicating that no issues where detected for that service.  The score
   augmented with the symptoms is called the health status.

Symptoms explain the score seems to be a duplicate and can be removed.


(7) p 6, sec 3.  A Functional Architecture

   The SAIN architecture is a generic architecture, applicable to
   multiple environments (e.g. wireline, wireless), but also different
   domains (e.g. 5G network function virtualization (NFV) domain with a
   virtual infrastructure manager (VIM)), etc.  And as already noted,
   for physical or virtual devices, as well as virtual functions.
   Thanks to the distributed graph design principle, graphs from
   different environments/orchestrator can be combined together.

perhaps: combined together -> combined together for a given service.


(8) p 7, sec 3.  A Functional Architecture

  +-+
  | Service |
  | Orchestrator|<+
  | | |
  +-+ |
 |^   |
 || Network   |

Re: [OPSAWG] [Editorial Errata Reported] RFC9291 (7162)

[Rob Wilton (rwilton)]

Yes.  I've just verified it.  Nikolai, thanks for raising it.

Regards,
Rob



From: Joe Clarke (jclarke) 
Sent: 13 October 2022 13:48
To: mohamed.boucad...@orange.com; RFC Errata System 
; nmal...@ieee.org
Cc: luis-angel.mu...@vodafone.com; opsawg@ietf.org; Rob Wilton (rwilton) 

Subject: Re: [Editorial Errata Reported] RFC9291 (7162)

Agreed.  Rob?

Joe

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
mailto:mohamed.boucad...@orange.com>>
Date: Thursday, October 13, 2022 at 7:29 AM
To: RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>>, 
nmal...@ieee.org<mailto:nmal...@ieee.org> 
mailto:nmal...@ieee.org>>
Cc: luis-angel.mu...@vodafone.com<mailto:luis-angel.mu...@vodafone.com> 
mailto:luis-angel.mu...@vodafone.com>>, 
opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Subject: Re: [OPSAWG] [Editorial Errata Reported] RFC9291 (7162)
Hi Nikolai, all,

Thank you for reporting this.

This editorial erratum should be accepted. Thanks.

Cheers,
Med

> -Message d'origine-
> De : RFC Errata System 
> mailto:rfc-edi...@rfc-editor.org>>
> Envoyé : jeudi 13 octobre 2022 13:23
> À : rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>
> Cc : nmal...@ieee.org<mailto:nmal...@ieee.org>; BOUCADAIR Mohamed INNOV/NET
> mailto:mohamed.boucad...@orange.com>>;
> oscar.gonzalezded...@telefonica.com<mailto:oscar.gonzalezded...@telefonica.com>;
> samier.barguilgiraldo@telefonica.com<mailto:samier.barguilgiraldo@telefonica.com>;
>  luis-
> angel.mu...@vodafone.com<mailto:angel.mu...@vodafone.com>; 
> opsawg@ietf.org<mailto:opsawg@ietf.org>
> Objet : [Editorial Errata Reported] RFC9291 (7162)
>
> The following errata report has been submitted for RFC9291, "A
> YANG Network Data Model for Layer 2 VPNs".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7162
>
> --
> Type: Editorial
> Reported by: Nikolai Malykh mailto:nmal...@ieee.org>>
>
> Section: 9
>
> Original Text
> -
>'ethernet-segments' and 'vpn-services':  An attacker who is
> able to
>   access network nodes can undertake various attacks, such as
>   deleting a running L2VPN service, interrupting all the
> traffic of
>   a client.  In addition, an attacker may modify the
> attributes of a
>   running service (e.g., QoS, bandwidth) or an ES, leading to
>   malfunctioning of the service and therefore to SLA
> violations.  In
>   addition, an attacker could attempt to create an L2VPN
> service,
>   add a new network access, or intercept/redirect the traffic
> to a
>   non-authorized node.  In addition to using NACM to prevent
>   authorized access, such activity can be detected by
> adequately
>   monitoring and tracking network configuration changes.
>
>
> Corrected Text
> --
>'ethernet-segments' and 'vpn-services':  An attacker who is
> able to
>   access network nodes can undertake various attacks, such as
>   deleting a running L2VPN service, interrupting all the
> traffic of
>   a client.  In addition, an attacker may modify the
> attributes of a
>   running service (e.g., QoS, bandwidth) or an ES, leading to
>   malfunctioning of the service and therefore to SLA
> violations.  In
>   addition, an attacker could attempt to create an L2VPN
> service,
>   add a new network access, or intercept/redirect the traffic
> to a
>   non-authorized node.  In addition to using NACM to prevent
>   unauthorized access, such activity can be detected by
> adequately
>   monitoring and tracking network configuration changes.
>
>
> Notes
> -
> Typo in last sentence, should be "unauthorized".
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary,
> please use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party can log
> in to change the status and edit the report, if necessary.
>
> --
> RFC9291 (draft-ietf-opsawg-l2nm-19)
> --
> Title   : A YANG Network Data Model for Layer 2 VPNs
> Publication Date: September 2022
> Author(s)   : M. Boucadair, Ed., O. Gonzalez de Dios, Ed.,
> S. Barguil, L. Munoz
> Category: PROPOSED STANDARD
> Source  : Operations and Management Area Working Group
> Area 

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

[Rob Wilton (rwilton)]

Hi Med,

Comments inline below ...

I've snipped out anything that we have already reached agreement on.


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 23 September 2022 14:04
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> sap@ietf.org; opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-sap-09
> 
> Hi Rob,
> 
> Thank you for the review. The changes can be tracked at:
> https://tinyurl.com/sap-latest
> 
> Please note that I made a change to better allow for reuse of the SAP
> information in other modules (this can be tracked here:
> https://github.com/IETF-OPSAWG-
> WG/lxnm/commit/e8b406d7fad5225dd84ad7ff03f6da446eae6736).

Okay.


> 
> Please see inline for more context.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) 
> > Envoyé : vendredi 23 septembre 2022 14:01
> > À : draft-ietf-opsawg-sap@ietf.org; opsawg@ietf.org
> > Objet : AD review of draft-ietf-opsawg-sap-09
> >
> > Hi authors, WG,
> >
> > Thank you for this document.  I also think that this document is
> > well written and in good shape, and I mostly found the
> > explanations and examples clear.  There were two specific points
> > that I found slightly confusing related to differentiating between
> > SAPs in use, and those that are not, and also parent interfaces
> > also be listed as SAPs, details below.
> 
> [Med] Thanks
> 
> >
> > Moderate level comments:
> >
> > (1) p 10, sec 5.  SAP Module Tree Structure
> >
> >   SAPs that are associated with the interfaces that are
> > directly
> >   hosting services, interfaces that are ready to host per-
> > service
> >   sub-interfaces (but not yet activated), or service that are
> >   already instantiated on sub-interfaces are listed as SAPs.
> >
> > >From the model, is isn't clear to me how different differentiates
> > between a SAP that has been pre-provisioned to potentially be used
> > for a service in future, v.s., one is that is actively
> > provisioned.
> 
> [Med] This is inferred from the service-status=down for these SAPs.

So, thinking of this at device level configuration there is effectively 3 
levels of configuration/activation (at least for L2VPNs):

(1) A sub-interface is configured, but without any IP address or VRF (for 
L3VPN), or without being attached to an L2VPN or Bridge Domain (for L2VPNs).  
I.e., the sub-interface isn't connected anyway.
(2) The sub-interface is configured and connected into a bridge domain or P2P 
L2VPN but that service is down (e.g., perhaps because the AC at the remote end 
of the L2VPN is physically down).
(3) The sub-interface is configured and connected into a bridge domain or P2P 
L2VPN and that service is up.

I think that you are saying that you regard that both (1) and (2) would be 
indicated by service-status=down?  Would it be worth expanding the description 
at all to make this more explicit?  But I'm still not convinced this will be 
sufficient (e.g., see my following response below related to the example for 
selecting a service).

> 
> 
>   I think that it would be helpful if these two cases
> > can be clearly distinguished.  Note, I have made a similar comment
> > related to appendix D about identifying a "free" SAP.
> 
> [Med] Added this NEW to the appendix:
> 
> "SAPs that are ready to host per-service (but not yet activated) are 
> identified
> by the "service-status" set to "ietf-vpn-common:op-down"."

But how do you distinguish between a SAP that hasn't been provisioned yet to a 
service vs a SAP that has been provisioned but the service is down?  E.g., 
trying to find a free SAP just by looking for a SAP with a service-status of 
op-down doesn't appear to be sufficient on its own.



> 
> >
> >
> > (2) p 28, sec Appendix B.  A Simple Example of SAP Network Model:
> > Node Filter
> >
> 
> [Med] Please note "Simple" in the title :-)

OK, noted. ;-)


> 
> >A service orchestrator can query what services are provided on
> > which
> >SAPs of PE1 from the network controller by sending, e.g., a GET
> >RESTCONF request.  Figure 9 shows the body of the RESTCONF
> > response
> >that is received from the network controller.
> >
> > In this example, you have GE0/6/4 as being ready to host SAPs, but
> > I could equally imagine that given GE0/6/4 is just a UNI, then you
> > may not want the parent interface to be available to host SAPs
> > directly at all.  I.e., it may always the case that sub-interfaces
> > are used as SAPs.  Hence, did you consider whether i

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

[Rob Wilton (rwilton)]

Hi authors, WG,

Thank you for this document.  I also think that this document is well written 
and in good shape, and I mostly found the explanations and examples clear.  
There were two specific points that I found slightly confusing related to 
differentiating between SAPs in use, and those that are not, and also parent 
interfaces also be listed as SAPs, details below.

Moderate level comments:

(1) p 10, sec 5.  SAP Module Tree Structure

  SAPs that are associated with the interfaces that are directly
  hosting services, interfaces that are ready to host per-service
  sub-interfaces (but not yet activated), or service that are
  already instantiated on sub-interfaces are listed as SAPs.

>From the model, is isn't clear to me how different differentiates between a 
>SAP that has been pre-provisioned to potentially be used for a service in 
>future, v.s., one is that is actively provisioned.  I think that it would be 
>helpful if these two cases can be clearly distinguished.  Note, I have made a 
>similar comment related to appendix D about identifying a "free" SAP.


(2) p 28, sec Appendix B.  A Simple Example of SAP Network Model: Node Filter

   A service orchestrator can query what services are provided on which
   SAPs of PE1 from the network controller by sending, e.g., a GET
   RESTCONF request.  Figure 9 shows the body of the RESTCONF response
   that is received from the network controller.

In this example, you have GE0/6/4 as being ready to host SAPs, but I could 
equally imagine that given GE0/6/4 is just a UNI, then you may not want the 
parent interface to be available to host SAPs directly at all.  I.e., it may 
always the case that sub-interfaces are used as SAPs.  Hence, did you consider 
whether it makes sense for there to be a different category of SAP 
service-types for UNI's and NNI's that don't host services directly on the 
interface, but always on sub-interfaces?  Related to this, it feels slightly 
strange to me to have GE0/6/4 listed under both l3vpn and vpls SAP lists.  
Having the same information twice in the data model introduces the risk that a 
device could export inconsistent information and hence it hard for the customer 
to know which data is accurate.  I can understand why having it twice might be 
convenient, but having an indication that it is actually just a container node 
for SAPs rather than a SAP itself might be better.



Minor level comments:

(3) p 3, sec 3.  Sample SAP Network Model Usage

   Management operations of a service provider network can be automated
   using a variety of means such as interfaces based on YANG modules
   [RFC8969].

Would a reference to NETCONF and potentially RESTCONF be helpful here in 
addition to RFC8969?


(4) p 4, sec 3.  Sample SAP Network Model Usage

   The service orchestration layer does not need to know about the
   internals of the underlying network (e.g., P nodes).

Would "all the internals" be better than just "internals".  I.e., presumably 
the service orchestration layer probably does need to know about some of the 
internals of the underlying network.


(5) p 10, sec 5.  SAP Module Tree Structure

   These service types build on the types that are already defined in
   [RFC9181] and additional types that are defined in this document.
   Other service types can be defined in future YANG modules, if needed.

In future YANG modules, or perhaps also future versions of the YANG model 
defined in this document?


(6) p 11, sec 5.  SAP Module Tree Structure

  This data node can be used, for example, to decide whether an
  existing SAP can be (re)used to host a service or if a new sub-
  interface has to be instantiated.

So, is this field effectively also being used to determine if the SAP is in use?


(7) p 12, sec 5.  SAP Module Tree Structure

  When both a sub-interface and its parent interface are present,
  the status of the parent interface takes precedence over the
  status indicated for the sub-interface.

This seems strange to me.  E.g., if the parent-interface was up, but the 
sub-interface was administratively down then would you be expected to report 
the sap-status as up?  I would think that this should always be reporting the 
sub-interface state, but that the sub-interface state should inherit


(8) p 16, sec 6.  SAP YANG Module

 identity logical {
   base interface-type;
   description
 "Refers to a logical sub-interface that is typically
  used to bind a service. This type is used only
  if none of the other logical types can be used.";
 }

Perhaps clarify what you mean by "other logical types".  E.g., do you just mean 
loopback or irb, or does this include local-bridge as well?


(9) p 17, sec 6.  SAP YANG Module

 leaf peer-sap-id {
   type string;
   description
 "Indicates an identifier of the peer's termination
  identifier (e.g., Customer Edge (CE)). This
   

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

[Rob Wilton (rwilton)]

Hi Tom,

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

Thanks,
Rob


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

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

[Rob Wilton (rwilton)]

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?

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

Rob 



> -Original Message-
> From: Adrian Farrel 
> Sent: 16 September 2022 10:34
> 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.
> 
> 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  On Behalf Of tom petch
> Sent: 15 September 2022 11:37
> To: 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
> 
> 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 e

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

[Rob Wilton (rwilton)]

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.

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 (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 thou

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

[Rob Wilton (rwilton)]

Hi Bo, authors,

Okay, thanks for the clarifications.  Please see inline …


From: Wubo (lana) 
Sent: 14 September 2022 15:31
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,

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 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 tim

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

[Rob Wilton (rwilton)]

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) 
Sent: 14 September 2022 09:25
To: Rob Wilton (rwilton) ; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
Cc: 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:

I’m not really concerned about whether the data can be gathered at the same 
time (i.e., in the same request), but I would have thought that it is likely 
that some operators may want to do PM at both the network and overlay at the 
same time.

If you take the diagram in 4.1, that shows an underlay network with two VPN1 
and VPN2 service overlays, then am I right to assume that they will be modelled 
as 3 separate list entries in the /nw:networks/nw:network/ list, one 

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

[Rob Wilton (rwilton)]

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) 
Sent: 13 September 2022 07:38
To: Rob Wilton (rwilton) ; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
Cc: 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.







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









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



Looks good.  Thanks.





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



  A

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

[Rob Wilton (rwilton)]

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.


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


(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?


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


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


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


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


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

   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 provide
   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.  Figure 4
   illustrates an example of VPN PM and the difference between two VPN
   PM measurement methods.  One is the VPN tunnel PM and the other is
   inter-VPN-access interface PM.

By "VPN Network PM", do you mean the "VPN Network PM YANG module", or is this 
just referring to performance monitoring in general?


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

   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, 

Re: [OPSAWG] Checking in on draft-ietf-opsawg-yang-vpn-service-pm

[Rob Wilton (rwilton)]

Hi Adrian, and authors,

Sorry, this is me catching up with after summer holidays.  But the IESG 
telechat reviews for this week have been light, so I should get my AD review 
completed this week.

Thanks,
Rob


-Original Message-
From: Adrian Farrel  
Sent: 05 September 2022 20:48
To: Rob Wilton (rwilton) 
Cc: draft-ietf-opsawg-yang-vpn-service-pm@ietf.org; opsawg@ietf.org
Subject: RE: [OPSAWG] Checking in on draft-ietf-opsawg-yang-vpn-service-pm

Hi Rob,

Here is your monthly reminder that we await the next steps with this draft.
We're now at the three month since the publication request, and more than
six weeks in "AD review" state.

Please do let us know if there is anything we can do to help advance this
work.

Thanks,
Adrian (as Shepherd)

-Original Message-
From: OPSAWG  On Behalf Of Adrian Farrel
Sent: 05 August 2022 14:03
To: 'Rob Wilton (rwilton)' 
Cc: draft-ietf-opsawg-yang-vpn-service-pm@ietf.org; opsawg@ietf.org
Subject: [OPSAWG] Checking in on draft-ietf-opsawg-yang-vpn-service-pm

Hi Rob,

Just doing my document shepherd thing and checking in with you.

Publication request was made for this document on 6th June. So we're at our
two-month marker.

I very much appreciate the thoroughness with which you review drafts, and I
understand the "gatekeeper role" of the IESG, but this may be a case where
you need to "get out of the way" a bit.

Perhaps you could consider doing your review in parallel with IETF last call
so as not to hold up the document any further.

Thanks,
Adrian

___
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] OFFLIST TR: New Version Notification for draft-ietf-opsawg-l2nm-13.txt

[Rob Wilton (rwilton)]

Hi Med,

Indeed.  I've requested IETF LC.

Thank you, the other authors, and WG for their work on this model.  And 
apologies for the slightly slow interactions during the AD review.  I do 
believe that this work is an important piece in an overall network management 
architecture solution. 

Regards,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 29 April 2022 14:00
> To: Rob Wilton (rwilton) 
> Cc: opsawg@ietf.org
> Subject: RE: OFFLIST TR: New Version Notification for draft-ietf-opsawg-
> l2nm-13.txt
> 
> Re-,
> 
> Thanks Rob for checking.
> 
> A new version that implements the remaining changes is now online.
> 
> I think that we are now ready for the IETF LC.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) 
> > Envoyé : vendredi 29 avril 2022 14:29
> > À : BOUCADAIR Mohamed INNOV/NET
> 
> > Cc : opsawg@ietf.org
> > Objet : RE: OFFLIST TR: New Version Notification for draft-ietf-
> > opsawg-l2nm-13.txt
> >
> > Hi Med,
> >
> > >- translate 2 with tag-2 leaf is
> > >  provided: the outer tag is
> > popped
> > >  while the inner tag is
> > translated.";
> >
> > I think that using tag-1 leaf would be more consistent with other
> > models and the CLis that I am familiar with - but possibly that is
> > vendor bias.  I.e., I would think that generally that tag-2 can
> > only be configured if tag-1 is also configured.
> >
> > E.g., I think that this would be:
> >
> > - translate 2 with tag-1 leaf is
> >   provided: the outer tag is
> > popped
> >   while the inner tag is
> > translated to the value in tag-1";
> >
> > But I'm okay to leave this to you - since the behaviour is well
> > specified either way.
> >
> > Thanks,
> > Rob
> >
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > 
> > > Sent: 29 April 2022 11:23
> > > To: Rob Wilton (rwilton) 
> > > Cc: opsawg@ietf.org
> > > Subject: RE: OFFLIST TR: New Version Notification for
> > > draft-ietf-opsawg- l2nm-13.txt
> > >
> > > Re-,
> > >
> > > > I'm not that keen to binding the behaviour to the type of the
> > tag, I
> > > > think that what I suggested previously of indicating the
> > number of
> > > > tags being translated would end up being simpler and easier to
> > > > understand, and besides I think that sometimes implementations
> > want
> > > > to change both the tag type and value.
> > >
> > > Noted.
> > >
> > > What about the following:
> > >
> > >   leaf translate {
> > > type uint8 {
> > >   range "1|2";
> > > }
> > > description
> > >   "Translate one or two outer tags.
> > PCP
> > >bits are preserved.
> > >
> > >The following operations are
> > >supported:
> > >
> > >- translate 1 with tag-1 leaf is
> > >  provided: only the outermost
> > tag is
> > >  translated.
> > >
> > >- translate 2 with both tag-1 and
> > >  tag-2 leaves are provided: both
> > >  inner and outer tags are
> > translated.
> > >
> > >- translate 2 with tag-2 leaf is
> > >  provided: the outer tag is
> > popped
> > >  while the inner tag is
> > translated.";
> > >   }
> > > }
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : Rob Wilton (rwilton)  Envoyé :
> > vendredi 29
> > > > avril 2022 11:51 À : BOUCADAIR Mohamed INNOV/NET
> > > 
> > > > Cc : opsawg@ietf.org
> > > > Objet

Re: [OPSAWG] OFFLIST TR: New Version Notification for draft-ietf-opsawg-l2nm-13.txt

[Rob Wilton (rwilton)]

Hi Med,

>- translate 2 with tag-2 leaf is
>  provided: the outer tag is popped
>  while the inner tag is translated.";

I think that using tag-1 leaf would be more consistent with other models and 
the CLis that I am familiar with - but possibly that is vendor bias.  I.e., I 
would think that generally that tag-2 can only be configured if tag-1 is also 
configured.

E.g., I think that this would be:

- translate 2 with tag-1 leaf is
  provided: the outer tag is popped
  while the inner tag is translated to the 
value in tag-1";

But I'm okay to leave this to you - since the behaviour is well specified 
either way.

Thanks,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 29 April 2022 11:23
> To: Rob Wilton (rwilton) 
> Cc: opsawg@ietf.org
> Subject: RE: OFFLIST TR: New Version Notification for draft-ietf-opsawg-
> l2nm-13.txt
> 
> Re-,
> 
> > I'm not that keen to binding the behaviour to the type of the tag,
> > I think that what I suggested previously of indicating the number
> > of tags being translated would end up being simpler and easier to
> > understand, and besides I think that sometimes implementations
> > want to change both the tag type and value.
> 
> Noted.
> 
> What about the following:
> 
>   leaf translate {
> type uint8 {
>   range "1|2";
> }
> description
>   "Translate one or two outer tags. PCP
>bits are preserved.
> 
>The following operations are
>supported:
> 
>- translate 1 with tag-1 leaf is
>  provided: only the outermost tag is
>  translated.
> 
>- translate 2 with both tag-1 and
>  tag-2 leaves are provided: both
>  inner and outer tags are translated.
> 
>- translate 2 with tag-2 leaf is
>  provided: the outer tag is popped
>              while the inner tag is translated.";
>   }
> }
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) 
> > Envoyé : vendredi 29 avril 2022 11:51
> > À : BOUCADAIR Mohamed INNOV/NET
> 
> > Cc : opsawg@ietf.org
> > Objet : RE: OFFLIST TR: New Version Notification for draft-ietf-
> > opsawg-l2nm-13.txt
> >
> > Hi Med,
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > 
> > > Sent: 29 April 2022 10:45
> > > To: Rob Wilton (rwilton) 
> > > Cc: opsawg@ietf.org
> > > Subject: RE: OFFLIST TR: New Version Notification for
> > > draft-ietf-opsawg- l2nm-13.txt
> > >
> > > Hi Rob,
> > >
> > > What we had in mind is as follows:
> > >
> > > The following operations are
> > > supported: (1) Translate both the
> > > inner and outer tags. This operation
> > > requires providing both tag-1 and
> > > tag-2 leaves. (2) Translate only the
> > > outer tag. This operation requires
> > > providing one tag with the same type
> > > as the outer tag. (3) Translate the
> > > inner tag while popping the outer tag.
> > > This operation requires providing one
> > > tag having the same type as the inner
> > > tag.";
> > >
> > > I can update the description with this text.
> >
> > I'm not that keen to binding the behaviour to the type of the tag,
> > I think that what I suggested previously of indicating the number
> > of tags being translated would end up being simpler and easier to
> > understand, and besides I think that sometimes implementations
> > want to change both the tag type and value.
> >
> > Thanks,
> > Rob
> >
> >
> >
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : Rob Wilton (rwilton)  Envoyé :
> > vendredi 29
> > > > avril 2022 11:18 À : BOUCADAIR Mohamed INN

Re: [OPSAWG] OFFLIST TR: New Version Notification for draft-ietf-opsawg-l2nm-13.txt

[Rob Wilton (rwilton)]

Hi Med,

> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 29 April 2022 10:45
> To: Rob Wilton (rwilton) 
> Cc: opsawg@ietf.org
> Subject: RE: OFFLIST TR: New Version Notification for draft-ietf-opsawg-
> l2nm-13.txt
> 
> Hi Rob,
> 
> What we had in mind is as follows:
> 
> The following operations are
> supported: (1) Translate both the
> inner and outer tags. This operation
> requires providing both tag-1 and
> tag-2 leaves. (2) Translate only the
> outer tag. This operation requires
> providing one tag with the same type
> as the outer tag. (3) Translate the
> inner tag while popping the outer tag.
> This operation requires providing one
> tag having the same type as the inner
> tag.";
> 
> I can update the description with this text.

I'm not that keen to binding the behaviour to the type of the tag, I think that 
what I suggested previously of indicating the number of tags being translated 
would end up being simpler and easier to understand, and besides I think that 
sometimes implementations want to change both the tag type and value.

Thanks,
Rob



> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) 
> > Envoyé : vendredi 29 avril 2022 11:18
> > À : BOUCADAIR Mohamed INNOV/NET
> 
> > Cc : opsawg@ietf.org
> > Objet : RE: OFFLIST TR: New Version Notification for draft-ietf-
> > opsawg-l2nm-13.txt
> >
> > Hi Med,
> >
> > Please see inline ...
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > 
> > > Sent: 28 April 2022 15:53
> > > To: Rob Wilton (rwilton) 
> > > Cc: opsawg@ietf.org
> > > Subject: RE: OFFLIST TR: New Version Notification for
> > > draft-ietf-opsawg- l2nm-13.txt
> > >
> > > Re-,
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : Rob Wilton (rwilton)  Envoyé : jeudi
> > 28
> > > > avril 2022 16:23 À : BOUCADAIR Mohamed INNOV/NET
> > > 
> > > > Cc : opsawg@ietf.org
> > > > Objet : RE: OFFLIST TR: New Version Notification for draft-
> > ietf-
> > > > opsawg-l2nm-13.txt
> > > >
> > > > Hi Med,
> > > >
> > > > Just one further tweak under QinQ:
> > > >
> > > >  leaf translate {
> > > >type empty;
> > > >description
> > > >  "Translate one or two outer
> > tags.
> > > > PCP
> > > >bits are preserved.";
> > > >  }
> > > >
> > > > Do you need to change this to:
> > > >
> > > >  leaf translate {
> > > >type uint8 {
> > > >  range "1|2";
> > > >}
> > > >description
> > > >  "Translate one or two outer
> > tags.
> > > > PCP
> > > >bits are preserved.";
> > > >  }
> > > >
> > > > To indicate whether it is one or two outer tags that are being
> > > > translated?
> > > >
> > >
> > > [Med] The presence of tag-1/type and/are tag-2/type is redundant
> > with
> > > indicating it in the range. No?
> >
> > Ah, okay.
> >
> > The distinction I was trying to draw was how many tags are being
> > logically removed and how many are being logically, with the
> > assumption that if a tag is being both removed and added then in
> > essence it is translated and the PCP bits are preserved.  E.g.,
> > you could just model a translate using push 1 or 2 new tags and
> > pop 1 or 2 tags, which IIRC, is how I model it in the VLAN sub-
> > interface YANG draft.
> >
> > With regards to your model above:
> >
> > When you have only one tag (e.g., under dot1q) then you allow that
> > single tag to be rewritten (translated) to one or two new tags.
> >
> > In the QinQ case, do you ever want to allow that same behaviour?
> > I.e., allow only the outer tag to be rewritten (translated)

Re: [OPSAWG] OFFLIST TR: New Version Notification for draft-ietf-opsawg-l2nm-13.txt

[Rob Wilton (rwilton)]

Hi Med,

Please see inline ...

> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 28 April 2022 15:53
> To: Rob Wilton (rwilton) 
> Cc: opsawg@ietf.org
> Subject: RE: OFFLIST TR: New Version Notification for draft-ietf-opsawg-
> l2nm-13.txt
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-
> > De : Rob Wilton (rwilton) 
> > Envoyé : jeudi 28 avril 2022 16:23
> > À : BOUCADAIR Mohamed INNOV/NET
> 
> > Cc : opsawg@ietf.org
> > Objet : RE: OFFLIST TR: New Version Notification for draft-ietf-
> > opsawg-l2nm-13.txt
> >
> > Hi Med,
> >
> > Just one further tweak under QinQ:
> >
> >  leaf translate {
> >type empty;
> >description
> >  "Translate one or two outer tags.
> > PCP
> >bits are preserved.";
> >  }
> >
> > Do you need to change this to:
> >
> >  leaf translate {
> >type uint8 {
> >  range "1|2";
> >}
> >description
> >  "Translate one or two outer tags.
> > PCP
> >bits are preserved.";
> >  }
> >
> > To indicate whether it is one or two outer tags that are being
> > translated?
> >
> 
> [Med] The presence of tag-1/type and/are tag-2/type is redundant with
> indicating it in the range. No?

Ah, okay.

The distinction I was trying to draw was how many tags are being logically 
removed and how many are being logically, with the assumption that if a tag is 
being both removed and added then in essence it is translated and the PCP bits 
are preserved.  E.g., you could just model a translate using push 1 or 2 new 
tags and pop 1 or 2 tags, which IIRC, is how I model it in the VLAN 
sub-interface YANG draft.

With regards to your model above:

When you have only one tag (e.g., under dot1q) then you allow that single tag 
to be rewritten (translated) to one or two new tags.

In the QinQ case, do you ever want to allow that same behaviour?  I.e., allow 
only the outer tag to be rewritten (translated) with two tags (i.e., which 
would presumably end up with at least 3 tags on the packet).  Or the reverse 
behaviour where you match 2 tags and want to replace both tags with a single 
new tag?

Hence, it is unclear to me what translate operations you actually support for 
QinQ, and also whether you want to add more flexibility that what you currently 
have.  But either way, I think that we need to elaborate the description to 
ensure that semantics/behaviour is really specific.

Thanks,
Rob


> 
> > E.g., trans-1-2 would be translate 1 with both tag-1/tag-1-type
> > and tag-2/tag-2-type pushed tags.  Trans-2-2 would be translate 2
> > + tag-1/tag-1-type and tag-2/tag-2-type.  Trans-2-1 would be
> > translate 2 + tag-1/tag-1-type.
> >
> > Perhaps in the descriptions for tag-1/tag-2 indicate that tag-1-
> > type etc must be specified (or maybe add must statements to
> > enforce this)?  Alternatively could add defaults so that tag-1-
> > type defaults to S-VLAN and tag-2-type defaults to C-VLAN?
> >
> 
> [Med] I like using defaults. Thanks.
> 
> > Otherwise, I think that all other changes look good.
> >
> > Regards,
> > Rob
> >
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > 
> > > Sent: 28 April 2022 13:41
> > > To: Rob Wilton (rwilton) 
> > > Cc: opsawg@ietf.org
> > > Subject: RE: OFFLIST TR: New Version Notification for
> > > draft-ietf-opsawg- l2nm-13.txt
> > >
> > > Re-,
> > >
> > > All good comments. Many thanks.
> > >
> > > The new version -14 tries to address these comments, in
> > particular:
> > > * use ieee802-dot1q-types
> > > * add explicit nodes to indicate the tag types of the
> > manipulated
> > > tagged
> > > * add the various clarification
> > >
> > > The changes can be tracked at:
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-
> > > opsawg-l2nm-14
> > >
> > > Please let me know if any further change is needed.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> >

Re: [OPSAWG] OFFLIST TR: New Version Notification for draft-ietf-opsawg-l2nm-13.txt

[Rob Wilton (rwilton)]

Hi Med,

I think that this should be a normative reference, but I don’t think that 
should be a problem.

Regards,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 29 April 2022 07:34
> To: Rob Wilton (rwilton) ; adr...@olddog.co.uk
> Cc: opsawg@ietf.org
> Subject: RE: OFFLIST TR: New Version Notification for draft-ietf-opsawg-
> l2nm-13.txt
> 
> Hi Rob, Adrian,
> 
> As you may note in -14, the following reference:
> 
>[IEEE802.1Qcp-2018]
>   IEEE, "IEEE Standard for Local and metropolitan area
>   networks--Bridges and Bridged Networks--Amendment 30: YANG
>   Data Model", September 2018,
>   <https://ieeexplore.ieee.org/document/8467507>.
> 
> is listed as informative. The rationale was to align with what i2rs did (they
> discussed this specific point in the context of RFC 8944).
> 
> Please advise if you think that we should change that. Thanks.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : BOUCADAIR Mohamed INNOV/NET
> > Envoyé : jeudi 28 avril 2022 16:53
> > À : 'Rob Wilton (rwilton)' 
> > Cc : opsawg@ietf.org
> > Objet : RE: OFFLIST TR: New Version Notification for draft-ietf-
> > opsawg-l2nm-13.txt
> >
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Rob Wilton (rwilton)  Envoyé : jeudi 28
> > avril
> > > 2022 16:23 À : BOUCADAIR Mohamed INNOV/NET
> > >  Cc : opsawg@ietf.org Objet : RE:
> > > OFFLIST TR: New Version Notification for draft-ietf-
> > > opsawg-l2nm-13.txt
> > >
> > > Hi Med,
> > >
> > > Just one further tweak under QinQ:
> > >
> > >  leaf translate {
> > >type empty;
> > >description
> > >  "Translate one or two outer
> > tags.
> > > PCP
> > >bits are preserved.";
> > >  }
> > >
> > > Do you need to change this to:
> > >
> > >  leaf translate {
> > >type uint8 {
> > >  range "1|2";
> > >}
> > >description
> > >  "Translate one or two outer
> > tags.
> > > PCP
> > >bits are preserved.";
> > >  }
> > >
> > > To indicate whether it is one or two outer tags that are being
> > > translated?
> > >
> >
> > [Med] The presence of tag-1/type and/are tag-2/type is redundant
> > with indicating it in the range. No?
> >
> > > E.g., trans-1-2 would be translate 1 with both tag-1/tag-1-type
> > and
> > > tag-2/tag-2-type pushed tags.  Trans-2-2 would be translate 2
> > > + tag-1/tag-1-type and tag-2/tag-2-type.  Trans-2-1 would be
> > > translate 2 + tag-1/tag-1-type.
> > >
> > > Perhaps in the descriptions for tag-1/tag-2 indicate that tag-1-
> > type
> > > etc must be specified (or maybe add must statements to enforce
> > this)?
> > > Alternatively could add defaults so that tag-1- type defaults to
> > > S-VLAN and tag-2-type defaults to C-VLAN?
> > >
> >
> > [Med] I like using defaults. Thanks.
> >
> > > Otherwise, I think that all other changes look good.
> > >
> > > Regards,
> > > Rob
> > >
> > >
> > > > -Original Message-
> > > > From: mohamed.boucad...@orange.com
> > > > 
> > > > Sent: 28 April 2022 13:41
> > > > To: Rob Wilton (rwilton) 
> > > > Cc: opsawg@ietf.org
> > > > Subject: RE: OFFLIST TR: New Version Notification for
> > > > draft-ietf-opsawg- l2nm-13.txt
> > > >
> > > > Re-,
> > > >
> > > > All good comments. Many thanks.
> > > >
> > > > The new version -14 tries to address these comments, in
> > > particular:
> > > > * use ieee802-dot1q-types
> > > > * add explicit nodes to indicate the tag types of the
> > > manipulated
> > > > tagged
> > > > * add the various clarification
> > > >
> > > >

Re: [OPSAWG] OFFLIST TR: New Version Notification for draft-ietf-opsawg-l2nm-13.txt

[Rob Wilton (rwilton)]

Hi Med,

Just one further tweak under QinQ:

 leaf translate {
   type empty;
   description
 "Translate one or two outer tags. PCP
   bits are preserved.";
 }

Do you need to change this to:

 leaf translate {
   type uint8 {
 range "1|2";
   }
   description
 "Translate one or two outer tags. PCP
   bits are preserved.";
 }

To indicate whether it is one or two outer tags that are being translated?

E.g., trans-1-2 would be translate 1 with both tag-1/tag-1-type and 
tag-2/tag-2-type pushed tags.  Trans-2-2 would be translate 2 + 
tag-1/tag-1-type and tag-2/tag-2-type.  Trans-2-1 would be translate 2 + 
tag-1/tag-1-type.

Perhaps in the descriptions for tag-1/tag-2 indicate that tag-1-type etc must 
be specified (or maybe add must statements to enforce this)?  Alternatively 
could add defaults so that tag-1-type defaults to S-VLAN and tag-2-type 
defaults to C-VLAN?

Otherwise, I think that all other changes look good.

Regards,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 28 April 2022 13:41
> To: Rob Wilton (rwilton) 
> Cc: opsawg@ietf.org
> Subject: RE: OFFLIST TR: New Version Notification for draft-ietf-opsawg-
> l2nm-13.txt
> 
> Re-,
> 
> All good comments. Many thanks.
> 
> The new version -14 tries to address these comments, in particular:
> * use ieee802-dot1q-types
> * add explicit nodes to indicate the tag types of the manipulated tagged
> * add the various clarification
> 
> The changes can be tracked at: https://www.ietf.org/rfcdiff?url2=draft-ietf-
> opsawg-l2nm-14
> 
> Please let me know if any further change is needed.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) 
> > Envoyé : mercredi 27 avril 2022 16:03
> > À : BOUCADAIR Mohamed INNOV/NET
> 
> > Cc : opsawg@ietf.org
> > Objet : RE: OFFLIST TR: New Version Notification for draft-ietf-
> > opsawg-l2nm-13.txt
> >
> > Hi Med,
> >
> > I've replied back separately on the 2b comments.
> >
> > I've also includes some further comments on the VLAN tag
> > manipulations here:
> >
> > - The description for leaf push (for both dot1q and qinq) might be
> > better as "push one or two tags defined by the tag-1 and tag-2
> > leaves".
> > - For tag-1 and tag-2 it might be helpful to be explicit which of
> > those tags is outermost when written in the Ethernet/802.1Q frame
> > header.
> > - For the vlan ids, should they be restricted to 1..4094 (or you
> > could reuse the vlanid type from here
> > https://github.com/YangModels/yang/blob/main/standard/ieee/publish
> > ed/802.1/ieee802-dot1q-types.yang).
> > - The model doesn’t indicate whether the outer/inner tags that are
> > pushed are C-VLAN or S-VLAN tags.  In the case where two tags are
> > pushed I would assume that it would be an outer S-VLAN followed by
> > a inner C-VLAN, but it is somewhat ambiguous is only a single tag
> > is being pushed.  I think that it would be helpful for the model
> > to specify the behaviour here.
> > - Should the model say anything about the PCP bits if a tag is
> > pushed (i.e., are then just left as 0 unless explicitly set by a
> > QoS policy).  Also what is the behaviour on a translate, are the
> > PCP bits in the header preserved?
> > - For QinQ, is only a single outer tag allowed to be translated,
> > if so the description should be "translate the outer tag",
> > alternatively, the type could be changed to uint16 to allow the
> > number of tags to be translated to be specified.
> >
> > I've also checked the diffs between -12 and -13 and then look good
> > to me, except that I had one further comment on the CoS:
> >
> > case other {
> >  description
> >"Other bandwidth types.";
> >  uses bandwidth-parameters;
> >}
> >
> > Is it possible to have a more descriptive name/description instead
> > of "other"? E.g., cos-unaware?  Even if you keep the existing
> > name, expanding the description slightly might be helpful.
> >
> > Thanks,
> > Rob
> >
> >
>

Re: [OPSAWG] AD review of draft-ietf-opsawg-l2nm-12 (2n Part)

[Rob Wilton (rwilton)]

Hi Med,

Thanks, just ack'ing that I agree with your proposed fixes, and sorry for 
getting the terminology mixed up.

Thanks,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 28 April 2022 12:27
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> l2nm@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
> 
> Hi Rob,
> 
> Thank you for the follow-up.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) 
> > Envoyé : mercredi 27 avril 2022 14:38
> > À : BOUCADAIR Mohamed INNOV/NET
> ;
> > draft-ietf-opsawg-l2nm@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : RE: AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
> >
> > Hi Med,
> >
> > Catching up with email, sorry for the delay, please see further
> > comments inline ...
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > 
> > > Sent: 05 April 2022 11:40
> > > To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> > > l2nm@ietf.org
> > > Cc: opsawg@ietf.org
> > > Subject: RE: AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
> > >
> > > Hi Rob,
> > >
> > > Focusing on the first part of your review, except point (9).
> > >
> > > The changes can be tracked at: https://github.com/IETF-OPSAWG-
> > > WG/lxnm/commit/337f65012f55e71df4105481bc28fe53ac8bb302, while
> > the
> > > full changes made so far can be tracked at:
> > > https://tinyurl.com/l2nm-latest
> > >
> > > Please see inline for more context.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : Rob Wilton (rwilton)  Envoyé : jeudi
> > 17 mars
> > > > 2022 21:53 À : draft-ietf-opsawg-l2nm@ietf.org
> > > > Cc : opsawg@ietf.org
> > > > Objet : AD review of draft-ietf-opsawg-l2nm-12
> > > >
> > > > Hi,
> > > >
> > > > Apologies for the delay, but I have now managed my AD review
> > of
> > > > draft- ietf-opsawg-l2nm-12.  (Also attached in case my email
> > is
> > > > truncated ...)
> > > >
> > > > I would like to thank the authors, WG for their work on this
> > > > document, and the shepherd for his review.  I found the
> > document to
> > > > be well written and pretty straightforward to follow and
> > understand.
> > > > I also believe that this document is a useful addition to the
> > YANG
> > > > and Network Management Ecosystem, to thank you for that.
> > > >
> > > > Anyway, here my comments.  I think that they mostly pretty
> > minor,
> > > > but perhaps a few that my need a bit more thought.  Hopefully
> > they
> > > > will help improve the doc.
> > > >
> > > > ---
> > > >
> > > > Moderate comments:
> > > >
> > > > (1)
> > > >The VPN network access is comprised of:
> > > >
> > > >'id':  Includes an identifier of the VPN network access.
> > > >
> > > >'description':  Includes a textual description of the VPN
> > > > network
> > > >   access.
> > > >
> > > >'interface-id':  Indicates the interface on which the VPN
> > > > network
> > > >   access is bound.
> > > >
> > > >'global-parameters-profile':  Provides a pointer to an
> > active
> > > >   'global-parameters-profile' at the VPN node level.
> > > > Referencing an
> > > >   active 'global-parameters-profile' implies that all
> > associated
> > > >   data nodes will be inherited by the VPN network
> > access.
> > > > However,
> > > >   some of the inherited data nodes (e.g., ACL policies)
> > can be
> > > >   overridden at the VPN network access level.  In such
> > case,
> > > >   adjusted values take precedence over inherited ones.
> > > >
> > > > It wasn't entirely clear to me how this works with the global
> > > > parameters defined at the VPN network access level and the VPN
> > node
> > > > level work.  Is this meant to be 

Re: [OPSAWG] OFFLIST TR: New Version Notification for draft-ietf-opsawg-l2nm-13.txt

[Rob Wilton (rwilton)]

Hi Med,

I've replied back separately on the 2b comments.

I've also includes some further comments on the VLAN tag manipulations here:

- The description for leaf push (for both dot1q and qinq) might be better as 
"push one or two tags defined by the tag-1 and tag-2 leaves".
- For tag-1 and tag-2 it might be helpful to be explicit which of those tags is 
outermost when written in the Ethernet/802.1Q frame header.
- For the vlan ids, should they be restricted to 1..4094 (or you could reuse 
the vlanid type from here 
https://github.com/YangModels/yang/blob/main/standard/ieee/published/802.1/ieee802-dot1q-types.yang).
- The model doesn’t indicate whether the outer/inner tags that are pushed are 
C-VLAN or S-VLAN tags.  In the case where two tags are pushed I would assume 
that it would be an outer S-VLAN followed by a inner C-VLAN, but it is somewhat 
ambiguous is only a single tag is being pushed.  I think that it would be 
helpful for the model to specify the behaviour here.
- Should the model say anything about the PCP bits if a tag is pushed (i.e., 
are then just left as 0 unless explicitly set by a QoS policy).  Also what is 
the behaviour on a translate, are the PCP bits in the header preserved?
- For QinQ, is only a single outer tag allowed to be translated, if so the 
description should be "translate the outer tag", alternatively, the type could 
be changed to uint16 to allow the number of tags to be translated to be 
specified.

I've also checked the diffs between -12 and -13 and then look good to me, 
except that I had one further comment on the CoS:

case other {
 description
   "Other bandwidth types.";
 uses bandwidth-parameters; 
   }

Is it possible to have a more descriptive name/description instead of "other"? 
E.g., cos-unaware?  Even if you keep the existing name, expanding the 
description slightly might be helpful.

Thanks,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 14 April 2022 12:09
> To: Rob Wilton (rwilton) 
> Subject: OFFLIST TR: New Version Notification for draft-ietf-opsawg-l2nm-
> 13.txt
> 
> Hi Rob,
> 
> Please let me know if any further changes is needed. Thank you again for the
> review.
> 
> Cheers,
> Med
> 
> -Message d'origine-
> De : internet-dra...@ietf.org 
> Envoyé : jeudi 14 avril 2022 11:56
> À : Luis Angel Munoz ; Luis Munoz  angel.mu...@vodafone.com>; BOUCADAIR Mohamed INNOV/NET
> ; Oscar Gonzalez de Dios
> ; Oscar de Dios
> ; Samier Barguil
> ; samier barguil
> 
> Objet : New Version Notification for draft-ietf-opsawg-l2nm-13.txt
> 
> 
> A new version of I-D, draft-ietf-opsawg-l2nm-13.txt has been successfully
> submitted by Mohamed Boucadair and posted to the IETF repository.
> 
> Name: draft-ietf-opsawg-l2nm
> Revision: 13
> Title:A YANG Network Data Model for Layer 2 VPNs
> Document date:2022-04-14
> Group:opsawg
> Pages:158
> URL:https://www.ietf.org/archive/id/draft-ietf-opsawg-l2nm-13.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l2nm
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-l2nm-13
> 
> Abstract:
>This document defines an L2VPN Network YANG Model (L2NM) which can
> be
>used to manage the provisioning of Layer 2 Virtual Private Network
>services within a network (e.g., service provider network).  The L2NM
>complements the Layer 2 Service Model (L2SM) by providing a network-
>centric view of the service that is internal to a service provider.
>The L2NM is particularly meant to be used by a network controller to
>derive the configuration information that will be sent to relevant
>network devices.
> 
>Also, this document defines a YANG module to manage Ethernet segments
>and the initial versions of two IANA-maintained modules that defines
>a set of identities of BGP Layer 2 encapsulation types and pseudowire
>types.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
&g

Re: [OPSAWG] AD review of draft-ietf-opsawg-l2nm-12 (2n Part)

[Rob Wilton (rwilton)]

Hi Med,

Catching up with email, sorry for the delay, please see further comments inline 
...

> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 05 April 2022 11:40
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> l2nm@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
> 
> Hi Rob,
> 
> Focusing on the first part of your review, except point (9).
> 
> The changes can be tracked at: https://github.com/IETF-OPSAWG-
> WG/lxnm/commit/337f65012f55e71df4105481bc28fe53ac8bb302, while the
> full changes made so far can be tracked at: https://tinyurl.com/l2nm-latest
> 
> Please see inline for more context.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) 
> > Envoyé : jeudi 17 mars 2022 21:53
> > À : draft-ietf-opsawg-l2nm@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : AD review of draft-ietf-opsawg-l2nm-12
> >
> > Hi,
> >
> > Apologies for the delay, but I have now managed my AD review of draft-
> > ietf-opsawg-l2nm-12.  (Also attached in case my email is truncated ...)
> >
> > I would like to thank the authors, WG for their work on this document,
> > and the shepherd for his review.  I found the document to be well
> > written and pretty straightforward to follow and understand.  I also
> > believe that this document is a useful addition to the YANG and Network
> > Management Ecosystem, to thank you for that.
> >
> > Anyway, here my comments.  I think that they mostly pretty minor, but
> > perhaps a few that my need a bit more thought.  Hopefully they will help
> > improve the doc.
> >
> > ---
> >
> > Moderate comments:
> >
> > (1)
> >The VPN network access is comprised of:
> >
> >'id':  Includes an identifier of the VPN network access.
> >
> >'description':  Includes a textual description of the VPN
> > network
> >   access.
> >
> >'interface-id':  Indicates the interface on which the VPN
> > network
> >   access is bound.
> >
> >'global-parameters-profile':  Provides a pointer to an active
> >   'global-parameters-profile' at the VPN node level.
> > Referencing an
> >   active 'global-parameters-profile' implies that all
> > associated
> >   data nodes will be inherited by the VPN network access.
> > However,
> >   some of the inherited data nodes (e.g., ACL policies) can
> > be
> >   overridden at the VPN network access level.  In such case,
> >   adjusted values take precedence over inherited ones.
> >
> > It wasn't entirely clear to me how this works with the global parameters
> > defined at the VPN network access level and the VPN node level work.  Is
> > this meant to be a 3 tier hierarchy, or is it always only 2 tiers?  Are
> > you allowed to reference different global profiles both at the VPN
> > network access level and the VPN node level?  Possibly, some slightly
> > expanded description here may be helpful (and/or in the YANG module).
> >
> >
> 
> [Med] Isn't this covered by this text:
> 
>The 'global-parameters-profile' defines reusable parameters for the
>same L2VPN service instance ('vpn-service').  Global parameters
>profile are defined at the VPN service level and then called at the
>VPN node and VPN network access levels.  Each VPN instance profile is
>identified by 'profile-id'.  Some of the data nodes can be adjusted
>at the VPN node or VPN network access levels.  These adjusted values
>take precedence over the global ones.  The subtree of 'global-
>parameters-profile' is depicted in Figure 7.

I think that have figured this out.  My understanding is:
1) 1 or more profiles can be defined globally with particular parameters.
2) Each VPN service can activate a subset of those global profiles, overriding 
parameters if they wish (need to check defaults).
3) Each vpn-node may reference one of the active "global-parameters-profiles".

Is this correct?

I will note that the model doesn't allow a single global profile to create two 
slightly different vpn-node profiles based on the same global profile (since 
the names match at all levels).  Possibly this is a good thing to avoid any 
possible confusion, but I wanted to ensure that you had noted it.

I still think that clarifying some of this text might be helpful in a couple of 
ways:

(i) In 7.4, possibly tweak the text something like:

OLD
   The 'global-parameters-profile' defines reusable parameters for the
   

Re: [OPSAWG] AD review of draft-ietf-opsawg-l2nm-12

[Rob Wilton (rwilton)]

Hi Med,

Thanks, your changes all look good, but I have a bit more comment on one 
specific point:

> > (3)
> >   'mac-loop-prevention':  Container for MAC loop prevention.
> >
> >  'window':  The timer when a MAC mobility event is detected.
> >
> >  'frequency':  The number of times to detect MAC duplication,
> > where a 'duplicate MAC address' situation has occurred and
> > the duplicate MAC address has been added to a list of
> > duplicate MAC addresses.
> >
> > The description of frequency wasn't really clear to me, perhaps this
> > could be made clearer, or perhaps I just need educating!
> 
> [Med] Please check https://github.com/IETF-OPSAWG-WG/lxnm/issues/241
> (especially the response from Raul when I asked the same question about
> frequency vs window).

Perhaps it would help if these descriptions were tweaked slightly? E.g., 
something like:

   'window':  The time interval over which a MAC mobility event is detected and 
checked.

   'frequency':  The number of times to detect MAC duplication,
   where a 'duplicate MAC address' situation has occurred within
   the 'window' time interval and the duplicate MAC address has
   been added to a list of duplicate MAC addresses.

If you do decide to update the descriptions here, you might also want to check 
the YANG descriptions as well.  And, in case it is of interest rfc6991-bis adds 
a type for a time interval in seconds (and it may have other useful types as 
well).  This has gone through WG LC, so I would expect it to be sent to the 
IESG relatively soon, but equally I understand if you don't want to create the 
dependency.

Thanks,
Rob


> -Original Message-----
> From: mohamed.boucad...@orange.com
> 
> Sent: 05 April 2022 08:06
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> l2nm@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-l2nm-12
> 
> Hi Rob,
> 
> Many thanks for the careful AD review.
> 
> Staring with the last part. You can track the changes at:
> https://tinyurl.com/l2nm-latest. Please see inline for more context.
> 
> There are also other edits that I made to fix nits, update references, etc.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) 
> > Envoyé : jeudi 17 mars 2022 21:53
> > À : draft-ietf-opsawg-l2nm@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : AD review of draft-ietf-opsawg-l2nm-12
> >
> > Hi,
> >
> > Apologies for the delay, but I have now managed my AD review of draft-
> > ietf-opsawg-l2nm-12.  (Also attached in case my email is truncated ...)
> >
> > I would like to thank the authors, WG for their work on this document,
> > and the shepherd for his review.  I found the document to be well
> > written and pretty straightforward to follow and understand.  I also
> > believe that this document is a useful addition to the YANG and Network
> > Management Ecosystem, to thank you for that.
> >
> > Anyway, here my comments.  I think that they mostly pretty minor, but
> > perhaps a few that my need a bit more thought.  Hopefully they will help
> > improve the doc.
> >
> > ---
> ...
> >
> >
> > Minor comments/nits:
> >
> > (1)
> >In particular, the model can be used in the communication
> >interface between the entity that interacts directly with the
> >customer, the service orchestrator (either fully automated or a human
> >operator), and the entity in charge of network orchestration and
> >control (a.k.a., network controller/orchestrator) by allowing for
> >more network-centric information to be included.
> >
> > Nit (since this is explained more clearly later in the document): It was
> > unclear to me whether this this sentence is about 3 entities or 2.
> > I.e., specifically, whether the "entity that interacts directly with the
> > customer" is the service orchestrator.  For clarity, would it be clearer
> > as: ",i.e., the service orchestrator,".
> >
> 
> [Med] I adjusted the sentence for better clarity.
> 
> > (2)'signaling-type':  Indicates the signaling that is used for
> > setting
> >   pseudowires.
> >
> > Nit: setting pseudowires => setting up pseudowires?
> 
> [Med] Fixed.
> 
> >
> > (3)
> >   'mac-loop-prevention':  Container for MAC loop prevention.
> >
> >  'window':  The timer when a MAC mobility event is detected.
> >
> >  'frequency':  The number of times to detect MAC duplication,
> > where a 'duplicate MAC addre

[OPSAWG] AD review of draft-ietf-opsawg-l2nm-12

[Rob Wilton (rwilton)]

Hi,

Apologies for the delay, but I have now managed my AD review of 
draft-ietf-opsawg-l2nm-12.  (Also attached in case my email is truncated ...)

I would like to thank the authors, WG for their work on this document, and the 
shepherd for his review.  I found the document to be well written and pretty 
straightforward to follow and understand.  I also believe that this document is 
a useful addition to the YANG and Network Management Ecosystem, to thank you 
for that.

Anyway, here my comments.  I think that they mostly pretty minor, but perhaps a 
few that my need a bit more thought.  Hopefully they will help improve the doc.
 
---

Moderate comments:

(1) 
   The VPN network access is comprised of:

   'id':  Includes an identifier of the VPN network access.

   'description':  Includes a textual description of the VPN network
  access.

   'interface-id':  Indicates the interface on which the VPN network
  access is bound.

   'global-parameters-profile':  Provides a pointer to an active
  'global-parameters-profile' at the VPN node level.  
Referencing an
  active 'global-parameters-profile' implies that all associated
  data nodes will be inherited by the VPN network access.  
However,
  some of the inherited data nodes (e.g., ACL policies) can be
  overridden at the VPN network access level.  In such case,
  adjusted values take precedence over inherited ones.

It wasn't entirely clear to me how this works with the global parameters 
defined at the VPN network access level and the VPN node level work.  Is this 
meant to be a 3 tier hierarchy, or is it always only 2 tiers?  Are you allowed 
to reference different global profiles both at the VPN network access level and 
the VPN node level?  Possibly, some slightly expanded description here may be 
helpful (and/or in the YANG module).


(2) |  +--rw encapsulation
  |  |  +--rw encap-type?identityref
  |  |  +--rw dot1q
  |  |  |  +--rw tag-type?   identityref
  |  |  |  +--rw cvlan-id?   uint16
  
Did you consider adding support for ranges or sets of VLAN Ids (e.g., a list of 
non-overlapping ranges) (both for the single and double tagged cases)?


(3)   |  +--rw lag-interface
  
I'm slightly surprised that you don't have parameters for the physical 
interfaces, and I can understand your justification for this, but then you do 
have configuration for LAG, including configuration for the underlying member 
interfaces.  This feels slightly inconsistent to me at the level that the 
configuration is being provided.  Understanding the rationale a bit more here 
might be helpful, and I think that we should double check that this should 
definitely be in this model.


(4)+--rw svc-pe-to-ce-bandwidth
 |   {vpn-common:inbound-bw}?
 |  +--rw pe-to-ce-bandwidth* [bw-type]

Can you specify different bandwidths for multiple CoS fields?  It looks like 
the list key is the bw-type, and hence you would only be able to specify the 
bandwidth for a single CoS field?  Is that sufficient?


(5)  8.3.  Ethernet Segments

The names used here don't seem to be particularly friendly.  Is giving them 
more human understandable identity names an option, or are these names directly 
mirroring some other registry?  Or perhaps even something like esi-type-1-lacp, 
esi-type-3-mac, etc?


(6)leaf svc-mtu {
 type uint32;
 description
   "Service MTU, it is also known as the maximum transmission
unit or maximum frame size. When a frame is larger than
the MTU, it is fragmented to accommodate the MTU of the
network.";
   }
  
MTU's turn up in various places.  Given that MTUs seem to mean different things 
for different people, please can you check the descriptions and given that this 
model is for L2VPN's be super explicit about whether these MTUs are 
representing the L3 payload, or the max frame size including the L2 header and 
presumably FCS sequence as well.


(7)  identity mac-action {
   description
 "Base identity for a MAC action.";
 }
 
Would an VPN implementation ever want to drop and log rather than just doing 
one or the other?


(8) Hierarchical groupings and defaults

I want to check what the model/plan is regarding hierarchical config (e.g., 
grouping parameters-profile) and default values.  It looks like some of the 
leaves in the provide have default values, which I believe will be ambiguous 
when it comes to hierarchical config.  I.e., normally I would 

Re: [OPSAWG] A review of draft-song-opsawg-ifit-framework-16

[Rob Wilton (rwilton)]

Hi Haoyu,

Thanks for the update version.  I've looked at the latest version that you have 
published, and it doesn't change my fundamental view or previous comments on 
this document.

This document is focussed on a new different variant of on-path telemetry.  
On-path telemetry is being working on in the IPPM WG, which is where this 
document would receive the necessary reviews to be able to progress.  This 
document needs to be taken there - it is not currently in charter for OPSAWG.

I cannot see how this work can progress without having discussions in IPPM 
first.

Regards,
Rob


-Original Message-
From: Haoyu Song  
Sent: 23 February 2022 01:27
To: Rob Wilton (rwilton) ; adr...@olddog.co.uk; 
draft-song-opsawg-ifit-framew...@ietf.org
Cc: opsawg@ietf.org; opsawg-cha...@ietf.org
Subject: RE: [OPSAWG] A review of draft-song-opsawg-ifit-framework-16

Hi Rob,

Thank you for the comments and questions. We just uploaded an update version of 
the draft based on the latest review comments. 
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/17/

We'd like to emphasize that this is  an architecture not a protocol solution. 
In fact, it pulls together the many existing and proposed protocol solutions to 
show how they fit together. The document itself doesn't propose any new 
techniques or protocols.  This is a kind of "cook book" to show why IETF 
solutions are important as part of a whole. Very often OAM solutions are 
developed in isolation without a big picture. In this sense, it's akin to the 
NTF document and we believe it fits in OPSAWG for the same reason NTF was 
adopted.

But certainly IFIT does not repeat NTF.  NTF is a very high-level architectural 
view covering all of the issues and aspects of telemetry. In contrast, IFIT 
"zooms in" to look just at the on-path telemetry tools in the category of 
forwarding-plane telemetry. These are the "new" telemetry tools in the IETF and 
are not so widely understood. Many are still in development and some are 
getting some focus. Moreover,  IFIT covers many data-plane specific issues and 
challenges that weren't discussed in NTF. For these reasons, we believe the 
framework is useful to help network operators and developers to understand and 
apply this relatively new branch of telemetry techniques.  

In the past two years, the document has evolved a lot with a clearer scope and 
architecture now. We ask the OPSAWG chairs and OPS ADs to review the latest 
version of the document again and consider to adopt it. We would continue to 
carefully address the issues raised by the colleagues.  

Thank you very much!

Best regards,
Haoyu

-----Original Message-
From: Rob Wilton (rwilton)  
Sent: Monday, February 21, 2022 11:07 AM
To: adr...@olddog.co.uk; draft-song-opsawg-ifit-framew...@ietf.org
Cc: opsawg@ietf.org
Subject: RE: [OPSAWG] A review of draft-song-opsawg-ifit-framework-16

Hi Adrian, authors, WG,

Warren, Martin Duke, and I looked at this document almost 2 years back, noted 
that the work that it is describing seemed to be close to work chartered in 
IPPM WG, and hence recommended to the authors, via Tianran, that this work 
should be presented to IPPM to see if there is interest on working on any 
protocols or protocol changes related to the framework.  Authors, do you know 
if that has happened?  And if so, what was the feedback reviewed from IPPM 
please?

If IPPM doesn't want to take up this work, or doesn't think that it falls 
within their charter, and if the authors are still interested then I would 
encourage the proponents to consider doing side meetings or a BOF on the 
solution to see if they can build is wider interest for standardizing it within 
the IETF.

Finally, when reading this document, I find the document content to be very 
abstract, and I struggle to get to the meat of what it is actually describing 
or defining beyond what is already described in the NTF draft related to 
general telemetry and full lifecycle monitoring.  As it stands, I struggle to 
see how this document fits into the OPSAWG charter.  It may be that 
standardizing some of the concrete protocol parts first, or in parallel to the 
framework document may end up with a more widely applicable standard.

Thanks,
Rob


-Original Message-
From: OPSAWG  On Behalf Of Adrian Farrel
Sent: 19 February 2022 15:55
To: draft-song-opsawg-ifit-framew...@ietf.org
Cc: opsawg@ietf.org
Subject: [OPSAWG] A review of draft-song-opsawg-ifit-framework-16

Hi,

I reviewed -09 of this draft at the time of the inconclusive adoption poll back 
in December 2019. A lot of changes have been made since then, including updates 
for my previous comments.

As the document appears to be somewhat stalled, I asked the chairs what they 
thought the status was, and they said that the work is not shut down, but they 
noted that the mailing list has been very quiet on the subject. This is 
possibly because we're all waiting to find out what h

Re: [OPSAWG] A review of draft-song-opsawg-ifit-framework-16

[Rob Wilton (rwilton)]

Hi Adrian, authors, WG,

Warren, Martin Duke, and I looked at this document almost 2 years back, noted 
that the work that it is describing seemed to be close to work chartered in 
IPPM WG, and hence recommended to the authors, via Tianran, that this work 
should be presented to IPPM to see if there is interest on working on any 
protocols or protocol changes related to the framework.  Authors, do you know 
if that has happened?  And if so, what was the feedback reviewed from IPPM 
please?

If IPPM doesn't want to take up this work, or doesn't think that it falls 
within their charter, and if the authors are still interested then I would 
encourage the proponents to consider doing side meetings or a BOF on the 
solution to see if they can build is wider interest for standardizing it within 
the IETF.

Finally, when reading this document, I find the document content to be very 
abstract, and I struggle to get to the meat of what it is actually describing 
or defining beyond what is already described in the NTF draft related to 
general telemetry and full lifecycle monitoring.  As it stands, I struggle to 
see how this document fits into the OPSAWG charter.  It may be that 
standardizing some of the concrete protocol parts first, or in parallel to the 
framework document may end up with a more widely applicable standard.

Thanks,
Rob


-Original Message-
From: OPSAWG  On Behalf Of Adrian Farrel
Sent: 19 February 2022 15:55
To: draft-song-opsawg-ifit-framew...@ietf.org
Cc: opsawg@ietf.org
Subject: [OPSAWG] A review of draft-song-opsawg-ifit-framework-16

Hi,

I reviewed -09 of this draft at the time of the inconclusive adoption poll
back in December 2019. A lot of changes have been made since then,
including updates for my previous comments.

As the document appears to be somewhat stalled, I asked the chairs what
they thought the status was, and they said that the work is not shut
down, but they noted that the mailing list has been very quiet on the
subject. This is possibly because we're all waiting to find out what
happens next.

Anyway, as a way of showing my continued interest in this document, I
have reviewed the current revision (-16). I hope these comments prove
useful to the authors.

I have shown my edits and comments in line with the document, attached.
While there are a lot of comments, I don't think any of these couldn't
have been worked on for a working group draft. But let's continue the
work with this draft and get it into a better shape.

One comment here rather than in the document: You talk about adding 
in-situ OAM to IPv4 encapsulations. I can, of course, see the benefit of
this for operators carrying IPv4 traffic. But I wonder how that runs 
into the IETF's policy with regard to extending IPv4. Certainly your
reference to draft-herbert-ipv4-eh is a bit dubious given how that work
appears to have been abandoned. Of course, encapsulations under the IPv4
header are a totally different thing.

Best,
Adrian

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

Re: [OPSAWG] Status of draft-ietf-opsawg-ntf

[Rob Wilton (rwilton)]

Hi Adrian,

Sorry, this had got stuck, I had wanted to check Roman's and Ben's abstain 
comments.  Anyway, I think that the document is in reasonable shape, and I've 
now pushed the button for this to proceed.

I would like to thank the authors and WG for their work on this document.

Regards,
Rob


-Original Message-
From: Adrian Farrel  
Sent: 18 February 2022 14:46
To: Rob Wilton (rwilton) 
Cc: opsawg@ietf.org; draft-ietf-opsawg-ntf@ietf.org
Subject: Status of draft-ietf-opsawg-ntf

Hi,

I'm just reviewing a different draft in OPSAWG
(draft-song-opsawg-ifit-framework) and it has a reference to
draft-ietf-opsawg-ntf

It seems to be in a bit of an odd state.
It went into IESG evaluation at the end of October and attracted some
weighty comments (one set attached to an Abstain ballot, one set to a
Discuss that has now been cleared). Nevertheless, the document shows it has
enough Yes ballots to be approved, and no Discusses. It is in
"Approved-announcement to be sent::AD Followup" state.

Since the start of the IESG review, the document has been updated (three
times with the last revision being on December 3rd) and emails seem to have
gone around explaining the updates. 

I see nothing on the OPSAWG mailing list to suggest that you have any
further issues with the document, so I wonder why it is "stuck" and if the
reference I am reviewing is good.

Any clues?

Thanks,
Adrian

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

Re: [OPSAWG] AD review of draft-ietf-opsawg-ntf-07 [2]

[Rob Wilton (rwilton)]

Hi Haoyu,

Thanks for the expedient updates, they look good to me.  I've requested IETF LC.

Regards,
Rob


> -Original Message-
> From: Haoyu Song 
> Sent: 13 October 2021 16:05
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> ntf@ietf.org
> Cc: opsawg@ietf.org; 'opsawg-chairs' 
> Subject: RE: AD review of draft-ietf-opsawg-ntf-07 [2]
> 
> Hi Rob,
> 
> Thank you very much for your second review! We have made all the
> modifications you pointed out.
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntf/09/
> Please help to move it forward. Thanks again!
> 
> Best regards,
> Haoyu
> 
> -Original Message-
> From: Rob Wilton (rwilton) 
> Sent: Tuesday, October 12, 2021 2:08 PM
> To: Haoyu Song ; draft-ietf-opsawg-
> ntf@ietf.org
> Cc: opsawg@ietf.org; 'opsawg-chairs' 
> Subject: RE: AD review of draft-ietf-opsawg-ntf-07 [2]
> 
> Hi Haoyu,
> 
> Thanks for applying the markups.
> 
> I've given -08 another read through, and I think that there are still some
> tweaks to the grammar that I would recommend.  I've also included some
> automated warnings from a grammar tool that a probably also worth fixing
> (you would get similar warnings during IESG review anyway).  I think that
> once you have fixed these we should be ready to go.
> 
> 3.2.  Use Cases
> 
>*  Security: Network intrusion detection and prevention systems need
>   to monitor network traffic and activities and act upon anomalies.
>   Given increasingly sophisticated attack vector coupled with
>   increasingly severe consequences of security breaches, new tools
>   and techniques need to be developed, relying on wider and deeper
>   visibility into networks.  The ultimate goal is to achieve the
>   ideal security with no or minimal human intervention.
> 
> RW: suggest
> no or minimal human => no, or only minimal, human intervention
> 
> 
> * Last sentence suggest:
> 
> The ultimate goal is to achieve the ideal security with no, or only minimal,
> human intervention.
> 
>   networks.  While a policy or an intent is enforced, the compliance
>   needs to be verified and monitored continuously relying on
>   visibility that is provided through network telemetry data, any
>   violation needs to be reported immediately, and updates need to be
>   applied to ensure the intent remains in force.
> 
> RW: Suggest:
> 
> While a policy or intent is enforced, the compliance
> needs to be verified and monitored continuously by relying on
> visibility that is provided through network telemetry data.  Any
> violation must be notified immediately, potentially resulting in
> updates to how the policy or intent is applied in the network to ensure
> that it remains in force, or otherwise alerting the network administrator
> to the policy or intent violation.
> 
>*  ...
>   overwhelming.  While machine learning technologies can be used for
>   root cause analysis, it up to the network to sense and provide the
>   relevant diagnostic data which are either actively fed into or
>   passively retrieved by machine learning applications.
> 
> RW: Suggest:
> actively fed into or passively retrieved by => actively fed into, or passively
> retrieved, by
> 
> 
> 4.  Network Telemetry Framework
> 
> RW: (Section 4.3)are applied. => (Section 4.3) are applied.
> 
> 
> 4.1.  Top Level Modules, diagram:
> 
> RW:
> 1. I still not sure that I would list "ACL" under a control plane object.
> 2. Thinking about it, I think that this table would be more consistent if the
> columns were ordered with management plane before control plane, e.g.,:
>+-+--+--+---+---+
>| Module  | Management   | Control  | Forwarding| External  |
>| | Plane| Plane| Plane | Data  |
> 
> 
> 4.1.1.  Management Plane Telemetry
> 
>*  Convenient Data Subscription: An application should have the
>   freedom to choose the data export means such as the data types (as
>   described in Figure 4) and the export means and frequency (e.g.,
>   on-change or periodic subscription).
> 
> RW:
> I don't think that the client is really choosing the data types, but
> instead choosing which data to export, and how it is exported.  How about:
> 
> Convenient Data Subscription: An application should have the
> freedom to choose which data is exported (see section 4.3) and the
> means and frequency of how that data is exported (e.g.,
> on-change or periodic subscription).
> 
>*  High Speed Data Transport: In order to keep up with the velocity
>   of infor

Re: [OPSAWG] AD review of draft-ietf-opsawg-ntf-07 [2]

[Rob Wilton (rwilton)]

res two periods.
Suggested change:  "e.g.,"

Section: A.4.1, draft text:
For example, a sports event takes place and some unexpected movement makes it 
highly interesting and many people connects to sites that are reporting on the 
event. 
Warning:  Consider using an extreme adjective for 'interesting'.
Suggested change:  "fascinating"

Section: A.4.1, draft text:
For example, a sports event takes place and some unexpected movement makes it 
highly interesting and many people connects to sites that are reporting on the 
event. 
Warning:  If 'people' is plural here, don't use the third-person singular verb.
Suggested change:  "connect"

Section: A.4.1, draft text:
Additional types of detector types can be added to the system but they will be 
generally the result of composing the properties offered by these main classes.
Warning:  Use a comma before 'but' if it connects two independent clauses 
(unless they are closely connected and short).
Suggested change:  "system, but"

Thanks,
Rob



> -Original Message-
> From: Haoyu Song 
> Sent: 08 October 2021 00:15
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> ntf@ietf.org
> Cc: opsawg@ietf.org; 'opsawg-chairs' 
> Subject: RE: AD review of draft-ietf-opsawg-ntf-07 [2]
> 
> Hi Rob,
> 
> We have updated the draft according to your review suggestions and uploaded
> the -08 version. In the new revision we believe all your suggestions/questions
> have been addressed. Please let me know if you have further questions. Thank
> you very much!
> 
> Best regards,
> Haoyu
> 
> 
> -
> A new version of I-D, draft-ietf-opsawg-ntf-08.txt has been successfully
> submitted by Haoyu Song and posted to the IETF repository.
> 
> Name: draft-ietf-opsawg-ntf
> Revision: 08
> Title:Network Telemetry Framework
> Document date:2021-10-07
> Group:opsawg
> Pages:40
> URL:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-ntf-
> 08.txtdata=04%7C01%7Chaoyu.song%40futurewei.com%7C96249f77ce
> 0246132c2608d989e79553%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7
> C1%7C637692450027508042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000
> p;sdata=fm%2FeutvtbKzZN7c%2BvZzlzmZzSWQs0I52sn68EQ1bSv0%3Dr
> eserved=0
> Status:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-
> ntf%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7C96249f77c
> e0246132c2608d989e79553%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%
> 7C1%7C637692450027508042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000
> mp;sdata=mPDw6Gz2JqqJ%2F6X0ISjEH5MH1nL%2Bgn5MK4VnbaBAfRs%3D&
> amp;reserved=0
> Htmlized:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-opsawg-
> ntfdata=04%7C01%7Chaoyu.song%40futurewei.com%7C96249f77ce02
> 46132c2608d989e79553%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1
> %7C637692450027508042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000
> sdata=x8mxaK3UugiiTtDDX1YCrs3a9%2FjhdUXBPMetNuoR1SM%3Drese
> rved=0
> Diff:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-opsawg-ntf-
> 08data=04%7C01%7Chaoyu.song%40futurewei.com%7C96249f77ce02
> 46132c2608d989e79553%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1
> %7C637692450027508042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000
> sdata=3QV9pT%2Fzs5xj6WxMLqIwGr2%2F4cD7xqclE3uznclsZfA%3Dres
> erved=0
> 
> 
> -Original Message-
> From: Haoyu Song
> Sent: Wednesday, October 6, 2021 9:14 AM
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> ntf@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-ntf-07 [2]
> 
> Hi Rob,
> 
> Thank you very much for the review! We'll update the draft as you suggested.
> 
> Best regards,
> Haoyu
> 
> -Original Message-
> From: Rob Wilton (rwilton) 
> Sent: Wednesday, October 6, 2021 3:55 AM
> To: draft-ietf-opsawg-ntf@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-ntf-07 [2]
> 
> Sigh, this also appears to be truncated in my email client.
> 
> To be sure that you see all the comments (i.e., to the end of the document),
> please either see the previous attachment. The full email can also be seen in
> the archives at
> https://nam11.safelinks.protection.outlook.com/?url=h

Re: [OPSAWG] AD review of draft-ietf-opsawg-ntf-07 [2]

[Rob Wilton (rwilton)]

Hi Haoyu,

Thanks for the quick updates.  I will check the diffs and see if I have any 
questions remaining.

Regards,
Rob


> -Original Message-
> From: Haoyu Song 
> Sent: 08 October 2021 00:15
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> ntf@ietf.org
> Cc: opsawg@ietf.org; 'opsawg-chairs' 
> Subject: RE: AD review of draft-ietf-opsawg-ntf-07 [2]
> 
> Hi Rob,
> 
> We have updated the draft according to your review suggestions and
> uploaded the -08 version. In the new revision we believe all your
> suggestions/questions have been addressed. Please let me know if you have
> further questions. Thank you very much!
> 
> Best regards,
> Haoyu
> 
> 
> -
> A new version of I-D, draft-ietf-opsawg-ntf-08.txt has been successfully
> submitted by Haoyu Song and posted to the IETF repository.
> 
> Name: draft-ietf-opsawg-ntf
> Revision: 08
> Title:Network Telemetry Framework
> Document date:2021-10-07
> Group:opsawg
> Pages:40
> URL:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-ntf-
> 08.txtdata=04%7C01%7Chaoyu.song%40futurewei.com%7C96249f77c
> e0246132c2608d989e79553%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7
> C1%7C637692450027508042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000
> p;sdata=fm%2FeutvtbKzZN7c%2BvZzlzmZzSWQs0I52sn68EQ1bSv0%3D
> reserved=0
> Status:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-
> ntf%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7C96249f77
> ce0246132c2608d989e79553%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%
> 7C1%7C637692450027508042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000
> mp;sdata=mPDw6Gz2JqqJ%2F6X0ISjEH5MH1nL%2Bgn5MK4VnbaBAfRs%3D&
> amp;reserved=0
> Htmlized:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-opsawg-
> ntfdata=04%7C01%7Chaoyu.song%40futurewei.com%7C96249f77ce02
> 46132c2608d989e79553%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1
> %7C637692450027508042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000
> sdata=x8mxaK3UugiiTtDDX1YCrs3a9%2FjhdUXBPMetNuoR1SM%3Dres
> erved=0
> Diff:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-opsawg-ntf-
> 08data=04%7C01%7Chaoyu.song%40futurewei.com%7C96249f77ce02
> 46132c2608d989e79553%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1
> %7C637692450027508042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000
> sdata=3QV9pT%2Fzs5xj6WxMLqIwGr2%2F4cD7xqclE3uznclsZfA%3Dre
> served=0
> 
> 
> -Original Message-
> From: Haoyu Song
> Sent: Wednesday, October 6, 2021 9:14 AM
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> ntf@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-ntf-07 [2]
> 
> Hi Rob,
> 
> Thank you very much for the review! We'll update the draft as you
> suggested.
> 
> Best regards,
> Haoyu
> 
> -Original Message-
> From: Rob Wilton (rwilton) 
> Sent: Wednesday, October 6, 2021 3:55 AM
> To: draft-ietf-opsawg-ntf@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-ntf-07 [2]
> 
> Sigh, this also appears to be truncated in my email client.
> 
> To be sure that you see all the comments (i.e., to the end of the document),
> please either see the previous attachment. The full email can also be seen in
> the archives at
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> archive.ietf.org%2Farch%2Fmsg%2Fopsawg%2FWDnVtM_vLm15X28OTEwI9
> Q6gfx0%2Fdata=04%7C01%7Chaoyu.song%40futurewei.com%7Cf1e79
> 80d22be45a356e608d988b7d5ba%7C0fee8ff2a3b240189c753a1d5591fedc%7
> C1%7C0%7C637691145441218654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> 0sdata=d3NH7iwGu4T99Y%2Fwh9jft0oWofQeKyfWhcuBCQSZcJM%3D
> reserved=0
> 
> Regards,
> Rob
> 
> 
> -Original Message-
> From: Rob Wilton (rwilton) 
> Sent: 06 October 2021 11:48
> To: draft-ietf-opsawg-ntf@ietf.org
> Cc: opsawg@ietf.org
> Subject: AD review of draft-ietf-opsawg-ntf-07 [2]
> 
> Hi,
> 
> 
> 
> Here is my belated AD review of draft-ietf-opsawg-ntf-07.txt.  [Text file with
> comments attached in case this also gets truncated.]
> 
> 
> 
> I woul

Re: [OPSAWG] AD review of draft-ietf-opsawg-ntf-07 [2]

[Rob Wilton (rwilton)]

Sigh, this also appears to be truncated in my email client.

To be sure that you see all the comments (i.e., to the end of the document), 
please either see the previous attachment. The full email can also be seen in 
the archives at 
https://mailarchive.ietf.org/arch/msg/opsawg/WDnVtM_vLm15X28OTEwI9Q6gfx0/

Regards,
Rob


-Original Message-
From: Rob Wilton (rwilton)  
Sent: 06 October 2021 11:48
To: draft-ietf-opsawg-ntf@ietf.org
Cc: opsawg@ietf.org
Subject: AD review of draft-ietf-opsawg-ntf-07 [2]

Hi,



Here is my belated AD review of draft-ietf-opsawg-ntf-07.txt.  [Text file with 
comments attached in case this also gets truncated.]



I would like to thank you for the effort that you have put into this document, 
and apologise for my long delay in reviewing it.



Broadly, I think that this is a good and useful framework, but in some of the 
latter parts of the document it seems to give prominence to protocols that I 
don't think have IETF consensus behind them yet (particularly DNP).  I have 
flagged specific comments in comments inline within the document, but I think 
that the document will have been accuracy/longevity if text about the potential 
technologies is mostly kept to the appendices.



There were quite a lot of cases where the text doesn't scan, or read easily, 
particularly in the latter sections of this document, although I acknowledge 
that none of the authors appear to be native English speakers.  Ideally, these 
sorts of issues would have been highlighted and addressed during WG LC.  
Although the RFC editor will improve the language of the documents, making the 
improvements now before IESG review will aid its passage, and hopefully result 
in a better document when it is published.  I have flagged and proposed 
alternative text/grammar where possible.  Once you have made the markups and 
resolved the issues/questions that I have raised then I can run it through a 
grammar checking tool (Lar's will run an equivalent tool during IESG review 
anyway ...)



All of my comments are directly inline, please search for "RW" or "RW:"









OPSAWG   H. Song

Internet-Draft Futurewei

Intended status: InformationalF. Qin

Expires: August 23, 2021China Mobile

   P. Martinez-Julia

NICT

L. Ciavaglia

   Nokia

 A. Wang

  China Telecom

   February 19, 2021





  Network Telemetry Framework

draft-ietf-opsawg-ntf-07



Abstract



   Network telemetry is a technology for gaining network insight and

   facilitating efficient and automated network management.  It

   encompasses various techniques for remote data generation,

   collection, correlation, and consumption.  This document describes an

   architectural framework for network telemetry, motivated by

   challenges that are encountered as part of the operation of networks

   and by the requirements that ensue.  Network telemetry, as

   necessitated by best industry practices, covers technologies and

   protocols that extend beyond conventional network Operations,



   Administration, and Management (OAM).  The presented network

   telemetry framework promises flexibility, scalability, accuracy,

   coverage, and performance.  In addition, it facilitates the

   implementation of automated control loops to address both today's and

   tomorrow's network operational needs.  This document clarifies the

   terminologies and classifies the modules and components of a network

   telemetry system from several different perspectives.  The framework

   and taxonomy help to set a common ground for the collection of

   related work and provide guidance for related technique and standard

   developments.



RW:

I would suggest condensing the abstract to the following, and move the other 
text to the introduction if it is not already covered there.



   Network telemetry is a technology for gaining network insight and

   facilitating efficient and automated network management.  It

   encompasses various techniques for remote data generation,

   collection, correlation, and consumption.  This document describes an

   architectural framework for network telemetry, motivated by

   challenges that are encountered as part of the operation of networks

   and by the requirements that ensue.  This document clarifies the

   terminologies and classifies the modules and com

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

[Rob Wilton (rwilton)]

Sorry, the IETF mail filters have truncated my email.  I'll resend as HTML to 
see if that helps.

Rob


-Original Message-
From: Rob Wilton (rwilton)  
Sent: 06 October 2021 11:35
To: draft-ietf-opsawg-ntf@ietf.org
Cc: opsawg@ietf.org
Subject: AD review of draft-ietf-opsawg-ntf-07

Hi,

Here is my belated AD review of draft-ietf-opsawg-ntf-07.txt.

I would like to thank you for the effort that you have put into this document, 
and apologise for my long delay in reviewing it.

Broadly, I think that this is a good and useful framework, but in some of the 
latter parts of the document it seems to give prominence to protocols that I 
don't think have IETF consensus behind them yet (particularly DNP).  I have 
flagged specific comments in comments inline within the document, but I think 
that the document will have been accuracy/longevity if text about the potential 
technologies is mostly kept to the appendices.

There were quite a lot of cases where the text doesn't scan, or read easily, 
particularly in the latter sections of this document, although I acknowledge 
that none of the authors appear to be native English speakers.  Ideally, these 
sorts of issues would have been highlighted and addressed during WG LC.  
Although the RFC editor will improve the language of the documents, making the 
improvements now before IESG review will aid its passage, and hopefully result 
in a better document when it is published.  I have flagged and proposed 
alternative text/grammar where possible.  Once you have made the markups and 
resolved the issues/questions that I have raised then I can run it through a 
grammar checking tool (Lar's will run an equivalent tool during IESG review 
anyway ...)

All of my comments are directly inline, please search for "RW" or "RW:"





OPSAWG   H. Song
Internet-Draft Futurewei
Intended status: InformationalF. Qin
Expires: August 23, 2021China Mobile
   P. Martinez-Julia
NICT
L. Ciavaglia
   Nokia
 A. Wang
   China Telecom
   February 19, 2021


  Network Telemetry Framework
draft-ietf-opsawg-ntf-07

Abstract

   Network telemetry is a technology for gaining network insight and
   facilitating efficient and automated network management.  It
   encompasses various techniques for remote data generation,
   collection, correlation, and consumption.  This document describes an
   architectural framework for network telemetry, motivated by
   challenges that are encountered as part of the operation of networks
   and by the requirements that ensue.  Network telemetry, as
   necessitated by best industry practices, covers technologies and
   protocols that extend beyond conventional network Operations,
   
   Administration, and Management (OAM).  The presented network
   telemetry framework promises flexibility, scalability, accuracy,
   coverage, and performance.  In addition, it facilitates the
   implementation of automated control loops to address both today's and
   tomorrow's network operational needs.  This document clarifies the
   terminologies and classifies the modules and components of a network
   telemetry system from several different perspectives.  The framework
   and taxonomy help to set a common ground for the collection of
   related work and provide guidance for related technique and standard
   developments.

RW:
I would suggest condensing the abstract to the following and move the other 
text to the introduction if it is not already covered there.

   Network telemetry is a technology for gaining network insight and
   facilitating efficient and automated network management.  It
   encompasses various techniques for remote data generation,
   collection, correlation, and consumption.  This document describes an
   architectural framework for network telemetry, motivated by
   challenges that are encountered as part of the operation of networks
   and by the requirements that ensue.  This document clarifies the
   terminologies and classifies the modules and components of a network
   telemetry system from several different perspectives.  The framework
   and taxonomy help to set a common ground for the collection of
   related work and provide guidance for related technique and standard
   developments.


Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions 

[OPSAWG] AD review of draft-ietf-opsawg-ntf-07

[Rob Wilton (rwilton)]

Hi,

Here is my belated AD review of draft-ietf-opsawg-ntf-07.txt.

I would like to thank you for the effort that you have put into this document, 
and apologise for my long delay in reviewing it.

Broadly, I think that this is a good and useful framework, but in some of the 
latter parts of the document it seems to give prominence to protocols that I 
don't think have IETF consensus behind them yet (particularly DNP).  I have 
flagged specific comments in comments inline within the document, but I think 
that the document will have been accuracy/longevity if text about the potential 
technologies is mostly kept to the appendices.

There were quite a lot of cases where the text doesn't scan, or read easily, 
particularly in the latter sections of this document, although I acknowledge 
that none of the authors appear to be native English speakers.  Ideally, these 
sorts of issues would have been highlighted and addressed during WG LC.  
Although the RFC editor will improve the language of the documents, making the 
improvements now before IESG review will aid its passage, and hopefully result 
in a better document when it is published.  I have flagged and proposed 
alternative text/grammar where possible.  Once you have made the markups and 
resolved the issues/questions that I have raised then I can run it through a 
grammar checking tool (Lar's will run an equivalent tool during IESG review 
anyway ...)

All of my comments are directly inline, please search for "RW" or "RW:"





OPSAWG   H. Song
Internet-Draft Futurewei
Intended status: InformationalF. Qin
Expires: August 23, 2021China Mobile
   P. Martinez-Julia
NICT
L. Ciavaglia
   Nokia
 A. Wang
   China Telecom
   February 19, 2021


  Network Telemetry Framework
draft-ietf-opsawg-ntf-07

Abstract

   Network telemetry is a technology for gaining network insight and
   facilitating efficient and automated network management.  It
   encompasses various techniques for remote data generation,
   collection, correlation, and consumption.  This document describes an
   architectural framework for network telemetry, motivated by
   challenges that are encountered as part of the operation of networks
   and by the requirements that ensue.  Network telemetry, as
   necessitated by best industry practices, covers technologies and
   protocols that extend beyond conventional network Operations,
   
   Administration, and Management (OAM).  The presented network
   telemetry framework promises flexibility, scalability, accuracy,
   coverage, and performance.  In addition, it facilitates the
   implementation of automated control loops to address both today's and
   tomorrow's network operational needs.  This document clarifies the
   terminologies and classifies the modules and components of a network
   telemetry system from several different perspectives.  The framework
   and taxonomy help to set a common ground for the collection of
   related work and provide guidance for related technique and standard
   developments.

RW:
I would suggest condensing the abstract to the following and move the other 
text to the introduction if it is not already covered there.

   Network telemetry is a technology for gaining network insight and
   facilitating efficient and automated network management.  It
   encompasses various techniques for remote data generation,
   collection, correlation, and consumption.  This document describes an
   architectural framework for network telemetry, motivated by
   challenges that are encountered as part of the operation of networks
   and by the requirements that ensue.  This document clarifies the
   terminologies and classifies the modules and components of a network
   telemetry system from several different perspectives.  The framework
   and taxonomy help to set a common ground for the collection of
   related work and provide guidance for related technique and standard
   developments.


Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.




Song, et al. 

Re: [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)

[Rob Wilton (rwilton)]

Carsten & Med,

Thanks for raising this.  I agree with the errata, but this will need to be 
hold for doc update, because we cannot create a different revision of a YANG 
module through the errata process.

Thanks,
Rob


From: iesg  On Behalf Of Francesca Palombini
Sent: 05 October 2021 15:12
To: Carsten Bormann ; mohamed.boucad...@orange.com
Cc: draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg@ietf.org; 
opsawg-cha...@ietf.org; The IESG ; net...@ietf.org
Subject: Re: [OPSAWG] Francesca Palombini's Discuss on 
draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)

Thanks Carsten for noticing this! I did overlook completely that bps was being 
used as bytes per seconds... Thanks Med for clarifying in this document and for 
opening errata https://www.rfc-editor.org/errata/eid6703 . The OPS ADs are on 
it, I am sure.

Francesca

From: Carsten Bormann mailto:c...@tzi.org>>
Date: Tuesday, 5 October 2021 at 09:05
To: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Cc: Francesca Palombini 
mailto:francesca.palomb...@ericsson.com>>, 
The IESG mailto:i...@ietf.org>>, 
draft-ietf-opsawg-l3sm-l...@ietf.org
 
mailto:draft-ietf-opsawg-l3sm-l...@ietf.org>>,
 opsawg-cha...@ietf.org 
mailto:opsawg-cha...@ietf.org>>, 
opsawg@ietf.org 
mailto:opsawg@ietf.org>>, 
net...@ietf.org 
mailto:net...@ietf.org>>
Subject: Re: [OPSAWG] Francesca Palombini's Discuss on 
draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)
Hi Med,

> I confirm that what I meant is "bits per second" to align with rfc8299#6.12.1.

Ah.

> I'm actually for more explicit units similar to what we are using in another 
> active spec:

As long as there is this confusion in YANG units, that is the only way that 
makes sense.
One little tweak I'd have for that spec:

> ==
>  enum bit-ps {
>value 2;
>description
>  "Bits per Second (bit/s).";
>  }
>  enum byte-ps {
>value 3;
>description
>  "Bytes per second (Byte/s).";

Maybe use the actual ISO/IEC 8 notation here: B/s.
(For those that don't know how ISO/IEC 8 allocates "B" for byte, the legend 
"Bytes per second" is unambiguous.)

>  }
> ==
>
> However, we are in a territory where we are trying to map as much to the 
> above service model and hence use the same labels for the units.
>
> FWIW, RFC8466 used to have the following:
>
> =
>  leaf pbs {
>type uint64;
>units "bps";
>description
>  "Peak Burst Size.  It is measured in bytes per
>   second.";
>  }
> =
>
> ...which is weird.

This is really errata land, as "bps" is used as the kitchen slang for "bit/s" 
in all other cases (along with "mbps" for Mbit/s, shudder).

> This is why we don't blindly inherit that draft-ietf-opsawg-l2nm and went for 
> the following:
>
>  leaf pbs {
>type uint64;
>units "bytes per second";
>description
>  "Peak Burst Size.";
>  }

I think this would also benefit from "Bytes per Second (B/s)".

Grüße, Carsten

>
> Cheers,
> Med
>
>> -Message d'origine-
>> De : Carsten Bormann mailto:c...@tzi.org>>
>> Envoyé : lundi 4 octobre 2021 17:50
>> À : BOUCADAIR Mohamed INNOV/NET 
>> mailto:mohamed.boucad...@orange.com>>
>> Cc : Francesca Palombini 
>> mailto:francesca.palomb...@ericsson.com>>; 
>> The IESG
>> mailto:i...@ietf.org>>; 
>> draft-ietf-opsawg-l3sm-l...@ietf.org;
>>  opsawg-
>> cha...@ietf.org; 
>> opsawg@ietf.org; 
>> net...@ietf.org
>> Objet : Re: [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-
>> l3sm-l3nm-16: (with DISCUSS and COMMENT)
>>
>> On 2021-10-04, at 13:34, 
>> mohamed.boucad...@orange.com wrote:
>>>
>>> bytes per second (bps),
>>
>> Whoa.
>>
>> I know that the IETF doesn't usually care about precision in these things,
>> but "bps" is kitchen slang for "bit/s", so this is very confusing.
>>
>> (Given that we have done the work in RFC 8428 and 8798, I'd rather see
>> that we use it, instead of creating more confusion at each further step.
>> We do have ms and B/s in RFC 8798, because people using SenML asked for
>> that.)
>>
>> Grüße, Carsten
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a 

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-l3sm-l3nm-11.txt

[Rob Wilton (rwilton)]

Thanks Med for confirming that all IETF LC comments have been resolved.  I've 
issued the IESG ballot, it should be on the telechat in approx. 2 week's time.

Regards,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 10 September 2021 08:14
> To: opsawg@ietf.org; Rob Wilton (rwilton) 
> Cc: draft-ietf-opsawg-l3sm-l...@ietf.org
> Subject: RE: [OPSAWG] I-D Action: draft-ietf-opsawg-l3sm-l3nm-11.txt
> 
> Hi Rob, all,
> 
> This version integrates the IETF LC comments. Detailed replies for each
> review were already sent to the list.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de internet-
> > dra...@ietf.org
> > Envoyé : vendredi 10 septembre 2021 08:06
> > À : i-d-annou...@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : [OPSAWG] I-D Action: draft-ietf-opsawg-l3sm-l3nm-11.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 Layer 3 VPN Network YANG Model
> > Authors : Samier Barguil
> >   Oscar Gonzalez de Dios
> >   Mohamed Boucadair
> >   Luis Angel Munoz
> >   Alejandro Aguado
> > Filename: draft-ietf-opsawg-l3sm-l3nm-11.txt
> > Pages   : 142
> > Date: 2021-09-09
> >
> > Abstract:
> >This document defines an L3VPN Network YANG Model (L3NM) that can
> be
> >used for the provisioning of Layer 3 Virtual Private Network (VPN)
> >services within a service provider network.  The model provides a
> >network-centric view of L3VPN services.
> >
> >L3NM is meant to be used by a network controller to derive the
> >configuration information that will be sent to relevant network
> >devices.  The model can also facilitate the communication between a
> >service orchestrator and a network controller/orchestrator.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/
> >
> > There is also an htmlized version available at:
> > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l3sm-l3nm-11
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-l3sm-l3nm-11
> >
> >
> > 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
> 
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.

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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-vpn-common-10.txt

[Rob Wilton (rwilton)]

Thanks Med for confirming that all IETF LC comments have been resolved.  I've 
issued the IESG ballot, it should be on the telechat in approx. 2 week's time.

Regards,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 10 September 2021 08:07
> To: Rob Wilton (rwilton) ; opsawg@ietf.org
> Cc: draft-ietf-opsawg-vpn-common@ietf.org
> Subject: RE: [OPSAWG] I-D Action: draft-ietf-opsawg-vpn-common-10.txt
> 
> Hi Rob, all,
> 
> This version integrates the IETF LC comments, mainly those revived from
> directorate reviewers. Detailed replies for each review were already sent to
> the list.
> 
> We are ready for the IESG review.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de internet-
> > dra...@ietf.org
> > Envoyé : vendredi 10 septembre 2021 07:54
> > À : i-d-annou...@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : [OPSAWG] I-D Action: draft-ietf-opsawg-vpn-common-10.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 Layer 2/3 VPN Common YANG Model
> > Authors : Samier Barguil
> >   Oscar Gonzalez de Dios
> >   Mohamed Boucadair
> >   Qin Wu
> > Filename: draft-ietf-opsawg-vpn-common-10.txt
> > Pages   : 69
> > Date: 2021-09-09
> >
> > Abstract:
> >This document defines a common YANG module that is meant to be
> reused
> >by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN
> >network models.
> >
> > Editorial Note (To be removed by RFC Editor)
> >
> >Please update these statements within the document with the RFC
> >number to be assigned to this document:
> >
> >*  "This version of this YANG module is part of RFC ;"
> >
> >*  "RFC : A Layer 2/3 VPN Common YANG Model";
> >
> >*  reference: RFC 
> >
> >Also, please update the "revision" date of the YANG module.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/
> >
> > There is also an htmlized version available at:
> > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-vpn-common-10
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-vpn-common-10
> >
> >
> > 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
> 
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.

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

Re: [OPSAWG] AD review of draft-ietf-opsawg-vpn-common-08

[Rob Wilton (rwilton)]

Hi Med,

[Just to also close this thread/review.]

I think that you are good to go.

Thanks for accommodating my comments.

Regards,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 13 July 2021 16:17
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-vpn-
> common@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-vpn-common-08
> 
> Re-,
> 
> I updated the file to take into account your feedback:
> 
> * Module: https://github.com/IETF-OPSAWG-
> WG/lxnm/commit/fcc9f6c1e79d5074469fe454d95770fe9f1becdb (in addition
> to the changes already reported as part of the L3NM review).
> * I-D: https://tinyurl.com/vpn-common-latest
> 
> Unless you have further comments, I will contact the secretariat to publish
> this version. Thanks.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > Envoyé : mardi 13 juillet 2021 16:25
> > À : BOUCADAIR Mohamed INNOV/NET
> ;
> > draft-ietf-opsawg-vpn-common@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : RE: AD review of draft-ietf-opsawg-vpn-common-08
> >
> > Hi Med,
> >
> > Please see inline, just a couple of points to resolve ...
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > 
> > > Sent: 12 July 2021 18:35
> > > To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> > vpn-
> > > common@ietf.org
> > > Cc: opsawg@ietf.org
> > > Subject: RE: AD review of draft-ietf-opsawg-vpn-common-08
> > >
> > > Hi Rob,
> > >
> > > Many thanks for the review. A candidate updated version can be
> > seen at:
> > > https://tinyurl.com/vpn-common-latest
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com] Envoyé :
> > lundi
> > > > 12 juillet 2021 17:15 À : draft-ietf-opsawg-vpn-
> > common@ietf.org
> > > > Cc : opsawg@ietf.org
> > > > Objet : AD review of draft-ietf-opsawg-vpn-common-08
> > > >
> > > > Hi,
> > > >
> > > > This is my AD review of draft-ietf-opsawg-vpn-common-08.
> > > >
> > > > Thank you for this document.  Again, just minor
> > > > comments/suggestions.
> > > >
> > > >
> > > >
> > > > 1.
> > > > In section 3.  Description of the VPN Common YANG Module
> > > > "Encapsulation features  such as" -> "Encapsulation features.
> > Such
> > > > as"
> > > > "Routing features  such as" -> "Routing features.  Such as"
> > > >
> > >
> > > [Med] Fixed.
> >
> >
> > Okay.
> >
> > >
> > > > 2.
> > > > As a very minor comment.  Where you have lists (i.e.,
> > encapsulation
> > > > features, routing features, service type) and particularly
> > because
> > > > they have references, it may be slightly easier to read if the
> > list
> > > > was indented.  Also does it make sense for this list to just be
> > > > examples, or are they actually normative lists of service types
> > that
> > > > are supported?
> > >
> > > [Med] Sure. These are only examples. We cite them as we need to
> > list
> > > include in the main text any reference quoted in the module.
> >
> > Okay.
> >
> >
> > >
> > > >
> > > > E.g.,
> > > >'service-type':  Used to identify the VPN service type.
> > > >   Examples of supported service types are:
> > > >
> > > >   o L3VPN,
> > > >
> > > >   o Virtual Private LAN Service (VPLS) using BGP [RFC4761],
> > > >
> > > >   o VPLS using Label Distribution Protocol (LDP) [RFC4762],
> > > >
> > > >   o Virtual Private Wire Service (VPWS) [RFC8214],
> > > >
> > > >   o BGP MPLS-Based Ethernet VPN [RFC7432],
> > > >
> > > >   o Ethernet VPN (EVPN) [RFC8365], and
> > > >
> > > >   o Provider Backbone Bridging Combined with Ethernet
> > > > VPN (PBB-EVPN) [RFC7623].
> > > >
> > > >
> > > > In the Yang Modul

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

[Rob Wilton (rwilton)]

Hi Med,

I think that you are good to go.

Thanks for accommodating my comments.

Regards,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 13 July 2021 17:04
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-l3sm-
> l3nm@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09
> 
> Re-,
> 
> Please see inline.
> 
> Cheeers,
> Med
> 
> > -----Message d'origine-
> > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > Envoyé : mardi 13 juillet 2021 17:55
> > À : BOUCADAIR Mohamed INNOV/NET
> ;
> > draft-ietf-opsawg-l3sm-l3nm@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09
> >
> > Hi Med,
> >
> > Looking at the diff, I think that you have a typo for "oubound".
> 
> [Med] Will be fixed.
> 
> >
> > But just to check, the "inbound-rate-limit" and "inbound-bandwidth"
> > both act in the same direction, right?
> 
> [Med] Yes. The text says inbound-rate-limit is a % of inbound-bandwidth.
> 
> The text also indicates that the direction is from the perspective of the
> customer site. That definition is also inherited from the common module. We
> don't revert the directions to ease the mapping between L3SM and L3NM.
> 
> 
>   That was the consistency
> > that I was striving for.  Normally, when I think of a QoS policy as
> > acting on say a PE interface, I think that inbound/outbound would
> > have the reverse sense to have the input-bandwidth/outbound-
> > bandwidth is described.   I think that it would be good for these
> > directions to be consistency if possible, but at a minimum the
> > description needs to be very clear and using input vs inbound
> > perhaps makes more sense if they are acting in different directions.
> >
> > Thanks,
> > Rob
> >
> 
> 
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.

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

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

[Rob Wilton (rwilton)]

Hi Med,

Looking at the diff, I think that you have a typo for "oubound".

But just to check, the "inbound-rate-limit" and "inbound-bandwidth" both act in 
the same direction, right?  That was the consistency that I was striving for.  
Normally, when I think of a QoS policy as acting on say a PE interface, I think 
that inbound/outbound would have the reverse sense to have the 
input-bandwidth/outbound-bandwidth is described.   I think that it would be 
good for these directions to be consistency if possible, but at a minimum the 
description needs to be very clear and using input vs inbound perhaps makes 
more sense if they are acting in different directions.

Thanks,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 13 July 2021 15:42
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-l3sm-
> l3nm@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09
> 
> Ho Rob,
> 
> I updated the files to take into account your feedback:
> 
> * Fix input/output in the common I-D (diff): https://github.com/IETF-
> OPSAWG-WG/lxnm/commit/ff456448a9398311457eb51c1d78adc8210fd8f8
> * L3NM (diff): https://github.com/IETF-OPSAWG-
> WG/lxnm/commit/ed48b938990e6e7e4be7e329d986592ebcdc0c37
> * I-D (diff): https://tinyurl.com/l3nm-latest
> 
> Please see inline for the context.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > Envoyé : mardi 13 juillet 2021 14:52
> > À : BOUCADAIR Mohamed INNOV/NET
> ;
> > draft-ietf-opsawg-l3sm-l3nm@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09
> >
> > Hi Med,
> >
> > Thanks for the quick reply.
> >
> > A few comments inline ...
> >
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > 
> > > Sent: 12 July 2021 18:57
> > > To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> > l3sm-
> > > l3nm@ietf.org
> > > Cc: opsawg@ietf.org
> > > Subject: RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09
> > >
> > > Re-,
> > >
> > > Many thanks for the review. A candidate version can be tracked at:
> > > https://tinyurl.com/l3nm-latest.
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com] Envoyé :
> > lundi
> > > > 12 juillet 2021 14:13 À : draft-ietf-opsawg-l3sm-
> > l3nm@ietf.org
> > > > Cc : opsawg@ietf.org
> > > > Objet : AD review of draft-ietf-opsawg-l3sm-l3nm-09
> > > >
> > > > Hi,
> > > >
> > > > Sorry for the delay in the review (it is a long draft).  The
> > review
> > > > of the common l2vpn module will follow later today.
> > > >
> > > > I believe that this work will be really helpful for SPs
> > modelling
> > > > their networks and hence I would like to thank the authors,
> > > > shepherd, and WG for the effort that they have put into this
> > > > document.
> > > >
> > > > Most of my comments on this draft are either minor, or editorial
> > in
> > > > nature.  I've listed the minor questions first, for which a
> > response
> > > > would be useful, and then the editorial/grammar suggestions are
> > at
> > > > the end, and in the attached copy of the draft (labelled with
> > #RW:).
> > > >
> > > >
> > > > 4.  L3NM Reference Architecture
> > > >
> > > >The terminology from [RFC8309] is introduced to show the
> > > > distinction
> > > >between the customer service model, the service delivery
> > model,
> > > > the
> > > >network configuration model, and the device configuration
> > model.
> > > > In
> > > >that context, the "Domain Orchestration" and "Config
> > Manager"
> > > > roles
> > > >may be performed by "Controllers".
> > > >
> > > > 1. Service delivery model doesn't seem to be included in figure
> > 1,
> > >
> > > [Med] This is supposed to be covered by "network model" in the
> > figure.
> > > Updated the figure with an explicit mention.
> >
>

Re: [OPSAWG] AD review of draft-ietf-opsawg-vpn-common-08

[Rob Wilton (rwilton)]

Hi Med,

Please see inline, just a couple of points to resolve ...

> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 12 July 2021 18:35
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-vpn-
> common@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-vpn-common-08
> 
> Hi Rob,
> 
> Many thanks for the review. A candidate updated version can be seen at:
> https://tinyurl.com/vpn-common-latest
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > Envoyé : lundi 12 juillet 2021 17:15
> > À : draft-ietf-opsawg-vpn-common@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : AD review of draft-ietf-opsawg-vpn-common-08
> >
> > Hi,
> >
> > This is my AD review of draft-ietf-opsawg-vpn-common-08.
> >
> > Thank you for this document.  Again, just minor
> > comments/suggestions.
> >
> >
> >
> > 1.
> > In section 3.  Description of the VPN Common YANG Module
> > "Encapsulation features  such as" -> "Encapsulation features.  Such
> > as"
> > "Routing features  such as" -> "Routing features.  Such as"
> >
> 
> [Med] Fixed.


Okay.

> 
> > 2.
> > As a very minor comment.  Where you have lists (i.e., encapsulation
> > features, routing features, service type) and particularly because
> > they have references, it may be slightly easier to read if the list
> > was indented.  Also does it make sense for this list to just be
> > examples, or are they actually normative lists of service types that
> > are supported?
> 
> [Med] Sure. These are only examples. We cite them as we need to list include
> in the main text any reference quoted in the module.

Okay.


> 
> >
> > E.g.,
> >'service-type':  Used to identify the VPN service type.
> >   Examples of supported service types are:
> >
> >   o L3VPN,
> >
> >   o Virtual Private LAN Service (VPLS) using BGP [RFC4761],
> >
> >   o VPLS using Label Distribution Protocol (LDP) [RFC4762],
> >
> >   o Virtual Private Wire Service (VPWS) [RFC8214],
> >
> >   o BGP MPLS-Based Ethernet VPN [RFC7432],
> >
> >   o Ethernet VPN (EVPN) [RFC8365], and
> >
> >   o Provider Backbone Bridging Combined with Ethernet
> > VPN (PBB-EVPN) [RFC7623].
> >
> >
> > In the Yang Module:
> >
> > 3. OPSA => OPSAWG
> > Please can you check if this needs to be fixed for the L3NM YANG
> > model as well.
> 
> [Med] Fixed.

Okay.

> 
> >
> > 4.
> >   feature qinany {
> > description
> >   "Indicates the support of the QinAny encapsulation.";
> >   }
> >
> > Is there a reference, or perhaps a more detailed description that
> > you can use here?
> >
> 
> [Med] This was also a comment raised in the WGLC, but we don't have any
> acceptable authoritative reference to cite for it.

Okay, then perhaps give a brief description of what QinAny means, i.e., in this 
context I think that frames have a pair of VLAN Ids, where the outer VLAN Id is 
fixed, but the inner VLAN Id can take any valid VLAN Id value.


> 
> > 5.
> > Very minor:
> > feature ipv4, feature ipv6, is it worth adding references to the
> > RFCs?  I appreciate that they are obvious, but since you have
> > references for everything else, it seems like it might be worth
> > using adding them?
> 
> [Med] OK

Okay.

> 
> >
> > 6.
> >   feature rtg-ospf-sham-link {
> > description
> >   "Indicates support of OSPF sham links.";
> >
> > Does this mean that feature rtg-ospf excldues this support?  This
> > feature seems very specific relative to the other features in this
> > YANG module.
> 
> [Med] Yes. We are barrowing this one for RFC8299, fyi.

Okay, makes sense.


> 
> >
> > 7.
> > As mentioned in the other document, would "feature carrierscarrier"
> > be better as "feature carriers-carrier"?
> 
> [Med] No problem. Fixed.

Okay.

> 
> >
> > 8.
> > "Indicates the support of" => "Indicates support for"
> > "Indicates support of" -> "Indicates support for"
> 
> [Med] Fixed.

Okay.

> 
> >
> > 9.
> > This model defines a lot of features, and I wasn't sure how helpful
> > that will really be in practice.  Is the intention here for an SP to
> > use features to

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

[Rob Wilton (rwilton)]

Hi Med,

Thanks for the quick reply.

A few comments inline ...


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 12 July 2021 18:57
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-l3sm-
> l3nm@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09
> 
> Re-,
> 
> Many thanks for the review. A candidate version can be tracked at:
> https://tinyurl.com/l3nm-latest.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > Envoyé : lundi 12 juillet 2021 14:13
> > À : draft-ietf-opsawg-l3sm-l3nm@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : AD review of draft-ietf-opsawg-l3sm-l3nm-09
> >
> > Hi,
> >
> > Sorry for the delay in the review (it is a long draft).  The review
> > of the common l2vpn module will follow later today.
> >
> > I believe that this work will be really helpful for SPs modelling
> > their networks and hence I would like to thank the authors,
> > shepherd, and WG for the effort that they have put into this
> > document.
> >
> > Most of my comments on this draft are either minor, or editorial in
> > nature.  I've listed the minor questions first, for which a response
> > would be useful, and then the editorial/grammar suggestions are at
> > the end, and in the attached copy of the draft (labelled with #RW:).
> >
> >
> > 4.  L3NM Reference Architecture
> >
> >The terminology from [RFC8309] is introduced to show the
> > distinction
> >between the customer service model, the service delivery
> > model, the
> >network configuration model, and the device configuration
> > model.  In
> >that context, the "Domain Orchestration" and "Config
> > Manager" roles
> >may be performed by "Controllers".
> >
> > 1. Service delivery model doesn't seem to be included in figure 1,
> 
> [Med] This is supposed to be covered by "network model" in the figure.
> Updated the figure with an explicit mention.

Ok.

> 
> > and doesn't appear to be referenced further.  Does it need to be
> > mentioned at all?
> >
> >
> > 7.3.  VPN Services
> >
> >The 'vpn-service' is the data structure that abstracts a
> > VPN service
> >in the service provider network.  Each 'vpn-service' is
> > uniquely
> >identified by an identifier: 'vpn-id'.  Such 'vpn-id' is
> > only
> >meaningful locally within the network controller.  The
> > subtree of the
> >
> > 2. Why limit the vpn-id to the network controller?  Presumably, an
> > implementation could allow these identifiers to be unique within the
> > SP's management network (e.g., perhaps by using a network controller
> > specific prefix)?
> 
> [Med] Agree. Made this change: s/meaningful locally (e.g., within the
> network controller)

Ok.

> 
> >
> >
> > 7.4.  VPN Instance Profiles
> >
> > | |  |  +--rw vpn-policies
> > | |  | +--rw import-policy?   string
> > | |  | +--rw export-policy?   string
> >
> > 3. Is it right that import-policy and export-policy are plain
> > strings?
> 
> [Med] That usage is correct as we define vpn-id in the common draft as a
> generic identifier. That is why we mention "service identifier" as an example.
> We can make that more clearer in the common I-D.

Yes, making it clearer in the common I-D, will be helpful.


> 
> >
> >
> > 7.6.  VPN Network Access
> >
> > +--rw vpn-network-access* [id]
> >+--rw id vpn-
> > common:vpn-id
> >+--rw port-id?   vpn-
> > common:vpn-id
> >
> > 4. I'm surprised that port-id is of type vpn-common:vpn:id
> 
> [Med]  We don't require any structure for the identification of the port;
> hence the use of the string (vpn-common:vpn-id) type.

Okay, my point is that the model isn't just saying that it is a string (since 
it is using the type vpn-id) but is using a type with more meaning assigned to 
it.  I.e., I would expect that a vpn-id should be the identifier for a VPN.  If 
isn't one of these, then I don't think that it should be a vpn-id.

> 
> 
>  Also, is
> > the name port-id better than interface-id?  E.g., if the
> > connectivity was not via a physical port?  I think that th

[OPSAWG] AD review of draft-ietf-opsawg-vpn-common-08

[Rob Wilton (rwilton)]

Hi,

This is my AD review of draft-ietf-opsawg-vpn-common-08.

Thank you for this document.  Again, just minor comments/suggestions.



1.
In section 3.  Description of the VPN Common YANG Module
"Encapsulation features  such as" -> "Encapsulation features.  Such as"
"Routing features  such as" -> "Routing features.  Such as"

2.
As a very minor comment.  Where you have lists (i.e., encapsulation features, 
routing features, service type) and particularly because they have references, 
it may be slightly easier to read if the list was indented.  Also does it make 
sense for this list to just be examples, or are they actually normative lists 
of service types that are supported?

E.g., 
   'service-type':  Used to identify the VPN service type.  
  Examples of supported service types are:
  
  o L3VPN,
  
  o Virtual Private LAN Service (VPLS) using BGP [RFC4761],
  
  o VPLS using Label Distribution Protocol (LDP) [RFC4762],
  
  o Virtual Private Wire Service (VPWS) [RFC8214],
  
  o BGP MPLS-Based Ethernet VPN [RFC7432],
  
  o Ethernet VPN (EVPN) [RFC8365], and
  
  o Provider Backbone Bridging Combined with Ethernet
VPN (PBB-EVPN) [RFC7623].


In the Yang Module:

3. OPSA => OPSAWG
Please can you check if this needs to be fixed for the L3NM YANG model as well.

4. 
  feature qinany {
description
  "Indicates the support of the QinAny encapsulation.";
  }
  
Is there a reference, or perhaps a more detailed description that you can use 
here?

5.
Very minor:  
feature ipv4, feature ipv6, is it worth adding references to the RFCs?  I 
appreciate that they are obvious, but since you have references for everything 
else, it seems like it might be worth using adding them?

6.
  feature rtg-ospf-sham-link {
description
  "Indicates support of OSPF sham links.";
  
Does this mean that feature rtg-ospf excldues this support?  This feature seems 
very specific relative to the other features in this YANG module.

7.
As mentioned in the other document, would "feature carrierscarrier" be better 
as "feature carriers-carrier"?

8.
"Indicates the support of" => "Indicates support for"
"Indicates support of" -> "Indicates support for"

9. 
This model defines a lot of features, and I wasn't sure how helpful that will 
really be in practice.  Is the intention here for an SP to use features to 
customize the model to their needs?  I wonder if the heavy use of features 
won't work so well if both L2VPN and L3VPN's are being modelled and support 
different protocols/etc.  Will having the common features act as a limitation?  
E.g., an alternative might be to express the features in the L2NM and L3NM 
models directly allowing them to enabled/disable different features.

10. Status leaves:
Would UP, DOWN, UNKNWON be better as Up, Down, Unknown?
Would "admin-enabled" be better than "admin-up" and "admin-disabled" be better 
than "admin-down".

For all the non-base identities, I would suggest removing the "Identity for" 
prefix in the descriptions.  It is self-evident that the descriptions are for 
identities, and the extra words probably would not help a GUI rendering of the 
description strings.

11. For all the "service type" identities, I would suggest ending all the 
descriptions with "service".
E.g., 
  "L3VPN service.";
  "Provider Backbone Bridging (PBB) EVPNs service.";
  "Virtual Private LAN Service (VPLS).";
  "Point-to-point Virtual Private Wire Service (VPWS).";
  "Provider Backbone Bridging (PBB) EVPN service.";
  "MPLS based EVPN service.";
  "VXLAN based EVPN service.";
  
12.
For the signalling identity descriptions:
  "Layer 2 VPNs using BGP signalling";
  "Targeted LDP signalling.";
  "L2TP signalling.";

13.   
For the bgp-signalling identity, does it make sense for the description to be 
specific to L2VPNs?  Couldn't bgp-signalling also be used for L3VPNs?

14.   
For the routing-protocol-type generic identities, would it make sense to add a 
"-routing" suffic to them, e.g., "direct-routing", "any-routing"?  Otherwise 
some of the identity names look fairly generic, but perhaps that is okay.

15.
vpn-topology:
 Is No P2P topology identity required?

16.
For identity qos-profile-direction:
  Rather than "site-to-wan" and "wan-to-site" identity names, would it be 
better to use "vpn" or "service" instead of wan.  E.g., "site-to-vpn", or 
"site-to-service"?

17.
  identity enhanced-vpn
  identity ietf-network-slice

Would it be helpful to add RFC or draft references for these identities?  E.g., 
[I-D.ietf-teas-enhanced-vpn], or an IETF network slice service 
[I-D.ietf-teas-ietf-network-slices]

18.
  identity protocol-type {
description
  "Base identity for Protocol Type.";
  }

  identity unknown {
base protocol-type;
description
  "Not known protocol type.";
  }
  
Is this identity required/useful?  Wouldn't it be better to 

Re: [OPSAWG] AD review of draft-ietf-opsawg-ipfix-mpls-sr-label-type-05

[Rob Wilton (rwilton)]

Thanks Thomas.

IETF LC requested.

Regards,
Rob


> -Original Message-
> From: thomas.g...@swisscom.com 
> Sent: 02 July 2021 05:23
> To: Rob Wilton (rwilton) ;
> mohamed.boucad...@orange.com
> Cc: opsawg@ietf.org; opsawg-cha...@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-ipfix-mpls-sr-label-type-05
> 
> Hi Rob,
> 
> Excellent. Many thanks for the AD review and comments.
> 
> I updated and posted the draft -06 version accordingly.
> 
> Best wishes
> Thomas
> 
> -Original Message-
> From: Rob Wilton (rwilton) 
> Sent: Thursday, July 1, 2021 8:17 PM
> To: Graf Thomas, INI-NET-TCZ-ZH1 ; draft-
> ietf-opsawg-ipfix-mpls-sr-label-type@ietf.org;
> mohamed.boucad...@orange.com
> Cc: opsawg@ietf.org; opsawg-cha...@ietf.org
> Subject: AD review of draft-ietf-opsawg-ipfix-mpls-sr-label-type-05
> 
> Hi Thomas,
> 
> This is my AD review of draft-ietf-opsawg-ipfix-mpls-sr-label-type-05.
> 
> Thanks for the draft, it is both short and sweet, and I have only a few minor
> comments/suggestions:
> 
> 1. In the abstract, I would suggest changing on which MPLS control plane
> protocol within => the MPLS control plane protocol used within
> 
> 2. Please add a reference to RFC 7012 in the IANA registrations.
> 
> E.g., something like:
> 
>This document requests IANA to allocate the following code points in
>the existing subregistry "IPFIX MPLS label type (Value 46)" under the
>"IPFIX Information Elements" registry [RFC7012] available at [IANA-IPFIX].
> 
> 3. Two minor nits:
> 
> Also [I-D.ali-spring-sr-traffic-accounting] => Also, 
> [I-D.ali-spring-sr-traffic-
> accounting]
> 
> I would like to thank to =>
> I would like to thank
> 
> Please post an updated draft with these changes, then let me know and I'll
> kick off the IETF LC.
> 
> Med, thanks for the good shepherd writeup, it is both clear and informative.
> 
> Thanks,
> Rob

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

[OPSAWG] AD review of draft-ietf-opsawg-ipfix-mpls-sr-label-type-05

[Rob Wilton (rwilton)]

Hi Thomas,

This is my AD review of draft-ietf-opsawg-ipfix-mpls-sr-label-type-05.

Thanks for the draft, it is both short and sweet, and I have only a few minor 
comments/suggestions:

1. In the abstract, I would suggest changing
on which MPLS control plane protocol within =>
the MPLS control plane protocol used within

2. Please add a reference to RFC 7012 in the IANA registrations.

E.g., something like:

   This document requests IANA to allocate the following code points in
   the existing subregistry "IPFIX MPLS label type (Value 46)" under the
   "IPFIX Information Elements" registry [RFC7012] available at [IANA-IPFIX].

3. Two minor nits:

Also [I-D.ali-spring-sr-traffic-accounting] =>
Also, [I-D.ali-spring-sr-traffic-accounting]

I would like to thank to =>
I would like to thank

Please post an updated draft with these changes, then let me know and I'll kick 
off the IETF LC.

Med, thanks for the good shepherd writeup, it is both clear and informative.

Thanks,
Rob

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

Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)

[Rob Wilton (rwilton)]

Hi Ben,

When you get a chance, please can you check whether -15 is sufficient to clear 
your discuss.  I think that is the last step to progressing this doc.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/

Regards,
Rob


> -Original Message-
> From: iesg  On Behalf Of Randy Bush
> Sent: 21 May 2021 23:12
> To: Benjamin Kaduk 
> Cc: Benjamin Kaduk via Datatracker ; draft-ietf-opsawg-
> finding-geofe...@ietf.org; opsawg-cha...@ietf.org; The IESG
> ; g...@algebras.org; opsawg@ietf.org
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-
> geofeeds-12: (with DISCUSS and COMMENT)
> 
> > If we're going with "[#RPKI Signature] address range MUST match
> [inetnum:
> > followed to get here]", then there are probably a couple places that
> still
> > talk about "covered by" that should catch up.
> 
> don't find any
> 
> what i did find is that i forgot to remove
> 
>  The address range of the signing certificate MUST cover all
> -prefixes in the geofeed file it signs; and therefore must be
> -covered by the range of the inetnum:.
> +prefixes in the geofeed file it signs.
> 
> > We may also need to look more closely at the bits after "# RPKI
> > Signature".  The example uses a CIDR range, but IIRC inetnum: ranges
> > are not limited to CIDR blocks, which would mean we need a story for
> > how to handle non-CIDR blocks.
> 
> ranges are well-defined in rpki, inetnum:, etc.  8805 entries must be
> cidr.
> 
> that an inetnum: or rpki cert range must cover geofeed file prefixes
> seems pretty clear.  but i have tweaked wording a bit.  i can push my
> emacs buffer to id repo, but will wait a bit for other comments.
> 
> randy

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