[OPSAWG]Re: Fwd: New Liaison Statement, "LS on the new work item ITU-T Q.MUD_IoT “Framework for testing and monitoring IoT devices & networks using technical Requirements from Manufacturer Usage Descr

[Qin Wu]

Agree with Michael, The essence of this work is test specification limited for 
IoT devices and the focus is functionalities test within the device. I think it 
will be more useful to test network device and MUD controller/manager. If SG11 
agrees to do this, any outcome of this work item should also been reviewed by 
BMWG in IETF.
BTW: Who will be the consumer of this test specification? Test Instrumental 
manufacturer? 

-Qin
-邮件原件-
发件人: Michael Richardson [mailto:mcr+i...@sandelman.ca] 
发送时间: 2024年5月25日 3:10
收件人: m...@ietf.org; Scott Mansfield 
抄送: Mahesh Jethanandani ; opsawg@ietf.org
主题: [OPSAWG]Re: Fwd: New Liaison Statement, "LS on the new work item ITU-T 
Q.MUD_IoT “Framework for testing and monitoring IoT devices & networks using 
technical Requirements from Manufacturer Usage Description (MUD)”"


Mahesh Jethanandani  wrote:
> Please work with ITU liaison, Scott Mansfield, if the WG thinks a 
response needs to be sent.

>> Body: Abstract: This liaison statement informs ITU-T SG20, ITU-T SG13
>>and IETF that SG11, particularly Q12/11, initiated a new work item:
>>ITU-T Q.MUD_IoT “Framework for testing and monitoring IoT devices &
>>networks using technical Requirements from Manufacturer Usage
>>Description (MUD)”.
>>
>> During the ITU-T SG11 meeting (Geneva, 01-10 May 2024), Q12/11
>>(Testing of internet of things, its applications and identification
>>systems) initiated a new work item: ITU-T Q.MUD_IoT “Framework for
>>testing and monitoring IoT devices & networks using technical
>>Requirements from Manufacturer Usage Description (MUD)”.
>>
>> ITU-T Q.MUD_IoT aims to propose a standardized framework for testing
>>and monitoring IoT devices & networks using technical requirements from
>>the Manufacturer Usage Description (MUD). This recommendation will also
>>focus on test scenarios and compliance criteria relevant to the
>>behaviour and communication patterns of IoT devices with mandatory
>>requirements of MUD RFC 8520. It does not cover test scenarios that
>>verify implementation of other network components such as MUD
>>Controller/manager.

I wish the ITU-T SG13 good luck.
The work that has been described would seem to nearly impossible to do.
Certainly very difficult to do in a black-box testing scenario.

In order to verify *compliance* of a device, it will, I think, be necessary to 
convince the device to actually *do* all the things that it can.  Then observe 
if the MUD file actually allows all those things.

Aside from the difficulty of getting vendors to produce MUD files *at all*, I 
have no idea how SG13 plans to convince an IoT device to do all its things.

So my liason reply would be: "Sounds great.  Please email m...@ietf.org if 
there are details you need help with"

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

Re: [OPSAWG] WG LC: Attachment circuits work

[Qin Wu]

Hi,
These three Attachment Circuits work were factored out from L3SM, L2SM and are 
important foundation components and reusable building blocks for Network 
Service automation, can be applied to various different service scenarios such 
as network slicing, L3VPN, Site to Cloud etc
In addition, it separates AC provision from VPN service provision, which can 
greatly accelerate service delivery speed.
I have read the latest version, believe it is ready for publication. Also I 
have been aware that some operators have already planned to implement these 
work for network slicing automation solution.

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

主题: [Teas] WG LC: Attachment circuits work

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

The Attachment Circuits work is divided into four documents:

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

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

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

Re: [OPSAWG] IPR POLL: Attachment circuits work

[Qin Wu]

Hi, Joe:
No, I'm not aware of any IPR that applies to these drafts

-Qin
De: OPSAWG mailto:opsawg-boun...@ietf.org>> En nombre 
de Joe Clarke (jclarke)
Enviado el: viernes, 19 de abril de 2024 16:32
Para: opsawg@ietf.org
Asunto: [OPSAWG] IPR POLL: Attachment circuits work
We're up to WG LC on these four drafts.  And while we did an IPR poll before, 
we want to be thorough since this work has evolved.

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

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

Please state either:

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

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

If yes to the above, please state either:

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

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

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

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

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

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

[OPSAWG] Opsdir last call review of draft-ietf-opsawg-mud-tls-13

[Qin Wu via Datatracker]

Reviewer: Qin Wu
Review result: Has Issues

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This draft defines 3 YANG modules and specifies TLS profile for IoT device.
This TLS or DTLS profile can be used to detect unexpected TLS usage and prevent
malware download, block access to malicious domains, etc.

This document is on the right track and almost ready for publication. However I
have a few comments, especially to security section and IANA section, on the
latest version v-13: Major issues: None

Minor issues
1. Abstract said:
"
This memo extends the Manufacturer Usage Description (MUD)
specification to incorporate (D)TLS profile parameters.
"
This draft defines 3 YANG data modules, do you think all these 3 YANG modules
extend MUD specification?

2. Section 5.3 IANA (D)TLS profile YANG Module
Section 5.3 seems a little bit overdesign, see the section 2 of RFC7224, I
think the first 5 paragraphs in section 5.3 can be moved or consolidated into
IANA subsection for specific IANA maintained module.

3. Section 6 Processing of the MUD (D)TLS Profile
As for processing of the MUD TLS profile, I am wondering when the MUL DTLS
profile is not compliant, e.g., some TLS parameters are not defined in the MUD
TLS profile, do we need to define Error handling and standard Error code,
report specific error code to the management system? If it is not in the scope,
I think it will be nice to call out explicitly. Otherwise it seems like a not
complete solution.

4. Section 6 said:
"
If the (D)TLS parameter observed in a (D)TLS session is not
specified in the MUD (D)TLS profile and the (D)TLS parameter is
not recognized by the firewall, it can ignore the unrecognized
parameter and the correct behavior is not to block the (D)TLS
session.
"
Regarding DTLS parameters not recognized by the firewall, I am wondering there
still is potential security risk. Is there needed to report these unrecognized
parameters associated with some security context information to the management
system for further investigation.

5. Section 6 also said:
"
*  Deployments update at different rates, so an updated MUD (D)TLS
profile may support newer parameters.  If the firewall does not
recognize the newer parameters, an alert should be triggered to
the firewall vendor and the IoT device owner or administrator.
"
I believe this alert is necessary for security protection or further
investigation, do you think the same alert should be used to remind IoT Device
owner or administrators to update device software or firmware?

6 Section 8 Security Section
This draft defines three YANG modules, ietf-acl-tls.yang,
iana-tls-profile.yang, ietf-mud-tls. ietf-acl-tls.yang is extended from ACL
module defined in RFC8519, iana-tls-profile.yang is standalone module, the
third module draft-mud-tls is extended from MUD module defined in RFC8520.
Following the structure of section 5 of draft-ietf-netconf-ssh-client-server, I
think security consideration should be specified for each YANG data module.

Secondly, since the first YANG module ietf-acl-tls.yang is extended from ACL
YANG data module defined in RFC85219 therefore I still think security
considerations mentioned in Section 3.7 of [RFC8407]still apply. Please follow
example in section 5.7 of draft-ietf-netconf-ssh-client-server.

7. Section 8 Security consideration
s/anomaly detection/network anomaly detection

8. Section 10 IANA consideration
Similarly, since this draft defines three YANG data modules, I think IANA
consideration should be specified for each YANG data module. You can follow the
example in section 6.3, 6.4 of draft-ietf-netconf-ssh-client-server.

9. Section 10 IANA consideration said:
"
IANA is requested to create an the initial version of the IANA-
maintained YANG Module called "iana-tls-profile", based on the
contents of Section 5.3, which will allow for new (D)TLS parameters and (D)TLS
versions to be added.  IANA is requested to add this note: " Please follow the
template defined in Section 4.30.3.1 of [I-D.ietf-netmod-rfc8407bis] for IANA
maintained YANG modules and consolidate the text described in section 5.3. See
example in section 6.4 of draft-ietf-netconf-ssh-client-server.



___
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

[Qin Wu]

Hi, Nigel, Joe, and Italo
Thanks for valuable input to this draft, see my reply inline below.
发件人: Davis, Nigel [mailto:nda...@ciena.com]
发送时间: 2024年2月20日 21:06
收件人: Italo Busi ; Qin Wu 
; Joe Clarke (jclarke) 
; Henk Birkholz 
; OPSAWG ; n...@ietf.org
主题: RE: [OPSAWG]  WG Adoption Call for draft-feng-opsawg-incident-management-04

Hi all,

As Joe points out, there is work by other bodies in this area that must be 
accounted for, and that was certainly the intention. One of the challenges of 
course, as Joe also notes, is gaining access to some of this work. In addition, 
in many cases one bodies work can only be used in the context of the other 
models from that body. We did discuss in TM Forum (~15 years ago), the 
construction of a federation of models from various bodies, but this did not 
develop. Since then we have had several attempts to reduce unnecessary variety 
in the industry with some success (that has usually occurred where there are 
individuals active across several bodies). Perhaps it is time to approach that 
federation again.

[Qin Wu] Thanks for sharing your experience to work with other SDOs or 
organizations,  I am optimistic with coordinations between IETF and many other 
various different SDOs. First IETF have liaison coordinators and liaison 
manager to facilitate such coordination, secondly even there is no formal 
liaison relation between IETF and other organization or body, it doesn’t prevent
Liaison statement exchanged between any two organization. Note that IVY WG was 
created  based on ITU-T SG15, ONF, IETF, Openconfig have common interests in 
some common building block. TMF in the past has sent many liaison statement to 
IETF, IRTF for feedback, it works well, you can check liaison 
pages(https://datatracker.ietf.org/liaison/). Many successful story depends on 
whether we have some delegate who in both organizations.
I think access to some work in SDOs who require membership is not big issues, 
e.g., for some SDOs, when standard work get published, it will be available to 
the public.

Considering federation, we have a similar work item in TAPI (related to problem 
reporting). The intention now is to not develop the model in the TAPI community 
and instead to leverage the IETF work. Hence, my aim is to ensure that the IETF 
work is also applicable for TAPI so that we have one YANG model, developed in 
IETF, that supports both needs. I aim to coordinate this as we proceed. The 
work in IETF will provide an open YANG model that is aligned with other IETF 
models and the intention is that this be consistent with the TAPI model.

[Qin Wu] Great to see TAPI community is willing to leverage the IETF work and 
thanks for help coordinate between TAPI community and IETF community, which 
help build a good eco-system.
One thing I want to clarify, TMF is not aimed at developing any YANG data 
model, they publish many API profile, but they are not targeted to develop YANG 
model work.
Note than I have reached out TMF experts who publish related work, he will 
chime in probably soon to clarify such collaboration.

As noted in the email chain below, there is a terminology challenge. We have 
taken an action to clean up the terminology usage and will aim to, where 
possible, align with terms used in the industry (although, as is often the 
case, the terms are used ambiguously and will need local definitions).

[Qin Wu] Thanks, one input from my side is we may use various different term at 
device level, network level, service level, I hope this alignment take place at 
each level. It is not good conflate everything together without level 
categorization.

I hope the above helps…

Regards,

Nigel


From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of Italo Busi
Sent: Monday, February 19, 2024 2:59 PM
To: Qin Wu mailto:bill...@huawei.com>>; Joe Clarke 
(jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 Henk Birkholz mailto:henk.birkholz@ietf.contact>>; 
OPSAWG mailto:opsawg@ietf.org>>; 
n...@ietf.org<mailto:n...@ietf.org>
Subject: [**EXTERNAL**] Re: [OPSAWG]  WG Adoption Call for 
draft-feng-opsawg-incident-management-04

Qin, Joe,

A couple of comments of mine in line

Thanks, Italo

From: Qin Wu mailto:bill...@huawei.com>>
Sent: domenica 18 febbraio 2024 03:13
To: Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 Henk Birkholz mailto:henk.birkholz@ietf.contact>>; 
OPSAWG mailto:opsawg@ietf.org>>; 
n...@ietf.org<mailto:n...@ietf.org>
Subject: Re: [OPSAWG]  WG Adoption Call for 
draft-feng-opsawg-incident-management-04

Hi, Joe:
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2024年2月16日 21:15
收件人: Henk Birkholz 
mailto:henk.birkholz@ietf.contact>>; OPSAWG 
mailto:opsawg@ietf.org>>
主题: Re: [OPSAWG]  WG Adoption Call for draft-feng-opsawg-incident-management-04

=== As a contributor ===

I struggle to see why the IETF should be working on thi

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

[Qin Wu]

Thanks Roland for your support.
I have noted down your comment in the github issue tracker
https://github.com/billwuqin/network-incident/issues/6
I can see two key differences:
1. draft feng-opsawg- focus on "network as a service" interface while 
draft-netana-opsawg-nmrg-network-anomaly-semantics is more related to telemetry 
interface
2. draft feng-opsawg focus on abstraction of network anomaly and performance 
data, other various data such log data, why draft--netana-opsawg-nmrg-network 
focus on correlating symptom data with incident data,
  Note that draft--netana-opsawg-nmrg-network references feng-opsawg for the 
term "incident".
Therefore my first impression they are complementary. Yes we will discuss align 
between two drafts, thanks for bringing this up earlier.

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 roland.sch...@telekom.de
发送时间: 2024年2月22日 2:54
收件人: opsawg@ietf.org
主题: Re: [OPSAWG]  WG Adoption Call for draft-feng-opsawg-incident-management-04

Hi,

regarding the adoption of the draft as WG item, I think this is a good idea to 
work on.

I have in mind that there has been the aim align the 
ietf-incident-semantic-metadata.yang with draft-feng-opsawg-incident-management.
In case this has not been done so far, I suggest having a look into this. 
This could be done after the adoption of the draft. 

Best Regards

Roland



-Ursprüngliche Nachricht-
Von: Henk Birkholz  
Gesendet: Donnerstag, 8. Februar 2024 16:44
An: OPSAWG 
Betreff: [OPSAWG]  WG Adoption Call for 
draft-feng-opsawg-incident-management-04

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]  WG Adoption Call for draft-feng-opsawg-incident-management-04

[Qin Wu]

Thanks Zhengqiang for your support and comment.
Regarding you question, incident server needs to rely on data correlation 
technology and data analytics component to tell him the real effect on the 
relevant service, such data correlation technology is also referred to as 
service impact analysis to help incident server to understand whether lower 
level or device level network anomaly has impact on the service, hope this 
clarifies.

-Qin
发件人: li_zhenqi...@hotmail.com [mailto:li_zhenqi...@hotmail.com]
发送时间: 2024年2月20日 16:10
收件人: Qin Wu ; Rob Wilton (rwilton) ; 
alex.huang-f...@insa-lyon.fr; Henk Birkholz ; 
draft-feng-opsawg-incident-management@ietf.org
抄送: opsawg@ietf.org; n...@ietf.org
主题: Re: Re: [OPSAWG] WG Adoption Call for 
draft-feng-opsawg-incident-management-04

Hello all,

I think NMOP is the right place to discuss this draft now. I support its 
adoption there.

Please consider the following question: As the definition in this draft, 
network incident is defined from the perspective of a service and is raised by 
an incident server. Can the incident server know the real effect on the 
relevant services? For example, in figure 5 in this draft, VPN A may not 
perceive the link down between P1 and P2 because its packets are not lost 
during the interruption.


Best Regards,
Zhenqiang Li
China Mobile
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

发件人： Qin Wu<mailto:bill.wu=40huawei@dmarc.ietf.org>
发送时间： 2024-02-18 10:17
收件人： Rob Wilton (rwilton)<mailto:rwil...@cisco.com>; Alex Huang 
Feng<mailto:alex.huang-f...@insa-lyon.fr>; Henk 
Birkholz<mailto:henk.birkholz@ietf.contact>; 
draft-feng-opsawg-incident-management@ietf.org<mailto:draft-feng-opsawg-incident-management@ietf.org>
抄送： OPSAWG<mailto:opsawg@ietf.org>; n...@ietf.org<mailto:n...@ietf.org>
主题： Re: [OPSAWG] WG Adoption Call for draft-feng-opsawg-incident-management-04
Hi, NMOP Chairs:
Since this document has been discussed in OPSAWG for a long time, and because 
it was ready for adoption there, and considering that it is now 'suddenly' in 
scope for NMOP, could we please consider moving the existing adoption poll to 
NMOP (perhaps extending it to make up for time when NMOP was not aware of the 
poll).

-Qin (on behalf of authors)
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
发送时间: 2024年2月13日 18:06
收件人: Alex Huang Feng 
mailto:alex.huang-f...@insa-lyon.fr>>; Henk 
Birkholz mailto:henk.birkholz@ietf.contact>>; 
draft-feng-opsawg-incident-management@ietf.org<mailto:draft-feng-opsawg-incident-management@ietf.org>
抄送: OPSAWG mailto:opsawg@ietf.org>>; 
n...@ietf.org<mailto:n...@ietf.org>
主题: Re: [OPSAWG] [cid:image002.jpg@01DA673C.DF63A880] WG Adoption Call for 
draft-feng-opsawg-incident-management-04

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 mailto:opsawg-boun...@ietf.org>> on 
behalf of Alex Huang Feng 
mailto:alex.huang-f...@insa-lyon.fr>>
Date: Tuesday, 13 February 2024 at 05:25
To: Henk Birkholz 
mailto:henk.birkholz@ietf.contact>>
Cc: OPSAWG mailto:opsawg@ietf.org>>
Subject: Re: [OPSAWG] [cid:image002.jpg@01DA673C.DF63A880] 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 
mailto:henk.birkholz@ietf.contact>> 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 se

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

[Qin Wu]

Hi, NMOP Chairs:
Since this document has been discussed in OPSAWG for a long time, and because 
it was ready for adoption there, and considering that it is now 'suddenly' in 
scope for NMOP, could we please consider moving the existing adoption poll to 
NMOP (perhaps extending it to make up for time when NMOP was not aware of the 
poll).

-Qin (on behalf of authors)
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
发送时间: 2024年2月13日 18:06
收件人: Alex Huang Feng ; Henk Birkholz 
; draft-feng-opsawg-incident-management@ietf.org
抄送: OPSAWG ; n...@ietf.org
主题: Re: [OPSAWG]  WG Adoption Call for draft-feng-opsawg-incident-management-04

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 mailto:opsawg-boun...@ietf.org>> on 
behalf of Alex Huang Feng 
mailto:alex.huang-f...@insa-lyon.fr>>
Date: Tuesday, 13 February 2024 at 05:25
To: Henk Birkholz 
mailto:henk.birkholz@ietf.contact>>
Cc: OPSAWG mailto:opsawg@ietf.org>>
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 
mailto:henk.birkholz@ietf.contact>> 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]  WG Adoption Call for draft-feng-opsawg-incident-management-04

[Qin Wu]

Hi, Joe:
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2024年2月16日 21:15
收件人: Henk Birkholz ; OPSAWG 
主题: Re: [OPSAWG]  WG Adoption Call for draft-feng-opsawg-incident-management-04

=== As a contributor ===

I struggle to see why the IETF should be working on this.  Clearly there are 
other SDOs that work in the area of incident management.  This draft refers to 
a [IMHO tenuous] reference to a TM Forum API spec (which I cannot read as I am 
not a member), but ITIL has similar definitions of incidents and problems.  
There does not seem to be any liaison or indication of a close relationship 
with these other SDOs to help drive consistent use of terminology and help 
their members achieve desired goals.

[Qin Wu]
Thanks Joe for valuable input and comments, see my clarification in the 
presentation in IETF 116 
(https://datatracker.ietf.org/meeting/116/materials/slides-116-opsawg-incident-management-for-network-service-00.pdf),
 which I clarify the relationship
with TMF API spec, as you can see what draft-feng proposes to do is to define 
YANG model for incident lifecycle management, complementary to TMF API profile 
which focus on requirements, function, component capability. Talking with TMF 
API profile authors in TMF, they are happy to have this work land on IETF since 
IETF has more YANG model work expertise.

Secondly, the definition of network incidents and problems in TMF API spec is 
sourced from ITIL. ITIL is an internationally recognized and widespread 
de-facto standard for IT services management, not **developed by any other 
SDOs**, the idea of the definition of network incident and problem in TMF API 
spec is to introduce incident concept originally applied to IT field to 
**operator's network field**, which require support not only from domain 
controllers but also OSS. The typical scenario not only applied to optical 
scenario but also applied to IP network scenario.
Therefore in my opinion, alignment with TMF specification by quoting TMF 
network incident definition is sufficient, note that TMF specification has 
already been published by TMF. if you think necessary, I can consult with TMF 
specification authors for clarification.

Even in this first pass, I see what I feel is a mix of terminology.  You have 
an enumeration on leaf type where “fault” reads as the type of incident being a 
fault.  To me, this is the type of problem (i.e., the cause of the incident).  
The incident type might be an SLA violation.

[Qin Wu] I believe this is naming confusion issue, according to network 
incident definition, the incident type can be unexpected interruption of the 
network service, or degradation of the network service, in the current design, 
we use fault and potential risk, if this is not clear, we can use better term 
as you suggested. Thanks.
Also as you can see, Nigel and Adrian have started a new draft on incident 
management terminology based on action point taken in IETF 118 side meeting on 
incident management, which can also help produce better terminology for this 
work.

I do not feel this work should be adopted by the IETF in its current form.

[Qin Wu] I am thinking change the title into "A YANG Data Model for Network 
Incident management", which will focus on network level model, in the same 
level as L3NM, L2NM and Attachment Circuit.
Joe

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of Henk Birkholz 
mailto:henk.birkholz@ietf.contact>>
Date: Thursday, February 8, 2024 at 10:44
To: OPSAWG mailto:opsawg@ietf.org>>
Subject: [OPSAWG]  WG Adoption Call for 
draft-feng-opsawg-incident-management-04
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<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]  WG Adoption Call for draft-feng-opsawg-incident-management-04

[Qin Wu]

+1, support as coauthor.
发件人： LUIS MIGUEL CONTRERAS 
MURILLOmailto:luismiguel.contrerasmuri...@telefonica.com>>
收件人： Henk 
Birkholzmailto:henk.birkholz@ietf.contact>>;OPSAWGmailto:opsawg@ietf.org>>
主题： Re: [OPSAWG]  WG Adoption Call for draft-feng-opsawg-incident-management-04
时间： 2024-02-11 01:39:52

Dear Henk, all,

As co-author, I support the adoption of the draft.

Thanks, best regards

Luis

-Mensaje original-
De: OPSAWG  En nombre de Henk Birkholz
Enviado el: jueves, 8 de febrero de 2024 16:44
Para: OPSAWG 
Asunto: [OPSAWG]  WG Adoption Call for draft-feng-opsawg-incident-management-04

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



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

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

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

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

[Qin Wu]

Hi Chairs:
I am not aware of any IPR related to this work.



吴钦 Wu Qin
Mobile：+86-13914734360(Mobile Number)
Email：bill...@huawei.com

发件人： Henk 
Birkholzmailto:henk.birkholz@ietf.contact>>
收件人： 
OPSAWGmailto:opsawg@ietf.org>>;draft-feng-opsawg-incident-managementmailto:draft-feng-opsawg-incident-managem...@ietf.org>>
主题：  IPR Call for draft-feng-opsawg-incident-management-04
时间： 2024-02-09 00:01:19

Dear authors and contributors,

as a part of the adoption process, the chairs would also like to issue a
first IPR call on the content of adoption candidates (there will also be
a second IPR call after successful WGLC).

Please respond on-list as to whether or not you are aware of any IPR
that pertains to draft-feng-opsawg-incident-management-04.

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


For the OPAWG co-chairs,

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

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Qin Wu]

-邮件原件-
发件人: Evans, John [mailto:jevanamz=40amazon.co...@dmarc.ietf.org] 
发送时间: 2024年1月31日 20:25
收件人: Qin Wu ; Evans, John ; Henk 
Birkholz ; OPSAWG 
主题: Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

Hi Qin,

> [Qin Wu] Maybe a new section can be added to clarify the relation with 
> RFC8343.

We will explicitly call out the relationship to data models.

> the table in section 3 just provides model structure but doesn't specify 
> parameters details.

Yes - agreed - we will expand on that 

> [Qin Wu] Sorry not to make me clear, I just feel the 9 rules you set 
> in section 4.3 is more like you set requirements for packet discard 
> reporting, to me, the rules are more something related to auto mitigation 
> actions which is confusing.

Section 4.3 is the examples in 02:
https://datatracker.ietf.org/doc/html/draft-opsawg-evans-discardmodel-02#section-4.3

I'm assuming you mean the 11 rules in section 4.2?
https://datatracker.ietf.org/doc/html/draft-opsawg-evans-discardmodel-02#section-4.2

The rules here are intended to be with respect to packet loss reporting 
requirements rather than auto-mitigation actions.  Could you call out a 
specific example which is confusing?
[Qin Wu] No strong opinion here, just feel the term 'rule' and 'requirement' 
are interchangeable term, requirement seems more reasonable term to me.

Cheers

John


On 31/01/2024, 11:57, "OPSAWG on behalf of Qin Wu" mailto:opsawg-boun...@ietf.org> on behalf of 
bill.wu=40huawei@dmarc.ietf.org <mailto:40huawei@dmarc.ietf.org>> wrote:


Hi, John:


> I am wondering whether this draft should update [RFC8343] to address such 
> limitation.


Ultimately, I think we should update the corresponding data models to reflect 
whatever we agree in this draft, should we progress it. In this specific case, 
RFC8343 has reflected what is in RFC1213. Hence, our focus is first on 
standardising a framework for packet loss reporting. Once the information model 
is agreed, we can proceed to apply that to the corresponding data models, which 
we currently define as out of scope in section 1:
"There are multiple ways that this information model could be implemented 
(i.e., data models), including SNMP [RFC1157], NETCONF [RFC6241] / YANG 
[RFC7950], and IPFIX [RFC5153], but they are outside of the scope of this 
document."


I will update section 1 to reference RFC8343 in addition to RFC1213.


[Qin Wu] Maybe a new section can be added to clarify the relation with RFC8343. 
In addition, the table in section 3 just provides model structure but doesn't 
specify parameters details. Section 5 and section 6 of RFC3060 provide a good 
example on how these details can be specified.


> 6. Section 4.3 specific requirements rather than rules for packet loss 
> reporting


I'm not sure what you mean here - could you please clarify your feedback?


[Qin Wu] Sorry not to make me clear, I just feel the 9 rules you set in section 
4.3 is more like you set requirements for packet discard reporting, to me, the 
rules are more something related to auto mitigation actions which is confusing.
Also not sure you can enumerate all the rules in a single section?






On 31/01/2024, 08:06, "OPSAWG on behalf of Qin Wu" mailto:opsawg-boun...@ietf.org> <mailto:opsawg-boun...@ietf.org 
<mailto:opsawg-boun...@ietf.org>> on behalf of 
bill.wu=40huawei@dmarc.ietf.org <mailto:40huawei@dmarc.ietf.org> 
<mailto:40huawei@dmarc.ietf.org <mailto:40huawei@dmarc.ietf.org>>> 
wrote:




Hi,
I have read the latest version of this draft and have the following comments:
1. what is the difference between packet loss and packet discard, it seems this 
two terms are used interchangeably in the draft, in some places packet discard 
reporting is used, while in some other places, packet loss reporting, which I 
think lack consistency. Suggest to introduce two terms defintiion in the 
terminology section.
2. Section 1, 1st paragraph said:
"
Router-reported packet loss is the most direct signal for network operations to 
identify customer impact from unintended packet loss.
"
I feel packet loss is just one of signals for network operators to identify 
customer impact? How about network latency, jitter?
3.Section 1, 2nd paragraph said:
"
The existing metrics for packet loss as defined in [RFC1213] - namely 
ifInDiscards, ifOutDiscards, ifInErrors, ifOutErrors - do not provide 
sufficient precision to be able to automatically identify the cause of the loss 
and mitigate the impact. From a network operators' perspective, ifindiscards 
can represent both intended packet loss (i.e., packets discarded due to policy) 
and unintended packet loss (e.g., packets dropped in error).
"
It looks not only metrics for packet loss defined in [RFC1213] has its 
limitation, but also YANG model for interface management defined i

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Qin Wu]

Hi, John:

> I am wondering whether this draft should update [RFC8343] to address such 
> limitation.

Ultimately, I think we should update the corresponding data models to reflect 
whatever we agree in this draft, should we progress it.  In this specific case, 
RFC8343 has reflected what is in RFC1213. Hence, our focus is first on 
standardising a framework for packet loss reporting.  Once the information 
model is agreed, we can proceed to apply that to the corresponding data models, 
which we currently define as out of scope in section 1:
"There are multiple ways that this information model could be implemented 
(i.e., data models), including SNMP [RFC1157], NETCONF [RFC6241] / YANG 
[RFC7950], and IPFIX [RFC5153], but they are outside of the scope of this 
document."

I will update section 1 to reference RFC8343 in addition to RFC1213.

[Qin Wu] Maybe a new section can be added to clarify the relation with RFC8343. 
In addition, the table in section 3 just provides model structure but doesn't 
specify parameters details. Section 5 and section 6 of RFC3060 provide a good 
example on how these details can be specified.

> 6. Section 4.3 specific requirements rather than rules for packet loss 
> reporting

I'm not sure what you mean here - could you please clarify your feedback?

[Qin Wu] Sorry not to make me clear, I just feel the 9 rules you set in section 
4.3 is more like you set requirements for packet discard reporting, to me, the 
rules are more something related to auto mitigation actions which is confusing.
Also not sure you can enumerate all the rules in a single section?



On 31/01/2024, 08:06, "OPSAWG on behalf of Qin Wu" mailto:opsawg-boun...@ietf.org> on behalf of 
bill.wu=40huawei@dmarc.ietf.org <mailto:40huawei@dmarc.ietf.org>> wrote:


Hi,
I have read the latest version of this draft and have the following comments:
1. what is the difference between packet loss and packet discard, it seems this 
two terms are used interchangeably in the draft, in some places packet discard 
reporting is used, while in some other places, packet loss reporting, which I 
think lack consistency. Suggest to introduce two terms defintiion in the 
terminology section.
2. Section 1, 1st paragraph said:
"
Router-reported packet loss is the most direct signal for network operations to 
identify customer impact from unintended packet loss.
"
I feel packet loss is just one of signals for network operators to identify 
customer impact? How about network latency, jitter?
3.Section 1, 2nd paragraph said:
"
The existing metrics for packet loss as defined in [RFC1213] - namely 
ifInDiscards, ifOutDiscards, ifInErrors, ifOutErrors - do not provide 
sufficient precision to be able to automatically identify the cause of the loss 
and mitigate the impact. From a network operators' perspective, ifindiscards 
can represent both intended packet loss (i.e., packets discarded due to policy) 
and unintended packet loss (e.g., packets dropped in error).
"
It looks not only metrics for packet loss defined in [RFC1213] has its 
limitation, but also YANG model for interface management defined in [RFC8343], 
I am wondering whether this draft should update [RFC8343] to address such 
limitation.
4. If my understanding is correct, the solution described in Section 2 include 
three key elements, packet loss, cause, and auto-mitigation actions the cause 
can be seen as trigger or condition, which will trigger different 
auto-mitigation actions, these concept is similar to ECA concept in 
(https://datatracker.ietf.org/doc/draft-ietf-netmod-eca-policy/ 
<https://datatracker.ietf.org/doc/draft-ietf-netmod-eca-policy/>) which include 
Event, condition and action three elements, when the event meets specific 
condition, e.g., packet loss is greater than specific threshold value, the 
action will be triggered, the action can be sending an notification, or sending 
a snapshot of device statistics.
Different from ECA, in this draft, auto-mitigation actions and cause is not 
modelled in the packet loss model, I am wondering how packet loss reporting 
trigger auto-mitigation action? Do you need to populate specific policy in the 
device, this policy will be associated with specific monitoring object such as 
"discards/error/l2/rx/", is such policy corresponding to specific python code, 
which can be excuted based on the logic described in the policy?
5. Section 4 defines a information model, I am wondering whether this packet 
discard model should augment interface YANG model defined in [RFC8343]?
For the current shape, I feel it lack sufficient details on the definition for 
each attributes.


6. Section 4.3 specific requirements rather than rules for packet loss reporting


7 Section 5, can we model both packet loss statistics and auto-mitigation 
action in the same model, similar to what ECA model is doing in 
draft-ietf-netmod-eca-policy.


-Qin
-邮件原件-

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Qin Wu]

Hi,
I have read the latest version of this draft and have the following comments:
1. what is the difference between packet loss and packet discard, it seems this 
two terms are used interchangeably in the draft, in some places packet discard 
reporting is used, while in some other places, packet loss reporting, which I 
think lack consistency. Suggest to introduce two terms defintiion 
in the terminology section.
2. Section 1, 1st paragraph said:
"
Router-reported packet loss is the most direct signal for network operations to 
identify customer impact from unintended packet loss. 
"
I feel packet loss is just one of signals for network operators to identify 
customer impact? How about network latency, jitter?
3.Section 1, 2nd paragraph said:
"
The existing metrics for packet loss as defined in [RFC1213] - namely 
ifInDiscards, ifOutDiscards, ifInErrors, ifOutErrors - do not provide 
sufficient precision to be able to automatically identify the cause of the loss 
and mitigate the impact. From a network operators' perspective, ifindiscards 
can represent both intended packet loss (i.e., packets discarded due to policy) 
and unintended packet loss (e.g., packets dropped in error). 
"
It looks not only metrics for packet loss defined in [RFC1213] has its 
limitation, but also YANG model for interface management defined in [RFC8343],
I am wondering whether this draft should update [RFC8343] to address such 
limitation.
4. If my understanding is correct, the solution described in Section 2 include 
three key elements, packet loss, cause, and auto-mitigation actions
   the cause can be seen as trigger or condition, which will trigger different 
auto-mitigation actions, these concept is similar to ECA concept in 
(https://datatracker.ietf.org/doc/draft-ietf-netmod-eca-policy/) which include 
Event, condition and action three elements, when the event meets specific 
condition, e.g., packet loss is greater than specific threshold value,
   the action will be triggered, the action can be sending an notification, or 
sending a snapshot of device statistics.
   Different from ECA, in this draft, auto-mitigation actions and cause is not 
modelled in the packet loss model, I am wondering how packet loss reporting
   trigger auto-mitigation action? Do you need to populate specific policy in 
the device, this policy will be associated with specific monitoring object such 
as "discards/error/l2/rx/", is such policy corresponding to specific python 
code, which can be excuted based on the logic described in the policy?
5. Section 4 defines a information model, I am wondering whether this packet 
discard model should augment interface YANG model defined in [RFC8343]?
   For the current shape, I feel it lack sufficient details on the definition 
for each attributes.
   
6. Section 4.3 specific requirements rather than rules for packet loss reporting

7 Section 5, can we model both packet loss statistics and auto-mitigation 
action in the same model, similar to what ECA model is doing in 
draft-ietf-netmod-eca-policy.

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Henk Birkholz
发送时间: 2024年1月17日 20:52
收件人: OPSAWG 
主题: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

Dear OPSAWG members,

this email starts a call for Working Group Adoption of

> https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.htm
> l

ending on Wednesday, January 31st.

As a reminder, this I-D describes an information model in support of automated 
network mitigation on what and how to report about unintentional packet 
discards/losses that can have an impact on service level objectives. 
Implementation of the informational model, which could manifest, e.g., via 
NETCONF/YANG, SNMP or IPFIX, is out-of-scope.

The chairs acknowledge feedback to and interest for the topic during the
IETF118 meeting and on the list after afterwards. 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] Network Incident Management Side Meeting Summary

[Qin Wu]

v-04 is posted 
(https://datatracker.ietf.org/doc/draft-feng-opsawg-incident-management/), the 
main changes focuses on addressing comments raised in last IETF meeting and 
side meeting and include:

· Update incident definition based on TMF incident API profile 
specification.¶<https://datatracker.ietf.org/doc/html/draft-feng-opsawg-incident-management#appendix-A-3.1.1>

· Update use case on Multi-layer Fault Demarcation based on side 
meeting discussion and IETF 119 session 
discussion.¶<https://datatracker.ietf.org/doc/html/draft-feng-opsawg-incident-management#appendix-A-3.2.1>

· Update section 5.1 to explain how network incident is generated based 
on other 
factors.¶<https://datatracker.ietf.org/doc/html/draft-feng-opsawg-incident-management#appendix-A-3.3.1>

· Add one new use cases on Security Events noise reduction based on 
Situation 
Awareness.¶<https://datatracker.ietf.org/doc/html/draft-feng-opsawg-incident-management#appendix-A-3.4.1>

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Qin Wu
发送时间: 2023年11月10日 15:46
收件人: opsawg@ietf.org
抄送: draft-opsawg-evans-discardmo...@ietf.org; 
draft-netana-opsawg-nmrg-network-anomaly-semant...@ietf.org; 
draft-feng-opsawg-incident-managem...@ietf.org
主题: [OPSAWG] Network Incident Management Side Meeting Summary


Hi, All:

Thanks all folks who participated in network incident management discussion on 
Tuesday afternoon. The side meeting was spent one hour exploring network 
incident concepts and use cases; three related drafts were discussed. We 
received a lot of great contributions for the following drafts being discussed:



https://datatracker.ietf.org/doc/draft-feng-opsawg-incident-management/ 
(Service Level Incident)

https://datatracker.ietf.org/doc/draft-opsawg-evans-discardmodel/ (Anomaly 
Detection, Correlation and Mitigation for Packet Discard)

https://datatracker.ietf.org/doc/draft-netana-opsawg-nmrg-network-anomaly-semantics/
 (Network anomaly semantics)



It was identified that multi-layer Fault Demarcation is related to POI, however 
the network incident model can be defined as generic model used for many other 
use cases.



A few issues were raised in the meeting:



1. Network Incident definitions needs more clarity even though it origins from 
TMF specification, e.g., how it is related to symptom, anomaly, etc.

2. Besides SLO violation, how network incident is generated based on other 
factors, more usage examples are needed for these.

3. Incident terminology is well-defined and should be consistent across the 
drafts and, where possible, synced with other SDO meanings (although the 
language may vary)



Follow up actions include:



1. Nigel and Adrian volunteered to help define key terminology uses and define 
terms;

2. Dan to check with MEF and TMF documentation to check for SLO handling, 
including incident and problem coordination and definitions;

3. Open the network incident draft GitHub to the public and use it for draft 
development and tracking issues.



-Qin (on behalf of Team)

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

[OPSAWG] Opsdir early review of draft-ietf-opsawg-ipfix-fixes-03

[Qin Wu via Datatracker]

Reviewer: Qin Wu
Review result: Has Nits

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF
 documents being processed by the IESG.  These comments were written with the
 intent of improving the operational aspects of the IETF drafts. Comments that
 are not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these
 comments just like any other last call comments.

This document Updates IPFIX IANA Registry to fix several issues including
consistency issues. This update help IANA to better structure the content in
more consistent way and also help automate extraction of values from IANA
registry.

This document is well written and I believe it is ready for publication.
However I have a few comments on the latest version v-03:

Major issues:
None

Minor issues
1. Abstract:
I believe IANA IPFIX registry is associated with all IPFIX  related RFCs, I am
wondering whether update to
 IANA IPFIX registry indicate update to all these IPFIX related RFC as well
 such as RFC7125,RFC7012 and etc?

2. Section 4.1.1 said:
“
  [I-D.ietf-opsawg-ipfix-tcpo-v6eh] specifies a new Information Element
   to fix the last issue.
”
It is not clear where or which section the procedure is specified from the
first glance. If my understanding is correct, the solution to address the last
issue is to define new IEs to address all the ipv6ExtensionHeaders IE
limitations rather than simply specifying the procedure.

To better clarify the relation between this document and
[I-D.ietf-opsawg-ipfix-tcpo-v6eh] and understand where the procedure is
specified, I propose the following change: s/ [I-D.ietf-opsawg-ipfix-tcpo-v6eh]
specifies a new Information Element/ Section 3 of
[I-D.ietf-opsawg-ipfix-tcpo-v6eh] specifies a new Information Element

3. Section 4.1.1 said:
“
Note that some implementations may not be able to export all observed
 extension headers in a Flow because of a hardware of software limit
 (see, e.g., [I-D.ietf-6man-eh-limits].
”
What is the reason for some implementation may not be able to export all
observed extension headers in a Flow? Software limit, hardware limit or
hardware/software limit, here the proposed change: s/a hardware of software
limit/a hardware or software limit

4.
Section 4.2.2 said:
"
4.2.2.  Update the Description of the tcpOptions IE

   This document requests IANA to update the description of the
   tcpOptions IE in the IANA IPFIX registry [IANA-IPFIX] as follows:

"
Section 3 said:
"
The current forwardingStatus entry in [IANA-IPFIX] deviates from what
   is provided in [RFC7270].

"
Section 4 said:
"
This document requests IANA to update the description of the
   following entries in [IANA-IPFIX].

"
You can see some places use "the IANA IPFIX registry [IANA-IPFIX]",
some places use "IANA-IPFIX", it is not consistent.



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

Re: [OPSAWG] Network Incident Management Side Meeting Summary

[Qin Wu]

Thanks Adrian for the update, look forward to reviewing the version and happy 
to set up a meeting when it is ready.

-Qin
发件人: Adrian Farrel [mailto:adr...@olddog.co.uk]
发送时间: 2023年12月13日 0:54
收件人: Qin Wu ; opsawg@ietf.org
抄送: draft-opsawg-evans-discardmo...@ietf.org; 
draft-netana-opsawg-nmrg-network-anomaly-semant...@ietf.org; 
draft-feng-opsawg-incident-managem...@ietf.org; ne...@ietf.org
主题: RE: [OPSAWG] Network Incident Management Side Meeting Summary

[Adding the NMOP list �C which is currently called NETMO]

It’s a month later.

Nigel and I have been working on the first version of key terminology. We’ve 
actually made some progress (perhaps slower than our initial enthusiasm might 
have suggested).

We’re just putting the last polish on our first version that we intent to share 
“soon.”

Cheers,
Adrian

From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of Qin Wu
Sent: 10 November 2023 07:46
To: opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc: 
draft-opsawg-evans-discardmo...@ietf.org<mailto:draft-opsawg-evans-discardmo...@ietf.org>;
 
draft-netana-opsawg-nmrg-network-anomaly-semant...@ietf.org<mailto:draft-netana-opsawg-nmrg-network-anomaly-semant...@ietf.org>;
 
draft-feng-opsawg-incident-managem...@ietf.org<mailto:draft-feng-opsawg-incident-managem...@ietf.org>
Subject: [OPSAWG] Network Incident Management Side Meeting Summary


Hi, All:

Thanks all folks who participated in network incident management discussion on 
Tuesday afternoon. The side meeting was spent one hour exploring network 
incident concepts and use cases; three related drafts were discussed. We 
received a lot of great contributions for the following drafts being discussed:



https://datatracker.ietf.org/doc/draft-feng-opsawg-incident-management/ 
(Service Level Incident)

https://datatracker.ietf.org/doc/draft-opsawg-evans-discardmodel/ (Anomaly 
Detection, Correlation and Mitigation for Packet Discard)

https://datatracker.ietf.org/doc/draft-netana-opsawg-nmrg-network-anomaly-semantics/
 (Network anomaly semantics)



It was identified that multi-layer Fault Demarcation is related to POI, however 
the network incident model can be defined as generic model used for many other 
use cases.



A few issues were raised in the meeting:



1. Network Incident definitions needs more clarity even though it origins from 
TMF specification, e.g., how it is related to symptom, anomaly, etc.

2. Besides SLO violation, how network incident is generated based on other 
factors, more usage examples are needed for these.

3. Incident terminology is well-defined and should be consistent across the 
drafts and, where possible, synced with other SDO meanings (although the 
language may vary)



Follow up actions include:



1. Nigel and Adrian volunteered to help define key terminology uses and define 
terms;

2. Dan to check with MEF and TMF documentation to check for SLO handling, 
including incident and problem coordination and definitions;

3. Open the network incident draft GitHub to the public and use it for draft 
development and tracking issues.



-Qin (on behalf of Team)

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

Re: [OPSAWG] Time Schedule Side Meeting Update

[Qin Wu]

Good catch, thank Luis for additional points, we keep track these open issues 
in the github.

-Qin
发件人: LUIS MIGUEL CONTRERAS MURILLO 
[mailto:luismiguel.contrerasmuri...@telefonica.com]
发送时间: 2023年11月10日 11:47
收件人: Qin Wu ; opsawg@ietf.org
抄送: Yingzhen Qu 
主题: RE: Time Schedule Side Meeting Update

Hi Qin, all,

Thanks for the summary.

As also commented, this is as well an opportunity to check if the parameters 
considered in the model are sufficient. For instance, I miss some time zone 
parameter which can be relevant for networks spanning more than one time zone 
(e.g., international carriers’ networks) where the scheduling could require 
some time zone awareness. Let’s discuss these things during the draft alignment 
process.

Thanks again

Best regards

Luis

De: OPSAWG mailto:opsawg-boun...@ietf.org>> En nombre 
de Qin Wu
Enviado el: viernes, 10 de noviembre de 2023 10:02
Para: opsawg@ietf.org<mailto:opsawg@ietf.org>
CC: Yingzhen Qu mailto:yingzhen...@futurewei.com>>
Asunto: [OPSAWG] Time Schedule Side Meeting Update


Hi,

Thanks to all folks who participated in the time schedule discussion on 
Thursday afternoon and provided good inputs; the side meeting spent one-hour 
discussing common model design for various use cases described in:



https://datatracker.ietf.org/doc/draft-ma-opsawg-schedule-yang/ (ACL policy 
activation based on date and time conditions)



https://datatracker.ietf.org/doc/draft-united-tvr-schedule-yang/ (manage 
network resources with time scheduled changes)



https://datatracker.ietf.org/doc/draft-contreras-opsawg-scheduling-oam-tests/ 
(schedule on-demand OAM tests)



We focused on the uses cases and network resource management with 
time-scheduled changes for the TVR scenarios. We do not see any issue with the 
scheduled OAM use cases and can create examples for human-readable and 
machine-readable scenarios.



The authors of draft-united-tvr-schedule-yang and 
draft-contreras-opsawg-scheduling-oam-tests agreed to use common building 
blocks such as grouping defined in draft-ma-opsawg-schedule-yang, once we show 
some examples that meet their requirements. The usage examples for other use 
cases will be provided in draft-ma-opsawg-schedule-yang in an appendix. The 
authors of draft-united-tvr-schedule-yang and 
draft-contreras-opsawg-scheduling-oam-tests will review and align with changes 
made in draft-ma-opsawg-schedule-yang to address their needs.



Thanks again to everyone involved in the discussion; it was a very productive 
meeting and will ensure the reusability of models across different working 
groups."

-Qin (on behalf of the team)



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

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

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


Le informamos de que el responsable del tratamiento de sus datos es la entidad 
del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el 
contacto profesional y gestionar la relación establecida con el destinatario o 
con la entidad a la que está vinculado. Puede contactar con el responsable del 
tratamiento y ejercitar sus derechos escribiendo a 
privacidad@telefonica.com<mailto:privacidad@telefonica.com>. Puede 
consultar información adicional sobre el tratamiento de sus datos en nuestra 
Política de 
Privacidad<https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>.

We inform you that the data controller is the Telefónica Group entity linked to 
the sen

[OPSAWG] Time Schedule Side Meeting Update

[Qin Wu]

Hi,

Thanks to all folks who participated in the time schedule discussion on 
Thursday afternoon and provided good inputs; the side meeting spent one-hour 
discussing common model design for various use cases described in:



https://datatracker.ietf.org/doc/draft-ma-opsawg-schedule-yang/ (ACL policy 
activation based on date and time conditions)



https://datatracker.ietf.org/doc/draft-united-tvr-schedule-yang/ (manage 
network resources with time scheduled changes)



https://datatracker.ietf.org/doc/draft-contreras-opsawg-scheduling-oam-tests/ 
(schedule on-demand OAM tests)



We focused on the uses cases and network resource management with 
time-scheduled changes for the TVR scenarios. We do not see any issue with the 
scheduled OAM use cases and can create examples for human-readable and 
machine-readable scenarios.



The authors of draft-united-tvr-schedule-yang and 
draft-contreras-opsawg-scheduling-oam-tests agreed to use common building 
blocks such as grouping defined in draft-ma-opsawg-schedule-yang, once we show 
some examples that meet their requirements. The usage examples for other use 
cases will be provided in draft-ma-opsawg-schedule-yang in an appendix. The 
authors of draft-united-tvr-schedule-yang and 
draft-contreras-opsawg-scheduling-oam-tests will review and align with changes 
made in draft-ma-opsawg-schedule-yang to address their needs.



Thanks again to everyone involved in the discussion; it was a very productive 
meeting and will ensure the reusability of models across different working 
groups."

-Qin (on behalf of the team)
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Network Incident Management Side Meeting Summary

[Qin Wu]

Hi, All:

Thanks all folks who participated in network incident management discussion on 
Tuesday afternoon. The side meeting was spent one hour exploring network 
incident concepts and use cases; three related drafts were discussed. We 
received a lot of great contributions for the following drafts being discussed:



https://datatracker.ietf.org/doc/draft-feng-opsawg-incident-management/ 
(Service Level Incident)

https://datatracker.ietf.org/doc/draft-opsawg-evans-discardmodel/ (Anomaly 
Detection, Correlation and Mitigation for Packet Discard)

https://datatracker.ietf.org/doc/draft-netana-opsawg-nmrg-network-anomaly-semantics/
 (Network anomaly semantics)



It was identified that multi-layer Fault Demarcation is related to POI, however 
the network incident model can be defined as generic model used for many other 
use cases.



A few issues were raised in the meeting:



1. Network Incident definitions needs more clarity even though it origins from 
TMF specification, e.g., how it is related to symptom, anomaly, etc.

2. Besides SLO violation, how network incident is generated based on other 
factors, more usage examples are needed for these.

3. Incident terminology is well-defined and should be consistent across the 
drafts and, where possible, synced with other SDO meanings (although the 
language may vary)



Follow up actions include:



1. Nigel and Adrian volunteered to help define key terminology uses and define 
terms;

2. Dan to check with MEF and TMF documentation to check for SLO handling, 
including incident and problem coordination and definitions;

3. Open the network incident draft GitHub to the public and use it for draft 
development and tracking issues.



-Qin (on behalf of Team)

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

[OPSAWG] 转发: Network Incident Management Side meeting

[Qin Wu]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Central Europe Standard Time
BEGIN:STANDARD
DTSTART:16010101T03
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Qin Wu:MAILTO:bill...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=opsawg@iet
 f.org:MAILTO:opsawg@ietf.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Joe Clarke
  (jclarke):MAILTO:jcla...@cisco.com
DESCRIPTION;LANGUAGE=zh-CN:FYI.\n-原始约会-\n发件人: Qin Wu\
 n发送时间: 2023年11月5日 20:34\n收件人: Qin Wu\; adrian@olddog.c
 o.uk\; dan...@olddog.co.uk\; luismiguel.contrerasmuri...@telefonica.com\; 
 Thomas.Graf\; victor.lo...@nokia.com\; yuchaode\; Aihua Guo\; mohamed.bouc
 ad...@orange.com\; Rob Wilton (rwilton)\; opsawg-cha...@ietf.org\n抄送: 
 maqiufang (A)\; Wubo (lana)\n主题: Network Incident Management Side meet
 ing\n时间: 2023年11月7日星期二 16:30-17:30(UTC+01:00) 贝尔格莱
 德，布拉迪斯拉发，布达佩斯，卢布尔雅那，布拉格。\n
 地点:\n\n•Meeting Location and Time: Tuesday\, 16:30 – 17:30
  am\, Karlin 4\n•Motivation:\n>  The frequency and quantity 
 of alarms\, KPI\, trace information overwhelmed the management system\n-  
   The traditional solutions\, e.g.\, data compression are time-consumi
 ng and labor-intensive\n>  Alarms\, KPI\, trace information are manage
 d by different management system at different layer\, difficult to assess\
 n-the impact of alarms\, performance metrics and other anomaly dat
 a on network services without known\n-relation across layer of the
  network topology data\n-or the relation with other network topolo
 gy data.\n•Goal: Provide consistent management of different type
  of data sources and Use AI for Service impact analysis to improve inciden
 t diagnosis efficiency and low O requirements\n•Meeting Agenda
 :\n•1. Network Incident Introduction\n•2. Use Case Dis
 cussion\n•Relevant documents:\n>  draft-feng-opsawg-incident
 -management-00\n>  TMF 724 Incident Management API profile\n>  Ala
 rm Management  RFC8632\n>  Service Assurance Management RFC9417/RFC941
 8\n>  NETCONF/RESTCONF Extension to support Trace Context propagation\
 n>  Incident ONAP open source project\n•Use Cases:\n>  M
 ulti-layer Fault Demarcation  > Multi-layer Service Monitoring\n\n• 
Remote participation is via https://ietf.webex.com/meet/sidemeetingietf
 1\n\n
UID:04008200E00074C5B7101A82E0083005B1F32510DA01000
 010009E22AF85716ACF4F9789070B8AAD7F3C
SUMMARY;LANGUAGE=zh-CN:转发: Network Incident Management Side meeting
DTSTART;TZID=Central Europe Standard Time:20231107T163000
DTEND;TZID=Central Europe Standard Time:20231107T173000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20231105T193336Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=zh-CN:
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:975550439
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR
___
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

[Qin Wu]

Thank for clarification, Michael. I believe my confusion comes from the 
following paragraph:
"
   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.
"
I think keeping state to cache results is necessary for establishing subsequent 
connection the same site.
I am wondering how long the results can be cached, which factor will affect 
cache lifetime? Session state duration, TCP timeout, UDP time out?
Or DNS timeout/ TTL of DNS results.
In the below discussion, You seems to indicate session state duration is not 
affected by DNS timeout. But from what I read the above paragraph,
It seems that the cache lifetime is decided by TTL of DNS results, have nothing 
to do with session state duration, correct?
Cached results will be torn down after TTL of DNS results or Cached results 
will be updated with new IP address,
Therefore it needs another DNS lookup. 
Let me know if my understanding is correct.

-Qin
-邮件原件-
发件人: Michael Richardson [mailto:mcr+i...@sandelman.ca] 
发送时间: 2023年11月1日 22:56
收件人: Qin Wu 
抄送: Eliot Lear ; Rob Wilton (rwilton) 
; opsawg@ietf.org; 
draft-ietf-opsawg-mud-iot-dns-considerati...@ietf.org
主题: Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08


Qin Wu  wrote:
> Hi Michale: If my interpretation is correct, the mapping between IP
> address and Name is only valid for specific session or connection, when

I don't understand your comment.
The policy might say, "permit TCP port 1245 to example.com"
In order to enact this policy, the enforcement point needs a mapping from 
example.com to (e.g.,) 192.0.0.1 [%].  There are a number of ways of 
implementing the enforcement point, not all have to maintain state for the 
entire connection.  But even among those that do, the state is attached to the 
IP address, not the name.

So I don't understand how the mapping is only valid for a specific session.







[%] actually, example.com has an actual IPv4/IPv6 address which answers on
port 80 and 443 :-).  And it's not a documentation IP.

> the session or connection is torn down, The mapping is no longer valid
> even though you cached the them, especially, TTL exceeds the
> preconfigured period of time.  I am wondering whether session
> expiration time is also cached together with the mapping as the state?

MUD does not say anything about how long the session could last.
For policy enforcement points that keep state on every session, whether or not 
that state is allowed to exceed the TTL on the name is an interesting
implementation question.   I would think carefully about whether I wanted my
enforcement point to keep so much state, and I don't think I'd kill sessions 
because the DNS name timed out.  Maybe, I'd have an upper limit on session 
state duration, but does violate the end to end principal.  Still, it happens 
all the time with NAT44.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*
___
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

[Qin Wu]

Hi Michale:
If my interpretation is correct, the mapping between IP address and Name is 
only valid for specific session or connection, when the session or connection 
is torn down, 
The mapping is no longer valid even though you cached the them, especially, TTL 
exceeds the preconfigured period of time.
I am wondering whether session expiration time is also cached together with the 
mapping as the state?

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Michael Richardson
发送时间: 2023年10月26日 6:14
收件人: Eliot Lear 
抄送: Rob Wilton (rwilton) ; opsawg@ietf.org; 
draft-ietf-opsawg-mud-iot-dns-considerati...@ietf.org
主题: Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08


Eliot Lear  wrote:
> On 23.10.2023 17:27, Michael Richardson wrote:
>> Maybe someone else can explain it back to me in a better way.

> The fundamental issue is this:

>  * If you are permitting an IP address in an ACL based on a name in a
> MUD file, the mapping to that address is valid for the greater of the
> TTL on the name or the state of a connection, assuming you have that
> state.  If the state isn't there and endpoints inappropriately cache
> the name beyond TTL, That Would Be Bad.

The section involved is about why you can't go from IP address to name.
Assuming that you could make it work once, the point of the section is that you 
have to keep doing it every TTL period.  It's not the TTL on the name, but the 
TTL on the PTR record...

I'm just going to truncate like this (section "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.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*



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

[OPSAWG] Review of draft-wang-opsawg-service-information-yang on Computing Information Exposure

[Qin Wu]

Hi, Xuewei:
I have read your -v 00 of draft-wang-opsawg-service-information-yang and feel 
it is an interesting work, since it can be used to exposure computing 
information.
A few quick comments on this draft:

1.   For computing information exposure, there are two other relevant drafts
https://datatracker.ietf.org/doc/draft-contreras-alto-service-edge/
https://datatracker.ietf.org/doc/draft-sun-alto-arch-computing-optical-network/
https://datatracker.ietf.org/doc/draft-rcr-opsawg-operational-compute-metrics/
https://datatracker.ietf.org/doc/html/draft-dunbar-cats-edge-service-metrics-01
It will be great to see how these drafts are related to each other regarding 
computing metrics definition, is there any common computing metrics 
definitions, is there any technology
Specific metrics.


2.   In your draft, YANG data model for computing information is proposed 
and used between CATS-Control Center and CATS-Router. In 
draft-contreras-alto-service-edge, computing information can be collected from 
Infrastructure and sent to ALTO server,
At the same time, you believe computing aware method described in your draft is 
not limited to
CATS Architecture.
I am wondering which architecture or framework are these metrics applied? Is 
there common framework for metrics definition, collection, aggregation and 
exposure.


3.   I assume you collect computing metrics from in network computing 
device, I am wondering which tools are you using to collect these computing 
metrics? Which tools are used to measure these computing metrics?
Do you use K8S to manage these in network computing device?

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

[OPSAWG] YANG based Collection and Aggregation Framework//: New Version Notification for draft-opsawg-poweff-00.txt

[Qin Wu]

Hi, Jan, Marisol:
I have read the latest version of 
draft-lindblad-tlm-philatelist
 and feel it is very interesting draft since it can aggregate data from various 
different data sources using different telemetry technologies.
First I see many metadata related work in this space , some of them are 
ongoing, some of them have already expired, e.g.,

1.   out of band metadata collection  
https://datatracker.ietf.org/doc/draft-ietf-opsawg-collected-data-manifest/

2.   in band metadata collection 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09

3.   Semantic Metadata Annotation  
https://datatracker.ietf.org/doc/draft-netana-opsawg-nmrg-network-anomaly-semantics/

4.   cloud-native metrics and time series format  
https://datatracker.ietf.org/doc/html/draft-richih-opsawg-openmetrics-00

5.   self-describing format for metadata abstract  
https://www.ietf.org/archive/id/draft-gray-sampled-streaming-03.txt

Secondly. I think the metadata can be used to collect telemetry context 
information, telemetry data classification information,
In your draft, the metadata collected by YANG based collection and aggregation 
framework seems more related to measurement related attributes,
Such as measurement unit, mathematic operation such as sum, average, max, 
min,etc, I remember XPATH 1.0 do support some of mathematic computation 
operation, such as max, min and logical operation such as AND and OR,
This has been discussed in 
https://www.ietf.org/archive/id/draft-ietf-netmod-eca-policy-01.
I can imagine the network device has already support some of mathematic 
computation operation, therefore can report summary statistics data using 
telemetry interface.

3.Regarding measurement quantities, I think open metrics also can be used to 
aggregate metrics related data, express all system states as numerical values;
counts, current values, enumerations, and Boolean states, I am wondering how 
these two work are different, whether 
draft-lindblad-tlm-philatelist
 can better align with
open metrics regarding metric aggregation.
4. Section 3.3 said:
“

Each flow is associated with one or more inputs, one output and a

   series of processing operations.  Each input flow and output flow may

   have an pre-processing or post-processing operation applied to it

   separately.  Then all the input flows are combined using one or more

   aggregation operations.

”
It is very interesting to keep track of flow from the data source to 
destination group and traverse a set of aggregation points,
It seems to provide a good visibility to the flow path within the analytics 
platform, I am wondering what is the benefit or goal to keep track of these 
flow path?
Is this implementation specific?

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Marisol Palmero Amador 
(mpalmero)
发送时间: 2023年10月28日 1:07
收件人: opsawg@ietf.org
抄送: Gonzalo Salgueiro (gsalguei) ; Jan Lindblad (jlindbla) 
; Snezana Mitrovic (snmitrov) ; 
emile.step...@orange.com; Per Andersson (perander) ; Esther 
Roure Vila (erourevi) ; emile.step...@orange.com
主题: [OPSAWG] FW: New Version Notification for draft-opsawg-poweff-00.txt

Dear OPSA WG,

Earlier this week, we posted a new draft that introduces a data model for power 
and energy related metrics :
https://datatracker.ietf.org/doc/draft-opsawg-poweff/
The focus is mainly on runtime information provided by power sensors, but also 
an extension to other related metrics and given attributes that will complement 
the representation of the energy consumed by the network device, implemented in 
hardware or software, as well as by specific network components.
This is a first-version approach where we see still challenges based on 
implementation.
Note: Some of those challenges are covered on Jan`s draft: 
draft-lindblad-tlm-philatelist

Along with POWEFF draft, we’ve also updated the version of the Sustainability 
Insights draft:
https://datatracker.ietf.org/doc/draft-almprs-sustainability-insights/
where we introduced an updated architecture reference diagram, that provides a 
more structured view of the functional blocks that might be part of where those 
attributes and metrics might be produced, processed, visualized, etc. We also 
have reviewed and added Use Cases that such framework could drive.

We greatly appreciate your thoughts and comments.

Many thanks,
Marisol Palmero


From: internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>
Date: Friday, 20 October 2023 at 17:45
To: Gonzalo Salgueiro (gsalguei) 
mailto:gsalg...@cisco.com>>, Jan Lindblad (jlindbla) 
mailto:jlind...@cisco.com>>, Marisol Palmero Amador 
(mpalmero) mailto:mpalm...@cisco.com>>, Snezana Mitrovic 
(snmitrov) mailto:snmit...@cisco.com>>
Subject: New Version 

Re: [OPSAWG] I-D Action: draft-feng-opsawg-incident-management-03.txt

[Qin Wu]

v- 03 is posted, the main changes include:
*  Motivation and goal clarification in the introduction section.
*  Revise sample use case section and Add one new use cases on Incident 
Generation.
*  Add some text to the model design overview.
*  Add reference to Precision Availability Metric defined in IPPM PAM
   WG document.

-Qin (on behalf of authors)
-邮件原件-
发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2023年10月23日 17:49
收件人: i-d-annou...@ietf.org
主题: I-D Action: draft-feng-opsawg-incident-management-03.txt

Internet-Draft draft-feng-opsawg-incident-management-03.txt is now available.

   Title:   Incident Management for Network Services
   Authors: Chong Feng
Tong Hu
Luis Miguel Contreras Murillo
Thomas Graf
Qin Wu
Chaode Yu
Nigel Davis
   Name:draft-feng-opsawg-incident-management-03.txt
   Pages:   39
   Dates:   2023-10-23

Abstract:

   A network incident refers to an unexpected interruption of a network
   service, degradation of a network service quality, or sub-health of a
   network service.  Different data sources including alarms, metrics
   and other anomaly information can be aggregated into few amount of
   network incidents by data correlation analysis and the service impact
   analysis.

   This document defines YANG modules for the network incident lifecycle
   management.  The YANG modules are meant to provide a standard way to
   report, diagnose, and resolve network incidents for the sake of
   network service health and root cause analysis.

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

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-feng-opsawg-incident-management-03

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-feng-opsawg-incident-management-03

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


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce

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

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

[Qin Wu]

Support, AC series breaks down connectivity service into a set of common 
building block, can be reused in other YANG model work, also establish the 
correlation with the network topology and SAP model.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2023年10月2日 21:22
收件人: opsawg@ietf.org
主题: [OPSAWG] CALL FOR ADOPTION: Attachment circuits work

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

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

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

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

The CfA will end on October 23.

Thanks.

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

Re: [OPSAWG] IPR POLL: Attachment circuits work

[Qin Wu]

Hi,
I am not aware of any IPR that applies to any of these drafts.

-Qin
发件人: Joe Clarke (jclarke) [mailto:jcla...@cisco.com]
发送时间: 2023年9月25日 23:29
收件人: opsawg@ietf.org; mohamed.boucadair ; Richard 
Roberts ; Oscar González de Dios 
; samir.barg...@gmail.com; Wubo (lana) 
; victor.lo...@nokia.com; ivan.by...@rbbn.com; Qin Wu 
; ke-oog...@kddi.com; luis-angel.mu...@vodafone.com
主题: IPR POLL: Attachment circuits work


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

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

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

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

Joe

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

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

[Qin Wu]

+1,
draft-ietf-Ccamp only focuses on hardware inventory while draft-wzwb is more 
aligned with IVY charter goal and scope and show its completeness.
Maybe from each of two drafts, we can pick one leading operator and one leading 
vendor to work together and document the merged version.
Hope this can be seen another option for the way forward.

-Qin
发件人: Inventory-yang [mailto:inventory-yang-boun...@ietf.org] 代表 
mohamed.boucad...@orange.com
发送时间: 2023年9月4日 23:52
收件人: maqiufang (A) ; 
inventory-y...@ietf.org
抄送: ivy-cha...@ietf.org; opsawg ; cc...@ietf.org
主题: Re: [Inventory-yang] [inventory-yang] poll for network inventory base model

Hi all,

I do think that both documents include parts that are very relevant to the IVY 
work.

I’m in favor of (3) with the chairs holding the pen at least for -00. It is 
unlikely that parts of (1) and (2) will be injected into (3).

Cheers,
Med

De : Inventory-yang 
mailto:inventory-yang-boun...@ietf.org>> De la 
part de maqiufang (A)
Envoyé : lundi 28 août 2023 08:22
À : inventory-y...@ietf.org
Cc : ivy-cha...@ietf.org; opsawg 
mailto:opsawg@ietf.org>>; cc...@ietf.org
Objet : [Inventory-yang] [inventory-yang] poll for network inventory base model

Hi Working Group,

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

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

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


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

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

Thank you,

Qiufang and Daniele




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] IPR poll for draft-ma-opsawg-ucl-acl-03

[Qin Wu]

I am not aware of any IPR related to this draft.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2023年9月1日 15:51
收件人: opsawg@ietf.org
抄送: opsawg-cha...@ietf.org
主题: [OPSAWG] IPR poll for draft-ma-opsawg-ucl-acl-03

Hi WG,

According to the decision from IETF117, we are going to run the working group 
adoption call for draft-ma-opsawg-ucl-acl-03.
https://datatracker.ietf.org/doc/draft-ma-opsawg-ucl-acl/

Ahead the adoption call, we’d like to poll for known IPR.

Authors and contributors please respond to the mailing list whether or not you 
are aware of any IPR that pertains to this work.

Please state either:

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

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

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

Re: [OPSAWG] WG Adoption call for IPFIX

[Qin Wu]

Support, a few comments below:
draft-boucla-opsawg-ipfix-fixes-06
This draft is well written, a few comments below:
1.Section 4.1.2
It is confusing to add section Number to old text and new text.
Suggest remove section numbers associated with OLD and NEW, i.e., section 
4.1.2.1 and section 4.1.2.2
2. Section 4.2.2
Similar to section 4.1.2, it is It is confusing to add section Number to old 
description and new description.
Suggest remove section numbers associated with OLD Description and NEW 
Description.
3. Is this process issue? It looks the main goal of this draft is to request 
IANA to update IPFIX registry,
do we really require a new draft to this? or send a request action proposal 
directly to IANA?
Get approved in the IESG telechat?
4. It looks this draft lists all the open issues that have already known, what 
about other new issues that will
come up with in the future, do we intend to make this draft always open to 
future bug fixes?

draft-boucadair-opsawg-ipfix-tcpo-v6eh
Why this draft is not consolidated into draft-boucla-opsawg-ipfix-fixes-06?

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2023年6月6日 8:19
收件人: opsawg 
抄送: opsawg-chairs 
主题: [OPSAWG] WG Adoption call for IPFIX

Hi WG,

As we agreed on IETF 116, this mail starts a two weeks working group adoption 
call for the following three related drafts:

Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry
https://datatracker.ietf.org/doc/draft-boucla-opsawg-ipfix-fixes/

Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements
https://datatracker.ietf.org/doc/draft-boucadair-opsawg-ipfix-tcpo-v6eh/

Export of UDP Options Information in IP Flow Information Export (IPFIX)
https://datatracker.ietf.org/doc/draft-boucadair-opsawg-tsvwg-udp-ipfix/

Please send your support or objection to the list.
Any comments are welcome.

This call will be end on June 20.

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

[OPSAWG] Review of draft-ietf-opsawg-mud-acceptable-urls-05

[Qin Wu]

Hi, authors of draft-ietf-opsawg-mud-acceptable-urls-05:
Sorry for late comments. I have read the latest version of 
draft-ietf-opsawg-mud-acceptable-urls-05 and have a few questions:
1. should Updating of the MUD files lead to updating of MUD URL? why adding 
capabilities involves
   new connection, which can be either incoming connection or outgoing 
connection?
  I am not sure I understand what the connection is? Can you provide me an 
example of such connection?
   Should this connection be telnet connection initiated by the controller?
2. as described in section 2.1, last paragraph, upgrade process involves 
downtime,
which might introduce risk due to needed   needed evaluations not having 
been completed,
   I am wondering what is the solution to address this risk? should this risk 
be documented in security section?
3. I can understand adding capability or removing capabilities will lead to MUD 
file updating?
   It is not clear to me why changes to TLS protocol will not lead to MUD file 
updating?
   are you saying this is beyond scope of this document?
4. Refer to section 2.4 for motivation for updating MUD URLs, I am wondering 
whether updating MUD URL
   is mandatory requirement?
5. It is not clear to me how file structure changing is different from hosting 
URLs changing?
   It seems that both are related to MUD URL updating? No?

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

Re: [OPSAWG] [netmod] How many "digital twins" every single network should have? Who would map between "twins"?

[Qin Wu]

Hi, Tom:
Model driven technology has laid foundation for operators and service provides 
to build their Digital twin platform, one more concrete reference can be 
RFC8969, which not only looks into top down service fulfillment, but also
Bottom up service assurance or performance monitoring, in my understanding 
digital twin is more related to telemetry, service assurance, network 
visibility, the reason I quote IRTF work is to provide an example on what 
digital twin will look like.

In IETF, we already see a lot of digital twin like model that has been 
standardized, e.g., RFC8345, RFC8346, RFC8795, etc, hope this clarifies.

-Qin
-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com] 
发送时间: 2022年12月15日 20:30
收件人: Qin Wu ; Vasilenko Eduard 
; Jan Lindblad 
抄送: opsawg@ietf.org; net...@ietf.org; Paolo Volpato ; 
Xipengxiao 
主题: Re: [netmod] How many "digital twins" every single network should have? Who 
would map between "twins"?

From: netmod  on behalf of Qin Wu 

Sent: 15 December 2022 08:07

Hi, Eduard:
Thank for bring this issue up, I think digital twins is more related to network 
topology model, network monitoring model rather than LxSM service delivery 
model or LxNM network model


I was going to ask for an explanation of a digital twin and then saw that it is 
a research topic of the IRSG about which consensus has not been achieved.  As 
such, I think it wrong for us to try and introduce it to YANG at this point in 
time

Tom Petch


First, As described in RFC8969 or RFC8309, LxSM service delivery model or LxNM 
network model focuses on service level abstraction and resource level 
abstraction respectively,  we expect Service level abstraction Can be 
decomposed into network/resource level abstraction, and resource level 
abstraction to be translated into a bunches of device level models, but we 
don’t expect translation across level can be standardized in the same way.
Service mapping process, configuration translation process should play the key 
roles, this provide flexibility and meet requirements of various difference use 
cases.
Another reason is not to choose use augmentation of LxSM model is mapping 
service parameter into configuration parameters is not always 1 to 1 mapping, 
in many cases,it is N to M mapping, domain specific level controller needs to 
allocate additional resource level parameters. Therefore I feel augmentation is 
more suitable device level, but not suggested to be used in top down service 
mapping.
But To reduce the mapping,cost, What we consider in LxNM model design is to try 
to reuse many data type that are also applied to LxSM. Please refer to RFC9181

Secondly, I disagree LxNM is designed for single vendor scenarios, the reason 
to introduce network level model, is to address multi-vendor interoperability 
issue since different vendor control can be deployed in various different 
domain, sometime it is IP domain, sometime it is optical domain.

Third, for service mapping, there are some other work to be developed in TEAS 
working group, e.g., 
https://datatracker.ietf.org/doc/draft-ietf-teas-te-service-mapping-yang/
https://datatracker.ietf.org/doc/draft-dhody-teas-ietf-network-slice-mapping/
They solve different jigsaw composing or decomposing. So you don’t need too 
much worry about the issue you raised.

Regarding How many "digital twins" every single network, I think you should 
more look into how to network topology model developed by IETF, e.g., Network 
Topology model
L3 Topology Model
L2 Topology model
DC Fabric Model
TE Topology model
L3 TE topology model., etc
To build digital twin model, I believe these topology related model are a good 
basis, in addition, you should get KPI data, Log Data, flow statistics data, 
Alarm data, other inventory related data, correlate them with topology data to 
build digital twin network, In IRTF NMRG, we have digital twin network 
architecture, try to build a whole picture, tackle key challenges to build 
digital twin network 
https://datatracker.ietf.org/doc/draft-irtf-nmrg-network-digital-twin-arch/
also there are many other digital twin related work in NMRG, which can be a 
good input to this architecture.
Hope this helps.

-Qin
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Vasilenko Eduard
发送时间: 2022年12月8日 2:42
收件人: Jan Lindblad 
抄送: opsawg@ietf.org; net...@ietf.org; Paolo Volpato ; 
Xipengxiao 
主题: Re: [netmod] How many "digital twins" every single network should have? Who 
would map between "twins"?

Hi Jan,
Thanks for you your answer.
Reading more I have found more evidence that the “digital network twin” should 
be single/unified for a network of any size:
- I did mention below OpenConfig that had merged configuration and operational 
data models many years ago,
- RFC8342 is asking for the same☺,
- RFC8969 is going a step further and asking to have the cross-layer 
convergence to the unified YANG model.
It looks obvious – all relationships are better t

Re: [OPSAWG] [netmod] How many "digital twins" every single network should have? Who would map between "twins"?

[Qin Wu]

Hi, Eduard:
Thank for bring this issue up, I think digital twins is more related to network 
topology model, network monitoring model rather than LxSM service delivery 
model or LxNM network model

First, As described in RFC8969 or RFC8309, LxSM service delivery model or LxNM 
network model focuses on service level abstraction and resource level 
abstraction respectively,  we expect Service level abstraction
Can be decomposed into network/resource level abstraction, and resource level 
abstraction to be translated into a bunches of device level models, but we 
don’t expect translation across level can be standardized in the same way.
Service mapping process, configuration translation process should play the key 
roles, this provide flexibility and meet requirements of various difference use 
cases.
Another reason is not to choose use augmentation of LxSM model is mapping 
service parameter into configuration parameters is not always 1 to 1 mapping, 
in many cases,it is N to M mapping, domain specific level controller needs to 
allocate additional resource level parameters. Therefore I feel augmentation is 
more suitable device level, but not suggested to be used in top down service 
mapping.
But To reduce the mapping,cost, What we consider in LxNM model design is to try 
to reuse many data type that are also applied to LxSM. Please refer to RFC9181

Secondly, I disagree LxNM is designed for single vendor scenarios, the reason 
to introduce network level model, is to address multi-vendor interoperability 
issue since different vendor control can be deployed in various different 
domain, sometime it is
IP domain, sometime it is optical domain.

Third, for service mapping, there are some other work to be developed in TEAS 
working group, e.g.,
https://datatracker.ietf.org/doc/draft-ietf-teas-te-service-mapping-yang/
https://datatracker.ietf.org/doc/draft-dhody-teas-ietf-network-slice-mapping/
They solve different jigsaw composing or decomposing. So you don’t need too 
much worry about the issue you raised.

Regarding How many "digital twins" every single network, I think you should 
more look into how to network topology model developed by IETF, e.g.,
Network Topology model
L3 Topology Model
L2 Topology model
DC Fabric Model
TE Topology model
L3 TE topology model., etc
To build digital twin model, I believe these topology related model are a good 
basis, in addition, you should get KPI data, Log Data, flow statistics data,
Alarm data, other inventory related data, correlate them with topology data to 
build digital twin network,
In IRTF NMRG, we have digital twin network architecture, try to build a whole 
picture, tackle key challenges to build digital twin network
https://datatracker.ietf.org/doc/draft-irtf-nmrg-network-digital-twin-arch/
also there are many other digital twin related work in NMRG, which can be a 
good input to this architecture.
Hope this helps.

-Qin
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Vasilenko Eduard
发送时间: 2022年12月8日 2:42
收件人: Jan Lindblad 
抄送: opsawg@ietf.org; net...@ietf.org; Paolo Volpato ; 
Xipengxiao 
主题: Re: [netmod] How many "digital twins" every single network should have? Who 
would map between "twins"?

Hi Jan,
Thanks for you your answer.
Reading more I have found more evidence that the “digital network twin” should 
be single/unified for a network of any size:
- I did mention below OpenConfig that had merged configuration and operational 
data models many years ago,
- RFC8342 is asking for the same☺,
- RFC8969 is going a step further and asking to have the cross-layer 
convergence to the unified YANG model.
It looks obvious – all relationships are better to have in the single 
consistent YANG data storage.
It is slowly happening in the IETF (examples above).

Yet RFC9182 has many disclaimers like:
“the L3NM is not defined as an augment to the L3SM, because a specific 
structure is required to meet network-oriented L3 needs”
“initial design was interpreted as if the deployment of the L3NM depends on the 
L3SM, while this is not the case”.
I see a couple of reasons for it:
- to minimize the disruption for many available implementations,
- to trade off unification and interoperability for functionality and 
flexibility.

After L3NM was disconnected from L3SM, many mapping between these models should 
be done in a proprietary way by coders.
Imagine that one product could map an event “A” in the L3NM to be related to 
the configuration XpathA in the L3SM,
But the different product would map an event “A” to be related to the 
configuration XpathB in the L3SM.
Then they would act inconsistently.
The other example could be when provisioning something in L3SM would be mapped 
to different Xpath in L3NM by different products.
It is again a problem if L3NMs from different vendors should support the same 
VPN.

If humans (with really the best knowledge and intelligence in respective IETF 
WGs) were not capable of automatically mapping L3SM to L3NM,
Then no hope that the 

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

[Qin Wu]

Hi, All:
Thanks authors to write this draft and validate it using Hackathon project. I 
take some time to review this draft, my general position is to support moving 
this work toward publication.
Here are a few comments and suggestions:

1.   Abstract:
What is the difference between “the SRv6 behavior that traffic is being 
forwarded with. “ and SRv6 forwarding plane? Should we just use SRv6 forwarding 
plane to replace original wording? Maybe I miss something.
But we need to consider consistency between abstract and introduction 
description.

2.Section 3, the definition of srhFlagsIPv6
At the current stage, 8 bit flags defined in SRH are all unused according to 
RFC8754,however looking up IANA registry for Segment Routing Header Flags,
Only OAM flag is allocated for RFC9259, I am wondering whether OAM flag should 
be reported together with other unused flags.
What is the impact on this parameter when some other flags have been allocated 
from Segment Routing Header Flags registry, it seems no harm, but do you think 
we should clarify only OAM flag is allocated in this srhFlagsIPv6 definition.

3.Section 3, the definition of srhTagsIPv6
I am wondering whether we need to have some out-band  mechanism to define the 
meaning or purpose of using these srhTagIPv6, when we say a group of packet 
sharing the same set of properties, what is the example of these properties? 
Should these srhTagIPv6 global unique? Or local scope specific?

4.Section 3 the definition of srhSegmentIPv6ListSection
I am not sure I understand the difference between srhSegmentIPv6BasicList and 
srhSegmentIPv6ListSection?
I know you provide an usage example to explain this, but  for the reader who 
are not familiar with IPFIX, it is hard to parse this. Would it be great to add 
some text in the definition of srhSegment IPv6ListSection to clarify this 
difference.
Maybe add a pointer to section 6.1

Also I believe srhSegmentIPv6BasicList and srhSegmentIPv6ListSection should not 
be reported at the same time? Two IE should be mutually excluded? No?

5.Section 3. The definition of srhSection IPv6
The same comment is applied to srhSection IPv6, I think we should add more 
texts to explain how srhSectionIPv6 organized? Or what information is included 
in srhSectionIPv6

6.Section 4
It looks these information in section 4 can be used to provide SRv6 visibility 
or troubleshooting, for the answer 2, I am wondering what else does the 
management system do for troubleshooting? Or the network devices have already 
done everything for the management system regarding troubleshooting?

7 Section5.2
When the device export srhTagIPv6 value to the management system, Who will tell 
the device or the management system about the meaning or purpose of srhTagIPv6? 
It is probably beyond scope, but it will be nice to clarify the mechanism to be 
used.

8. Section 5.9.1
For IPFIX IPv6 SRH Segment Type Subregistry,
I am wondering whether this draft-ietf-opsawg-ipfix-srv6-srh should also be 
added into additional information

9.Section 6.2
Is there any IPFIX mechanism to tell two side of communication between the 
management system and network devices whether compressed SID is used or 
non-compressed SID is used?

10.Section 6.3
When the management system and the network device exchange IPFIX information, 
how does two side know whether carrying multiple same IE in one data record is 
supported? Is there any capability exchanged in the IPFIX mechanism?

11. Section 9
s/the allocation/allocation
The security consideration is over simplified, I am wondering whether exposing 
detailed segmentIPv6BasicList has some security risk? Is there any security 
enhancement that need to be considered?

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2022年11月30日 21:54
收件人: opsawg@ietf.org
主题: [OPSAWG]  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
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Enterprise Inventory Management Side meeting Invitation (Tuesday 8:30~9:30 Mezzanine 12 )

[Qin Wu]

Hi, All

We got trouble to get access to webex link which require approval. I plan to 
abandon webex and use Zoom link instead, sorry to bring you inconvenience.

Join Zoom Meeting

https://us06web.zoom.us/j/84747399084?pwd=cFFWMFB5TVdabUNlaDFrQ2V1UGE0QT09

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

[OPSAWG] Enterprise Inventory Management Side meeting (Tuesday 8:30~9:30am Mezzanine 12 )

[Qin Wu]

Hi, Everyone:
We have planned to organize a side meeting on Network Inventory Management on 
Tuesday Morning 8:30~9:30am,
There are several relevant drafts in this space:
a. RFC8345 (Network Topology model: maintenance of an inventory of nodes 
contained in a network. )
b. RFC8348 (Hardware Management)
c draft-ietf-opsawg-sbom-access (Software Transparency and Vulnerability 
Information Retrieval)
d. draft-palmero-opsawg-dmlmo (IT asset management)
e. draft-wzwb-opsawg-network-inventory-management (Physical, Virtual Network 
Inventory)
f. draft-yg3bp-ccamp-network-inventory-yang (Physical Network Inventory)
.
The goal is to identify the gap of inventory management and produce gap 
analysis, discuss architecture mapping, various different inventory 
definition(e.g., network config inventory, network topo inventory, software 
inventory, physical inventory, etc ), reach agreement on inventory 
terminologies and scope of different relevant work.
If you are interested in this topic, feel free to contact us, Thanks in advance.

-Qin (On behalf of the team)

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

Re: [OPSAWG] Document Shepherd Review of draft-ietf-opsawg-sbom-access-11

[Qin Wu]

Elliot:
The suggested changes all look good, thank for clarification and addressing my 
comments, I will update document shepherd review to reflect the current 
implementation status.

-Qin
发件人: Eliot Lear [mailto:l...@lear.ch]
发送时间: 2022年10月9日 20:19
收件人: Qin Wu ; opsawg 
抄送: Eliot Lear ; draft-ietf-opsawg-sbom-acc...@ietf.org
主题: Re: [OPSAWG] Document Shepherd Review of draft-ietf-opsawg-sbom-access-11


Hi Qin,

Thanks for your review.  Please see below.
On 08.10.22 11:27, Qin Wu wrote:
Hi, authors:
I have read the latest version of this draft, it is well written, thank for 
that.
Here is the identified minor issues during document shepherd review of 
draft-ietf-opsawg-sbom-access-11:

1.   Abstract said:
“
It may optionally be discovered through manufacturer usage descriptions.

”

[Qin] This sentence is not clear. Are you saying MUD extensions transparency 
can be discovered using extensions defined in section 3.9 of RFC8520?
Or software transparency and vulnerability information can be discovered by 
using ACL example defined in section 5.4 of this draft? I assume it is the 
latter. Please clarify.

Ok, I propose the following change:

OLD:

This memo specifies a model to provide access to this information.  It

may optionally be discovered through manufacturer usage descriptions.



NEW:

This memo extends the MUD YANG model to provide the locations of software

bills of materials and to vulnerability information.




2.   Section 1 said:
“
   The mechanisms specified in this document are meant to satisfy
   several use cases:

   *  A network-layer management system retrieving information from an
  IoT device as part of its ongoing lifecycle.  Such devices may or
  may not have query interfaces available.

”
[Qin] How many use cases do we specify here? I believe it is two, how about be 
specific about the number of use cases here, s/several use cases/the following 
two use cases

Ok




3.   Section 1 said:
“   In the first case, devices will have interfaces that permit direct
   retrieval.  Examples of these interfaces might be an HTTP 
[RFC9110<https://datatracker.ietf.org/doc/html/rfc9110>],
   or COAP [RFC7252<https://datatracker.ietf.org/doc/html/rfc7252>] endpoint 
for retrieval.  There may also be private
   interfaces as well.

   In the second case, when a device does not have an appropriate
   retrieval interface, but one is directly available from the
   manufacturer, a URI to that information MUST be discovered.

   In the third case, a supplier may wish to make an SBOM or
   vulnerability information available under certain circumstances, and
   may need to individually evaluate requests.  The result of that
   evaluation might be the SBOM or vulnerability itself or a restricted

”
[Qin] I believe the first case, the second case, the third case are 
corresponding to three ways to discover object instead of two key use cases 
listed in section 1? Therefore there are confusing to be introduced here.

I suggest to change as follows:
s/in one of three ways/ through one of three method
s/In the first case/In the first method
s/In the second case/In the second method
s/in the third case/In the third method


Ok.  I changed the word "In" to "Using", but otherwise agree.



4.   Section 1.1

[Qin] s/in either/either in

Ok



5.   Section 1.1 said:

“ The MUD semantics provide a way for manufacturers

to control how often tooling should check for those changes through

the cache-validity node. “

[Qin] Can you provide a reference section in RFC8520 about such MUD semantics.

I have changed this to "MUD's cache-validity node provides a way..."

For your information, this is Section 3.5 of 8520.

6.   Section 3 N.B.

[Qin] What N.B. stands for? Can you provide a reference or change in other 
words.

N.B. is a commonly used Latin abbreviation for "nota bene" or "note well".  It 
falls into the class of i.e,  and e.g.





7.   Section 5.4 said:

“ 
5.4<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sbom-access-11#section-5.4>.
  With ACLS



Finally, here is a complete example where the device provides SBOM

and vulnerability information, as well as access-control information.



{

"ietf-mud:mud": {

"mud-version": 1,

"extensions": [
"ol",

"transparency"
], “


[Qin] How this draft is related to draft-ietf-opsawg-ol-01? In other words, how 
sbom access work together with Ownership and licensing statements in YANG 
described in draft-ietf-opsawg-ol-01.

If ‘ol’ extension is needed, I think a informative reference is needed here.

This as discussed within the working group, and the point was made that it is 
good to show mud working with unrelated extensions.  I would prefer for this 
reason not to include an informative reference.  Implementations need not 
process extensions they do not understand (to do so would require a major re

[OPSAWG] Document Shepherd Review of draft-ietf-opsawg-sbom-access-11

[Qin Wu]

Hi, authors:
I have read the latest version of this draft, it is well written, thank for 
that.
Here is the identified minor issues during document shepherd review of 
draft-ietf-opsawg-sbom-access-11:

1.   Abstract said:
"
It may optionally be discovered through manufacturer usage descriptions.

"

[Qin] This sentence is not clear. Are you saying MUD extensions transparency 
can be discovered using extensions defined in section 3.9 of RFC8520?
Or software transparency and vulnerability information can be discovered by 
using ACL example defined in section 5.4 of this draft? I assume it is the 
latter. Please clarify.


2.   Section 1 said:
"
   The mechanisms specified in this document are meant to satisfy
   several use cases:

   *  A network-layer management system retrieving information from an
  IoT device as part of its ongoing lifecycle.  Such devices may or
  may not have query interfaces available.

"
[Qin] How many use cases do we specify here? I believe it is two, how about be 
specific about the number of use cases here, s/several use cases/the following 
two use cases


3.   Section 1 said:
"   In the first case, devices will have interfaces that permit direct
   retrieval.  Examples of these interfaces might be an HTTP 
[RFC9110],
   or COAP [RFC7252] endpoint 
for retrieval.  There may also be private
   interfaces as well.

   In the second case, when a device does not have an appropriate
   retrieval interface, but one is directly available from the
   manufacturer, a URI to that information MUST be discovered.

   In the third case, a supplier may wish to make an SBOM or
   vulnerability information available under certain circumstances, and
   may need to individually evaluate requests.  The result of that
   evaluation might be the SBOM or vulnerability itself or a restricted

"
[Qin] I believe the first case, the second case, the third case are 
corresponding to three ways to discover object instead of two key use cases 
listed in section 1? Therefore there are confusing to be introduced here.

I suggest to change as follows:
s/in one of three ways/ through one of three method
s/In the first case/In the first method
s/In the second case/In the second method
s/in the third case/In the third method


4.  Section 1.1

[Qin] s/in either/either in

5.  Section 1.1 said:

" The MUD semantics provide a way for manufacturers

to control how often tooling should check for those changes through

the cache-validity node. "

[Qin] Can you provide a reference section in RFC8520 about such MUD semantics.

6.  Section 3 N.B.

[Qin] What N.B. stands for? Can you provide a reference or change in other 
words.

7.  Section 5.4 said:

" 
5.4.
  With ACLS



Finally, here is a complete example where the device provides SBOM

and vulnerability information, as well as access-control information.



{

"ietf-mud:mud": {

"mud-version": 1,

"extensions": [
"ol",

"transparency"
], "


[Qin] How this draft is related to draft-ietf-opsawg-ol-01? In other words, how 
sbom access work together with Ownership and licensing statements in YANG 
described in draft-ietf-opsawg-ol-01.

If 'ol' extension is needed, I think a informative reference is needed here.


8.  Section 6 said:

"N.B., for MUD, the mandatory method of retrieval is TLS. "

[Qin] New fashion of acronym,:)


9.  Section 6 said:

"

One example may be to issue a certificate to the client for

this purpose after a registration process has taken place.  Another

example would involve the use of OAUTH in combination with a
federations of SBOM servers. "

[Qin] I feel there is disconnection between the fifth sentence and the sixth 
sentence in the paragraph 9 . Two examples are provided here, I am wondering 
which security risk are addressed by which example?



10. Section 6 said:

"

Vulnerability information is generally made available to such

databases as NIST's National Vulnerability Database. "

[Qin] Do we need to list the Database Name developed by specific entity in the 
security section as normative text?



11. Do we have implementation that pertains to this draft?

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

Re: [OPSAWG]  CALL FOR ADOPTION: RADIUS Extensions for Encrypted DNS

[Qin Wu]

Thank for clarification, so Diameter protocol doesn't need to define any new 
attributes with similar functionality as Radius attributes, right?

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Alan DeKok
发送时间: 2022年9月15日 21:42
收件人: Qin Wu 
抄送: Joe Clarke (jclarke) ; opsawg@ietf.org
主题: Re: [OPSAWG]  CALL FOR ADOPTION: RADIUS Extensions for Encrypted DNS

On Sep 15, 2022, at 9:39 AM, Qin Wu  wrote:
> Is relying on specific RADIUS attributes mandatory? Can we rely on other AAA 
> message, e.g., Diameter message protocol to populate DHCP messages, no?

  All RADIUS attributes can be carried inside of Diameter.  This capability is 
part of Diameter, and does not need to be mentioned in any RADIUS specification.

  Alan DeKok.

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

Re: [OPSAWG]  CALL FOR ADOPTION: RADIUS Extensions for Encrypted DNS

[Qin Wu]

Med:
I have read the latest version of draft-boucadair-opsawg-add-encrypted-dns and 
support adoption of this work with the following comments:

1.   Section 1, paragraph 1said:
“
The information used to populate DHCP messages and/or IPv6 Router Advertisements
relies upon specific Remote Authentication Dial-In User Service (RADIUS) 
[RFC2865] attributes, such as the DNS-Server-IPv6-Address
   Attribute specified in [RFC6911].
”
Is relying on specific RADIUS attributes mandatory? Can we rely on other AAA 
message, e.g., Diameter message protocol to populate DHCP messages, no?

2.   Section 1, paragraph 5 said:
“

The procedure defined in [I-D.ietf-add-dnr] is thus followed between the DHCPv6 
client and the DHCPv6 server.  The same procedure

is followed between the DHCPv6 client on endpoints serviced by the CPE and the 
DHCPv6 server on CPE.

”
I am not clear which procedure in which section can be followed between DHCPv6 
client and the DHCPv6 server. I thought when the DHCP message is sent back to 
the client, the task is done, and the client consume content extracted from 
DHCP rely message and

Establish DNS session with DNS server, no? Also I am wondering why 
draft-boucadair-opsawg-add-encrypted-dns is not consolidated into 
[I-D.ietf-add-dnr] if the procedure described in this draft can work together 
with the procedure defined in [I-D.ietf-add-dnr].


Also I want to better understand the last sentence, i.e.,

“The same procedure

is followed between the DHCPv6 client on endpoints serviced by the CPE and the 
DHCPv6 server on CPE.
”
Do you mean the DHCPv6 client and DHCP server are hosted on the same CPE? No
Would it be great to make them clear. Thanks for taking my comments into 
consideration.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2022年9月14日 22:28
收件人: opsawg@ietf.org
主题: [OPSAWG]  CALL FOR ADOPTION: RADIUS Extensions for Encrypted DNS

Hello, WG.  I like Henk’s subject icon.  Makes for some attention-grabbing.

This work has been discussed previously in opsawg, going back over a year.   
The authors have continued to progress the work and would like to gauge WG 
interest in adopting it.

One might ask, why opsawg?  The radext WG has been concluded, but, like IPFIX, 
there is interest in continuing to produce extensions for RADIUS.  It was 
suggested by Benjamin Kaduk that opsawg was a potential fit for this work.

Therefore, this kicks off a two-week CfA for 
https://datatracker.ietf.org/doc/draft-boucadair-opsawg-add-encrypted-dns/.  
Please comment on-list with support and/or discussion of the work.

Thanks.

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

Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

[Qin Wu]

Support this draft, with a few comments and suggestions below:

1.   It will be more reasonable to place use section before protocol 
definition section.

2.   Please add reference to RFC defining SRv6 Endpoint Behavior in both 
abstract and introduction section

3.   Please add reference to RFC which allocate 89 Element ID to 
forwardingStatus;

4.   Use case is not clear how these new IPFIX Information Elements work 
together with existing IPFIX Information Elements

Or how these new IPFIX Information Elements work together with SRv6.


-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Paolo Volpato
发送时间: 2022年8月22日 20:00
收件人: opsawg@ietf.org
主题: Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Hi,

I have read the draft and think it is useful in the area of network operations.
Therefore I support its adoption.

BR
Paolo

From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of Joe Clarke (jclarke)
Sent: Thursday, August 18, 2022 10:14 PM
To: opsawg@ietf.org
Subject: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Hello, WG.  We’d like to begin a two week call for adoption of this work.  Even 
as an individual draft it has already received some reviews and has iterated 
quite a bit.  Based on IETF 114 there does seem to be interest in adopting this 
in opsawg, but we need a formal adoption poll.

Please review and provide your adoption thoughts no later than September 1, 
2022.

Thanks.

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

Re: [OPSAWG] IPR POLL: draft-ietf-opsawg-sap

[Qin Wu]

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

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2022年4月23日 3:01
收件人: opsawg@ietf.org
主题: [OPSAWG] IPR POLL: draft-ietf-opsawg-sap

Authors and contributors, please respond on-list as to whether or not you are 
aware of any IPR that pertains to this work.

Please state either:

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

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

Joe


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

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

[Qin Wu]

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

-Qin
-邮件原件-
发件人: Joe Clarke (jclarke) [mailto:jcla...@cisco.com] 
发送时间: 2022年3月1日 7:11
收件人: Wubo (lana) ; Qin Wu ; 
mohamed.boucad...@orange.com; Oscar González de Dios 
; Bin Wen 
主题: Poll for IPR: draft-ietf-opsawg-yang-vpn-service-pm

Authors and contributors, please respond on-list as to whether or not you are 
aware of any IPR that pertains to this work.

Please state either:

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

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

Joe

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

Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

[Qin Wu]

Thanks Bo, I believe Dhruv asked the similar question as you raised.
Yes, I think interconnection point in end to end connectivity spanning across 
multiple domains can be saps.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Wubo (lana)
发送时间: 2022年1月19日 22:27
收件人: Tianran Zhou ; opsawg@ietf.org
抄送: opsawg-cha...@ietf.org
主题: Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi Tianran, all,

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

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

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

Hi WG,

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

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

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

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

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

Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

[Qin Wu]

Thanks Dhruv for valuable review, see reply inline below.

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Dhruv Dhody
发送时间: 2022年1月19日 20:40
收件人: Tianran Zhou 
抄送: opsawg@ietf.org; opsawg-cha...@ietf.org
主题: Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi Tianran,

I have read the I-D and I support its adoption.

Few comments -

1) Figure 1 uses the term "Service Network Models" which is not defined and not 
aligned to RFC 8309.
[Qin Wu]  I think it is referred to network configuration models since it sits 
on top of controller described in figure 3 of RFC8309. But I am not sure 
RFC8309 is better reference  since RFC8309 introducse layered SDN architecture 
and split orchestrator into service orchestrator and network orchestrator which 
intends to align with MEF SLO project.
I suggest we can align with RFC8969 instead, which use the term “network model” 
and reduce confusion when the number of layers in our targeted architecture is 
different from on described in figure 3 of RFC8309.
2) Is the attachment-id the key via which the SAP is linked to the physical 
topology? More text on this would be useful.
[Qin Wu] Yes the attachment-id is the key for service-attachment –point list 
which can mapped to the specific port in the physical topology, yes, we can 
make this clear in the update.

3) Consider adding an example (JSON or XML) of how this model would be used 
alongside L3SM.
[Qin Wu] Good suggestion and will add.

4) Can SAP be used for NNI? Some clarification would be nice!
[Qin Wu] Yes, I think we cover NNI use case, see the text in the introduction
“
With the help of
   other data models (e.g., L3SM 
[RFC8299<https://datatracker.ietf.org/doc/html/rfc8299>] or L2SM 
[RFC8466<https://datatracker.ietf.org/doc/html/rfc8466>]),
   hierarchical control elements could determine the feasibility of an
   end-to-end IP connectivity or L2VPN connectivity and therefore derive
   the sequence of domains and the points of interconnection to use.

”
I think the point of interconnection can be exposed attachment point in the NNI 
case.

Thanks!
Dhruv

On Wed, Jan 5, 2022 at 7:42 AM Tianran Zhou 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
Hi WG,

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

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

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

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

Cheers,
Tianran
___
OPSAWG mailing list
OPSAWG@ietf.org<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] WG Adoption Call for draft-dbwb-opsawg-sap-00

[Qin Wu]

Support as coauthor, I am not aware of any IPR related to this I-D.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 mohamed.boucad...@orange.com
发送时间: 2022年1月5日 15:32
收件人: Tianran Zhou ; opsawg@ietf.org
抄送: opsawg-cha...@ietf.org
主题: Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi Tianran, all,

I support adoption, obviously.

FWIW, I don’t have any IPR nor I’m aware of any related to this I-D.

Cheers,
Med

De : OPSAWG mailto:opsawg-boun...@ietf.org>> De la 
part de Tianran Zhou
Envoyé : mercredi 5 janvier 2022 03:12
À : opsawg@ietf.org
Cc : opsawg-cha...@ietf.org
Objet : [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi WG,

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

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

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

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

Cheers,
Tianran

_



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] CALL FOR ADOPTION: Transport Layer Security Verion 1.3 (TLS 1.3) Transport Model for the Simple Network Management Protocol Version 3 (SNMPv3)

[Qin Wu]

-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 tom petch
发送时间: 2021年12月7日 0:45
收件人: Andy Donati ; mohamed.boucad...@orange.com
抄送: opsawg@ietf.org
主题: Re: [OPSAWG] CALL FOR ADOPTION: Transport Layer Security Verion 1.3 (TLS 
1.3) Transport Model for the Simple Network Management Protocol Version 3 
(SNMPv3)

From: OPSAWG  on behalf of Andy Donati 

Sent: 01 December 2021 23:16

I support the adoption of this work.

Back when RFC 6353 was created in the ISMS working group the TLS working group 
lent a helping hand.  Hopefully they (TLS) can provide useful comments and 
information for the OPSAWG as well.


My recollection is slightly different, that at that time, WG had a security 
advisor assigned to them and that it was that individual that was helpful.   
These days I sense more of a silo mentality, that WG are less inclined to 
engage with the work of other WG, and that a more fruitful way forward could be 
to ask for an early Secdir review (once the work is under way).

[Qin Wu] Fully agree, I assume the consultation with MIB doctors have already 
taken place, since Jurgen has got involved. We did have writable MIB IESG 
statement 
(https://www.ietf.org/about/groups/iesg/statements/writable-mib-module/)  ,i.e.,
"
SNMP MIB modules creating and modifying configuration state should only be 
produced by working groups in cases of clear utility and consensus to use SNMP 
write operations for configuration, and in consultation with the MIB doctors.
"
Tom Petch.



Regards,
Andy D.

> On Nov 30, 2021, at 8:39 AM, mohamed.boucad...@orange.com wrote:
>
> Hi all,
>
> I support adopting this work.
>
> I think that the document has more chances to make progress in opsawg than 
> tls. I trust the chairs will liaise with the tls wg so that the document is 
> reviewed there as well.
>
> Cheers,
> Med
>
>> -Message d'origine-
>> De : OPSAWG  De la part de Michael 
>> Richardson Envoyé : samedi 20 novembre 2021 16:25 À : opsawg@ietf.org 
>> Objet : Re: [OPSAWG] CALL FOR ADOPTION: Transport Layer Security 
>> Verion
>> 1.3 (TLS 1.3) Transport Model for the Simple Network Management 
>> Protocol Version 3 (SNMPv3)
>>
>>
>> Joe Clarke \(jclarke\)  wrote:
>>> Hello, WG.  Kenneth presented
>>> https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update/ at
>> IETF112
>>> to us, and this was previously presented at SecDispatch at IETF111.
>> The
>>> feeling there was that this work had merit, but Sec didn't have
>> enough
>>> SNMP experience to be the owner.  At the AD level, the feeling was
>> that
>>> perhaps opsawg did have the expertise and could pick this up.
>>
>> I guess I missed this from IETF111.
>> I scanned the document briefly, and I don't see that much that 
>> requires *SNMP*-fu, so much as it requires TLS-fu.
>>
>> I think that the document will get lost in OPSAWG.
>>
>> Traditionally, WGs do their own MIB modules... so I don't understand 
>> why it is not in TLS.
>>
>> --
>> Michael Richardson. o O ( IPv6 IøT consulting )
>>   Sandelman Software Works Inc, Ottawa and Worldwide
>
> __
> ___
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les 
> pieces jointes. Les messages electroniques etant susceptibles d'alteration, 
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be 
> distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

___
OPSAWG 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 for draft-dbwb-opsawg-sap-00.txt

[Qin Wu]

Thank Chongfeng for valuable comments to this draft. See reply inline below.
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Chongfeng Xie
发送时间: 2021年11月2日 21:20
收件人:  
抄送: opsawg@ietf.org; Lopez, Victor (Nokia - ES/Madrid) 
主题: Re: [OPSAWG] New Version Notification for draft-dbwb-opsawg-sap-00.txt

Hi, all,
I have read this short draft and it is well written. I support the adoption of 
it since it provides a good management tool
for service attachment management. A few suggestions to this drafts:

1.  If the customer want to open a new line, can we add an usage example to 
show what kind of capability can be exposed

2.  from domain controller to the upper layer application?
[Qin]:Good suggestion, we authors also discuss what usage example we will bring 
up in the offline discussion and will present one of our usage example in the 
upcoming IETF 112.
Bear in mind, this model is not customer facing model but a model which can 
provide management tool for operators to manage their network and provide 
network visibility to the overlay
topology, even in the end to end service spanning across multiple domains, this 
model can also provide a mangaement tool for operators to know the sequence of 
dmomains involves and interconnection points assoicated with each domain.
2. I think we should emphasize L3NM or L2NM used to configure VPN while this 
model is used for capability exposure.
[Qin]: Agree with your assessment, thanks.

3.  if L3VPN service is allocated to an logical interface, for instance, an 
ethernet sub-interface, how do we support this

interface type? e.g., extend  if:interface-type to support such interface type? 
or reference IANA Interface Type defined in RFC7224?
[Qin]:Our initial thought is to investigate IANA interface Type in RFC7224, but 
it is apparently IANA interface type in RFC7224 is not sufficient to represent 
ethernet sub-interface,
If you look at RFC7224, it only specify atmSubInterface identity. Therefore we 
think it is more reasonable to extend if:interface-type to support some new 
interface type. Thanks
for raising this issue.

Chongfeng Xie
2021年10月22日 
下午8:04，mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 写道：

Hi all,

We updated the uni draft to address some of the comments we received in the 
past. For better clarity, we abandoned the uni terminology and went with 
service attachment points that is more generic. It can be used to build a 
network topology to be consumed by an orchestrator to handle a service request. 
SAPs can be the PE endpoint facing a CE or a peer PE (for services such as 
inter-AS VPN).

Comments, questions, and suggestions are more than welcome.

Cheers,
Oscar, Samier, Qin, Victor, & Med

-Message d'origine-
De : internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Envoyé : vendredi 22 octobre 2021 13:57
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; Oscar 
Gonzalez de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>;
 Oscar de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>;
 Qin WU mailto:bill...@huawei.com>>; Qin Wu 
mailto:bill...@huawei.com>>; Samier Barguil 
mailto:samier.barguilgiraldo@telefonica.com>>;
 Victor Lopez mailto:victor.lo...@nokia.com>>; samier 
barguil 
mailto:samier.barguilgiraldo@telefonica.com>>
Objet : New Version Notification for draft-dbwb-opsawg-sap-00.txt


A new version of I-D, draft-dbwb-opsawg-sap-00.txt has been successfully 
submitted by Mohamed Boucadair and posted to the IETF repository.

Name:   draft-dbwb-opsawg-sap
Revision:   00
Title:  A Network YANG Model for Service Attachment Points
Document date: 2021-10-22
Group:  Individual Submission
Pages:  21
URL:https://www.ietf.org/archive/id/draft-dbwb-opsawg-sap-00.txt
Status: https://datatracker.ietf.org/doc/draft-dbwb-opsawg-sap/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-dbwb-opsawg-sap


Abstract:
  This document defines a YANG data model for representing an abstract
  view of the provider network topology containing the points from
  which its services can be attached (e.g., basic connectivity, VPN,
  network slices).  The data model augments the 'ietf-network' data
  model by adding the concept of service attachment points (SAPs).  The
  service attachment points are the points to which network services
  (such as L3VPN or L2VPN) can be attached.  The customer endpoint of
  an attachment circuits are not covered in the SAP network topology.




The IETF 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 si

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

[Qin Wu]

-邮件原件-
发件人: Carsten Bormann [mailto:c...@tzi.org] 
发送时间: 2021年10月26日 15:18
收件人: Guy Harris 
抄送: Qin Wu ; opsawg@ietf.org
主题: Re: [OPSAWG]  WG Adoption Call for draft-gharris-opsawg-pcap-02

On 26. Oct 2021, at 09:00, Guy Harris  wrote:
> 
> I would vote for "both should point to a common location" so that neither the 
> pcap nor the pcapng spec says "there is *the* list of link-layer types" - it 
> points to a registry, and as more types are added to the registry, more specs 
> can be published define them.

Indeed, and running such a registry is exactly what IANA is good at.

One way to do this would be to jump-start the process by a short document 
establishing this registry, with a defined registration policy.
(We’d probably need to be able to point out candidates for the designated 
experts that will implement this policy to make this approach palatable to 
IESG.)

[Qin] Good proposal, agree with this.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Qin Wu]

-邮件原件-
发件人: Carsten Bormann [mailto:c...@tzi.org] 
发送时间: 2021年10月26日 14:35
收件人: Qin Wu 
抄送: opsawg@ietf.org
主题: Re: [OPSAWG]  WG Adoption Call for draft-gharris-opsawg-pcap-02

Hi Qin,

On 26. Oct 2021, at 03:43, Qin Wu  wrote:
> 
> I am not against this draft. I am just thinking whether Independent 
> submission stream process is a better choice for this document

I’m not sure which “this document” you are discussing here, as Michael asked 
about both pcap and pcapng.
Let’s assume you are talking about pcap.

[Qin Wu] Yes and no, related to both, I think.

> in the first round when WG and IESG have no change control to this work.

I have no idea what a second round would be.
The pcap format needs to be published only once.

[Qin Wu] My impression is that pcap will be the first and pcapng will derive 
from it. Maybe I am wrong, I am not clear
the relation between these two.

The pcap document *could* be an independent submission.
However, the document will benefit from wide review, as it is documenting 
widely spread practice, which makes the WG process more useful.


[Qin Wu] Just to clarify that my comment is more related to process for 
publication of this work, not aim at technical content.
If this document doesn't change the control from "The Tcpdump Group" to IETF or 
IESG or individual person, I feel we follow the wrong IETF registry template.
This comment is applied to both section 8.1 and 8.2.
That is why I feel Independent stream process is a better choice, but I also 
realized that Independent stream process doesn't provide IETF registry for new 
link type or new media type.
That is the tricking point.

Yes, WG process provides benefit for wide review, I am wondering what technical 
content change we can make for this document? 
I feel what we can do is cosmetic change. In addition what Directorate in each 
area can do about it? Maybe genart review has no issues.

> Upon this work get published as RFC 
> (https://www.rfc-editor.org/about/independent/), bisdocument can go through 
> WG submission process, if my understanding is correct.

No document here has to wait for any other document to be published.

[Qin Wu] I thought pcapng will be progressed after pcap draft and is 
replacement to pcap. Still we need to clarify the relation between two 
documents.
I think JSON document evolvement (RFC4627,RFC7158,RFC8259) is the right process 
for such kind of work. The cost is the time for iteration.
Grüße, Carsten

> 
> -Qin
> -邮件原件-
> 发件人: Michael Richardson [mailto:mcr+i...@sandelman.ca]
> 发送时间: 2021年10月26日 0:28
> 收件人: opsawg@ietf.org
> 抄送: l...@cisco.com; Toerless Eckert ; Qin Wu 
> ; Carsten Bormann ; 
> j.schoenwael...@jacobs-university.de; 
> vladi...@lightside-instruments.com; war...@kumari.net; 
> ie...@btconnect.com; a...@research.att.com
> 主题: Re: [OPSAWG]  WG Adoption Call for draft-gharris-opsawg-pcap-02
> 
> On 2021-10-20 12:40 p.m., Michael Richardson wrote:
>> On 2021-10-04 4:00 p.m., Henk Birkholz wrote:
>>> Dear OPSAWG members,
>>> 
>>> this starts a call for Working Group Adoption of
>>> 
>>>> https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02
>>> 
>>> ending on Monday, October 18th.
>> 
>> https://mailarchive.ietf.org/arch/msg/opsawg/4Cvm_msdnORHMUY3kbyCV6db
>> G yI is a very long thread about adoption from November 2020.
>> 
>> There were many suggestions at the time from many people on the CC.
>> 
>> It would be great if you could comment on the current plan.
>> 
> 
> A number of you spoke up last week about pcapng in this thread.
> Can you clarify if your support was for the pcapng only document, or for both 
> pcap and pcapng?
> 

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

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

[Qin Wu]

I am not against this draft. I am just thinking whether Independent submission 
stream process is a better choice for this document in the first round when WG 
and IESG have no change control to this work.
Upon this work get published as RFC 
(https://www.rfc-editor.org/about/independent/), bisdocument can go through WG 
submission process, if my understanding is correct.

-Qin
-邮件原件-
发件人: Michael Richardson [mailto:mcr+i...@sandelman.ca] 
发送时间: 2021年10月26日 0:28
收件人: opsawg@ietf.org
抄送: l...@cisco.com; Toerless Eckert ; Qin Wu 
; Carsten Bormann ; 
j.schoenwael...@jacobs-university.de; vladi...@lightside-instruments.com; 
war...@kumari.net; ie...@btconnect.com; a...@research.att.com
主题: Re: [OPSAWG]  WG Adoption Call for draft-gharris-opsawg-pcap-02

On 2021-10-20 12:40 p.m., Michael Richardson wrote:
> On 2021-10-04 4:00 p.m., Henk Birkholz wrote:
>> Dear OPSAWG members,
>>
>> this starts a call for Working Group Adoption of
>>
>>> https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02
>>
>> ending on Monday, October 18th.
> 
> https://mailarchive.ietf.org/arch/msg/opsawg/4Cvm_msdnORHMUY3kbyCV6dbG
> yI is a very long thread about adoption from November 2020.
> 
> There were many suggestions at the time from many people on the CC.
> 
> It would be great if you could comment on the current plan.
> 

A number of you spoke up last week about pcapng in this thread.
Can you clarify if your support was for the pcapng only document, or for both 
pcap and pcapng?

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

Re: [OPSAWG] Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS)

[Qin Wu]

I assume many of us don't understand the difference between device model and 
network model, how network model is mapped down to device level models.
See figure 5 of RFC8969, In order to deliver L3VPN service, the L3NM defined 
configuration or abstraction should be further decomposed into a set of 
detailed configuration parameters of device model such as BGP, Network 
Instance, QoS, key chain, etc 
which specify detailed protocol specific parameters such as BGP or feature 
specific parameters such as key chain. 
TCP-AO will be part of BGP configuration parameters. L3NM focus on specify 
which functionality needs to be invoked such as TCP-AO, BGP model will document 
details of configuration parameters which include TCP-AO. 
Another choice is L3NM defined configuration will be decomposed into 
example-network-dev...@2017-03-13.yang defined in 
draft-ietf-rtgwg-device-model, details of configuration related to TCP-AO will 
be specified in the example-network-dev...@2017-03-13.yang.
Therefore you can see different vendors may come up with different mapping 
solution or decomposition.
Hope this clarifies.

-Qin
-邮件原件-
发件人: Scharf, Michael [mailto:michael.sch...@hs-esslingen.de] 
发送时间: 2021年9月23日 17:42
收件人: Qin Wu ; mohamed.boucad...@orange.com; Martin Duke 
; The IESG 
抄送: draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg@ietf.org; 
opsawg-cha...@ietf.org
主题: RE: Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS)

Hi Qin,

I believe that in the specific case of "send-id" and "recv-id", the actual 
issue is that L3NM references to the RFC 8177 model that could theoretically 
include the required information. But RFC 8177 may have a gap there.

And since these values must be set consistently with the router a PE connects 
to, IMHO a default value or template for determining the device configuration 
may not work. As I have already said, for a lot of _other_ device configuration 
I can see how templates or the like would fill device configuration gaps in an 
abstract network model.

But for TCP-AO "send-id" and "recv-id", I think the L3NM document needs to 
explain where the actual values provisioned to each PE would come from. I don't 
understand how the PE could guess the correct value.

Granted, TCP-AO may be a minor detail of the overall L3NM model - but this kind 
of detail may be sort of a litmus test for how well network-level abstractions 
actually work.

Michael



> -Original Message-
> From: Qin Wu 
> Sent: Thursday, September 23, 2021 11:05 AM
> To: Scharf, Michael ; 
> mohamed.boucad...@orange.com; Martin Duke ; 
> The IESG 
> Cc: draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg@ietf.org; opsawg- 
> cha...@ietf.org
> Subject: RE: Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: 
> (with
> DISCUSS)
> 
> Hi, Michael, Med and all:
> I tend to agree with Med we should have a clear distinction between 
> device level configuration and network level abstraction.
> Device level configuration will provide complete set of TCP AO 
> properties configuration to make TCP AO functionality work while 
> network level abstraction should focus on network layers configuration 
> **across multiple devices **or **specifying which functionality need 
> to be invoked**. Sometimes it is hard to find the clear boundary, or 
> debatable to have or not have some parameters. But If we propose to 
> add send-id and recv-id to L3NM, I am arguing why not add MAC 
> algorithm, KDF, why not add other TCP connection parameters? If we 
> look for adding complete set of TCP AO configuration in the 
> draft-ietf-tcpm- yang-tcp, I think maybe meta model defined in 
> draft-ietf-rtgwg-device- model is a better choice.
> 
> -Qin
> -邮件原件-
> 发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Scharf, Michael
> 发送时间: 2021年9月22日 23:38
> 收件人: mohamed.boucad...@orange.com; Martin Duke 
> ; The IESG 
> 抄送: draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg@ietf.org; opsawg- 
> cha...@ietf.org
> 主题: Re: [OPSAWG] Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-
> 11: (with DISCUSS)
> 
> Hi Med,
> 
> Thanks for the useful references. More inline.
> 
> > -Original Message-
> > From: mohamed.boucad...@orange.com
> > 
> > Sent: Tuesday, September 21, 2021 2:56 PM
> > To: Scharf, Michael ; Martin Duke 
> > ; The IESG 
> > Cc: draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg@ietf.org; opsawg- 
> > cha...@ietf.org
> > Subject: RE: Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11:
> > (with
> > DISCUSS)
> >
> > Hi Michael,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Scharf, Michael [mailto:michael.sch...@hs-esslingen.de]
> > > Envoyé : lundi 20 

Re: [OPSAWG] Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS)

[Qin Wu]

Hi, Michael, Med and all:
I tend to agree with Med we should have a clear distinction between device 
level configuration and network level abstraction.
Device level configuration will provide complete set of TCP AO properties 
configuration to make TCP AO functionality work while network level abstraction 
should focus on
network layers configuration **across multiple devices **or **specifying which 
functionality need to be invoked**. Sometimes it is hard to find the clear 
boundary, or debatable to have or not have some parameters. But If we propose 
to add send-id and recv-id to L3NM, I am arguing why not add MAC algorithm, 
KDF, why not add other TCP connection parameters? If we look for adding 
complete set of TCP AO configuration in the draft-ietf-tcpm-yang-tcp, I think 
maybe meta model defined in draft-ietf-rtgwg-device-model is a better choice.

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Scharf, Michael
发送时间: 2021年9月22日 23:38
收件人: mohamed.boucad...@orange.com; Martin Duke ; The 
IESG 
抄送: draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg@ietf.org; 
opsawg-cha...@ietf.org
主题: Re: [OPSAWG] Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with 
DISCUSS)

Hi Med,

Thanks for the useful references. More inline.

> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: Tuesday, September 21, 2021 2:56 PM
> To: Scharf, Michael ; Martin Duke 
> ; The IESG 
> Cc: draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg@ietf.org; opsawg- 
> cha...@ietf.org
> Subject: RE: Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: 
> (with
> DISCUSS)
> 
> Hi Michael,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Scharf, Michael [mailto:michael.sch...@hs-esslingen.de]
> > Envoyé : lundi 20 septembre 2021 12:05 À : BOUCADAIR Mohamed 
> > INNOV/NET
> ; Martin
> > Duke ; The IESG  Cc : 
> > draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg@ietf.org; opsawg- 
> > cha...@ietf.org Objet : RE: Martin Duke's Discuss on 
> > draft-ietf-opsawg-l3sm-l3nm-11:
> > (with DISCUSS)
> >
> > Hi Med,
> >
> > What happens if PEs and CEs are both under operator control? In that 
> > case, the customer-facing L3SM model may not need any TCP-AO 
> > configuration.
> >
> > However, in that case, TCP-AO may need to be configured on the PEs 
> > and the "send-id" and "receive-id" values must be consistent with 
> > the CEs, no?
> 
> [[Med]] Agree.
> 
>  If the PE configuration is done by L3NM, the "send-id" and "receive-
> > id" must be part of L3NM model, no?
> 
> [[Med]] Not necessarily. See below.
> 
>  If not, how would the TCP-AO
> > provisioning on CEs and PEs work?
> 
> [[Med]] The assumption we had for this version of the module is that 
> send-id and recv-id are pre-configured while only the key reference is 
> manipulated in the L3NM. Some of the implementations separate the 
> TCP-AO configuration from the invocation in context of a particular 
> protocol, e.g.,
> 
> *
> https://www.juniper.net/documentation/en_US/junos/topics/reference/g
> eneral/release-notes/20.3/infocus-topicmaps/tcp-authentication-option-
> map-infocus.html
> * https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/72x/b-bgp-
> cg-ncs5500-72x/implementing-master-key-tuple-
> configuration.html#id_77361

Good references. As far as I can see, in those two cases the send-id and 
recv-id are modelled in the key-chain and therefore configurable as part of the 
key-chain. With such a key-chain, your assumption would work.

However, draft-ietf-opsawg-l3sm-l3nm-11 references to the key-chain from RFC 
8177. Unlike in those two previous examples, I don't understand how one would 
encode send-id and recv-id in the RFC 8177 model. 

So, my reading is that draft-ietf-opsawg-l3sm-l3nm-11 assumes that the 
referenced key-chain includes additional entries beyond RFC 8177, such as 
send-id and recv-id.

If that assumption is correct, IMHO the document draft-ietf-opsawg-l3sm-l3nm 
has to highlight that additions to the key-chain model beyond RFC 8177 may be 
required for TCP-AO to work.

> We can add a note about it you think this helps. Thank you.

If the document assumes additions to RFC 8177, this must be noted, IMHO.

Of course, an alternative would be just to import draft-ietf-tcpm-yang-tcp, 
which models the relevant entries, but that will be your call.

Michael 

> 
> >
> > In a nutshell, I don't understand the argument "send-id and 
> > receive-id are not needed in L3NM because they are not included in 
> > L3SM". Also, that generic argument would apply to _a lot_ of network 
> > level configuration that is not part of L3SM.
> >
> > BTW, I agree that augmentation will be important for many 
> > parameters, but IMHO you have to ensure that the L3NM model includes 
> > all base parameters that are required for connectivity. At least for 
> > TCP-AO, I don't understand your specific choice in L3NM so far.
> >
> > Best regards
> >
> > Michael
> >
> >
> >
> >
> > > -Original Message-
> 

Re: [OPSAWG] IPR Poll: draft-ietf-opsawg-l2nm

[Qin Wu]

No, I am not aware of any IPR that applies to draft-ietf-opsawg-l2nm.

-Qin (as contributor)
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2021年9月17日 0:03
收件人: opsawg@ietf.org
主题: [OPSAWG] IPR Poll: draft-ietf-opsawg-l2nm

Working Group, Authors,

As a part of the WGLC, this email starts the IPR poll.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/

 
Are you aware of any IPR that applies to draft-ietf-opsawg-l2nm?
 
If you are an author or contributor on this draft, please reply indicating 
whether or not you are aware of any IPR on this draft in accordance with IETF 
rules.

If you are on the OPSA WG email list but are not listed as an author or 
contributor, then please explicitly respond only if you are aware of any IPR 
that has not yet been disclosed in conformance with IETF rules.

Thus far, no IPR has been disclosed.

Thanks.

Joe

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

[OPSAWG] Opsdir last call review of draft-ietf-opsawg-l3sm-l3nm-10

[Qin Wu via Datatracker]

Reviewer: Qin Wu
Review result: Has Nits

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Summary:
This document defines L3VPN network model for provisioning L3VPN service within
service provider network. It provides network centric view of L3VPN service. I
think this document is well written and ready for publication. However I have a
few editorial comments I want like authors to consider.

Major issue: None
Nits:
1. Section 1, Paragraph 6
Is correspondence referred to corresponding relation or correlation? If they
are equivalent, I am okay with the current wording.

2. Section 5, Network topology module bullet
s/using the network topology module in [RFC8345]
/using the network topology module in [RFC8345]
Or its extension module such as UNI topology module
[I-D.ogondio-opsawg-uni-topology]

3.Section 6.1 Paragraph 1
The last sentence describes Causal relationship between template and batch
process and abstracting the parameter into upper SDN layer, it is not very
clear to me that which one is cause? Which one is effect? Maybe I am wrong.

4.Section 6.1 Paragraph 2
Customer sites are not modelled in the L3NM any more How about
s/ the addition or removal of customer sites / the addition or removal of VPN
nodes

5.Section 6.1 Paragraph 2
Is RT/RD synchronization mechanism between Pes in the scope of document? If
none, please make this clear.

6.Section 6.2, Paragraph 2
s/service model/network model

7.Section 6.3 Paragraph 2
Is MPLS P2MP the only transport for multicast traffic in this case or just an
example transport?

8.Section 7.4 'rd'definition
s/ these RD/the following RD

9. Section 7.6 'connection' definition
s/from where/from which

10. Section 7.6.3 said:
"The L3NM supports the configuration of one or more IPv4/IPv6 static
   routes.  Since the same structure is used for both IPv4 and IPv6, it
   was considered to have one single container to group both static
   entries independently of their address family, but that design was
   abandoned to ease the mapping with the structure in [RFC8299].
"
I think you emphasize that the L2NM and L3NM to follow the similar structure to
ease the mapping.

11.Section 7.6.3, 'status' definition
s/ is used to control the (de)activation/can also be used to control the
(de)activation

12. Section 7.6.3 'ipv6-site-of-origin' definition
s/IPv6 Address Specific BGP Extended/IPv6 Address Specific BGP Extended
Community

13. Section 7.6.3 'authentition' definition under BGP
I think we support different authentication modes such as TCP AO support, IPSEC
support, TLS support. I am not sure that TCP MD5 should be supported as an
option since it has break many protocols.

14. Section 7.6.6 'Layer 4' definition
s/data node under ‘l3’ (Figure 25)/data node under ‘l4’ (Figure 26)
I didn’t check other figure number consistency.

15. Section 8
s/RFC UUU/RFC XXX


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

Re: [OPSAWG] WG Last call for draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

[Qin Wu]

Support, a few comments for clarity:
General comment:
1.Have we considered to request early IANA allocation?

2.   Section 2
s/ dynamic BGP labels according to RFC8277 [RFC8277]/ dynamic BGP labels 
[RFC8277]
s/ BGP Prefix-SID according to RFC8669 [RFC8669]/ BGP Prefix-SID [RFC8669]
s/ in context of Seamless MPLS SR [I-D.hegde-spring-mpls-seamless-sr]/ in 
context of Seamless MPLS SR (see section 4.6 of 
[I-D.hegde-spring-mpls-seamless-sr])
s/ as described in RFC8661 [RFC8661]./ as described in [RFC8661] Appendix A.

3.   Section 4:
Suggest to add a note to RFC Editor on code point TBD4 allocation and update.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2021年6月8日 8:56
收件人: opsawg@ietf.org
主题: [OPSAWG] WG Last call for draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

Hi WG,

The following draft is mainly to request some IPFIX IE allocations.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-label-type/

We agreed to fast track this draft and move forward.
Now the authors think it’s stable. And we got IE expert reviewed.

This mail we start a two weeks WG last call, before June21.
Please reply your comments on this.

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

Re: [OPSAWG] IPR CALL: draft-ietf-opsawg-l3sm-l3nm

[Qin Wu]

Chairs：
I am not aware of any IPR that applies to this draft.

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2021年3月22日 21:34
收件人: opsawg@ietf.org
主题: [OPSAWG] IPR CALL: draft-ietf-opsawg-l3sm-l3nm

Authors, contributors, and WG members, as we are in WGLC for this document, we 
want to solicit knowledge of any IPR that may pertain to the 
draft-ietf-opsawg-l3sm-l3nm work.

Please state either, "no, I am not aware of any IPR that applies to this draft" 
or, "yes, I am aware of IPR that applies this draft".

If there is IPR, it must be disclosed in compliance with IETF IPR rules (i.e., 
RFCs 3669, 5378, and 8179).  Please indicate if this has been done.

If you have any additional details, please share those as well.

If you are an author or contributor, you must reply to indicate IPR status.

Joe


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

Re: [OPSAWG] IPR CALL: draft-ietf-opsawg-vpn-common

[Qin Wu]

Chairs:
I am not aware of any IPR that applies to this draft.

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2021年3月22日 21:33
收件人: opsawg@ietf.org
主题: [OPSAWG] IPR CALL: draft-ietf-opsawg-vpn-common

Authors, contributors, and WG members, as we are in WGLC for this document, we 
want to solicit knowledge of any IPR that may pertain to the 
draft-ietf-opsawg-vpn-common work.

Please state either, "no, I am not aware of any IPR that applies to this draft" 
or, "yes, I am aware of IPR that applies this draft".

If there is IPR, it must be disclosed in compliance with IETF IPR rules (i.e., 
RFCs 3669, 5378, and 8179).  Please indicate if this has been done.

If you have any additional details, please share those as well.

If you are an author or contributor, you must reply to indicate IPR status.

Joe


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

[OPSAWG] OpenMetric work

[Qin Wu]

Richard:
Thank for bringing up this work, it is interesting. Try to get the whole 
picture for this open metric work.
Can you clarify how this open metric work is related meter API, trace API, 
context API in the opentelemetry.
Also how this open metric is related to Distributed Trace work in W3C?
Thanks in advance.

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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-04.txt

[Qin Wu]

Tiru:
I am wondering whether section 4.2 “Encrypted DNS” should reference 7 of 
draft-richardson-opsawg-mud-iot-dns-considerations-03 for DNS recommendation.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 tirumal reddy
发送时间: 2021年1月18日 12:51
收件人: opsawg 
主题: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-04.txt

In this revised draft https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-04 
Privacy Considerations section is updated to address comments from Michael.

Further comments and suggestions are welcome.

Cheers,
-Tiru

On Sun, 17 Jan 2021 at 17:22, 
mailto:internet-dra...@ietf.org>> wrote:

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

Title   : Manufacturer Usage Description (MUD) (D)TLS Profiles 
for IoT Devices
Authors : Tirumaleswar Reddy
  Dan Wing
  Blake Anderson
Filename: draft-ietf-opsawg-mud-tls-04.txt
Pages   : 34
Date: 2021-01-17

Abstract:
   This memo extends the Manufacturer Usage Description (MUD)
   specification to incorporate (D)TLS profile parameters.  This allows
   a network security service to identify unexpected (D)TLS usage, which
   can indicate the presence of unauthorized software or malware on an
   endpoint.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-mud-tls-04
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-tls-04


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

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


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

Re: [OPSAWG]  WG Adoption Call on draft-lear-opsawg-sbom-access-00

[Qin Wu]

Hi, authors of draft-lear-opsawg-sbom-access-00:
What is key difference between sbom-url and local-uri? I feel a little bit 
confused when reading the definition of sbom-url and local-uri
Based on the definition of local-url,
"
case local-uri {
description
  "The choice of sbom-local means that the SBOM resides at
  a location indicated by an indicted scheme for the
  device in question, at well known location
  '/.well-known/sbom'.  For example, if the MUD file
  indicates that coaps is to be used and the host is
  located at address 10.1.2.3, the SBOM could be retrieved
  at 'coaps://10.1.2.3/.well-known/sbom'.  N.B., coap and
  http schemes are NOT RECOMMENDED.";
  }
"
I think local-url is more related to well know url while sbom url is more 
related to local domain URL, what am I missing?
The question is Should SBOM server be discovered in the Cloud or in the local 
domain?

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Henk Birkholz
发送时间: 2021年1月5日 0:10
收件人: opsawg 
主题: [OPSAWG]  WG Adoption Call on draft-lear-opsawg-sbom-access-00

Dear OPSAWG members,

this starts a call for Working Group Adoption on
https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00 ending on Monday, 
January 25.

As a reminder, this I-D describes different ways to acquire Software Bills of 
Material (SBOM) about distinguishable managed entities. The work was updated by 
the authors on October 13th and now elaborates on three ways SBOM can be found, 
including a MUD URI as one of the options.

Please reply with your support and especially any substantive comments you may 
have.


For the OPSAWG co-chairs,

Henk

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

Re: [OPSAWG]  WG Adoption Call on draft-richardson-opsawg-mud-iot-dns-considerations-03

[Qin Wu]

Support adoption of this document, agree with Eliot.
A few quick comments:
1. I want to make sure these recommendation and guidelines of using DNS are not 
only applicable to home network but also enterprise network as well.
2. Section 4.2 lack examples of non-deterministic CDN content.
3. Section 4.2 describe control protocol to connect to a known HTTP
  end point, can you provide an example of such control protocol, HTTP 
protocol, SUIT protocol, or any firmware update protocol.

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Eliot Lear
发送时间: 2021年1月5日 4:36
收件人: Henk Birkholz 
抄送: opsawg 
主题: Re: [OPSAWG]  WG Adoption Call on 
draft-richardson-opsawg-mud-iot-dns-considerations-03

Hi!

I’ve read this document and support its adoption.  Michael is doing a really 
good job here of making use of BCP in the truest sense of the word.  I suspect 
this would be a good document to involve the dnsops people in as well.

Eliot


> On 4 Jan 2021, at 19:03, Henk Birkholz  
> wrote:
> 
> Dear OPSAWG members,
> 
> this starts a call for Working Group Adoption on 
> https://tools.ietf.org/html/draft-richardson-opsawg-mud-iot-dns-considerations-03
>  ending on Monday, January 25.
> 
> As a reminder, this I-D describes potential issues and concerns regarding the 
> use of DNS names and IP addressed with RFC8520 Manufacturer Usage Description 
> (MUD) in support of device access.
> 
> Please reply with your support and especially any substantive comments you 
> may have.
> 
> 
> For the OPSAWG co-chairs,
> 
> Henk
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

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

Re: [OPSAWG]  WG adoption call on draft-richardson-opsawg-mud-acceptable-urls-03

[Qin Wu]

Hi, authors of draft-richardson-opsawg-mud-acceptable-urls:
I have seen most of comments I raised earlier on have been addressed, e.g.,
1. provide recommendation to the implementers or developer on when they choose 
MUD URL updating and when they choose MUD file updating?
2.Clarify the difference between RFC8520 and 
draft-richardson-opsawg-mud-acceptable-urls on MUD file signing
3.Add summary text at the beginning of the section 2
Thanks for that, it improve clarity and readability. I support adoption of this 
work

One more comment is Does MUD URL updating require any new protocol exchange 
between end device and firmware server, how does end device detect MUL URL 
change?
Thanks!

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Henk Birkholz
发送时间: 2021年1月5日 2:06
收件人: opsawg 
主题: [OPSAWG]  WG adoption call on 
draft-richardson-opsawg-mud-acceptable-urls-03

Dear OPSAWG members,

this starts a call for Working Group Adoption on
https://tools.ietf.org/html/draft-richardson-opsawg-mud-acceptable-urls-03
ending on Monday, January 25.

As a reminder, this I-D describes ways to update (if possible) MUD URIs as 
specified in RFC8520 Manufacturer Usage Description (MUD) in a secure and 
acceptable manner.

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

[OPSAWG] EVPN support in L2NM

[Qin Wu]

Hi, all:

We discussed EVPN support for L2NM in past L3NM Design team meetings and tried 
to identify what are missing parameters for EVPN support in L2NM.

First, EVPN have many different flavors, e.g.,

O MPLS EVPN (RFC7432)

o VXLAN EVPN (RFC8365)

o PBB EVPN (RFC7623)

o VPWs EVPN (RFC8214)

These flavors can be distinguished based on service type in the current model, 
we also discussed whether vpn node type is needed to distinguish

Different EVPN flavors, based on discussion, we think this vpn node type is 
redundant, since service type has already played this role.

Secondly, EVPN needs to support split horizon, split horizon can be interpreted 
as filtering mechanism on the PE node to prevent such loop and packet 
duplication, e.g., If a CE is multihomed to two or more PEs (represented by an 
ES ES1) and operating in an All-Active redundancy mode, sends a BUM (i.e., 
Broadcast, Unknown unicast, or Multicast) packet to one of these PEs, then it 
is important to ensure the packet is not looped back to the CE via another PE 
connected to this CE.

In the current model, we have defined split-horizon parameter to classify the 
connection into different group which implicitly indicate

split horizon support. In the Design team discussion, we discussed whether a 
Boolean parameter to indicate split horizon support explicitly.But maybe 
redundant and not need at the VPN node level.



Third, FRR support, in many cases, FRR is used with TE support. However we also 
see some work discuss how FRR can be supported without TE

https://www.apricot.net/apricot2006/slides/conf/thursday/Stefano_Previdi_IPFRR-Apricot.pdf
https://tools.ietf.org/html/rfc5714

So if FRR is highly tied with TE, we think the best place to define it is in 
the TE service mapping draft, if FRR can be decoupled with TE, it looks IP FRR 
can be introduced in L2NM.



Fourth, Diffserv model type support, In the RFC 3270, three MPLS DiffServ 
models are defined: Uniform, Pipe, and Short Pipe. MPLS Diffserv will be used 
in both local PE and egress PE to distinguish how data traffic is treated in 
the ingress node and egress node, which is different from QoS parameters 
(traffic classification+QoS Policy enforcement)defined in L2NM.

Should this be added as EVPN support? In the current model, we don't have 
Diffserv support. But it is nice to have this feature.


Fifth, Bridge domain ID support, as described in RFC7209,

"For each of the above services, a single bridge domain is assigned per service 
instance on the PE supporting the associated service.
For example, in case of the port mode, a single bridge domain is assigned for 
all the ports belonging to that service instance"
I am wondering whether bridge domain ID should be defined in L2NM as optional 
parameter.

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

Re: [OPSAWG] Feedback on draft-www-opsawg-yang-vpn-service-pm

[Qin Wu]

Good catch, Greg, the difference is the granularity of the percentile, 
supporting five 9s seems reasonable to me. I am happy to align with the 
percentile defined in STAMP YANG model.

-Qin
发件人: gregory.mir...@ztetx.com [mailto:gregory.mir...@ztetx.com]
发送时间: 2020年12月15日 4:32
收件人: Qin Wu 
抄送: mohamed.boucad...@orange.com; jclarke=40cisco@dmarc.ietf.org; 
opsawg@ietf.org
主题: Re:[OPSAWG] Feedback on draft-www-opsawg-yang-vpn-service-pm


Hi Qin,

thank you for the detailed analysis of advantages of using percentiles compared 
with an average metric. I've noticed that in the draft the percentile is 
defined as

  typedef percentile {

type decimal64 {

  fraction-digits 2;

}

description

  "The nth percentile of a set of data is the

   value at which n percent of the data is below it.";

  }

Doesn't that limit the ability of request the reported percentile, e.g., five 
9s? I can reference the STAMP YANG data 
model<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/?include_text=1>
 where:

   typedef percentile {

 type decimal64 {

   fraction-digits 5;

 }

 description

   "Percentile is a measure used in statistics

   indicating the value below which a given

   percentage of observations in a group of

   observations fall.";

   }



Regards,

Greg Mirsky



Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division


[cid:image001.gif@01D6D2C2.89CB9FC0]

[cid:image002.gif@01D6D2C2.89CB9FC0]
E: gregory.mir...@ztetx.com<mailto:gregory.mir...@ztetx.com>
www.zte.com.cn<http://www.zte.com.cn/>

Original Mail
Sender: QinWu
To: mohamed.boucad...@orange.com;Joe<mailto:mohamed.boucad...@orange.com;Joe> 
Clarke (jclarke);opsawg;
Date: 2020/12/14 07:33
Subject: Re: [OPSAWG] Feedback on draft-www-opsawg-yang-vpn-service-pm
Thanks Med for clarification, we discussed the downside of using average 
before, i.e., hide outlier, which is more appropriate for relative even 
distribution.
That is why we introduce percentiles. 3 percentiles value can be 50 
percentile,75 percentile,95 percentile which is configured by setting 
low-percentile,middle-percentile, high-percentile under nt:link
 augment /nw:networks/nw:network/nt:link:
   +--rw low-percentilepercentile
   +--rw high-percentile   percentile
   +--rw middle-percentile percentile
Then high-delay-percentile, high-jitter-percentile, etc can be used to report 
the measured delay value, jitter value corresponding to specific percentile 
value, i.e., high-percentile, low-percentile, middle-percentile.
As Med clarified we have defined default value for them.
Regarding the counter, I tend to agree, in addition, I think counter32 is 
sufficient for discard, error, unknown protocol related statistics, which is 
similar to
What is defined in ietf-interfaces.

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
发送时间: 2020年12月14日 22:58
收件人: Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 opsawg mailto:opsawg@ietf.org>>
主题: Re: [OPSAWG] Feedback on draft-www-opsawg-yang-vpn-service-pm

Hi Joe, all,

Thank you for sharing these comments.

Instead of sharing avg values, we do think that sharing percentile values is 
more useful. Up to 3 sets of percentiles can be shared for each performance 
metric: low (e.g., 5.00), mid (50.00), or high (90.00). The exact percentile 
value to characterize low/mid/high is configurable. Otherwise, default values 
will be used (will update the module + explain the behavior in the text).

If all *-percentile parameters are set to 0.00, this means that no 
percentile-related nodes will be reported for a given performance metric 
(one-way delay, one-way delay variation). Only peak/min/current values can be 
reported.

Fully agree with your comment on the counters.

More text will be added to describe the intended behavior.

Cheers,
Med

> -Message d'origine-
> De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de Joe Clarke
> (jclarke) Envoyé : vendredi 11 décembre 2020 21:28 À : opsawg
> mailto:opsawg@ietf.org>> Objet : [OPSAWG] Feedback on
> draft-www-opsawg-yang-vpn-service-pm
>
> During the IETF109 opsawg session, this draft was presented, and I was
> concerned that a lot of its work had happened amongst the authors of
> the L2NM/L3NM et al work.  I hadn’t seen a lot of discussion on this
> list.
>
> I wanted to kick off some discussion around it.
>
> As contributor:
>
> I think this work is useful and complements the VPN NM work nicely.
> I had a few questions/comments as I read the -02 version of this
> draft.  First, the percentile leafs use the word “percentile” to
> define wha

Re: [OPSAWG] Feedback on draft-www-opsawg-yang-vpn-service-pm

[Qin Wu]

Thanks Med for clarification, we discussed the downside of using average 
before, i.e., hide outlier, which is more appropriate for relative even 
distribution.
That is why we introduce percentiles. 3 percentiles value can be 50 
percentile,75 percentile,95 percentile which is configured by setting 
low-percentile,middle-percentile, high-percentile under nt:link
 augment /nw:networks/nw:network/nt:link:
   +--rw low-percentilepercentile
   +--rw high-percentile   percentile
   +--rw middle-percentile percentile
Then high-delay-percentile, high-jitter-percentile, etc can be used to report 
the measured delay value, jitter value corresponding to specific percentile 
value, i.e., high-percentile, low-percentile, middle-percentile.
As Med clarified we have defined default value for them.
Regarding the counter, I tend to agree, in addition, I think counter32 is 
sufficient for discard, error, unknown protocol related statistics, which is 
similar to
What is defined in ietf-interfaces.

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 mohamed.boucad...@orange.com
发送时间: 2020年12月14日 22:58
收件人: Joe Clarke (jclarke) ; opsawg 

主题: Re: [OPSAWG] Feedback on draft-www-opsawg-yang-vpn-service-pm

Hi Joe, all, 

Thank you for sharing these comments.

Instead of sharing avg values, we do think that sharing percentile values is 
more useful. Up to 3 sets of percentiles can be shared for each performance 
metric: low (e.g., 5.00), mid (50.00), or high (90.00). The exact percentile 
value to characterize low/mid/high is configurable. Otherwise, default values 
will be used (will update the module + explain the behavior in the text).

If all *-percentile parameters are set to 0.00, this means that no 
percentile-related nodes will be reported for a given performance metric 
(one-way delay, one-way delay variation). Only peak/min/current values can be 
reported.

Fully agree with your comment on the counters.

More text will be added to describe the intended behavior. 

Cheers,
Med

> -Message d'origine-
> De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de Joe Clarke 
> (jclarke) Envoyé : vendredi 11 décembre 2020 21:28 À : opsawg 
>  Objet : [OPSAWG] Feedback on 
> draft-www-opsawg-yang-vpn-service-pm
> 
> During the IETF109 opsawg session, this draft was presented, and I was 
> concerned that a lot of its work had happened amongst the authors of 
> the L2NM/L3NM et al work.  I hadn’t seen a lot of discussion on this 
> list.
> 
> I wanted to kick off some discussion around it.
> 
> As contributor:
> 
> I think this work is useful and complements the VPN NM work nicely.
> I had a few questions/comments as I read the -02 version of this 
> draft.  First, the percentile leafs use the word “percentile” to 
> define what it is.  I think some more wording around what is meant by 
> the low/middle/high percentiles would be useful.  One can piece this 
> together by reading through the YANG module, but I would like to see 
> some explanatory text in the body of the document that explains the 
> percentile breakdowns.  Examples of this would also be helpful.
> 
> What would happen if you set all percentile leafs to 0.00?  Would that 
> only affect the delay and jitter leafs?  Again, I think some 
> clarifying text is needed here as to how to use these data points.
> 
> I’m also curious about some of the tp-telemetry-attributes counters.
> Why are the octets, unicast, and nunicast counters 32-bit?  I think 
> they should be 64-bit to be in line with ietf-interfaces.  And for all 
> of these leafs, why are they uint instead of counter?  They seem to be 
> counters in reading the descriptions.  The same counter questions 
> applies to those -count leafs under loss-statistics.
> 
> Joe
> ___
> 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.

Re: [OPSAWG] New Version Notification for draft-tuexen-opsawg-pcapng-02.txt

[Qin Wu]

Hi, two Michaels:
Can you clarify what functionalities is missed for more modern applications? 
Since it is enhancement to libpcap, do you expect all the future packet capture 
tools support the format defined in this draft?

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Michael Richardson
发送时间: 2020年9月29日 4:31
收件人: Michael Tuexen ; pcap-ng-for...@winpcap.org; 
opsawg@ietf.org; Jasper Bongertz ; 
tcpdump-work...@lists.tcpdump.org; Fulvio Risso ; Guy 
Harris ; Gerald Combs 
主题: Re: [OPSAWG] New Version Notification for draft-tuexen-opsawg-pcapng-02.txt


Michael Tuexen  wrote:
>> internet-dra...@ietf.org wrote:
>>> Diff: https://www.ietf.org/rfcdiff?url2=draft-tuexen-opsawg-pcapng-02
>>
>> Hi, I have converted the xml to markdown.

> Why? If we want to publish this, it will be published in xmlv3. So
> better to use that format earlier...

It's so so so much easier to maintain and update and get contributions.
github will render it directly

If you object strongly, we can stick to XML.

>> The results in the diff are okay, but actually the conversion is not
>> complete as I cheated and left the tables as preformatted figures, and
>> there are many internal references that I have no yet updated.
>>
>> The xml file had a long list of URLs as references, many of which were
>> duplicated.  I will be going through and fixing those in the next week
>> or so.
>>
>> This work has been discussed on and off in OPSAWG, but at this point I
>> am going to suggest that the document just go through the Independant
>> Submission Editor.

> Do we want to finally publish that? Up to now, I think the point was to
> find a home where it is substantially discussed and improved...

If we can get OPSAWG to adopt it, great.
I'm just not holding my breath.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

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

Re: [OPSAWG] WGLC for draft-ietf-opsawg-ntf [CORRECT]

[Qin Wu]

Support for publication.
A quick comment, regarding event triggered data, I think FSM is just one 
example of how event is modelled, but not the only way.
Suggest to make this clear in the text.
-Qin
From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Sent: Thursday, September 24, 2020 08:39
To: opsawg mailto:opsawg@ietf.org>>
Cc: draft-ietf-opsawg-...@ietf.org
Subject: WGLC for draft-ietf-opsawg-ntf [CORRECT]


Sorry for attaching a wrong link to the draft. Please see as follows.



Hi WG,



This email starts a working group last call for draft-ietf-opsawg-ntf.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntf/



Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
welcome.



The WG LC will end on 9st Oct 2020.



Thanks,

Tianran

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

Re: [OPSAWG] Last Call: (A Framework for Automating Service and Network Management with YANG) to Informational RFC

[Qin Wu]

Hi,
-邮件原件-
发件人: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] 
发送时间: 2020年9月30日 3:55
收件人: mohamed.boucad...@orange.com; last-c...@ietf.org
抄送: draft-ietf-opsawg-model-automation-framework@ietf.org; opsawg@ietf.org
主题: Re: Last Call:  (A 
Framework for Automating Service and Network Management with YANG) to 
Informational RFC

Hi Med, see below...
On 29-Sep-20 18:40, mohamed.boucad...@orange.com wrote:
> Hi Brian,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
>> Envoyé : mardi 29 septembre 2020 00:25 À : last-c...@ietf.org Cc : 
>> draft-ietf-opsawg-model-automation-framework@ietf.org;
>> opsawg@ietf.org
>> Objet : Re: Last Call: > framework-06.txt> (A Framework for Automating Service and Network 
>> Management with YANG) to Informational RFC
>>
>> Hi,
>>
>> I have a question for clarification, and then a comment.
>>
>> First, consider these extracts:
>>
>>> 5.1.  L2VPN/L3VPN Service Delivery
>>>
>>>In reference to Figure 5, the following steps are performed to
>>>deliver the L3VPN service within the network management
>> automation
>>>architecture defined in this document:
>>>
>>>1.  The Customer requests to create two sites (as per service
>>>creation operation in Section 4.2.1)...
>> ...
>>> 5.2.  VN Lifecycle Management
>>>
>>>In reference to Figure 7, the following steps are performed to
>>>deliver the VN service within the network management automation
>>>architecture defined in this document:
>>>
>>>1.  Customer requests (service exposure operation in Section
>> 4.1.1)
>>>to create 'VN' based on Access point...
>> ...
>>>3.  The Customer exchanges connectivity-matrix on abstract node
>> and
>>>explicit path using TE topology model with the
>> orchestrator...
>>
>> In those examples, how does the customer "request" or "exchange"
>> data? I assume this is intended to happen by software, rather than by 
>> telefax.
> 
> [Med] We hope this can be by software if we want to benefit from the 
> automation in the full cycle but the approach still apply independently how a 
> service request is captured. 
> 
> We don't zoom that much on that interface because the document is more on the 
> provider's side.
> 
>> So what protocol is involved, and which entity on the customer side 
>> is doing it?
> 
> [Med] The component at the client side are generally represented as service 
> ordering (see RFC 4176). That component may interact with the Order Handling 
> at the provider side using a variety of means such as 
> https://www.rfc-editor.org/authors/rfc8921.txt (Section 5) or by offering a 
> management interface to the customer, etc. 

Well, I'd rather see a standardised and generic solution to that problem, as 
noted in my reply to Adrian. But indeed, that is the requirement.
 
> Please let us know if you think that we need to add some text on this part.

I think it needs just a few words in section 3 or 4, even just to say that the 
mechanism is out of scope for this document.

> 
>>
>>> 5.3.  Event-based Telemetry in the Device Self Management
>>>
>>>In reference to Figure 8, the following steps are performed to
>>>monitor state changes of managed objects or resources in a
>> network
>>>device and provide device self-management within the network
>>>management automation architecture defined in this document:
>>>
>>>1.  To control which state a network device should be in or is
>>>allowed to be in at any given time, a set of conditions and
>>>actions are defined and correlated with network events
>> (e.g.,
>>>allow the NETCONF server to send updates...
>>
>> Second, this is the first mention of NETCONF in the document, and the 
>> only other mention is in the Security Considerations. I suggest that 
>> there should be a short description of the role of NETCONF (and
>> RESTCONF) earlier in the document, either in section 3 or more likely 
>> in section 4 (Functional Blocks and Interactions).
> 
> [Med] Point taken. We will also clarify that in some cases the use of YANG 
> does not require NETCONF/RESTCONF. 

Thanks. (For example, draft-ietf-anima-grasp-distribution can serve for 
distributing YANG.)

[Qin]: Thanks Brian for heads up. I think what Med mean is YANG doesn't need to 
tie with NETCONF, or RESTCONF, it could be also work with gRPC.
YANG is transport independent data modeling language.
One motivation to write this draft is to focus on management plane approach and 
build fully automated YANG based system. I am not sure grasp can be used to 
distribute YANG.
My impression of information distribution is used to distribute information 
between autonomic nodes in the data plane, that is not in the scope of this 
document,
If my understanding is correct. But I agree with you we could investigate how 
YANG, ANINMA, NETCONF work together. That's a very interesting topic.

Brian
> 

Re: [OPSAWG] AD review for draft-ietf-opsawg-model-automation-framework-04

[Qin Wu]

Thanks Rob for quick checking.
Talking with Med, we have agreed to remove that sentence. The change is 
reflected in v-05
See v-05
https://tools.ietf.org/html/draft-ietf-opsawg-model-automation-framework-05
the diff is:
https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-opsawg-model-automation-framework-05.txt

-Qin
-邮件原件-
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com] 
发送时间: 2020年9月19日 1:21
收件人: mohamed.boucad...@orange.com; opsawg 
抄送: draft-ietf-opsawg-model-automation-framework@ietf.org
主题: RE: AD review for draft-ietf-opsawg-model-automation-framework-04

Hi Med,

The changes that you have made look good.  But I had some comments at the end 
of my review email that it doesn't look like you have responded to, or 
actioned.  Hence, I'm wondering if my review email might have been truncated, 
or the end of it missed (from "Also, I ...") onwards (copied below).


A.3.1.1.  Schema Mount

   That capability does not cover design time.

This sentence is unclear on its own.  Perhaps either expand it or remove it
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Error discovered during AUTH48 processing of draft-ietf-opsawg-tacacs

[Qin Wu]

I think the updated text removes confusion in the original proposal..

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Warren Kumari
发送时间: 2020年9月15日 4:13
收件人: opsawg ; ops-...@ietf.org; OpsAWG-Chairs 

主题: [OPSAWG] Error discovered during AUTH48 processing of 
draft-ietf-opsawg-tacacs

Dear OpsAWG,

During AUTH48 processing of RFC 8907 (draft-ietf-opsawg-tacacs) we ran into 
something that was clearly an error:
Original:
   As this information is not always subject to verification, it is
   recommended that this field is in policy evaluation.

We are planning on replacing it with:
Updated:
   As this information is not always subject to verification, it MUST NOT be
   used in policy evaluation.:


The original clearly makes no sense, butas  the correction flips the meaning 
from what was written when approved, I wanted to let the WG know.

I'm planning on approving the "Updated" on Monday Sept 21st unless I hear a 
clear and compelling argument why not...

W

--
I don't think the execution is relevant when it was obviously a bad idea in the 
first place.
This is like putting rabid weasels in your pants, and later expressing regret 
at having chosen those particular rabid weasels and that pair of pants.
   ---maf

___
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] Henk Birkholz as third OPSAWG chair

[Qin Wu]

Congratulation Henk, welcome.

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Rob Wilton (rwilton)
发送时间: 2020年9月12日 0:36
收件人: opsawg 
抄送: Henk Birkholz 
主题: [OPSAWG] Henk Birkholz as third OPSAWG chair

Dear all,

I am happy to announce that Henk Birkholz has agreed to serve as a third OPSAWG 
WG chair to help with the current workload and gain some chair experience.

Please welcome Henk to OPSAWG.

Kind regards,
Rob
 

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

Re: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[Qin Wu]

Support adoption of this work.
I have a few comments which I would like authors to consider:
1. Module name I strange, should not include surname and WG name in the 
standard module name, suggest to change it from reddy-opsawg-mud-tls-profile 
into ietf-mud-tls-profile
2. Can we still see this module as "ietf-mud" extension module? since 
reddy-opsawg-mud-tls-profile is not augmentation of ietf-mud module any more in 
v-03
3. Section 3 said:
"
   The compromised IoT devices are typically used for launching DDoS
   attacks (Section 3 of [RFC8576]).  Some of the DDoS attacks like
   Slowloris and Transport Layer Security (TLS) re-negotiation can be
   detected by observing the (D)TLS profile parameters.  For example,
   the victim's server certificate need not be signed by the same
   certifying authorities trusted by the IoT device.
"
How do you make sure you can detect DDoS attacks by only observing DTLS profile 
parameters? What about Legitimate IoT device's server certificate is also 
signed by the same certifying authorities?
You may block legitimate IoT devices who did TLS re-negotiation?
4. Section 4.1 said:
"
In other words, the
   scope of middle-box acting as a (D)TLS proxy is restricted to
   Enterprise network owning and managing the IoT devices.
"
How do I make sure middle box acting as DTLS proxy is not man in the middle 
attack? Is there mutual authentication mechanism which can be used? How do I 
authenticate middle box is a trusted entity?
5. Section 4.2 said:
"
   If an IoT device is pre-configured to use
   public DNS-over-(D)TLS or DNS-over-HTTPS servers, that middle-box
   needs to act as a DNS-over-TLS or DNS-over-HTTPS proxy and replace
   the esni_keys in the ESNI record with the middle box's esni_keys.
"
Same question is applicable to the quoted text? How do I make sure middle box 
is not a man in the middle attack?

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2020年9月2日 23:06
收件人: opsawg 
主题: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

Hello, opsawg.  This draft as underwent a number of revisions based on reviews 
and presentations at the last few IETF meetings.  The authors feel they have 
addressed the issues and concerns from the WG in their latest posted -05 
revision.  As a reminder, this document describes how to use (D)TLS profile 
parameters with MUD to expose potential unauthorized software or malware on an 
endpoint.

To that end, this serves as a two-week call for adoption for this work.  Please 
reply with your support and/or comments by September 16, 2020.

Thanks.

Joe and Tianran
___
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] L3VPN BGP Threshold and BGP Session parameters (https://github.com/IETF-OPSAWG-WG/l3nm/issues/34 and https://github.com/IETF-OPSAWG-WG/l3nm/issues/35)

[Qin Wu]

Yeah, I think it makes sense to add such knob to provide fine granularity 
control. Let me know if you have proposal for this.

-Qin
发件人: Roque Gagliano (rogaglia) [mailto:rogag...@cisco.com]
发送时间: 2020年7月24日 17:07
收件人: Qin Wu ; opsawg 
主题: Re: [OPSAWG] L3VPN BGP Threshold and BGP Session parameters 
(https://github.com/IETF-OPSAWG-WG/l3nm/issues/34 and 
https://github.com/IETF-OPSAWG-WG/l3nm/issues/35)

Hi Qin,

“Regarding bgp-max-prefix, I personal feel it is different from maximum-routes 
which is applicable to all protocols while bgp max prefix is bgp specific, 
threshold and action parameters only tie with bgp maximum prefix parameter.”

I agree with your comment. Additionally, maybe a more interesting question is 
if we want to set these parameters per neighbor, per PE-node or per VPN/VRF. I 
would think that we should have then generic per VRF/PE as part of the profiles 
but having the option to overwrite per neighbor. One example is a headquarter 
vs a branch…you may not want to set the same prefix-limits to them.

Regards,
Roque


From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of Qin Wu mailto:bill...@huawei.com>>
Date: Friday, 24 July 2020 at 10:18
To: opsawg mailto:opsawg@ietf.org>>
Subject: [OPSAWG] L3VPN BGP Threshold and BGP Session parameters 
(https://github.com/IETF-OPSAWG-WG/l3nm/issues/34 and 
https://github.com/IETF-OPSAWG-WG/l3nm/issues/35)

Hi, All:
We have been discussion additional BGP parameters such as L3VPN BGP threshold 
and BGP session parameters, which is corresponding to issue ticket #34 and #35 
on L3NM model,
And would like to have the following proposed change to L3NM model to resolve 
pending issue tickets:
OLD TEXT:
“
container bgp {
  when "derived-from-or-self(../type, 'l3vpn-ntw:bgp')" {
description
  "Only applies when protocol is BGP.";
  }
  if-feature "rtg-bgp";
  leaf peer-autonomous-system {
type inet:as-number;
mandatory true;
description
  "Customer AS number in case the customer
   requests BGP routing.";
  }
  leaf local-autonomous-system {
type inet:as-number;
description
  "Local-AS overwrite.";
  }
  leaf-list address-family {
type vpn-common:address-family;
min-elements 1;
description
  "If BGP is used on this site, this node
   contains a configured value.  This node
   contains at least one address family
   to be activated.";
  }
  leaf-list neighbor {
type inet:ip-address;
description
  "IP address(es) of the BGP neighbor. An IPv4
   and IPv6 neighbors may be indicated if
   two sessions will be used for IPv4 and IPv6.";
  }
  leaf multihop {
type uint8;
description
  "Describes the number of hops allowed between
   a given BGP neighbor and the PE router.";
  }
  uses security-params;
  uses vpn-common:service-status;
  leaf description {
type string;
description
  "Includes a description of the BGP session.
   Such description is meant to be used for
   diagnosis purposes. The semantic of the description
   is local to an implementation.";
  }
”
NEW TEXT:
“
container bgp {
  when "derived-from-or-self(../type, 'l3vpn-ntw:bgp')" {
description
  "Only applies when protocol is BGP.";
  }
  if-feature "rtg-bgp";
  leaf peer-autonomous-system {
type inet:as-number;
mandatory true;
description
  "Customer AS number in case the customer
   requests BGP routing.";
  }
  leaf local-autonomous-system {
type inet:as-number;
description
  

[OPSAWG] L3VPN BGP Threshold and BGP Session parameters (https://github.com/IETF-OPSAWG-WG/l3nm/issues/34 and https://github.com/IETF-OPSAWG-WG/l3nm/issues/35)

[Qin Wu]

Hi, All:
We have been discussion additional BGP parameters such as L3VPN BGP threshold 
and BGP session parameters, which is corresponding to issue ticket #34 and #35 
on L3NM model,
And would like to have the following proposed change to L3NM model to resolve 
pending issue tickets:
OLD TEXT:
"
container bgp {
  when "derived-from-or-self(../type, 'l3vpn-ntw:bgp')" {
description
  "Only applies when protocol is BGP.";
  }
  if-feature "rtg-bgp";
  leaf peer-autonomous-system {
type inet:as-number;
mandatory true;
description
  "Customer AS number in case the customer
   requests BGP routing.";
  }
  leaf local-autonomous-system {
type inet:as-number;
description
  "Local-AS overwrite.";
  }
  leaf-list address-family {
type vpn-common:address-family;
min-elements 1;
description
  "If BGP is used on this site, this node
   contains a configured value.  This node
   contains at least one address family
   to be activated.";
  }
  leaf-list neighbor {
type inet:ip-address;
description
  "IP address(es) of the BGP neighbor. An IPv4
   and IPv6 neighbors may be indicated if
   two sessions will be used for IPv4 and IPv6.";
  }
  leaf multihop {
type uint8;
description
  "Describes the number of hops allowed between
   a given BGP neighbor and the PE router.";
  }
  uses security-params;
  uses vpn-common:service-status;
  leaf description {
type string;
description
  "Includes a description of the BGP session.
   Such description is meant to be used for
   diagnosis purposes. The semantic of the description
   is local to an implementation.";
  }
"
NEW TEXT:
"
container bgp {
  when "derived-from-or-self(../type, 'l3vpn-ntw:bgp')" {
description
  "Only applies when protocol is BGP.";
  }
  if-feature "rtg-bgp";
  leaf peer-autonomous-system {
type inet:as-number;
mandatory true;
description
  "Customer AS number in case the customer
   requests BGP routing.";
  }
  leaf local-autonomous-system {
type inet:as-number;
description
  "Local-AS overwrite.";
  }
  leaf-list address-family {
type vpn-common:address-family;
min-elements 1;
description
  "If BGP is used on this site, this node
   contains a configured value.  This node
   contains at least one address family
   to be activated.";
  }
  leaf-list neighbor {
type inet:ip-address;
description
  "IP address(es) of the BGP neighbor. An IPv4
   and IPv6 neighbors may be indicated if
   two sessions will be used for IPv4 and IPv6.";
  }
  leaf multihop {
type uint8;
description
  "Describes the number of hops allowed between
   a given BGP neighbor and the PE router.";
  }
  uses security-params;
  uses vpn-common:service-status;
  leaf description {
type string;
description
  "Includes a description of the BGP session.
   Such description is meant to be used for
   diagnosis purposes. The 

Re: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm

[Qin Wu]

Joe:
I support adoption, I think the model proposed in this draft is a good starting 
point. We need to see how this model can be extended to support various 
different flavor of L2VPN, EVPN is one of important flavor.
I also believe factoring out common model is a good approach. Reviewing the 
latest version of common VPN model, I think referencing data outside the 
grouping in any "path" statements should be avoided.

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2020年6月16日 22:18
收件人: opsawg 
主题: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm

Hello, opsawg.  I hope everyone is doing well.

This starts a two-week poll for adoption of the L2 network module document.  
There does seem to be interest in this work, and it is progressing nicely in 
GitHub with side meetings.  There appears to be questions on what will be 
broken out into commonality between this module and the L3NM (work which is 
also underway).  So while we anticipate changes to this draft, the chairs think 
it’s reached a point where we’d like to see if the WG wants to formally adopt 
the work.

Please reply on-list with your comments on the draft and whether or not you 
support its WG adoption.  We will conclude this call on June 30, 2020.

Thanks.

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

Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

[Qin Wu]

Hi, Roque and all:
Thanks for fixing the bug in your proposal. However I am still not convinced 
why upper layer OSS should care about which RD should be allocated from which 
RD-pool, if it wants to rely on the controller to allocate RD, it should 
completely delegate the task to the controller. What it only need to do is to 
create RD leaf with empty value, which provide indication to controller that 
the controller should take care of rd assignment. If troubleshooting or service 
maintenance is needed, it could be in the separate model to take care of RD 
resource lifecycle management.
In addition, I have been aware, RT auto assign also need to be fixed in L3NM 
current version. It looks this issue has been slipped out.

-Qin
发件人: Roque Gagliano (rogaglia) [mailto:rogag...@cisco.com]
发送时间: 2020年6月2日 3:14
收件人: Qin Wu ; Oscar González de Dios 
; opsawg 
主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

Hi Qin,

You are absolutely right, I made a bad copy between what I tested:

leaf rd {
  type rt-types:route-distinguisher;
}
container dynamic-assign-rd {
  presence "Auto-assign-rd";
  when "not(../rd)";
  leaf rd-pool-name {
type string;
  }
}

Regarding this point:

Should rd-pool-name be defined in L3SM, how does upper layer OSS the RD pool 
list and related names?
If rd-pool-name is introduced only for troubleshooting, should a separate NBI 
interface should be defined to expose RD pool resource to the upper layer OSS 
and maintain the binding between RD and RD pool?

[Roque] I am not very familiar with L3SM but I believe L3NM should have its own 
lifecycle and not assume that the northbound system is even using L3SM (could 
be something else). In any case, the assumption that RDs can be assigned 
dynamically was already in the original L3NM document. I only pointed out that 
a controller may need more guidance on how to perform this auto-assignment.

Remember the Original description text:
//   "Route distinguisher value. If this leaf has not been
//configured, the server will auto-assign a route
//distinguisher value and use that value operationally.
//This calculated value is available in the operational
//state. Use the empty type to indicate rd has no value
//and is not to be auto-assigned"


Please give your troubleshooting usage example to explain how the anomaly in 
the network change can be located and repaired.

[Roque] There are many reasons why people perform log analysis in the 
northbound APIs. Some related to problems but some related to auditing or 
accounting. I would be able to answer your specific question but that is 
implementation-specific.

Also in your proposed, I think RD should be defined as 
rt-types:route-distinguisher instead of empty type.

[Roque] Correct, see above (copy and paste error)

Roque

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Roque Gagliano (rogaglia)
发送时间: 2020年5月26日 17:39
收件人: Oscar González de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>;
 opsawg mailto:opsawg@ietf.org>>
主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

Hi Oscar,

Thursday was a national holiday and I was not able to participate.

I believe I did say in my previous email that there are not syntax issues with 
using the union of an empty leaf. I implemented two logics for dynamic rd, one 
using the current draft construct and one using a different construct with a 
presence container (to avoid an extra leaf). The reason for a container is that 
I believe we are also missing to say something about the pool from where the RD 
should be chosen as there could be more than one pool in a network. So, we will 
need additional leafs anyhow:

leaf rd {
  type empty;
}
container dynamic-assign-rd {
  presence "Aut-assign-rd";
  when "not(../rd)";
  leaf rd-pool-name {
type string;
  }
}

Now, let’s put owerselves on the shoes of a person troubleshooting some 
provisioning problems of validating a posible network change, Which of these 
two payloads are clearer to know that a dynamic RD should be used?


1) Implicit using current draft:



{

  "data": {

"ietf-l3vpn-ntw:l3vpn-ntw": {

  "vpn-services": {

"vpn-service": [

  {

"vpn-id": "650087400",

"ie-profiles": {

  "ie-profile": [

{

  "ie-profile-id": "ie_00”

}

  ]

}

  }

]

  }

}

  }

}

2)  Using Explicit mentioned with a presence container and specifying the 
name of the pool:


{

  "data": {

"ietf-l3vpn-ntw:l3vpn-ntw": {

  "vpn-services": {

"vpn-service": [

  {

Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

[Qin Wu]

Good, thank for clarification.

-Qin
发件人: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
发送时间: 2020年6月4日 15:31
收件人: Qin Wu ; Joe Clarke (jclarke) 
; SAMIER BARGUIL GIRALDO 

抄送: OPSAWG@ietf.org
主题: RE: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

Hi Qin,

I cited ietf-packet-fields as an example if a common module with groupings. 
Apologies for the confusion.

As you know, we already import ietf-packet-fields and reuse it as much we can 
in the l3nm current version. We don’t plan to change that.

Cheers,
Med

De : Qin Wu [mailto:bill...@huawei.com]
Envoyé : jeudi 4 juin 2020 09:24
À : BOUCADAIR Mohamed TGI/OLN; Joe Clarke (jclarke); SAMIER BARGUIL GIRALDO
Cc : OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
Objet : RE: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

Common features, yes, factoring out some reusable groupings from other 
documents, I am not sure 100% sure, there is some gray area, e.g., 
ietf-packet-fields has already been defined in RFC8519, it is separated 
document, when needed, why not just import and reuse it.
发件人: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
[mailto:mohamed.boucad...@orange.com]
发送时间: 2020年6月4日 13:42
收件人: Qin Wu mailto:bill...@huawei.com>>; Joe Clarke 
(jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 SAMIER BARGUIL GIRALDO 
mailto:samier.barguilgiraldo@telefonica.com>>
抄送: OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
主题: RE: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

Hi Qin, all,

The idea is to have a common module listing items that can be reused by other 
VPN modules than L3NM. This “common” module does not have to be called “common 
types”.

As such, it is OK to have reusable groupings (e.g., ietf-packet-fields in 
RFC8519) or even common features (e.g., ietf-softwire-common in RFC8676).

Cheers,
Med

De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de Qin Wu
Envoyé : jeudi 4 juin 2020 06:09
À : Joe Clarke (jclarke); SAMIER BARGUIL GIRALDO
Cc : OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
Objet : Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2020年6月4日 0:16
收件人: SAMIER BARGUIL GIRALDO 
mailto:samier.barguilgiraldo@telefonica.com>>
抄送: OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)


The module is available in the following PULL REQUEST: 
https://github.com/IETF-OPSAWG-WG/l3nm/pull/118

I know other *types module have included groupings, but to add groupings in a 
types module seems wrong to me.  I would just expect typedefs and identities.

[Qin]: We lack a good usage guidance on which kind of groupings should be 
included in types module,
section 4.3 of RFC8407 said:
“
4.13<https://tools.ietf.org/html/rfc8407#section-4.13>.  Reusable Groupings

   A reusable grouping is a YANG grouping that can be imported by
   another module and is intended for use by other modules.
”
But it didn’t tell us whether the reusable grouping should be in the separate 
module or in the same type modules as identity and typedef.
Following some published type module examples,e.g.,RFC8294 and 
draft-ietf-teas-yang-te-types-13 in the RFC queue, it did add some of reusable 
grouping in the type modules, my impression is grouping that contain newly 
defined typedef and identities can be added into type modules, grouping in 
grouping, we need to be very carefully,
There are some guidance on reusable grouping in section 4.3 of RFC8407
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

[Qin Wu]

And on that topic, your operational-type is used for both admin and oper 
status.  It seems to me that admin status would either be up or down (or maybe 
something like testing such as in the ietf-interfaces module).  The oper-status 
may be richer.

And in your grouping for service-status, you have a timestamp tied to admin 
that should indicate the _actual_ date and time of the service being up or 
down.  This won’t necessarily be the case for an admin status.

[Qin]: Agree with Joe, two points to add here:

1.   why tie timestamp with both admin and oper status, why not define 
additional leaf for timestamp within service-status container?

2.   since operational-type is used for both admin and oper status, I think 
operation-type could be extended to support additional function, such as 
testing.

In addition, I would two additional typedefs



typedef oper-status {

type operational-type;

description

"Defines a type representing the operational status of

a vpn service.";

}

typedef admin-status {

type operational-type;

description

"Defines a type representing the administrative status of

a vpn service.";
}

Joe

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

Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

[Qin Wu]

Common features, yes, factoring out some reusable groupings from other 
documents, I am not sure 100% sure, there is some gray area, e.g., 
ietf-packet-fields has already been defined in RFC8519, it is separated 
document, when needed, why not just import and reuse it.
发件人: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
发送时间: 2020年6月4日 13:42
收件人: Qin Wu ; Joe Clarke (jclarke) 
; SAMIER BARGUIL GIRALDO 

抄送: OPSAWG@ietf.org
主题: RE: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

Hi Qin, all,

The idea is to have a common module listing items that can be reused by other 
VPN modules than L3NM. This “common” module does not have to be called “common 
types”.

As such, it is OK to have reusable groupings (e.g., ietf-packet-fields in 
RFC8519) or even common features (e.g., ietf-softwire-common in RFC8676).

Cheers,
Med

De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de Qin Wu
Envoyé : jeudi 4 juin 2020 06:09
À : Joe Clarke (jclarke); SAMIER BARGUIL GIRALDO
Cc : OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
Objet : Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2020年6月4日 0:16
收件人: SAMIER BARGUIL GIRALDO 
mailto:samier.barguilgiraldo@telefonica.com>>
抄送: OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)


The module is available in the following PULL REQUEST: 
https://github.com/IETF-OPSAWG-WG/l3nm/pull/118

I know other *types module have included groupings, but to add groupings in a 
types module seems wrong to me.  I would just expect typedefs and identities.

[Qin]: We lack a good usage guidance on which kind of groupings should be 
included in types module,
section 4.3 of RFC8407 said:
“
4.13<https://tools.ietf.org/html/rfc8407#section-4.13>.  Reusable Groupings

   A reusable grouping is a YANG grouping that can be imported by
   another module and is intended for use by other modules.
”
But it didn’t tell us whether the reusable grouping should be in the separate 
module or in the same type modules as identity and typedef.
Following some published type module examples,e.g.,RFC8294 and 
draft-ietf-teas-yang-te-types-13 in the RFC queue, it did add some of reusable 
grouping in the type modules, my impression is grouping that contain newly 
defined typedef and identities can be added into type modules, grouping in 
grouping, we need to be very carefully,
There are some guidance on reusable grouping in section 4.3 of RFC8407
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

[Qin Wu]

Hi, Haomian:
The idea here is to factor out common pieces of L3NM and L2NM if my 
understanding is correct, these common pieces could be reused by other future 
modules, so I am not sure your assumption on 10 out of 100 is correct.
In any case, I would suggest to reuse types in the existing published types 
modules as much as possible, make sure we will not reinvent any new wheels that 
have been defined somewhere else.

-Qin
发件人: Zhenghaomian
发送时间: 2020年6月4日 14:16
收件人: Qin Wu ; Joe Clarke (jclarke) 
; SAMIER BARGUIL GIRALDO 

抄送: OPSAWG@ietf.org
主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

Hi, Joe, Qin,

The groupings in the types is understood to be used in multiple other modules. 
Considering about the potential ‘uses’ in other models, it may not be a matter 
for putting in a same type YANG or separate one.

A more challenging issue is to have a ‘right-fit’ types. If a types contain 100 
typedef and identities, sometimes we will be in the dilemma whether we should 
import it as we may only use no more than 10 in it. In such case re-definition 
seems to be a waste but importation would be too much weight. It can be even 
worse if we start a new one, then redefine some of them and add more for 
extension.

Thoughts?

Best wishes,
Haomian

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Qin Wu
发送时间: 2020年6月4日 12:09
收件人: Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 SAMIER BARGUIL GIRALDO 
mailto:samier.barguilgiraldo@telefonica.com>>
抄送: OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2020年6月4日 0:16
收件人: SAMIER BARGUIL GIRALDO 
mailto:samier.barguilgiraldo@telefonica.com>>
抄送: OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)


The module is available in the following PULL REQUEST: 
https://github.com/IETF-OPSAWG-WG/l3nm/pull/118

I know other *types module have included groupings, but to add groupings in a 
types module seems wrong to me.  I would just expect typedefs and identities.

[Qin]: We lack a good usage guidance on which kind of groupings should be 
included in types module,
section 4.3 of RFC8407 said:
“
4.13<https://tools.ietf.org/html/rfc8407#section-4.13>.  Reusable Groupings

   A reusable grouping is a YANG grouping that can be imported by
   another module and is intended for use by other modules.
”
But it didn’t tell us whether the reusable grouping should be in the separate 
module or in the same type modules as identity and typedef.
Following some published type module examples,e.g.,RFC8294 and 
draft-ietf-teas-yang-te-types-13 in the RFC queue, it did add some of reusable 
grouping in the type modules, my impression is grouping that contain newly 
defined typedef and identities can be added into type modules, grouping in 
grouping, we need to be very carefully,
There are some guidance on reusable grouping in section 4.3 of RFC8407
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

[Qin Wu]

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2020年6月4日 0:16
收件人: SAMIER BARGUIL GIRALDO 
抄送: OPSAWG@ietf.org
主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)


The module is available in the following PULL REQUEST: 
https://github.com/IETF-OPSAWG-WG/l3nm/pull/118

I know other *types module have included groupings, but to add groupings in a 
types module seems wrong to me.  I would just expect typedefs and identities.

[Qin]: We lack a good usage guidance on which kind of groupings should be 
included in types module,
section 4.3 of RFC8407 said:
“
4.13.  Reusable Groupings

   A reusable grouping is a YANG grouping that can be imported by
   another module and is intended for use by other modules.
”
But it didn’t tell us whether the reusable grouping should be in the separate 
module or in the same type modules as identity and typedef.
Following some published type module examples,e.g.,RFC8294 and 
draft-ietf-teas-yang-te-types-13 in the RFC queue, it did add some of reusable 
grouping in the type modules, my impression is grouping that contain newly 
defined typedef and identities can be added into type modules, grouping in 
grouping, we need to be very carefully,
There are some guidance on reusable grouping in section 4.3 of RFC8407
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

[Qin Wu]

Hi, Roque:
Should rd-pool-name be defined in L3SM, how does upper layer OSS the RD pool 
list and related names?
If rd-pool-name is introduced only for troubleshooting, should a separate NBI 
interface should be defined to expose RD pool resource to the upper layer OSS 
and maintain the binding between RD and RD pool?
Please give your troubleshooting usage example to explain how the anomaly in 
the network change can be located and repaired.
Also in your proposed, I think RD should be defined as 
rt-types:route-distinguisher instead of empty type.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Roque Gagliano (rogaglia)
发送时间: 2020年5月26日 17:39
收件人: Oscar González de Dios ; opsawg 

主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

Hi Oscar,

Thursday was a national holiday and I was not able to participate.

I believe I did say in my previous email that there are not syntax issues with 
using the union of an empty leaf. I implemented two logics for dynamic rd, one 
using the current draft construct and one using a different construct with a 
presence container (to avoid an extra leaf). The reason for a container is that 
I believe we are also missing to say something about the pool from where the RD 
should be chosen as there could be more than one pool in a network. So, we will 
need additional leafs anyhow:

leaf rd {
  type empty;
}
container dynamic-assign-rd {
  presence "Aut-assign-rd";
  when "not(../rd)";
  leaf rd-pool-name {
type string;
  }
}

Now, let’s put owerselves on the shoes of a person troubleshooting some 
provisioning problems of validating a posible network change, Which of these 
two payloads are clearer to know that a dynamic RD should be used?


1) Implicit using current draft:



{

  "data": {

"ietf-l3vpn-ntw:l3vpn-ntw": {

  "vpn-services": {

"vpn-service": [

  {

"vpn-id": "650087400",

"ie-profiles": {

  "ie-profile": [

{

  "ie-profile-id": "ie_00”

}

  ]

}

  }

]

  }

}

  }

}

2)   Using Explicit mentioned with a presence container and specifying the 
name of the pool:


{

  "data": {

"ietf-l3vpn-ntw:l3vpn-ntw": {

  "vpn-services": {

"vpn-service": [

  {

"vpn-id": "650087400",

"ie-profiles": {

  "ie-profile": [

{

  "ie-profile-id": "ie_00",

  "dynamic-assign-rd": {

"rd-pool-name": "metro1_rd_pool"

  }

}

  ]

}

  }

]

  }

}

  }

}



Regards,
Roque


From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of Oscar González de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>
Date: Thursday, 21 May 2020 at 16:27
To: opsawg mailto:opsawg@ietf.org>>
Subject: [OPSAWG] Minutes of L3NM/L2NM module discussions

Dear OPSAWG colleagues,

Thanks for participating in the call today. Please find bellow 
the minutes:

L3NM and L2NM module discussions
* Date: 21-May-2020

Participants
- Oscar Gonzalez de Dios (Telefonica)
- Samier Barguil (Telefonica)
- Anton Snizar (Sedona)
- Daniel King (Old Dog Consulting)
- Adrian Farrel (Old Dog Consulting)
- Qin Wu (Huawei)
- Sergio Belotti ()
- Sriram Krishnamurthy (Nokia)
- Italo Busi (Huawei)

1. Agenda:
- Revision of the L3NM Github issues 
(https://github.com/IETF-OPSAWG-WG/l3nm/issues)

2. L3NM
Revision of the three main issues:
Implementation Report by Cisco. It has two main issues 
(https://github.com/IETF-OPSAWG-WG/l3nm/issues/110)
- Common module to have all the L3NM specific requirements. Type-like module.
[Anton]: It makes implementation simpler. Does not generate unnecessary 
dependencies
[Adrian]: It depends on if we need module for specific types, to avoid 
unnecessary imports. Also don't you only need to import types, not the entire 
module?
[Qin]: With L3SM we did not take an augmentation approach. If there are common 
types defined in both models, then we may need to find the common components. 
We should decouple of L3SM.
[Sriram]: Prefer to have a separate type-file for the specific parameters.
[Oscar]: Define a common type-file for the service models.
[Qin]: Is it possible to manage it as an independent draft?

[Oscar in github issues]: After the discussions, it seems reasonable to have a 
separate Yang module to contain the types. The suggestion is to write the 
module to cover the four service models (client service models, l3sm, l2sm and 
Network service models, l2nm, l3nm). It seems re

Re: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03

[Qin Wu]

Speak as author of this document, support for publication.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2020年6月1日 10:25
收件人: opsawg@ietf.org
抄送: OpsAWG-Chairs 
主题: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation-framework-03


Hi WG,



The authors requested the WG last call. And we think this draft is mature and 
stable. We start a two week last call for this draft.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/



Please send your comments stating whether you believe the document is ready for 
publication.

If not, please explain why not and provide comments to improve this document.



Thanks,

Tianran and Joe

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

Re: [OPSAWG] IPR poll for draft-ietf-opsawg-model-automation-framework-03

[Qin Wu]

I’m not aware of any IPR that applies to this draft.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2020年6月1日 10:37
收件人: opsawg@ietf.org
抄送: OpsAWG-Chairs 
主题: [OPSAWG] IPR poll for draft-ietf-opsawg-model-automation-framework-03


Working Group, Authors,



As a part of the WGLC, this email starts the IPR poll.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/



Are you aware of any IPR that applies to 
draft-ietf-opsawg-model-automation-framework-03?



There are currently no IPR disclosure.



If you are listed as a document author or contributor please respond to this 
email regardless of whether or not you are aware of any relevant IPR.



If you are on the OPSA WG email list but are not listed as an author or 
contributor, then please explicitly respond only if you are aware of any IPR 
that has not yet been disclosed in conformance with IETF rules.


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

Re: [OPSAWG] L2NM: Layer 2 VPN Network Model: Request for Feedback and Review

[Qin Wu]

+1，support it.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 mohamed.boucad...@orange.com
发送时间: 2020年4月2日 20:41
收件人: Oscar González de Dios ; 
opsawg@ietf.org
主题: Re: [OPSAWG] L2NM: Layer 2 VPN Network Model: Request for Feedback and 
Review

Hi Oscar,

I agree this is an important piece of work. I will send you a PR.

Cheers,
Med

De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de Oscar González de 
Dios
Envoyé : jeudi 2 avril 2020 14:23
À : opsawg@ietf.org
Objet : [OPSAWG] L2NM: Layer 2 VPN Network Model: Request for Feedback and 
Review

Dear Opsawg colleagues,

In the line of the success of the L3NM, and also receiving request in the 
mailing list for a similar work for L2VPNs, we have prepared a new document, 
which will also be presented in the next OPSAWG virtual meeting, called  A 
Layer 2 VPN Network Yang Model draft-barguil-opsawg-l2sm-l2nm-01. You can find 
it in:

https://tools.ietf.org/html/draft-barguil-opsawg-l2sm-l2nm-01

The document defines a Yang Data model, L2NM, that can be used to manage the 
provisioning of Layer 2 VPN services in a Service Provider Network.  The Yang 
module defined in the document provides representation of the Layer 2 VPN 
Service and is aimed at being used  by a Network Controller, which can derive 
from it the configuration  information that will be sent to the network 
devices, as well as selecting a preference on the underlay transport network in 
a service provider environment.

We would like to request the OPSA Working Group colleagues for feedback and 
review of the document. We would also like to know if you consider this piece 
of work helpful in automating and programming the networks.

Best Regards and stay safe during the time that a small piece of ARN is ruling 
our lifes,

Oscar




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

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

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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-model-automation-framework-01.txt

[Qin Wu]

v-01 is posted to address issues raised in last IETF meeting.
The diff is:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-model-automation-framework-01

-Qin
-邮件原件-
发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2020年2月26日 20:52
收件人: i-d-annou...@ietf.org
抄送: opsawg@ietf.org
主题: I-D Action: draft-ietf-opsawg-model-automation-framework-01.txt


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

Title   : A Framework for Automating Service and Network 
Management with YANG
Authors : Qin Wu
  Mohamed Boucadair
  Diego R. Lopez
  Chongfeng Xie
  Liang Geng
Filename: draft-ietf-opsawg-model-automation-framework-01.txt
Pages   : 37
Date: 2020-02-26

Abstract:
   Data models for service and network management provides a
   programmatic approach for representing (virtual) services or networks
   and deriving (1) configuration information that will be communicated
   to network and service components that are used to build and deliver
   the service and (2) state information that will be monitored and
   tracked.  Indeed, data models can be used during various phases of
   the service and network management life cycle, such as service
   instantiation, service provisioning, optimization, monitoring,
   diagnostic, and assurance.  Also, data models are instrumental in the
   automation of network management.  They also provide closed-loop
   control for the sake of adaptive and deterministic service creation,
   delivery, and maintenance.

   This document describes an architecture for service and network
   management automation that takes advantage of YANG modeling
   technologies.  This architecture is drawn from a network provider
   perspective irrespective of the origin of a data module; it can thus
   accommodate even modules that are developed outside the IETF.

   The document aims in particular to exemplify an approach that
   specifies the journey from technology-agnostic services to
   technology-specific actions.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-model-automation-framework-01
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-model-automation-framework-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-model-automation-framework-01


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

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


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or 
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] IETF 106 Discussion about draft-gray-sampled-streaming - room moved

[Qin Wu]

Becos it is running out of time in the session, I haven't got time to comment 
on this, Good topic, there are two relevant drafts that are proposed recently 
in netmod, netconf, which focus on self describing data format and 
advertisement mechanism.
https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags-00
https://tools.ietf.org/html/draft-tao-netconf-notif-node-tag-capabilities-00
Feel free to comment on it.

-Qin
-邮件原件-
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Gray, Andrew A
发送时间: 2019年11月20日 12:11
收件人: opsawg@ietf.org
主题: [OPSAWG] IETF 106 Discussion about draft-gray-sampled-streaming - room moved

After a couple bits of feedback, I have moved the session to be in the Padang 
room at 9:00am to avoid conflict with the morning session.

On 11/20/19, 11:59 AM, "OPSAWG on behalf of Gray, Andrew A" 
 wrote:

Following the presentation of 
https://datatracker.ietf.org/doc/draft-gray-sampled-streaming/ during the 
session, questions and comments were cut off due to time, and there was the 
suggestion to make a separate session for ongoing conversation.

I reserved the Butterworth room on Thursday at 10am for this, and am very 
interested in hearing from people on this draft.

Thanks


E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely 
for the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.


E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.
___
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] IETF YANG Side meeting on YANG Use Cases

[Qin Wu]

Hi, Folks:
Continuing the last IETF side meeting on Next step of IETF YANG (which is not 
targeted YANG modeling language discussion), we would like to have another YANG 
side meeting (https://trac.ietf.org/trac/ietf/meeting/wiki/106sidemeetings) to 
investigate on some use cases to see how IETF YANG model interact with other 
model or Mechanisms. How IETF YANG are put together to deliver service.
The meeting time is: Wednesday afternoon 4:30~5:30
The meeting room is : Bras Basah
Feel free to join the discussion. Thanks!
-Qin Wu
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] conclusion//RE: WG adoption call for draft-wu-model-driven-management-virtualization-07

[Qin Wu]

Tom:
-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com] 
发送时间: 2019年11月14日 0:38
收件人: Qin Wu ; Brian E Carpenter 
; Tianran Zhou ; 
opsawg@ietf.org
抄送: draft-wu-model-driven-management-virtualization.auth...@ietf.org; 
opsawg-cha...@ietf.org
主题: Re: [OPSAWG] conclusion//RE: WG adoption call for 
draft-wu-model-driven-management-virtualization-07

- Original Message -
From: "Qin Wu" 
Sent: Wednesday, November 13, 2019 2:59 AM
> How about draft-ietf-opsawg-model-automation-framework if we agree to
change the name?:-)

Mutter mutter... As I said, I see it as an identifier, nothing more, not to be 
laden with semantic meaning as the filename will disappear into the dust of 
history.  As Brian says, it is rather long but then I never have to type it in. 
 It does spill off the side of the screen but that only becomes a problem when 
we have
draft-wu-model-driven-management-visualization-00 or something like that.

The Title in the I-D/RFC lasts for ever so that is the one that I think 
deserves attention; here, that Title is quite different and I think it is fine.

As to draft-author becoming draft-ietf, there was a comment recently by the PCE 
AD(Deborah Brungard) that a particular draft had to be named draft-ietf because 
the data-tracker relies on that; else the processes fail.  Reading between the 
lines, I was thnking that our ever more clever data-tracker might be relying on 
draft-author-wg-anyold becoming draft-ietf-wg-anyold for its processes to 
succeed although I know of no recent evidence for that.  But then I am forever 
being surprised by what the data-tracker gets up to - it seems to quite outside 
the control of the IAD, IESG, IETF, ...

[Qin]: I think this is responsibility of WG chairs to make sure 
draft-author-wg-anyold and draft-ietf-wg-anyold in the WG process, it might be 
a good idea to add history of draft-ietf-wg-anyold in the shepherd writeup 
before it is moved to the hand of AD.
I have experience that when draft-author-wg1-anyold is moved to wg 2 and 
changed the name to draft-author-wg2-anyold, but chair is not willing to 
establish the link between draft-author-wg1-anyold and draft-author-wg2-anyold, 
this may lead to the problem to track
the old history of the document.
If the link button can be controlled by the responsible chair or author of the 
draft is given the flexibility to make the link between drafts, this problem 
can be easily solved.

Historically, there have been problems with name changes because the WG Chairs 
had manually to make a link and they did not know that they should.  I think 
that this came up at IESG Review when ADs could not look back at earlier 
versions of the I-D because the link between draft-author-wgname-oldname and 
draft-ietf-wgname-differentname was missing and only those who had been around 
the WG in question some years earlier knew of the connection..

[Qin]:Understand, maybe it is a good idea to provide guideline on how to name 
the draft and how to link the draft, who is responsible for this.
Tom Petch

> -Qin
> -邮件原件-
> 发件人: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> 发送时间: 2019年11月13日 9:56
> 收件人: Tianran Zhou ; Qin Wu
; tom petch ; opsawg@ietf.org
> 抄送: draft-wu-model-driven-management-virtualization.auth...@ietf.org;
opsawg-cha...@ietf.org
> 主题: Re: [OPSAWG] conclusion//RE: WG adoption call for
draft-wu-model-driven-management-virtualization-07
>
> Actually there are no 100% rules but the tools work better if you
stick to draft-ietf-opsawg-something-00, and use the "Replaces" option when 
submitting the draft.
>
> "something" is really a matter of choice. However,
> draft-ietf-opsawg-model-driven-management-automation-00 is very very
long.
>
> Regards
>Brian
>
> On 13-Nov-19 14:34, Tianran Zhou wrote:
> > Hi Tom and Qin,
> >
> > Anyway we need to change the name. As the author agreed the proposed
naming is better, IMHO, I do not see the workload.
> > Or is there any rule that not suggest to do so?
> >
> > Tianran
> >> -Original Message-
> >> From: Qin Wu
> >> Sent: Wednesday, November 13, 2019 9:07 AM
> >> To: tom petch ; Tianran Zhou 
> >> ; opsawg@ietf.org
> >> Cc:
draft-wu-model-driven-management-virtualization.auth...@ietf.org;
> >> opsawg-cha...@ietf.org
> >> Subject: RE: [OPSAWG] conclusion//RE: WG adoption call for
> >> draft-wu-model-driven-management-virtualization-07
> >>
> >> Hi, Tom and Tianran:
> >> It looks the new proposed draft name more reflects what it is, but 
> >> referencing to IETF standards process, the draft name change rule
is
> >> nothing more than one mentioned by Tom.
> >> I knew in the history, there was some exception about draft name 
> >> changes, e.g., change draft-fielding-http-spec-01 into 
&g

Re: [OPSAWG] conclusion//RE: WG adoption call for draft-wu-model-driven-management-virtualization-07

[Qin Wu]

How about draft-ietf-opsawg-model-automation-framework if we agree to change 
the name?:-)

-Qin
-邮件原件-
发件人: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] 
发送时间: 2019年11月13日 9:56
收件人: Tianran Zhou ; Qin Wu ; tom 
petch ; opsawg@ietf.org
抄送: draft-wu-model-driven-management-virtualization.auth...@ietf.org; 
opsawg-cha...@ietf.org
主题: Re: [OPSAWG] conclusion//RE: WG adoption call for 
draft-wu-model-driven-management-virtualization-07

Actually there are no 100% rules but the tools work better if you stick to 
draft-ietf-opsawg-something-00, and use the "Replaces" option when submitting 
the draft.

"something" is really a matter of choice. However,
draft-ietf-opsawg-model-driven-management-automation-00 is very very long.

Regards
   Brian

On 13-Nov-19 14:34, Tianran Zhou wrote:
> Hi Tom and Qin,
> 
> Anyway we need to change the name. As the author agreed the proposed naming 
> is better, IMHO, I do not see the workload.
> Or is there any rule that not suggest to do so?
> 
> Tianran
>> -Original Message-
>> From: Qin Wu
>> Sent: Wednesday, November 13, 2019 9:07 AM
>> To: tom petch ; Tianran Zhou 
>> ; opsawg@ietf.org
>> Cc: draft-wu-model-driven-management-virtualization.auth...@ietf.org;
>> opsawg-cha...@ietf.org
>> Subject: RE: [OPSAWG] conclusion//RE: WG adoption call for
>> draft-wu-model-driven-management-virtualization-07
>>
>> Hi, Tom and Tianran:
>> It looks the new proposed draft name more reflects what it is, but 
>> referencing to IETF standards process, the draft name change rule is 
>> nothing more than one mentioned by Tom.
>> I knew in the history, there was some exception about draft name 
>> changes, e.g., change draft-fielding-http-spec-01 into 
>> draft-ietf-http-v10-spec, using "replace" button to link them 
>> together  and published as RFC1945, but it is the rare thing that seldom 
>> happens.
>> Therefore I have no strong preference on what WG draft name should be 
>> changed.
>> Thanks!
>>
>> -Qin
>> -邮件原件-
>> 发件人: tom petch [mailto:ie...@btconnect.com]
>> 发送时间: 2019年11月12日 18:02
>> 收件人: Tianran Zhou ; opsawg@ietf.org
>> 抄送: draft-wu-model-driven-management-virtualization.auth...@ietf.org;
>> opsawg-cha...@ietf.org
>> 主题: Re: [OPSAWG] conclusion//RE: WG adoption call for
>> draft-wu-model-driven-management-virtualization-07
>>
>> - Original Message -
>> From: "Tianran Zhou" 
>> Sent: Tuesday, November 12, 2019 6:10 AM
>>
>>> Hi WG,
>>>
>>> Now we conclude the poll and adopt this document as WG draft.
>>> We collected many interests and supports that can help the document
>> evolution.
>>>
>>> Authors,
>>> The chairs think "virtualization" in the draft name is confusing, 
>>> and
>> suggest to rename it as "model-driven-management-automation". What's 
>> your thoughts?
>>> Please republish draft-wu-model-driven-management-virtualization-07 
>>> as
>> draft-ietf-model-driven-management-automation-00 with only the date 
>> and file name changed. And please use "replace" in the data tracker.
>>
>>
>> Tianran
>>
>> I think that that is a bad idea.  Who cares what the draft name is?
>> What is needed is a stable handle for it as it wends its way through 
>> the IETF after which the draft name vanishes in the dust of history.  
>> The only expected change is from draft-authername to draft-ietf at the time 
>> of adoption.
>> Anything else just increases the workload, if only a fraction, for 
>> everyone involved.
>>
>> Tom Petch
>>
>>
>>> Cheers,
>>> Tianran & Joe
>>>
>>>> -Original Message-
>>>> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran
>> Zhou
>>>> Sent: Tuesday, October 29, 2019 9:44 AM
>>>> To: opsawg@ietf.org
>>>> Cc:
>> draft-wu-model-driven-management-virtualization.auth...@ietf.org;
>>>> opsawg-cha...@ietf.org
>>>> Subject: [OPSAWG] WG adoption call for
>>>> draft-wu-model-driven-management-virtualization-07
>>>>
>>>> Hi WG,
>>>>
>>>> This email starts a 2 weeks working group adoption call for 
>>>> draft-wu-model-driven-management-virtualization-07.
>>>>
>> https://datatracker.ietf.org/doc/draft-wu-model-driven-management-vir
>> tua
>>>> lization/
>>>> This document provides a framework that describes and discusses an 
>>>> architect

Re: [OPSAWG] conclusion//RE: WG adoption call for draft-wu-model-driven-management-virtualization-07

[Qin Wu]

Hi, Tom and Tianran:
It looks the new proposed draft name more reflects what it is, but referencing 
to IETF standards process, the draft name change rule is nothing more than one 
mentioned by Tom.
I knew in the history, there was some exception about draft name changes, e.g., 
change draft-fielding-http-spec-01 into draft-ietf-http-v10-spec, using 
"replace" button to link them together  and published as RFC1945, but it is the 
rare thing that seldom happens.
Therefore I have no strong preference on what WG draft name should be changed. 
Thanks!

-Qin
-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com] 
发送时间: 2019年11月12日 18:02
收件人: Tianran Zhou ; opsawg@ietf.org
抄送: draft-wu-model-driven-management-virtualization.auth...@ietf.org; 
opsawg-cha...@ietf.org
主题: Re: [OPSAWG] conclusion//RE: WG adoption call for 
draft-wu-model-driven-management-virtualization-07

- Original Message -
From: "Tianran Zhou" 
Sent: Tuesday, November 12, 2019 6:10 AM

> Hi WG,
>
> Now we conclude the poll and adopt this document as WG draft.
> We collected many interests and supports that can help the document
evolution.
>
> Authors,
> The chairs think "virtualization" in the draft name is confusing, and
suggest to rename it as "model-driven-management-automation". What's your 
thoughts?
> Please republish draft-wu-model-driven-management-virtualization-07 as
draft-ietf-model-driven-management-automation-00 with only the date and file 
name changed. And please use "replace" in the data tracker.


Tianran

I think that that is a bad idea.  Who cares what the draft name is?
What is needed is a stable handle for it as it wends its way through the IETF 
after which the draft name vanishes in the dust of history.  The only expected 
change is from draft-authername to draft-ietf at the time of adoption.  
Anything else just increases the workload, if only a fraction, for everyone 
involved.

Tom Petch


> Cheers,
> Tianran & Joe
>
> > -Original Message-
> > From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran
Zhou
> > Sent: Tuesday, October 29, 2019 9:44 AM
> > To: opsawg@ietf.org
> > Cc:
draft-wu-model-driven-management-virtualization.auth...@ietf.org;
> > opsawg-cha...@ietf.org
> > Subject: [OPSAWG] WG adoption call for
> > draft-wu-model-driven-management-virtualization-07
> >
> > Hi WG,
> >
> > This email starts a 2 weeks working group adoption call for 
> > draft-wu-model-driven-management-virtualization-07.
> >
https://datatracker.ietf.org/doc/draft-wu-model-driven-management-virtua
> > lization/
> > This document provides a framework that describes and discusses an 
> > architecture for service and network management automation that
takes
> > advantage of YANG modeling technologies.
> >
> > If you support adopting this document please say so, and please give
an
> > indication of why you think it is important. Also please say if you
will be
> > willing to review and help the draft.
> > If you do not support adopting this document as a starting point for
work
> > on this topic, please say why.
> > This poll will run until Nov 11.
> >
> > Thanks,
> > Tianran and Joe
> >
> > ___
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

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

Re: [OPSAWG] WG adoption call for draft-wu-model-driven-management-virtualization-07

[Qin Wu]

-邮件原件-
发件人: Joe Clarke (jclarke) [mailto:jcla...@cisco.com] 
发送时间: 2019年10月31日 1:11
收件人: Tianran Zhou 
抄送: opsawg@ietf.org; opsawg-cha...@ietf.org; 
draft-wu-model-driven-management-virtualization.auth...@ietf.org
主题: Re: WG adoption call for draft-wu-model-driven-management-virtualization-07

> On Oct 28, 2019, at 21:43, Tianran Zhou  wrote:
> 
> Hi WG,
> 
> This email starts a 2 weeks working group adoption call for 
> draft-wu-model-driven-management-virtualization-07.
> https://datatracker.ietf.org/doc/draft-wu-model-driven-management-virt
> ualization/ This document provides a framework that describes and 
> discusses an architecture for service and network management automation that 
> takes advantage of YANG modeling technologies.
> 
> If you support adopting this document please say so, and please give an 
> indication of why you think it is important. Also please say if you will be 
> willing to review and help the draft.
> If you do not support adopting this document as a starting point for work on 
> this topic, please say why.
> This poll will run until Nov 11.

As an individual, I support adoption.  I had some private comments for the 
authors on the latest revision that I will share here because I think they are 
critical to the adoption call.  I realize some of these may have been corrected 
in an upcoming rev.
[Qin]: Thanks Joe, most of your comments have been addressed in v-07. Figure 1 
in section 3.1 needs to be fall back to v-06, thanks Med for good catch.
* I found some of the text meandering and confusing.  The intro, for example, 
laid out a challenge around telemetry consumption, but this doc doesn’t really 
address the scale issue.
[Qin]:Fixed.
* Section 4.2.3 also crosses from a pure model discussion to something more 
NETCONF protocol-specific in directly mentioning  (and without 
reference).  I agree operational state is important, but this mention seems out 
of place.
[Qin]:Fixed in v-07.
* I’d also like to see your examples go through the entire lifecycle, or at 
least more so than they do.  For example, getting to fault diagnosis would be 
helpful since Section 4.2.4 doesn’t really give much content there.
[Qin]:Improved, thanks.
Joe

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

Re: [OPSAWG] WG adoption call for draft-wu-model-driven-management-virtualization-07

[Qin Wu]

Thanks Aijun. One size can not fit all, similarly one model can not fit all. In 
multi-layer, multi-domain scenario, you do need network layer model to 
establish the mapping between service request and underlying network resource.
In addition, network topology model and TE tunnel are also seen as network 
layer model which provide play key role when scheduling resource to meet the 
service requirements.

Regarding how these models are interleaved together, this is what we have 
clarified in section 3.1 and 4.3. and section 4.4, I.e., using policy model, 
schema mount model for same level model interleaving, using service mapping, 
service translation for different layer model interleaving. We can add more 
text to increase the clarity on the point you raised, thanks.

-Qin
-邮件原件-
发件人: Aijun Wang [mailto:wangai...@tsinghua.org.cn] 
发送时间: 2019年11月7日 14:22
收件人: Tianran Zhou ; opsawg@ietf.org
抄送: draft-wu-model-driven-management-virtualization.auth...@ietf.org; 
opsawg-cha...@ietf.org
主题: 答复: [OPSAWG] WG adoption call for 
draft-wu-model-driven-management-virtualization-07

Support the adoption.

This draft give the overall view for the different layers of Yang modules that 
defined within IETF(also applicable for Yang defined by other STD).
What I wondering is the that necessaries of the network layer model. More 
layers means more conversions between different layers, increased complex for 
the service automation management system and the relationship management 
between these models. 
Is there any way or mechanism to manage these interleaved modules in more 
automatic manners?

Can the above concerns be described in the updated version after its adoption?


Best Regards.

Aijun Wang
China Telecom


-邮件原件-
发件人: opsawg-boun...@ietf.org [mailto:opsawg-boun...@ietf.org] 代表
Tianran Zhou
发送时间: 2019年10月29日 9:44
收件人: opsawg@ietf.org
抄送: draft-wu-model-driven-management-virtualization.auth...@ietf.org;
opsawg-cha...@ietf.org
主题: [OPSAWG] WG adoption call for
draft-wu-model-driven-management-virtualization-07

Hi WG,

This email starts a 2 weeks working group adoption call for 
draft-wu-model-driven-management-virtualization-07.
https://datatracker.ietf.org/doc/draft-wu-model-driven-management-virtualiza
tion/
This document provides a framework that describes and discusses an architecture 
for service and network management automation that takes advantage of YANG 
modeling technologies.

If you support adopting this document please say so, and please give an 
indication of why you think it is important. Also please say if you will be 
willing to review and help the draft.
If you do not support adopting this document as a starting point for work on 
this topic, please say why.
This poll will run until Nov 11.
 
Thanks,
Tianran and Joe

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

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

Re: [OPSAWG] draft-ietf-opsawg-l3sm-l3nm

[Qin Wu]

2.Allow several BGP sessions under the same Network Access.
To support several Routing Protocols sessions under the same Network Access we 
have changed the Key to have an ID to allow several protocols under the same 
Network Access:



   | |+--rw routing-protocol* [id]

   | |   +--rw id  string

   | |   +--rw type?   identityref

   | |   +--rw routing-profiles* [id]

   | |   |  +--rw id  -> 
/l3vpn-ntw/vpn-profiles/valid-provider-identifiers/routing-profile-identifier/id

   | |   |  +--rw type?   ie-type

   | |   +--rw ospf {rtg-ospf}?

   | |   |  +--rw address-family*   address-family

   | |   |  +--rw area-address  yang:dotted-quad

   | |   |  +--rw metric?   uint16

   | |   |  +--rw mtu?  uint16

   | |   |  +--rw security

   | |   |  |  +--rw auth-key?   string

   | |   |  +--rw sham-links {rtg-ospf-sham-link}?

   | |   | +--rw sham-link* [target-site]

   | |   |+--rw target-sitesvc-id

   | |   |+--rw metric?uint16

   | |   +--rw bgp {rtg-bgp}?

   | |   |  +--rw autonomous-systemuint32

   | |   |  +--rw address-family*  address-family

   | |   |  +--rw neighbor?inet:ip-address

   | |   |  +--rw multihop?uint8

   | |   |  +--rw security

   | |   | +--rw auth-key?   string

   | |   +--rw static

   | |   |  +--rw cascaded-lan-prefixes

   | |   | +--rw ipv4-lan-prefixes* [lan next-hop] 
{ipv4}?

   | |   | |  +--rw lan inet:ipv4-prefix

   | |   | |  +--rw lan-tag?string

   | |   | |  +--rw next-hopinet:ipv4-address

   | |   | +--rw ipv6-lan-prefixes* [lan next-hop] 
{ipv6}?

   | |   |+--rw lan inet:ipv6-prefix

   | |   |+--rw lan-tag?string

   | |   |+--rw next-hopinet:ipv6-address

   | |   +--rw rip {rtg-rip}?

   | |   |  +--rw address-family*   address-family

   | |   +--rw vrrp {rtg-vrrp}?

   | |  +--rw address-family*   address-family

[Qin]: I think type under routing-protocol should add a new identity for 
routing-profiles category
identity routing-profile {
  base routing-protocol-type;
  description
  "Identity for routing profile type.";
}
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG adoption call for draft-wu-model-driven-management-virtualization-07

[Qin Wu]

Support as coauthor.
I don't have any IPR related to this draft.

-Qin
-邮件原件-
发件人: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com] 
发送时间: 2019年10月29日 16:35
收件人: Tianran Zhou ; opsawg@ietf.org
抄送: opsawg-cha...@ietf.org; 
draft-wu-model-driven-management-virtualization.auth...@ietf.org
主题: RE: WG adoption call for draft-wu-model-driven-management-virtualization-07

Hi all, 

I support this draft, obviously. 

FWIW, I don't have any IRP related to this draft. 

Cheers,
Med

> -Message d'origine-
> De : Tianran Zhou [mailto:zhoutian...@huawei.com] Envoyé : mardi 29 
> octobre 2019 02:44 À : opsawg@ietf.org Cc : opsawg-cha...@ietf.org; 
> draft-wu-model-driven-management- virtualization.auth...@ietf.org 
> Objet : WG adoption call for draft-wu-model-driven-management-
> virtualization-07
> 
> Hi WG,
> 
> This email starts a 2 weeks working group adoption call for 
> draft-wu-model- driven-management-virtualization-07.
> https://datatracker.ietf.org/doc/draft-wu-model-driven-management-
> virtualization/
> This document provides a framework that describes and discusses an 
> architecture for service and network management automation that takes 
> advantage of YANG modeling technologies.
> 
> If you support adopting this document please say so, and please give 
> an indication of why you think it is important. Also please say if you 
> will be willing to review and help the draft.
> If you do not support adopting this document as a starting point for 
> work on this topic, please say why.
> This poll will run until Nov 11.
> 
> Thanks,
> Tianran and Joe
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG adoption request for YANG data model framework for network management automation

[Qin Wu]

Thanks Chang for the support on 
(https://tools.ietf.org/html/draft-wu-model-driven-management-virtualization-06),
 ECA model referenced by draft-wu-model-driven-management-virtualization-06 is 
proceeded in IETF netmod working group right now, it has been in WG call for 
adoption stage since last IETF meeting.
-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 liuc...@chinaunicom.cn
发送时间: 2019年10月15日 11:42
收件人: OPSAWG 
主题: Re: [OPSAWG] WG adoption request for YANG data model framework for network 
management automation

Dear Authors,

Support to adopt this framework since I believe this work provides a good 
guideline for operator to deploy YANG data model at different layer and better 
understand how different layer model can put together to deliver end to end 
service.
One comment I have on this draft, this draft mention ECA policy model, I am 
wondering what is the status of ECA model, where is it progressed in IETF.

Thanks


Liu Chang
China Unicom
Email: liuc...@chinaunicom.cn
Phone: +8618601102572
Tel: 010-6879-7294
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG adoption request for YANG data model framework for network management automation

[Qin Wu]

Forge to add the link:
https://tools.ietf.org/html/draft-wu-model-driven-management-virtualization-06
Here it is.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Qin Wu
发送时间: 2019年10月10日 23:14
收件人: opsawg@ietf.org
主题: [OPSAWG] WG adoption request for YANG data model framework for network 
management automation

Dear WG and Chairs:
As you may recall I presented draft-wu-model-driven-management-virtualization 
in Montreal and got good supports from operators on building this framework and 
received a lot of comments and input from many contributors in opsawg meeting 
and YANG side meeting.
We have updated draft-wu-model-driven-management-virtualization based on 
Montreal meeting discussion and comments from the list.
The main changes include:
1.Move Layered YANG Modules Example to the appendix
2.Restructure and generalize content in Architecture Overview section and 
Architecture Concept section.
3.Polish the usage examples for YANG model integration.

We believe this draft has addressed all the open issues and is solid enough and 
would like ask for WG adoption for this work.
Comments and input are always welcome. Thanks!

-Qin (On behalf of authors)

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

[OPSAWG] WG adoption request for YANG data model framework for network management automation

[Qin Wu]

Dear WG and Chairs:
As you may recall I presented draft-wu-model-driven-management-virtualization 
in Montreal and got good supports from operators on building this framework and 
received a lot of comments and input from many contributors in opsawg meeting 
and YANG side meeting.
We have updated draft-wu-model-driven-management-virtualization based on 
Montreal meeting discussion and comments from the list.
The main changes include:
1.Move Layered YANG Modules Example to the appendix
2.Restructure and generalize content in Architecture Overview section and 
Architecture Concept section.
3.Polish the usage examples for YANG model integration.

We believe this draft has addressed all the open issues and is solid enough and 
would like ask for WG adoption for this work.
Comments and input are always welcome. Thanks!

-Qin (On behalf of authors)

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