[OPSAWG]Re:  WG Adoption Call for draft-gfz-opsawg-ipfix-alt-mark-01

[Tianran Zhou]

Hi Hank and all,

I support the adoption as coauthor.

Best,
Tianran






Sent from WeLink
发件人： Henk 
Birkholzmailto:henk.birkholz@ietf.contact>>
收件人： OPSAWGmailto:opsawg@ietf.org>>
主题： [OPSAWG] WG Adoption Call for draft-gfz-opsawg-ipfix-alt-mark-01
时间： 2024-06-26 11:59:01

Dear OPSAWG members,

this email starts a call for Working Group Adoption of

> https://datatracker.ietf.org/doc/html/draft-gfz-opsawg-ipfix-alt-mark-01

ending on Saturday, July 6th. That is a little bit of an odd duration,
but the I-D is crisp and concise and if there is rough consensus after
that time, this work may become a WG item before the upcoming cut-off.

As a reminder, this I-D specifies IPFIX Information Elements for the
Alternate-Marking Method as defined in RFC9341 & RFC9342; a technique
for measuring packet loss, delay, and jitter of packets in-flight.

The chairs acknowledge positive feedback and some review on the list and
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
To unsubscribe send an email to opsawg-le...@ietf.org
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG] Final agenda posted

[Tianran Zhou]

Hi WG,

We only have 1.5 hours joint with OPS area this time. So our agenda is very 
packed.
We adjust and post the final agenda:
https://datatracker.ietf.org/doc/agenda-119-opsawg/
The speakers please control your time and please send over your slides to the 
chairs two days before the meeting.

Look forward to seeing you soon in Brisbane.

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

Re: [OPSAWG] Individual Draft on information exposure - Request for presentation slot

[Tianran Zhou]

Hi Roland,

Thanks for sharing this interesting document to the mailing list.
But the agenda is really packed. We cannot give you the presentation this time.
I have a quick read about this draft. IMHO, if there is any new metric, should 
this be in IPPM WG?

Best,
Tianran

From: roland.sch...@telekom.de [mailto:roland.sch...@telekom.de]
Sent: Thursday, March 7, 2024 12:36 AM
To: opsawg@ietf.org; opsawg-cha...@ietf.org
Cc: sabine.randriam...@nokia-bell-labs.com; j...@qti.qualcomm.com; 
luismiguel.contrerasmuri...@telefonica.com; roland.sch...@telekom.de
Subject: Individual Draft on information exposure - Request for presentation 
slot


Dear OPSAWG and Chairs,



we were wondering if you would allow us to present for 5 minutes our draft on 
exposure of communication and compute information at IETF-119.

We have addressed this to the OPSAWG because we think this the appropriate 
place to discuss this topic.





Name: draft-rcr-opsawg-operational-compute-metrics

Revision: 03

Title:Joint Exposure of Network and Compute Information for 
Infrastructure-Aware Service Deployment

Date: 2024-03-04

Group:Individual Submission

Pages:20

Status:   
https://datatracker.ietf.org/doc/draft-rcr-opsawg-operational-compute-metrics/



Abstract:



   Service providers are starting to deploy computing capabilities

   across the network for hosting applications such as distributed AI

   workloads, AR/VR, vehicle networks, and IoT, among others.  In this

   network-compute environment, knowing information about the

   availability and state of the underlying communication and compute

   resources is necessary to determine both the proper deployment

   location of the applications and the most suitable servers on which

   to run them.  Further, this information is used by numerous use cases

   with different interpretations.  This document proposes an initial

   approach towards a common understanding and exposure scheme for

   metrics reflecting compute and communication capabilities.





Thanks for your consideration,

Sabine, Jordi, Luis, Roland.



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

Re: [OPSAWG] Hi, OPSAWG chairs. Request a time slot for a new draft: Threat Surface Management for Network Element

[Tianran Zhou]

Hi Frank,

The agenda is really packed. We cannot accommodate this request.
But this does not block you from promoting your work in the mailing list.

Best,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Xialiang(Frank, IP 
Security Standard)
Sent: Wednesday, March 6, 2024 9:31 AM
To: opsawg@ietf.org
Subject: [OPSAWG] Hi, OPSAWG chairs. Request a time slot for a new draft: 
Threat Surface Management for Network Element

Hi OPSAWG chairs,
I know it is a little bit later, but may I request a 10 minutes slot for 
presenting a new draft about Threat Surface Management for Network Element: 
https://datatracker.ietf.org/doc/draft-hu-network-element-tsm-yang/ ?
This new draft basically describes the use cases threat surface management of 
network devices, then provides its definition, finally attempts to define a 
YANG model for it.

Since this work is across OPS and SEC area, and we don't find a suitable OPS WG 
for it. So we applied for a 10-minute slot in OPSAWG to introduce it and 
collect suggestions.

Thank a lot!

夏靓  Frank (Liang) XIA
数据通信产品线标准专利部
华为技术有限公司

[Company_logo]


Mobile: +8613913840549
Email: frank.xiali...@huawei.com

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

[OPSAWG] OPSAWG 119 Agenda

[Tianran Zhou]

Hi WG,

The preliminary agenda for OPSAWG meeting at IETF119 is now posted.
https://datatracker.ietf.org/doc/agenda-119-opsawg/

Please see if there is anything missing.
Welcome to join the meeting.

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

Re: [OPSAWG] Call for presentations at IETF119

[Tianran Zhou]

Hi Jean,

Thanks for this request. I have put it on my list.
Best,
Tianran

From: Jean Quilbeuf [mailto:jean.quilbeuf=40huawei@dmarc.ietf.org]
Sent: Saturday, March 2, 2024 12:47 AM
To: Tianran Zhou ; OPSAWG 

Cc: opsawg-chairs 
Subject: RE: Call for presentations at IETF119

Dear OPSAWG chairs,
I would like to request a slot for draft-ietf-opsawg-collected-data-manifest-03 
which will be posted soon!

I might present remotely or Benoit Claise might present in person.

10 minutes should be enough.

Best,
Jean

From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of Tianran Zhou
Sent: Sunday, February 18, 2024 6:42 AM
To: OPSAWG mailto:opsawg@ietf.org>>
Cc: opsawg-chairs mailto:opsawg-cha...@ietf.org>>
Subject: [OPSAWG] Call for presentations at IETF119

Hi OPSAWG,

The IETF119 preliminary agenda is posted.

https://datatracker.ietf.org/meeting/119/agenda/

The joint OPSAWG and OPS Area meeting is scheduled at 15:30 - 17:00 Monday 
Session III.
We are now available to accept presentations. Please send your request to the 
chairs.
Look forward to seeing you in Brisbane.

Best,
Tianran

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

[OPSAWG] Call for presentations at IETF119

[Tianran Zhou]

Hi OPSAWG,

The IETF119 preliminary agenda is posted.

https://datatracker.ietf.org/meeting/119/agenda/

The joint OPSAWG and OPS Area meeting is scheduled at 15:30 - 17:00 Monday 
Session III.
We are now available to accept presentations. Please send your request to the 
chairs.
Look forward to seeing you in Brisbane.

Best,
Tianran

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

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

[Tianran Zhou]

Hi Authors,

I read this draft and I think this work is valuable. 
There are several comments for your consideration.
1.  We have YANG as the modeling language for configuration DM. For this draft, 
do you have any formal language for the IM? While I think the tree diagram is 
also clear, I am afraid the expression is not very strict.
2. The title indicates the content is about discard. And in fact section 4.1 
only described the discard class. However, the IM you proposed includes 
"traffic"  as a large part. So, I am thinking if you would consider to remove 
the "traffic" part, or your document is actually a more generic traffic IM.
3. In section 5, all your Signal-Cause-Mitigation mapping examples are actually 
"discard". Is there any use case for "good traffic"? I.e., maybe there is no 
need for the "good traffic" report, hence no need to include the "traffic" in 
your draft for your scenario.
4. In section 5, the Signal-Cause-Mitigation table is confusing. It's not clear 
what's the signal, cause, mitigation respectively. So it's better to indicate 
this information explicitly in the table.

Best,
Tianran

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Henk Birkholz
Sent: Wednesday, January 17, 2024 8:52 PM
To: OPSAWG 
Subject: [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] FW: New Version Notification for draft-opsawg-poweff-00.txt

[Tianran Zhou]

Hi Marisol,

Could you please add the YANG tree in the draft? So that people can understand 
your idea easier.

Best,
Tianran






Sent from WeLink
发件人： Marisol Palmero Amador 
(mpalmero)mailto:mpalmero=40cisco@dmarc.ietf.org>>
收件人： opsawgmailto:opsawg@ietf.org>>
抄送： Gonzalo Salgueiro 
(gsalguei)mailto:gsalg...@cisco.com>>;Jan Lindblad 
(jlindbla)mailto:jlind...@cisco.com>>;Snezana Mitrovic 
(snmitrov)mailto:snmit...@cisco.com>>;emile.stephanmailto:emile.step...@orange.com>>;Per
 Andersson (perander)mailto:peran...@cisco.com>>;Esther 
Roure Vila 
(erourevi)mailto:erour...@cisco.com>>;emile.stephanmailto:emile.step...@orange.com>>
主题： [OPSAWG] FW: New Version Notification for draft-opsawg-poweff-00.txt
时间： 2023-10-28 01:09:07

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 
Date: Friday, 20 October 2023 at 17:45
To: Gonzalo Salgueiro (gsalguei) , Jan Lindblad (jlindbla) 
, Marisol Palmero Amador (mpalmero) , 
Snezana Mitrovic (snmitrov) 
Subject: New Version Notification for draft-opsawg-poweff-00.txt
A new version of Internet-Draft draft-opsawg-poweff-00.txt has been
successfully submitted by Marisol Palmero and posted to the
IETF repository.

Name: draft-opsawg-poweff
Revision: 00
Title:Power and Energy Efficiency
Date: 2023-10-20
Group:Individual Submission
Pages:37
URL:  https://www.ietf.org/archive/id/draft-opsawg-poweff-00.txt
Status:   https://datatracker.ietf.org/doc/draft-opsawg-poweff/
HTMLized: https://datatracker.ietf.org/doc/html/draft-opsawg-poweff


Abstract:

   This document motivates and specifies a data model to report power
   and energy efficiency of an asset.  As highlighted during the IAB
   workshop on environmental impacts
   (https://datatracker.ietf.org/doc/html/draft-iab-ws-environmental-
   impacts-report-00), visibility is a very important first step
   (paraphrasing Peter Drucker's mantra of "You cannot improve what you
   don't measure").  During the workshop the need for standardized
   metrics was established, to avoid proprietary, double counting and
   even contradictory metrics across vendors.

   This Power and Energy Efficiency Telemetry Specification (POWEFF) is
   required to promote consistency across vendors and consumers, based
   on: 1.  The definition of datasets and attributes defining a common
   data model utilized by the standard calculation to yield power and
   energy efficiency value for any asset or network element.  2.  The
   standard calculations utilizing the specified datasets and attributes
   which will yield energy consumption and energy efficiency value for
   any asset or network element.

   The model provides information and data requirements for calculating
   the Power and Energy Efficiency for specific assets.  Assets can
   include hardware (physical or virtual), software, applications, or
   services.



The IETF Secretariat

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

Re: [OPSAWG] New Liaison Statement, "LS on the consent of draft Recommendation ITU-T Q.3962 (ex. Q.joint_tr) “Requirements and Reference Model for optimized traceroute of joint Internet Protocol/Mult

[Tianran Zhou]

Hi MPLS WG,

I forward this LS to MPLS because I believe it not really belongs to OPSAWG.
I think MPLS WG should be the right place to receive.

Best,
Tianran
 

-Original Message-
From: Liaison Statement Management Tool [mailto:stateme...@ietf.org] 
Sent: Tuesday, October 24, 2023 11:23 PM
To: Henk Birkholz ; Joe Clarke 
; Tianran Zhou 
Cc: Henk Birkholz ; Joe Clarke 
; Operations and Management Area Working Group Discussion 
List ; Robert Wilton ; Scott Mansfield 
; Tatiana Kurakova ; 
Tianran Zhou ; Warren Kumari ; 
itu-t-liai...@iab.org; liaison-coordinat...@iab.org
Subject: New Liaison Statement, "LS on the consent of draft Recommendation 
ITU-T Q.3962 (ex. Q.joint_tr) “Requirements and Reference Model for optimized 
traceroute of joint Internet Protocol/Multi-Protocol Label Switching”"

Title: LS on the consent of draft Recommendation ITU-T Q.3962 (ex. Q.joint_tr) 
“Requirements and Reference Model for optimized traceroute of joint Internet 
Protocol/Multi-Protocol Label Switching”
Submission Date: 2023-10-24
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1869/

From: Denis ANDREEV 
To: Henk Birkholz ,Joe Clarke 
,Tianran Zhou 
Cc: Robert Wilton ,Warren Kumari 
,itu-t-liai...@iab.org ,Joe Clarke 
,Scott Mansfield ,Operations 
and Management Area Working Group Discussion List ,Henk 
Birkholz ,Tianran Zhou 
 Response Contacts: Tatiana Kurakova 
 Technical Contacts: 
Purpose: For information

Body: This liaison statement provides information about the consented item as a 
result of the ITU-T SG11 meeting (Geneva, 10-20 October 2023).

ITU-T SG11 would like to inform ITU-T Study Group 13 and IETF about the draft 
new Recommendation ITU-T Q.3962 (ex. Q. joint_tr) “Requirements and Reference 
Model for optimized traceroute of joint Internet Protocol/Multi-Protocol Label 
Switching” which was consented during the ITU-T SG11 meeting (Geneva, 10-20 
October 2023).

The draft new Recommendation ITU-T Q. 3962 (ex. Q. joint_tr) “Requirements and 
Reference Model for optimized traceroute of joint Internet 
Protocol/Multi-Protocol Label Switching” is attached for your convenience.
ITU-T SG11 looks forward to collaborating with ITU-T Study Group 13 and IETF on 
this matter.

Attachment:
SG11-TD747/GEN: Consent – draft Recommendation ITU-T Q.3962 (ex. Q.joint_tr): 
Requirements and Reference Model for optimized traceroute of joint Internet 
Protocol/Multi-Protocol Label Switching (Geneva, 10-20 October 2023)
Attachments:

SG11-LS108-Att-TD747

https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2023-10-24-itu-t-sg-11-opsawg-ls-on-the-consent-of-draft-recommendation-itu-t-q3962-ex-qjoint_tr-requirements-and-reference-model-for-optim-attachment-1.pdf

SG11-LS108

https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2023-10-24-itu-t-sg-11-opsawg-ls-on-the-consent-of-draft-recommendation-itu-t-q3962-ex-qjoint_tr-requirements-and-reference-model-for-optim-attachment-2.docx



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

Re: [OPSAWG] Should the schedule YANG model be seperated from draft-ietf-opsawg-ucl-acl?

[Tianran Zhou]

QUESTION FOR THE CHAIRS
If this is split out, does it o into an individual draft for a further adoption 
poll, or can it be split into a second WG ID at once?

ZTR> In my opinion, it should go into an individual draft. We adopted 
draft-ietf-opsawg-ucl-acl because of the whole solution. Scheduling in this 
solution is only a component and very specific. If we want to generalize the 
scheduling for services, resources, etc, the common model is new work.

Best,
Tianran

发件人: OPSAWG  代表 Adrian Farrel
发送时间: 2023年10月10日 10:06
收件人: maqiufang (A) ; opsawg@ietf.org
抄送: draft-ietf-opsawg-ucl-...@ietf.org
主题: Re: [OPSAWG] Should the schedule YANG model be seperated from 
draft-ietf-opsawg-ucl-acl?

As I said in my original comment, I’d like to see this separation. Various 
recent conversations suggest that scheduling (services, resources, ACLs, etc.) 
is becoming a Big Thing. Having a common model to facilitate this would be 
really helpful.

QUESTION FOR THE CHAIRS
If this is split out, does it o into an individual draft for a further adoption 
poll, or can it be split into a second WG ID at once?

A

From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of maqiufang (A)
Sent: 07 October 2023 11:48
To: opsawg@ietf.org
Cc: 
draft-ietf-opsawg-ucl-...@ietf.org
Subject: [OPSAWG] Should the schedule YANG model be seperated from 
draft-ietf-opsawg-ucl-acl?

Hi, all

Based on the comments we’ve received during the adoption call of 
draft-ma-opsawg-ucl-acl [1], the authors would like to start a separate thread 
to highlight a question raised by Adrian:
should the schedule model be moved out into a separate document? And we would 
like to collect more feedback from the WG.

It is indeed that the ietf-schedule YANG model in the draft is now designed to 
be applicable in other common scheduling contexts and not specific to ACL 
policies.
The authors already see some usage of it in other date and time based 
context[2], and it might seem awkward for it (and other potential ones in the 
future) to reference draft-ietf-opsawg-ucl-acl for reusing the scheduling 
groupings.

It would be good to know if the WG think it useful for this model to be defined 
in a separate document, so that the authors will take the time to work on it if 
there is consensus.
Would appreciate any of your input, thanks a lot!


[1] https://datatracker.ietf.org/doc/draft-ietf-opsawg-ucl-acl/
[2] 
https://datatracker.ietf.org/doc/draft-contreras-opsawg-scheduling-oam-tests/


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

[OPSAWG] Conclusion//RE: Working group adoption call for draft-ma-opsawg-ucl-acl-03

[Tianran Zhou]

Hi WG,

This adoption call is concluded.
We got many supports in the mailing list, especially from four operators. And 
there is no objection.
This draft is adopted. The authors please resubmit the draft as 
draft-ietf-opsawg-ucl-acl-00 in the datatracker.
There are many useful comments during the adoption call. The authors please 
consider and revise the draft in the following versions.

Cheers,
Tianran, as WG Chair



From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Tuesday, September 5, 2023 9:13 AM
To: opsawg@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: [OPSAWG] Working group adoption call for draft-ma-opsawg-ucl-acl-03

Hi WG,

This mail starts a two weeks working group adoption call for 
draft-ma-opsawg-ucl-acl-03
https://datatracker.ietf.org/doc/draft-ma-opsawg-ucl-acl/

Please send over your objections or supports to the mailing list.
If you object the adoption, please also give the reason, so that the authors 
can improve.
We will conclude this adoption call on Sep 20, 2023.
All your comments are welcome.

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

[OPSAWG] Working group adoption call for draft-ma-opsawg-ucl-acl-03

[Tianran Zhou]

Hi WG,

This mail starts a two weeks working group adoption call for 
draft-ma-opsawg-ucl-acl-03
https://datatracker.ietf.org/doc/draft-ma-opsawg-ucl-acl/

Please send over your objections or supports to the mailing list.
If you object the adoption, please also give the reason, so that the authors 
can improve.
We will conclude this adoption call on Sep 20, 2023.
All your comments are welcome.

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

[OPSAWG] Conclusion//RE: IPR poll for draft-ma-opsawg-ucl-acl-03

[Tianran Zhou]

Hi WG,

We collected replies from all the authors.
All the authors are not aware of any IPR that applies to this draft. And there 
is no question in the mailing list.
So we will proceed.

Best,
Tianran


From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Friday, September 1, 2023 3:51 PM
To: opsawg@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: [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

[OPSAWG] IPR poll for draft-ma-opsawg-ucl-acl-03

[Tianran Zhou]

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] Some thoughts on Green Networking Metrics

[Tianran Zhou]

Hi Daniele,

Thanks for the clarification.
Now I understand what you want to include is static value.

Best,
Tianran



Sent from WeLink
发件人： Daniele Ceccarellimailto:daniele.i...@gmail.com>>
收件人： Tianran Zhoumailto:zhoutian...@huawei.com>>
抄送： Alexander L 
Clemmmailto:lud...@clemm.org>>;opsawgmailto:opsawg@ietf.org>>
主题： Re: [OPSAWG] Some thoughts on Green Networking Metrics
时间： 2023-08-21 20:33:57

HI Tianran, Alex,

the power consumed at a given time is highly changing over time, but parameters 
like e.g. power consumption of a card at 50%, 75% and 100% of the load don't.
I don't disagree with Alex when saying that this is not directly inventory, but 
it's strictly related to it and should probably be an augmentation of the 
device inventory.

BR
Daniele

On Fri, Aug 18, 2023 at 3:20 AM Tianran Zhou 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
I am not quite clear about the applicability of the inventory.
What’s the difference with hardware model or entity model.
I see energy work was related to entity mib in eman before:
https://datatracker.ietf.org/wg/eman/documents/

It seems inventory should be something static from the name. But IMO, the 
energy metrics are dynamic, can will change all the time.

Best,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org<mailto:opsawg-boun...@ietf.org>] 
On Behalf Of Alexander L Clemm
Sent: Friday, August 18, 2023 7:05 AM
To: opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: Re: [OPSAWG] Some thoughts on Green Networking Metrics


Hi Daniele,

apologies for the late reply.

I think inventory is somewhat orthogonal to this, but of course devices and 
equipment (including chassis, line cards, equipment holders etc) will be 
considered part of inventory.   Therefore via transitive closure it is 
certainly conceivable to make power consumption data accessible via inventory.  
This could make sense as part of a consolidated controller view of a network.  
However, on a network element itself, the network inventory aspect would not 
apply but the metrics should still be available so the device/equipment level 
category still applies.  As to whether device level data should be replicated 
as part of network inventory data  would presumably depend on the use case.

--- Alex
On 7/26/2023 6:35 PM, Daniele Ceccarelli (dceccare) wrote:
Hi Alex, all,

Just following up on the comment I did ad the mic earlier today.

The drafts speaks about metrics at: device/equipment level, flow level, path 
level, network level.
The  device/equipment level covers power consumption per chassis, line card and 
port at different loads of traffic, hence IMO should fall into the inventory 
category.
Would you agree?

Cheers,
Daniele




___

OPSAWG mailing list

OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>

https://www.ietf.org/mailman/listinfo/opsawg

___
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] Some thoughts on Green Networking Metrics

[Tianran Zhou]

I am not quite clear about the applicability of the inventory.
What’s the difference with hardware model or entity model.
I see energy work was related to entity mib in eman before:
https://datatracker.ietf.org/wg/eman/documents/

It seems inventory should be something static from the name. But IMO, the 
energy metrics are dynamic, can will change all the time.

Best,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Alexander L Clemm
Sent: Friday, August 18, 2023 7:05 AM
To: opsawg@ietf.org
Subject: Re: [OPSAWG] Some thoughts on Green Networking Metrics


Hi Daniele,

apologies for the late reply.

I think inventory is somewhat orthogonal to this, but of course devices and 
equipment (including chassis, line cards, equipment holders etc) will be 
considered part of inventory.   Therefore via transitive closure it is 
certainly conceivable to make power consumption data accessible via inventory.  
This could make sense as part of a consolidated controller view of a network.  
However, on a network element itself, the network inventory aspect would not 
apply but the metrics should still be available so the device/equipment level 
category still applies.  As to whether device level data should be replicated 
as part of network inventory data  would presumably depend on the use case.

--- Alex
On 7/26/2023 6:35 PM, Daniele Ceccarelli (dceccare) wrote:
Hi Alex, all,

Just following up on the comment I did ad the mic earlier today.

The drafts speaks about metrics at: device/equipment level, flow level, path 
level, network level.
The  device/equipment level covers power consumption per chassis, line card and 
port at different loads of traffic, hence IMO should fall into the inventory 
category.
Would you agree?

Cheers,
Daniele




___

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] OPSAWG meeting agenda

[Tianran Zhou]

Hi WG,

The preliminary agenda is posted:
https://datatracker.ietf.org/doc/agenda-117-opsawg/

Please see if there is anything missing.
Please contact us if you have any question.
Look forward to seeing you in SF.

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

Re: [OPSAWG] RFC 9417 on Service Assurance for Intent-Based Networking Architecture

[Tianran Zhou]

Hi Authors and Contributors,

Congratulations to your work!

Cheers,
Tianran

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of 
rfc-edi...@rfc-editor.org
Sent: Wednesday, July 12, 2023 2:36 PM
To: ietf-annou...@ietf.org; rfc-d...@rfc-editor.org
Cc: rfc-edi...@rfc-editor.org; drafts-update-...@iana.org; opsawg@ietf.org
Subject: [OPSAWG] RFC 9417 on Service Assurance for Intent-Based Networking 
Architecture

A new Request for Comments is now available in online RFC libraries.


RFC 9417

Title:  Service Assurance for Intent-Based Networking 
Architecture 
Author: B. Claise,
J. Quilbeuf,
D. Lopez,
D. Voyer,
T. Arumugam
Status: Informational
Stream: IETF
Date:   July 2023
Mailbox:benoit.cla...@huawei.com,
jean.quilb...@huawei.com,
diego.r.lo...@telefonica.com,
daniel.vo...@bell.ca,
thangav...@yahoo.com
Pages:  23
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-opsawg-service-assurance-architecture-13.txt

URL:https://www.rfc-editor.org/info/rfc9417

DOI:10.17487/RFC9417

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

This document is a product of the Operations and Management Area Working Group 
Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of this memo 
is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search For 
downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the author of 
the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless specifically 
noted otherwise on the RFC itself, all RFCs are for unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

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

Re: [OPSAWG] Call for presentation//FW: IETF 117 Preliminary Agenda

[Tianran Zhou]

OK.  It’s clear.

Tianran



Sent from WeLink
发件人： Benoit 
Claisemailto:benoit.claise=40huawei@dmarc.ietf.org>>
收件人： Tianran 
Zhoumailto:zhoutianran=40huawei@dmarc.ietf.org>>;Benoit
 
Claisemailto:benoit.claise=40huawei@dmarc.ietf.org>>;opsawgmailto:opsawg@ietf.org>>
主题： Re: [OPSAWG] Call for presentation//FW: IETF 117 Preliminary Agenda
时间： 2023-06-27 21:22:04

Hi Tiaran,

You are right. My bad. draft-quilbeuf-opsawg-configuration-tracing is
for NETCONF.
draft-ietf-opsawg-collected-data-manifest is OPSAWG

Regards, Benoit

On 6/27/2023 3:10 AM, Tianran Zhou wrote:
> Hi Benoit,
>
> It's on my list.
> On draft-ietf-opsawg-collected-data-manifest and 
> draft-quilbeuf-opsawg-configuration-tracing, why not in NETCONF?
>
> Best,
> Tianran
>
> -Original Message-
> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Benoit Claise
> Sent: Tuesday, June 27, 2023 3:08 AM
> To: Tianran Zhou ; opsawg@ietf.org
> Subject: Re: [OPSAWG] Call for presentation//FW: IETF 117 Preliminary Agenda
>
> Hi Tianran,
>
> We would like to request some presentation slots:
> -
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-collected-data-manifest/,
> either Jean Quilbeuf or myself, 10 min
> -
> https://datatracker.ietf.org/doc/draft-quilbeuf-opsawg-configuration-tracing/,
> either Jean Quilbeuf or myself, 10 min
> - https://datatracker.ietf.org/doc/draft-havel-opsawg-digital-map/, Olga 
> Havel, 10 to 15 min (if possible since it's a new draft)
>
> Regards, Benoit
>
> On 6/25/2023 11:39 AM, Tianran Zhou wrote:
>> Hi WG,
>>
>> The IETF117 preliminary agenda is posted.
>> The OPSAWG meeting is scheduled on WEDNESDAY, July 26, 1300-1500  Session II.
>> We start to accept presentation request.
>> Please send over your request with title, speaker, time slot, and draft name 
>> to the chairs.
>>
>> Cheers,
>> Tianran
>>
>>
>> -Original Message-
>> From: WGChairs [mailto:wgchairs-boun...@ietf.org] On Behalf Of IETF
>> Agenda
>> Sent: Saturday, June 24, 2023 5:14 AM
>> To: Working Group Chairs 
>> Subject: IETF 117 Preliminary Agenda
>>
>> IETF 117
>> San Francisco, CA, USA
>> July 22-28, 2023
>> Hosted By: NOKIA
>>
>>
>> The IETF 117 preliminary agenda has been posted. The final agenda will be 
>> published on Friday, June 30, 2023.
>>
>> If you would like to request a change to the preliminary agenda, please send 
>> a message to supp...@ietf.org and copy all relevant Area Directors.
>>
>> https://datatracker.ietf.org/meeting/117/agenda.html
>> https://datatracker.ietf.org/meeting/117/agenda.txt
>>
>> The preliminary agenda includes all planned WG, RG, and BoF sessions. 
>> Information about side meetings will be available when the final agenda is 
>> posted.
>>
>> Thank you!
>>
>> IETF Secretariat
>>
>> ___
>> 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

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

Re: [OPSAWG] Call for presentation//FW: IETF 117 Preliminary Agenda

[Tianran Zhou]

Hi Benoit,

It's on my list.
On draft-ietf-opsawg-collected-data-manifest and 
draft-quilbeuf-opsawg-configuration-tracing, why not in NETCONF?

Best,
Tianran

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Benoit Claise
Sent: Tuesday, June 27, 2023 3:08 AM
To: Tianran Zhou ; opsawg@ietf.org
Subject: Re: [OPSAWG] Call for presentation//FW: IETF 117 Preliminary Agenda

Hi Tianran,

We would like to request some presentation slots:
-
https://datatracker.ietf.org/doc/draft-ietf-opsawg-collected-data-manifest/,
either Jean Quilbeuf or myself, 10 min
-
https://datatracker.ietf.org/doc/draft-quilbeuf-opsawg-configuration-tracing/,
either Jean Quilbeuf or myself, 10 min
- https://datatracker.ietf.org/doc/draft-havel-opsawg-digital-map/, Olga Havel, 
10 to 15 min (if possible since it's a new draft)

Regards, Benoit

On 6/25/2023 11:39 AM, Tianran Zhou wrote:
> Hi WG,
>
> The IETF117 preliminary agenda is posted.
> The OPSAWG meeting is scheduled on WEDNESDAY, July 26, 1300-1500  Session II.
> We start to accept presentation request.
> Please send over your request with title, speaker, time slot, and draft name 
> to the chairs.
>
> Cheers,
> Tianran
>
>
> -Original Message-
> From: WGChairs [mailto:wgchairs-boun...@ietf.org] On Behalf Of IETF 
> Agenda
> Sent: Saturday, June 24, 2023 5:14 AM
> To: Working Group Chairs 
> Subject: IETF 117 Preliminary Agenda
>
> IETF 117
> San Francisco, CA, USA
> July 22-28, 2023
> Hosted By: NOKIA
>
>
> The IETF 117 preliminary agenda has been posted. The final agenda will be 
> published on Friday, June 30, 2023.
>
> If you would like to request a change to the preliminary agenda, please send 
> a message to supp...@ietf.org and copy all relevant Area Directors.
>
> https://datatracker.ietf.org/meeting/117/agenda.html
> https://datatracker.ietf.org/meeting/117/agenda.txt
>
> The preliminary agenda includes all planned WG, RG, and BoF sessions. 
> Information about side meetings will be available when the final agenda is 
> posted.
>
> Thank you!
>
> IETF Secretariat
>
> ___
> 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] Call for presentation//FW: IETF 117 Preliminary Agenda

[Tianran Zhou]

Hi WG,

The IETF117 preliminary agenda is posted.
The OPSAWG meeting is scheduled on WEDNESDAY, July 26, 1300-1500  Session II.
We start to accept presentation request.
Please send over your request with title, speaker, time slot, and draft name to 
the chairs.

Cheers,
Tianran


-Original Message-
From: WGChairs [mailto:wgchairs-boun...@ietf.org] On Behalf Of IETF Agenda
Sent: Saturday, June 24, 2023 5:14 AM
To: Working Group Chairs 
Subject: IETF 117 Preliminary Agenda

IETF 117
San Francisco, CA, USA
July 22-28, 2023
Hosted By: NOKIA


The IETF 117 preliminary agenda has been posted. The final agenda will be 
published on Friday, June 30, 2023.  

If you would like to request a change to the preliminary agenda, please send a 
message to supp...@ietf.org and copy all relevant Area Directors.

https://datatracker.ietf.org/meeting/117/agenda.html 
https://datatracker.ietf.org/meeting/117/agenda.txt 

The preliminary agenda includes all planned WG, RG, and BoF sessions. 
Information about side meetings will be available when the final agenda is 
posted. 

Thank you!

IETF Secretariat

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

[OPSAWG] Conclusion//RE: WG Adoption call for IPFIX

[Tianran Zhou]

Hi WG,

We conclude the adoption call.
There is consensus in the working group to adopt these three drafts.

Please resubmit the documents as draft-ietf-opsawg-xxx without change.

We received substantial comments. The authors please revise the documents in 
the following version.

Cheers,
Tianran



Sent from WeLink
发件人： Tianran 
Zhoumailto:zhoutianran=40huawei@dmarc.ietf.org>>
收件人： opsawgmailto:opsawg@ietf.org>>
抄送： opsawg-chairsmailto:opsawg-cha...@ietf.org>>
主题： [OPSAWG] WG Adoption call for IPFIX
时间： 2023-06-06 13:20:58

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] Conclusion//RE: IPR poll for 3 IPFIX drafts

[Tianran Zhou]

We conclude the IPR call.
We collected all the replies from authors. There is no IPR applies to these 
drafts.

Tianran






Sent from WeLink
发件人： Tianran 
Zhoumailto:zhoutianran=40huawei@dmarc.ietf.org>>
收件人： opsawgmailto:opsawg@ietf.org>>
抄送： opsawg-chairsmailto:opsawg-cha...@ietf.org>>
主题： [OPSAWG] IPR poll for 3 IPFIX drafts
时间： 2023-06-06 14:13:11

Hi WG,

Accompany with the adoption call, this mail starts an IPR poll for the 
following drafts.
https://datatracker.ietf.org/doc/draft-boucla-opsawg-ipfix-fixes/
https://datatracker.ietf.org/doc/draft-boucadair-opsawg-ipfix-tcpo-v6eh/
https://datatracker.ietf.org/doc/draft-boucadair-opsawg-tsvwg-udp-ipfix/

The authors, contributors and the WG, 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 you are aware of IPR, please 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] RFC 9408 on A YANG Network Data Model for Service Attachment Points (SAPs)

[Tianran Zhou]

Congratulations to the authors and contributors!

Cheers,
Tianran

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of 
rfc-edi...@rfc-editor.org
Sent: Wednesday, June 21, 2023 1:28 PM
To: ietf-annou...@ietf.org; rfc-d...@rfc-editor.org
Cc: rfc-edi...@rfc-editor.org; drafts-update-...@iana.org; opsawg@ietf.org
Subject: [OPSAWG] RFC 9408 on A YANG Network Data Model for Service Attachment 
Points (SAPs)

A new Request for Comments is now available in online RFC libraries.


RFC 9408

Title:  A YANG Network Data Model 
for Service Attachment Points (SAPs) 
Author: M. Boucadair, Ed.,
O. Gonzalez de Dios,
S. Barguil,
Q. Wu,
V. Lopez
Status: Standards Track
Stream: IETF
Date:   June 2023
Mailbox:mohamed.boucad...@orange.com,
oscar.gonzalezded...@telefonica.com,
samier.barguil_gira...@nokia.com,
bill...@huawei.com,
victor.lo...@nokia.com
Pages:  37
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-opsawg-sap-15.txt

URL:https://www.rfc-editor.org/info/rfc9408

DOI:10.17487/RFC9408

This document defines a YANG data model for representing an abstract view of 
the provider network topology that contains the points from which its services 
can be attached (e.g., basic connectivity, VPN, network slices). Also, the 
model can be used to retrieve the points where the services are actually being 
delivered to customers (including peer networks).

This document augments the 'ietf-network' data model defined in RFC
8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are 
the network reference points to which network services, such as Layer 3 Virtual 
Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be 
attached. One or multiple services can be bound to the same SAP. Both 
User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are 
supported in the SAP data model.

This document is a product of the Operations and Management Area Working Group 
Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track protocol 
for the Internet community, and requests discussion and suggestions for 
improvements.  Please refer to the current edition of the Official Internet 
Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this memo 
is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search For 
downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the author of 
the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless specifically 
noted otherwise on the RFC itself, all RFCs are for unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
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] IPR poll for 3 IPFIX drafts

[Tianran Zhou]

Hi WG,

Accompany with the adoption call, this mail starts an IPR poll for the 
following drafts.
https://datatracker.ietf.org/doc/draft-boucla-opsawg-ipfix-fixes/
https://datatracker.ietf.org/doc/draft-boucadair-opsawg-ipfix-tcpo-v6eh/
https://datatracker.ietf.org/doc/draft-boucadair-opsawg-tsvwg-udp-ipfix/

The authors, contributors and the WG, 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 you are aware of IPR, please 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

[OPSAWG] WG Adoption call for IPFIX

[Tianran Zhou]

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] Conclusion//RE: Extension//RE: WG adoption call for draft-palmero-opsawg-dmlmo-09

[Tianran Zhou]

Hi WG,

This mail concludes the WGAC for draft-palmero-opsawg-dmlmo-09.
It appeared very low interest from the mailing list.
The chairs decide not to adopt this work at present.

Tianran as co-chair

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Wednesday, April 5, 2023 10:44 AM
To: Tianran Zhou ; opsawg 

Cc: opsawg-chairs 
Subject: [OPSAWG] Extension//RE: WG adoption call for 
draft-palmero-opsawg-dmlmo-09

Hi WG,

As we were all in IETF last week, people might not tend to deal with mail.
We would like to extend this adoption call for another two weeks for more 
discussions and feedback. We will conclude on April 18.
Your comments and suggestions are welcome. Please help if you are interested on 
the inventory work.


Best,
Tianran as cochair




Sent from WeLink
发件人： Tianran 
Zhoumailto:zhoutianran=40huawei@dmarc.ietf.org>>
收件人： opsawgmailto:opsawg@ietf.org>>
抄送： opsawg-chairsmailto:opsawg-cha...@ietf.org>>
主题： [OPSAWG] WG adoption call for draft-palmero-opsawg-dmlmo-09
时间： 2023-03-17 10:32:57

Hi WG,

This mail we start a two weeks working group adoption call for:
https://datatracker.ietf.org/doc/draft-palmero-opsawg-dmlmo/

Please show your support or objection in the mailing list.
Any comment and suggestion is welcome.
As this draft is part of the inventory related work, suggestions on how to 
cooperate are expected.

The call will end on April 3.

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

[OPSAWG] Extension//RE: WG adoption call for draft-palmero-opsawg-dmlmo-09

[Tianran Zhou]

Hi WG,

As we were all in IETF last week, people might not tend to deal with mail.
We would like to extend this adoption call for another two weeks for more 
discussions and feedback. We will conclude on April 18.
Your comments and suggestions are welcome. Please help if you are interested on 
the inventory work.


Best,
Tianran as cochair





Sent from WeLink
发件人： Tianran 
Zhoumailto:zhoutianran=40huawei@dmarc.ietf.org>>
收件人： opsawgmailto:opsawg@ietf.org>>
抄送： opsawg-chairsmailto:opsawg-cha...@ietf.org>>
主题： [OPSAWG] WG adoption call for draft-palmero-opsawg-dmlmo-09
时间： 2023-03-17 10:32:57

Hi WG,

This mail we start a two weeks working group adoption call for:
https://datatracker.ietf.org/doc/draft-palmero-opsawg-dmlmo/

Please show your support or objection in the mailing list.
Any comment and suggestion is welcome.
As this draft is part of the inventory related work, suggestions on how to 
cooperate are expected.

The call will end on April 3.

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

Re: [OPSAWG] OPSAWG meeting agenda

[Tianran Zhou]

Hi WG,

I updated the order of the presentations to make the agenda more compact.
The speakers please get ready.

Cheers,
Tianran


发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2023年3月16日 19:16
收件人: opsawg@ietf.org
抄送: opsawg-cha...@ietf.org
主题: [OPSAWG] OPSAWG meeting agenda

Hi WG,

We just posted the preliminary agenda for IETF116.
https://datatracker.ietf.org/doc/agenda-116-opsawg/

It’s really great that we got so many requests.
We prepare the schedule by first come first serve. So there are 3 topics can 
only be presented when time allows.
Please check if there is anything missing.

The speaker please send over your slides before the meeting date.

Look forward to see you in Yokohama.

Cheers,
Tianran, Joe, Hank


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

Re: [OPSAWG] New Version Notification for draft-palmero-opsawg-dmlmo-09.txt

[Tianran Zhou]

Hi Marisol,

Thanks for your reply.
My comments are not only to your draft, but also on how all the inventory 
related drafts can cooperate.
I think the WG need to figure out the relationship between asset and inventory. 
I can see many common parts.
I see from the introduction that inventory also covers "application".
Could inventory cover the application and service mentioned by asset? (Maybe 
this is a question to the inventory authors :))
Also I see Chong is now discussing about incident.
In all, I think more discussions and cross review are helpful. And the 
inventory side meeting is useful.

Best,
Tianran



From: Marisol Palmero Amador (mpalmero) 
[mailto:mpalmero=40cisco@dmarc.ietf.org]
Sent: Tuesday, March 21, 2023 8:36 AM
To: Tianran Zhou ; opsawg@ietf.org; Rob Wilton 
(rwilton) 
Cc: Camilo Cardona ; Frank Brockners (fbrockne) 
; Diego R. Lopez ; Shwetha 
Bhandari ; Sudhendu Kumar 
; Eric Vyncke (evyncke) ; 
inventory-y...@ietf.org; Jan Lindblad (jlindbla) 
Subject: Re: New Version Notification for draft-palmero-opsawg-dmlmo-09.txt

Many thanks for your email,

Just to clarify our approach to "dis-engage" from the inventory drafts/RFC's 
discussions:

  *   The asset module, doesn't contain any more "inventory" on the name of the 
module,
  *   it was reduced drastically to consume from any existing inventory 
RFC/draft reference.
  *   Asset module cannot be eliminated from the DMLMO draft because it needs 
still to host the link to "entitlement" and "feature/usage".
  *   Asset represents refers to hardware, software, applications, or services. 
From my research, inventory related drafts are dedicated to hardware or 
software, independently, what means that we have to relay on the asset module 
to be able to make that reference.


The mentioned Incident-management draft has been recently submitted; from my 
reading the approach is different from the incident-management module in DMLMO:
https://datatracker.ietf.org/doc/draft-feng-opsawg-incident-management/
v00 released March-13 2023


In DMLMO, incident management module includes the incident management 
attributes to handle incidents. Where incident refers to the record and report 
of any problem the user has faced with the asset, feature or entitlement.




Many Thanks,
Marisol Palmero


From: Tianran Zhou 
mailto:zhoutianran=40huawei@dmarc.ietf.org>>
Date: Thursday, 16 March 2023 at 07:43
To: Marisol Palmero Amador (mpalmero) 
mailto:mpalm...@cisco.com>>, 
opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>, Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>>
Cc: Camilo Cardona 
mailto:juancamilo.card...@imdea.org>>, Frank 
Brockners (fbrockne) mailto:fbroc...@cisco.com>>, Diego R. 
Lopez mailto:diego.r.lo...@telefonica.com>>, 
Shwetha Bhandari 
mailto:shwetha.bhand...@thoughtspot.com>>, 
Sudhendu Kumar 
mailto:sudhendu.kumar@gmail.com>>, Eric 
Vyncke (evyncke) mailto:evyn...@cisco.com>>, 
inventory-y...@ietf.org<mailto:inventory-y...@ietf.org> 
mailto:inventory-y...@ietf.org>>, Jan Lindblad 
(jlindbla) mailto:jlind...@cisco.com>>
Subject: RE: New Version Notification for draft-palmero-opsawg-dmlmo-09.txt
Hi Marisol,

Thanks very much for this revision. It's good to see you think about the 
adaption to other inventory models.
Here I would like to raise my proposal on the inventory collaboration.
I think this draft covers too many things. My understanding, according to 
figure 1,  the focus should be on Entitlements and Usage.
The Asset has many overlap with the inventory model. I am thinking if you can 
just reuse the ietf inventory model, i.e., not to define a new asset.
So that, all the ietf models could build a big picture. The ietf inventory 
model can deal with the mapping to openconfig model.
So this draft can also reduce the mapping work.

I see there is a new specific  Incident draft 
"draft-feng-opsawg-incident-management".  Maybe you can also reuse this.

What's your thoughts?

Best,
Tianran


From: Inventory-yang [mailto:inventory-yang-boun...@ietf.org] On Behalf Of 
Marisol Palmero Amador (mpalmero)
Sent: Wednesday, January 18, 2023 1:58 AM
To: opsawg@ietf.org<mailto:opsawg@ietf.org>; Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>>
Cc: Camilo Cardona 
mailto:juancamilo.card...@imdea.org>>; Frank 
Brockners (fbrockne) mailto:fbroc...@cisco.com>>; Diego R. 
Lopez mailto:diego.r.lo...@telefonica.com>>; 
Shwetha Bhandari 
mailto:shwetha.bhand...@thoughtspot.com>>; 
Sudhendu Kumar 
mailto:sudhendu.kumar@gmail.com>>; Eric 
Vyncke (evyncke) mailto:evyn...@cisco.com>>; 
inventory-y...@ietf.org<mailto:inventory-y...@ietf.org>; Jan Lindblad 
(jlindbla) mailto:jlind...@cisco.com>>
Subject: [Inventory-yang] FW: New Version Notification for 
draft-palmero-opsawg-dmlmo-09.txt

Dear OPSA WG/AD,

We've just posted a 

[OPSAWG] WG adoption call for draft-palmero-opsawg-dmlmo-09

[Tianran Zhou]

Hi WG,

This mail we start a two weeks working group adoption call for:
https://datatracker.ietf.org/doc/draft-palmero-opsawg-dmlmo/

Please show your support or objection in the mailing list.
Any comment and suggestion is welcome.
As this draft is part of the inventory related work, suggestions on how to 
cooperate are expected.

The call will end on April 3.

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

[OPSAWG] IPR Poll on draft-palmero-opsawg-dmlmo-09

[Tianran Zhou]

Hi Authors and Contributors,

Accompany with the WG adoption on this draft, I'd like all authors and 
contributors to confirm on the list.
https://datatracker.ietf.org/doc/draft-palmero-opsawg-dmlmo/

Please respond if you are aware of any IPR related to this draft.
If you are aware of IPR, please indicate whether or not this has been disclosed 
per IETF IPR rules (see RFCs 3669, 5378, and 8179).

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

[OPSAWG] OPSAWG meeting agenda

[Tianran Zhou]

Hi WG,

We just posted the preliminary agenda for IETF116.
https://datatracker.ietf.org/doc/agenda-116-opsawg/

It's really great that we got so many requests.
We prepare the schedule by first come first serve. So there are 3 topics can 
only be presented when time allows.
Please check if there is anything missing.

The speaker please send over your slides before the meeting date.

Look forward to see you in Yokohama.

Cheers,
Tianran, Joe, Hank


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

Re: [OPSAWG] New Version Notification for draft-palmero-opsawg-dmlmo-09.txt

[Tianran Zhou]

Hi Marisol,

Thanks very much for this revision. It's good to see you think about the 
adaption to other inventory models.
Here I would like to raise my proposal on the inventory collaboration.
I think this draft covers too many things. My understanding, according to 
figure 1,  the focus should be on Entitlements and Usage.
The Asset has many overlap with the inventory model. I am thinking if you can 
just reuse the ietf inventory model, i.e., not to define a new asset.
So that, all the ietf models could build a big picture. The ietf inventory 
model can deal with the mapping to openconfig model.
So this draft can also reduce the mapping work.

I see there is a new specific  Incident draft 
"draft-feng-opsawg-incident-management".  Maybe you can also reuse this.

What's your thoughts?

Best,
Tianran


From: Inventory-yang [mailto:inventory-yang-boun...@ietf.org] On Behalf Of 
Marisol Palmero Amador (mpalmero)
Sent: Wednesday, January 18, 2023 1:58 AM
To: opsawg@ietf.org; Rob Wilton (rwilton) 
Cc: Camilo Cardona ; Frank Brockners (fbrockne) 
; Diego R. Lopez ; Shwetha 
Bhandari ; Sudhendu Kumar 
; Eric Vyncke (evyncke) ; 
inventory-y...@ietf.org; Jan Lindblad (jlindbla) 
Subject: [Inventory-yang] FW: New Version Notification for 
draft-palmero-opsawg-dmlmo-09.txt

Dear OPSA WG/AD,

We've just posted a new version, v09, for DMLMO, data model for lifecycle 
management and operations:
https://www.ietf.org/archive/id/draft-palmero-opsawg-dmlmo-09.txt

Where we have been addressing the comments given during OPSA WG meeting and 
inventory side meeting, part of IETF #115.

DMLMO version 09 is independent from inventory, where the DMLMO YANG modules, 
as specific ietf-lmo-assets YANG module, can consume from any other specific 
inventory YANG module(s). An example is given in Appendix A.

   version 09

   *  Rename "license" to "entitlement".

   *  renamed ietf-lmo-assets-inventory to ietf-lmo-assets.

   *  ietf-lmo-assets provides capability of integration and extention for a 
different approach on how to address inventory use cases. Process is explained 
in the Appendix A.

   *  ietf-lmo-example-mapping-XXX YANG modules accommodates the 
ietf-lmo-assets YANG module to any other inventory which will be required in 
the future to be referenced.

We greatly appreciate your thoughts, comments and evaluation.

Many thanks,
Marisol Palmero

From: internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>
Date: Tuesday, 17 January 2023 at 18:28
To: Camilo Cardona mailto:cam...@ntt.net>>, Diego Lopez 
mailto:diego.r.lo...@telefonica.com>>, Frank 
Brockners (fbrockne) mailto:fbroc...@cisco.com>>, Marisol 
Palmero Amador (mpalmero) mailto:mpalm...@cisco.com>>, 
Shwetha Bhandari 
mailto:shwetha.bhand...@thoughtspot.com>>, 
Sudhendu Kumar mailto:skuma...@ncsu.edu>>
Subject: New Version Notification for draft-palmero-opsawg-dmlmo-09.txt

A new version of I-D, draft-palmero-opsawg-dmlmo-09.txt
has been successfully submitted by Marisol Palmero and posted to the
IETF repository.

Name:   draft-palmero-opsawg-dmlmo
Revision:   09
Title:  Data Model for Lifecycle Management and Operations
Document date:  2023-01-17
Group:  Individual Submission
Pages:  80
URL:
https://www.ietf.org/archive/id/draft-palmero-opsawg-dmlmo-09.txt
Status: https://datatracker.ietf.org/doc/draft-palmero-opsawg-dmlmo/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-palmero-opsawg-dmlmo
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-palmero-opsawg-dmlmo-09

Abstract:
   This document motivates and specifies a data model for lifecycle
   management and operations.  It describes the motivation and
   requirements to collect asset-centric metrics including but not
   limited to asset adoption and usability, licensing, supported
   features and capabilities, enabled features and capabilities, etc.;
   with the primary objective to measure and improve the overall user
   experience along the lifecycle journey, from technical requirements
   and technology selection through advocacy and renewal, including the
   end of life of an asset.




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

[OPSAWG] Call for presentation//FW: [116all] IETF 116 Preliminary Agenda

[Tianran Zhou]

Hi WG,

The IETF116 preliminary agenda is posted.
The OPSAWG meeting is scheduled at 09:30 - 11:30 Tuesday Session I.
We open the call for presentation on the meeting.
Please send over your request with the topic, speaker, time slot to the chairs.

Look forward to seeing you in Yokohama.

Cheers,
Tianran

-Original Message-
From: 116all [mailto:116all-boun...@ietf.org] On Behalf Of IETF Agenda
Sent: Saturday, February 25, 2023 6:50 AM
To: IETF Announcement List 
Cc: i...@ietf.org; 116...@ietf.org
Subject: [116all] IETF 116 Preliminary Agenda

IETF 116
Yokohama, Japan
March 25-31, 2023
Hosted By: WIDE


The IETF 116 Preliminary Agenda has been posted. The final agenda will be 
published on Friday, March 3, 2023.

https://datatracker.ietf.org/meeting/116/agenda.html
https://datatracker.ietf.org/meeting/116/agenda.txt

The preliminary agenda includes all planned WG, RG, and BoF sessions. 
Information about side meetings will be available when the final agenda is 
posted. 

IETF 116 Information: https://www.ietf.org/how/meetings/116/
Register online at: https://registration.ietf.org/116/

Don’t forget to register for these exciting IETF 116 events!


Social Event

The Osanbashi Pier's multipurpose hall will be transformed into a wonderful 
social event location for IETF 116 attendees in Yokohama.

Attendees will be delighted by the music of internationally renowned artist 
Kaoru Watanabe, delicious food and a Japanese sake corner introducing attendees 
to sake from all thirteen sake breweries in Kanagawa Prefecture.

- Date: Thursday, March 30

- Start/End Times: 19:00 – 21:30

- Cost per ticket: $25 per ticket

- Limit of tickets per attendee: Two per attendee.

More information:
https://www.ietf.org/how/meetings/116/social/
https://ietf116.jp/social-event/ 


Hackathon 

Onsite signup: https://registration.ietf.org/116/new/hackathon_onsite/
Remote signup: https://registration.ietf.org/116/new/hackathon_remote/  
More information: https://www.ietf.org/how/runningcode/hackathons/116-hackathon/
Keep up to date by subscribing to: 
https://www.ietf.org/mailman/listinfo/hackathon


Code Sprint

More information and signups: https://notes.ietf.org/notes-ietf-116-tools#

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

[OPSAWG] Conclusion//RE: WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Tianran Zhou]

Hi WG,

This mail we conclude the adoption call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
It's cross reviewed by IPPM.
We received reasonable sufficient supports from both WGs. The discussion moved 
well.
We also collected all the IPR responses from the authors.
The working group will adopt this work.
The authors please submit the draft to datatracker with only the name changed 
to draft-ietf-opsawg-**.
And the authors please revise the document based on the discussions during the 
adoption call in the following update.

Cheers,
Tianran (as co-chair)

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Thursday, December 22, 2022 10:26 AM
To: opsawg@ietf.org
Cc: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/


Please reply your supports or objections.

We would really appreciate your comments.


Since there are holidays, this call will last for 3 weeks, and end on Thursday, 
Jan 12, 2023.

Cheers,
Tianran (as co-chairs)
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [ippm] 回复: FW: WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Tianran Zhou]

Hi Zhenqiang and Thomas,

Thanks very much for sharing your experience and the discussion in the mailing 
list.
IMO, whether to use gRPC or IPFIX is not a technique problem, but different 
choice/preference from users.
I agree with Zhenqiang our intention is not to have many options for the same 
feature.
But the world is diverse. Like we always have the same IGP extension for both 
OSPF and ISIS. At present I cannot see the dominance of one protocol.
I have practice on both gRPC and IPFIX. I believe both approaches can achieve 
this case.
Because this is neither large volume nor frequent.
The fast path will process delay per-packet, but the export will only work on 
mean/min/max delay.

Best,
Tianran

From: li_zhenqi...@hotmail.com [mailto:li_zhenqi...@hotmail.com]
Sent: Wednesday, January 11, 2023 4:23 PM
To: Benoit Claise ; thomas.g...@swisscom.com; Tianran 
Zhou ; ippm 
Cc: opsawg@ietf.org
Subject: Re: Re: [ippm] 回复: FW: WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hello Mr. Claise,

please see my comments beginning with [ZQ].


Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

发件人： Benoit Claise<mailto:benoit.cla...@huawei.com>
发送时间： 2023-01-10 05:15
收件人： thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>; 
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; 
zhoutianran=40huawei@dmarc.ietf.org<mailto:zhoutianran=40huawei@dmarc.ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>
抄送： opsawg@ietf.org<mailto:opsawg@ietf.org>
主题： Re: [ippm] 回复: FW: WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01
Dear all,

I agree with Thomas on a couple of points.

What is important is that, for accounting information, monitored at high 
frequency, such as IPFIX flow records metering data plane traffic, should be 
exported directly from line cards, without proxying to the route processor. As 
such, UDP is the way to go (*). On top of that, losing an export packet or two 
is not the end of the world.
In this case (draft-tgraf-opsawg-ipfix-on-path-telemetry-01), where we monitor 
delay over (all packets of) the flow record lifetime, it's the same principle: 
we need the UDP-based export. So the IPFIX protocol.
[ZQ] I don't think it is apropriate to limit the implementation especailly the 
internal software and hardware architecture when we define protocol. Our lab 
tests show gRPC works well for exporting the iOAM metrics and gRPC is TCP 
based. I am not sure whether or not  our vendors implement this by  proxying 
the collected data plane information to the route processor and then packeting 
and exporting all the relevant information to the colloctor. Why do we need to 
tell the vendors how to do it? From the specification point, IPFIX does not 
require UDP,  TCP based SCTP is a valid option.

[ZQ] I agree with you that the packets of iOAM flow should not be sampled, i.e. 
all packets of the flow need to be monitored.

Btw, the flow record lifetime is configurable, based on timers... in case you 
want to act on the delay (in the flow record) faster... at the cost of 
exporting more flow records.

[ZQ] iOAM metrics should be exported in seconds, in minutes is not acceptable. 
IPFIX exporting timer is usually in minutes.

Now, if we speak about events, this is a different story, as events needs to 
acted upon. So a reliable transport is required here.

Let's keep in mind that we speak about hybrid type I (see 
https://www.rfc-editor.org/rfc/rfc7799#section-3.8), so the issue of isolating 
the specific packets to look at at intermediate node is trivial.

(*) and this is the reason why SCTP, the compulsory export protocol in RFC 7011 
was never a success. See 
https://www.claise.be/from-netflow-to-ipfix-via-psamp-13-years-of-standardization-explained-2/

Regards, Benoit
On 1/9/2023 11:06 AM, thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> 
wrote:
Dear Zhenqiang,

See response inline.

Best wishes
Thomas

From: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> 
<mailto:li_zhenqi...@hotmail.com>
Sent: Monday, January 9, 2023 8:43 AM
To: Graf Thomas, INI-NET-VNC-HCS 
<mailto:thomas.g...@swisscom.com>; Tianran Zhou 
<mailto:zhoutianran=40huawei@dmarc.ietf.org>;
 ippm <mailto:i...@ietf.org>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: Re: RE: [ippm] 回复: FW: WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

DearThomas,

Please see my further discussion beginning with [ZQ].


Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

发件人： thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>
发送时间： 2023-01-07 01:23
收件人： li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; 
zhoutianran=40huawei@dmarc.ietf.org<mailto:zhoutianran=40huawei@dmarc.ietf.org>;
 i...@ietf.org&l

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Tianran Zhou]

Hi Thomas,

Thanks for your reply. Please see inline.

Cheers,
Tianran

From: thomas.g...@swisscom.com [mailto:thomas.g...@swisscom.com]
Sent: Thursday, January 5, 2023 9:22 PM
To: Tianran Zhou ; gregimir...@gmail.com
Cc: opsawg@ietf.org; draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org; 
i...@ietf.org
Subject: RE: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear Tianran,

Thanks a lot for your feedback. I understood that with 
draft-zhou-ippm-enhanced-alternate-marking we already have a document which 
intends to extend alternat path marking with timestamping. Very well.

Regarding IOAM-DEX. I was refereeing to the Section 3.2 of RFC 9326 
(https://datatracker.ietf.org/doc/html/rfc9326#section-3.2) where "Flags" and 
"Extension-Flags" are being described for IOAM Trace Option-Types. As you 
pointed out, we would need not only to add similar to 
https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.1 the bit 2 and 3 in 
the "Flags" field but also need to support similar to 
https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.2.3 and 
https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.2.4 the possibility 
to add the timestamps in the "Extension-Flags" field. This was he point you 
wanted to highlight correct?


ZTR> I think I understand how you can achieve. You can add to bits in 
"extension-flags" in rfc9326, as the knob to control the existence of 
timestamp, just like the flow id and sequence. Right?

Best wishes
Thomas

From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Sent: Wednesday, December 28, 2022 2:04 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 
mailto:thomas.g...@swisscom.com>>; 
gregimir...@gmail.com<mailto:gregimir...@gmail.com>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org<mailto:draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>
Subject: RE: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi Thomas,

Some comments to your reply.

> Alternate Marking does not describe a method were the timestamp is within the 
> packet

You can refer to the following draft, where you can get the timestamp you need.
https://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zhou-ippm-enhanced-alternate-marking%2F=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=sk2JFwgWOE1HuNrUR1f4DDtFq%2Feefsf55f%2B1wQ%2FZvsA%3D=0>

> In case of postcard mode that would have been the Direct Exporting (DEX) 
> IOAM-Option-Type 
> (https://datatracker.ietf.org/doc/html/rfc9326#section-3<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9326%23section-3=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=HKGG3eZAfuBQo690OK9C9%2BeNc%2B0bQnq0YmGow3RHX3M%3D=0>)
>  if bits 2 and 3 in flags field for the timestamps would be set able.

I do not think you can get the timestamp by setting Bit 2 and 3 in IOAM-DEX.

Cheers,
Tianran

From: thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> 
[mailto:thomas.g...@swisscom.com]
Sent: Tuesday, December 27, 2022 5:13 PM
To: gregimir...@gmail.com<mailto:gregimir...@gmail.com>; Tianran Zhou 
mailto:zhoutian...@huawei.com>>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org<mailto:draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>
Subject: RE: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear Greg,

Thanks a lot for the review and feedback.
?  as I understand it, the scope of this document is on reporting delay-related 
metrics based on the use of IOAM specifically. Is that correct understanding? 
If it is, reflecting that in the title might be helpful as other op-path 
telemetry methods, for example, Alternate Marking, might use a different set of 
IEs.
The document focuses solely on the IPFIX export of the on-path telemetry 
measured delay. However these delay measurements are on-path telemetry protocol 
agnostic and can be applied to IOAM, iFIT and path tracing as described in 
section 1 
(https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry-01#section-1<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-op

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Tianran Zhou]

Hi Thomas,

Some comments to your reply.

> Alternate Marking does not describe a method were the timestamp is within the 
> packet

You can refer to the following draft, where you can get the timestamp you need.
https://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking/

> In case of postcard mode that would have been the Direct Exporting (DEX) 
> IOAM-Option-Type (https://datatracker.ietf.org/doc/html/rfc9326#section-3) if 
> bits 2 and 3 in flags field for the timestamps would be set able.

I do not think you can get the timestamp by setting Bit 2 and 3 in IOAM-DEX.

Cheers,
Tianran

From: thomas.g...@swisscom.com [mailto:thomas.g...@swisscom.com]
Sent: Tuesday, December 27, 2022 5:13 PM
To: gregimir...@gmail.com; Tianran Zhou 
Cc: opsawg@ietf.org; draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org; 
i...@ietf.org
Subject: RE: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear Greg,

Thanks a lot for the review and feedback.
?  as I understand it, the scope of this document is on reporting delay-related 
metrics based on the use of IOAM specifically. Is that correct understanding? 
If it is, reflecting that in the title might be helpful as other op-path 
telemetry methods, for example, Alternate Marking, might use a different set of 
IEs.
The document focuses solely on the IPFIX export of the on-path telemetry 
measured delay. However these delay measurements are on-path telemetry protocol 
agnostic and can be applied to IOAM, iFIT and path tracing as described in 
section 1 
(https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry-01#section-1).
 To my knowledge, and please correct me if I am wrong, Alternate Marking does 
not describe a method were the timestamp is within the packet. If you feel that 
section 1 could be updated to make the scope more clearer, your feedback would 
be much appreciated.
?  I appreciate you using a picture (Figure 1) to illustrate the use case for 
IEs. It might be helpful for an operator to add more information about how IOAM 
is expected to be used. For example:

 *   IOAM Option Types that are applicable to the defined IEs;
 *   any special considerations using different IOAM Trace Option-Types;
 *   mandatory IOAM Trace-Type.
Very valid point. I think this would fit best in the operational considerations 
section. We have section 7.3 
(https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry-01#section-7.3)
 which focuses solely on timestamps at the moment. I agree that section 7 could 
be expanded to describe within IOAM to which IOAM Option Types the document 
applies.

In case of passport mode that would be the IOAM Edge-to-Edge Option-Type 
(https://datatracker.ietf.org/doc/html/rfc9197#section-4.6) with bits 2 and 3 
in flags fields for the timestamps set. Export would be only on the IOAM 
decapsulation node.

In case of postcard mode that would have been the Direct Exporting (DEX) 
IOAM-Option-Type (https://datatracker.ietf.org/doc/html/rfc9326#section-3) if 
bits 2 and 3 in flags field for the timestamps would be set able. We intend to 
prepare a separate IOAM DEX document describing this case. Export would be on 
the IOAM transit and decapsulation nodes.

Since IOAM Trace Option-Types 
(https://datatracker.ietf.org/doc/html/rfc9197#section-4.4) also supports bits 
2 and 3 in flags field for the timestamps, this document could be partially 
applied there as well. However all the fields described in section 4.2 of RFC 
9197 (https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.2) are IOAM 
specific and not covered in draft-tgraf-opsawg-ipfix-on-path-telemetry. We 
believe that draft-spiegel-ippm-ioam-rawexport 
(https://datatracker.ietf.org/doc/html/draft-spiegel-ippm-ioam-rawexport) is 
the appropriate document to cover these IPFIX entities. Export would be only on 
the IOAM decapsulation node.

I will prepare and update for after the adoption call and address this point as 
described. Feedback and comments welcome.

Best wishes
Thomas

From: Greg Mirsky mailto:gregimir...@gmail.com>>
Sent: Monday, December 26, 2022 9:22 PM
To: Tianran Zhou 
mailto:zhoutianran=40huawei@dmarc.ietf.org>>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org<mailto:draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org>
Subject: Re: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear All,
I read the latest version of the draft. I appreciate the work authors put into 
making the document clear and easy to read. Proposed IEs are essential for 
further developing an out-of-band collection of telemetry information. I 
strongly support the adoption of this work by the OPSAWG.
I have two notes to discuss (clearly non-blocking):

  *   as I understand it, the scope of this document is on reporting 
delay-related metrics based on the use of IOAM speci

[OPSAWG] IPR Poll on draft-tgraf-opsawg-ipfix-on-path-telemetry

[Tianran Zhou]

Hi Authors and Contributors,

Accompany with the WG adoption on this draft, I'd like all authors and 
contributors to confirm on the list.
Please respond if you are aware of any IPR related to this draft.
If you are aware of IPR, please indicate whether or not this has been disclosed 
per IETF IPR rules (see RFCs 3669, 5378, and 8179).

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

[OPSAWG] FW: WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Tianran Zhou]

Hi IPPM,

The OPSAWG just started a WG adoption call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/

There are performance metrics registrations within this draft.
We would really appreciate your comments from IPPM.

Thanks,
Tianran

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2022年12月22日 10:26
收件人: opsawg@ietf.org
抄送: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
主题: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/


Please reply your supports or objections.

We would really appreciate your comments.


Since there are holidays, this call will last for 3 weeks, and end on Thursday, 
Jan 12, 2023.

Cheers,
Tianran (as co-chairs)
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Tianran Zhou]

Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/


Please reply your supports or objections.

We would really appreciate your comments.


Since there are holidays, this call will last for 3 weeks, and end on Thursday, 
Jan 12, 2023.

Cheers,
Tianran (as co-chairs)
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Manifest need? Re: draft-claise-opsawg-collected-data-manifest

[Tianran Zhou]

A new idea just pop up.
How to control the manifest data?
Periodically, event?
What if the telemetry data is event triggered, not period?


Cheers,
Tianran
发件人: Benoit Claise
发送时间: 2022年12月8日 0:56
收件人: Alexander Clemm ; Tianran Zhou 
; opsawg@ietf.org
主题: Re: [OPSAWG] Manifest need? Re: draft-claise-opsawg-collected-data-manifest

Hi Alex,

Sorry for the delay in replying.

You are right in the sense we don't define new piece of information. I stressed 
it on the first slide during the IETF 115
•Goal is not to expose new information via YANG but rather to define what needs 
to be kept as metadata (or Data Manifest) to ensure that the data can still be 
interpreted correctly even:
–if the source device is not accessible (from the collection system)
–If the source device has been updated or has a new configuration


Let me make a distinction between two different use cases.
1. configuration management. The client knows every configuration parameters. 
No problem here
2. monitoring: device monitoring onboarding and network analytics

In case 2 (the focus of our draft), typically, new devices are installed in the 
network, and the analytics must be automatically consumed (assuming the 
telemetry is already configured) throughout the monitoring architecture:
1. YANG Push publisher (=router)
2. YANG Push receiver (=collector)
3. Message broker
4. TSDB
5. Analytic tool
Think of the IPFIX analogy (for which its onboarding is done automatically, as 
you send the template along with the data record).

Back to YANG push.
Yes, the telemetry receiver could query YANG models with information such as 
RFC8641 YANG module, YANG-library, software and hardware info, etc), and 
forward the information.
And yes, we could subscribe to YANG push subscription configuration data, or 
potentially other data.

What we want to achieve here is the ability for context information to follow 
the data, from 1 to 5 above, without explicit subscription (as Tianrian 
mentioned), in a standardized way.

Yes, we will clarify this in the draft. Thanks for your feedback.

Regards, Benoit
On 11/18/2022 5:39 PM, Alexander Clemm wrote:
So, saving the invocation of one command to establish the “meta-subscription”, 
that’s all this is for?  And for this we are asking implementors to create what 
is in effect redundant instrumentation?  This seems a lot of effort for a small 
saving.

As a thought, even in that case, would you even need a redundant YANG-data 
model, or would it make sense to instead augment the existing model with an 
additional parameter instead “provide manifest info”, which adds implicitly a 
subscription to the subscription info to the subscription itself?  Such an 
alternative could be accomplished by augmenting such a parameter into the 
existing model, and save the need to create YANG data instrumentation that is 
basically redundant, hence reduce the complexity of implementations.

--- Alex

From: Tianran Zhou <mailto:zhoutian...@huawei.com>
Sent: Thursday, November 17, 2022 10:49 PM
To: Alexander Clemm <mailto:a...@futurewei.com>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: RE: Manifest need? Re: draft-claise-opsawg-collected-data-manifest

Hi Alex,

I think this is a very good discussion. I raised this question before in the 
mailing list.
I think there may be some benefits:
1. The meta data can always go with the telemetry data, without explicit 
subscription. This facilitates the close loop automation.
2. Another subscription to the subscription information may make the management 
complex, since we put all the subscriptions in one list.

Best,
Tianran

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Alexander Clemm
发送时间: 2022年11月18日 7:40
收件人: opsawg@ietf.org<mailto:opsawg@ietf.org>
主题: [OPSAWG] Manifest need? Re: draft-claise-opsawg-collected-data-manifest

Hello draft-claise-opsawg-collected-data-manifest coauthors,

I just wanted to follow up on my comment at the microphone in London regarding 
draft-claise-opsawg-collected-data-manifest.

Clearly, there is a need to preserve context to be able to correctly interpret 
data after it has been collected.  That being said, as currently stated, the 
draft appears to overspecify some of those things, defining some YANG data that 
IMHO is not actually needed as the same can already be accomplished.  This 
concerns the specifics about the subscription itself.

RFC 8641 includes a YANG model that reflects for each subscription how it is 
configured (whether configured directly or established by RPC), including the 
selection filter, the update trigger, the period and anchor time (in case of 
periodic subscription), dampening periods and excluded changes (in case of 
on-change subscription), etc. The corresponding YANG data can be itself be 
subscribed to, or retrieved on demand, just like any other kind of YANG data.

I am therefore not quite sure what the proposed manifest would provide that 
couldn't be accomplished 

Re: [OPSAWG] Manifest need? Re: draft-claise-opsawg-collected-data-manifest

[Tianran Zhou]

Hi Nacho,

I am not sure if I really understand this argument.
There are different lines, like Yang push, gnmi, private implementations. If 
they cannot follow IETF subscription, i.e., Yang push, how could they follow an 
IETF manifest? I mean they will use their own way to indicate the collection 
information.
I mean I think we should only consider Yang push here.

Best,
Tianran



Sent from WeLink
发件人： Alexander Clemmmailto:a...@futurewei.com>>
收件人： IGNACIO DOMINGUEZ 
MARTINEZ-CASANUEVAmailto:ignacio.dominguezmarti...@telefonica.com>>;Tianran
 
Zhoumailto:zhoutian...@huawei.com>>;opsawgmailto:opsawg@ietf.org>>
主题： RE: [OPSAWG] Manifest need? Re: draft-claise-opsawg-collected-data-manifest
时间： 2022-11-22 02:09:12

Thank you for clarifying.  Yes, I think it will be good to make this more 
explicit to the draft (and perhaps hint also to at the alternative option of 
subscribing to the subscription configuration if it were only YANG-Push (as 
opposed to other mechanisms) that was being used, to more clearly differentiate 
the delta provided by this draft).
Best
--- Alex

From: IGNACIO DOMINGUEZ MARTINEZ-CASANUEVA 

Sent: Monday, November 21, 2022 4:58 AM
To: Alexander Clemm ; Tianran Zhou 
; opsawg@ietf.org
Subject: Re: [OPSAWG] Manifest need? Re: 
draft-claise-opsawg-collected-data-manifest

Hi Alex,

The purpose of the Data Collection Manifest is to cover all possible MDT 
mechanisms, not only YANG Push. There are other mechanisms like gNMI, which 
rely on subscriptions based on YANG path, for which we need the context of the 
subscription (e.g., on-change, suppress-redundancy). Additionally, vendors like 
Cisco or Huawei also implement other MDT mechanisms based on YANG Path.

For more details, you can follow an internal discussion he had on github: 
https://github.com/JeanQuilbeufHuawei/draft-collected-data-manifest/pull/30<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJeanQuilbeufHuawei%2Fdraft-collected-data-manifest%2Fpull%2F30=05%7C01%7Calex%40futurewei.com%7Cfc991751e54546b710f208dacbc010fe%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638046323051566819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=tCn666gG%2F5jeS3dCi6R5Xfxo0PVdzfBSeTkN0mMK7yE%3D=0>

In any case, I agree that we can better clarify this aspect in the draft.

Many thanks for your feedback!

Best regards,
Nacho.

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of Alexander Clemm mailto:a...@futurewei.com>>
Date: Friday, 18 November 2022 at 17:39
To: Tianran Zhou mailto:zhoutian...@huawei.com>>, 
"opsawg@ietf.org<mailto:opsawg@ietf.org>" 
mailto:opsawg@ietf.org>>
Subject: Re: [OPSAWG] Manifest need? Re: 
draft-claise-opsawg-collected-data-manifest

So, saving the invocation of one command to establish the “meta-subscription”, 
that’s all this is for?  And for this we are asking implementors to create what 
is in effect redundant instrumentation?  This seems a lot of effort for a small 
saving.

As a thought, even in that case, would you even need a redundant YANG-data 
model, or would it make sense to instead augment the existing model with an 
additional parameter instead “provide manifest info”, which adds implicitly a 
subscription to the subscription info to the subscription itself?  Such an 
alternative could be accomplished by augmenting such a parameter into the 
existing model, and save the need to create YANG data instrumentation that is 
basically redundant, hence reduce the complexity of implementations.

--- Alex

From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Sent: Thursday, November 17, 2022 10:49 PM
To: Alexander Clemm mailto:a...@futurewei.com>>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: RE: Manifest need? Re: draft-claise-opsawg-collected-data-manifest

Hi Alex,

I think this is a very good discussion. I raised this question before in the 
mailing list.
I think there may be some benefits:
1. The meta data can always go with the telemetry data, without explicit 
subscription. This facilitates the close loop automation.
2. Another subscription to the subscription information may make the management 
complex, since we put all the subscriptions in one list.

Best,
Tianran

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Alexander Clemm
发送时间: 2022年11月18日 7:40
收件人: opsawg@ietf.org<mailto:opsawg@ietf.org>
主题: [OPSAWG] Manifest need? Re: draft-claise-opsawg-collected-data-manifest

Hello draft-claise-opsawg-collected-data-manifest coauthors,

I just wanted to follow up on my comment at the microphone in London regarding 
draft-claise-opsawg-collected-data-manifest.

Clearly, there is a need to preserve context to be able to correctly interpret 
data after it has been collected.  That being said, as currently stated, the 
draft appears to overspecify some of those things, def

[OPSAWG] Selecting IETF Leadership

[Tianran Zhou]

Hi All,

Here is a notice from NOMCOM. Hope you could be aware and help.


The NomCom is tasked with selecting the IETF leadership, like the IESG and the 
IAB. For the NomCom to be able to make an informed decision, they need feedback 
from the wider IETF community.

Please, allocate some time to provide feedback on people that you interacted 
with to help the NomCom with their important task.

The deadline for this feedback is Nov 28.

https://datatracker.ietf.org/nomcom/2022/feedback/


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

Re: [OPSAWG] Manifest need? Re: draft-claise-opsawg-collected-data-manifest

[Tianran Zhou]

Hi Alex,

The authors may have more arguments.
Yes, I think a knob such as “provide manifest info” is a good idea for the YANG 
Push configuration.
On the other hand, please note, the proposed manifest is telemetry data, so 
that the collector can understand.

Best,
Tianran

发件人: Alexander Clemm [mailto:a...@futurewei.com]
发送时间: 2022年11月19日 0:39
收件人: Tianran Zhou ; opsawg@ietf.org
主题: RE: Manifest need? Re: draft-claise-opsawg-collected-data-manifest

So, saving the invocation of one command to establish the “meta-subscription”, 
that’s all this is for?  And for this we are asking implementors to create what 
is in effect redundant instrumentation?  This seems a lot of effort for a small 
saving.

As a thought, even in that case, would you even need a redundant YANG-data 
model, or would it make sense to instead augment the existing model with an 
additional parameter instead “provide manifest info”, which adds implicitly a 
subscription to the subscription info to the subscription itself?  Such an 
alternative could be accomplished by augmenting such a parameter into the 
existing model, and save the need to create YANG data instrumentation that is 
basically redundant, hence reduce the complexity of implementations.

--- Alex

From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Sent: Thursday, November 17, 2022 10:49 PM
To: Alexander Clemm mailto:a...@futurewei.com>>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: RE: Manifest need? Re: draft-claise-opsawg-collected-data-manifest

Hi Alex,

I think this is a very good discussion. I raised this question before in the 
mailing list.
I think there may be some benefits:
1. The meta data can always go with the telemetry data, without explicit 
subscription. This facilitates the close loop automation.
2. Another subscription to the subscription information may make the management 
complex, since we put all the subscriptions in one list.

Best,
Tianran

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Alexander Clemm
发送时间: 2022年11月18日 7:40
收件人: opsawg@ietf.org<mailto:opsawg@ietf.org>
主题: [OPSAWG] Manifest need? Re: draft-claise-opsawg-collected-data-manifest

Hello draft-claise-opsawg-collected-data-manifest coauthors,

I just wanted to follow up on my comment at the microphone in London regarding 
draft-claise-opsawg-collected-data-manifest.

Clearly, there is a need to preserve context to be able to correctly interpret 
data after it has been collected.  That being said, as currently stated, the 
draft appears to overspecify some of those things, defining some YANG data that 
IMHO is not actually needed as the same can already be accomplished.  This 
concerns the specifics about the subscription itself.

RFC 8641 includes a YANG model that reflects for each subscription how it is 
configured (whether configured directly or established by RPC), including the 
selection filter, the update trigger, the period and anchor time (in case of 
periodic subscription), dampening periods and excluded changes (in case of 
on-change subscription), etc. The corresponding YANG data can be itself be 
subscribed to, or retrieved on demand, just like any other kind of YANG data.

I am therefore not quite sure what the proposed manifest would provide that 
couldn't be accomplished already.  The suggestion to retain the subscription 
data along with the subscribed data makes a lot of sense but would appear to be 
a practice that will be up to the management application to implement, with the 
mechanism already provided.  (This could of course be included as a description 
of a recommended practice in the draft.)  Or is there something else that is 
missing?

If there is indeed a delta that cannot be otherwise accomplished, my suggestion 
would be to add text to the draft that clearly describes the possibility of 
subscribing to subscription configuration data, then explaining the functional 
delta that your draft covers in addition to that.

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

Re: [OPSAWG] Manifest need? Re: draft-claise-opsawg-collected-data-manifest

[Tianran Zhou]

Hi Alex,

I think this is a very good discussion. I raised this question before in the 
mailing list.
I think there may be some benefits:
1. The meta data can always go with the telemetry data, without explicit 
subscription. This facilitates the close loop automation.
2. Another subscription to the subscription information may make the management 
complex, since we put all the subscriptions in one list.

Best,
Tianran

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Alexander Clemm
发送时间: 2022年11月18日 7:40
收件人: opsawg@ietf.org
主题: [OPSAWG] Manifest need? Re: draft-claise-opsawg-collected-data-manifest

Hello draft-claise-opsawg-collected-data-manifest coauthors,

I just wanted to follow up on my comment at the microphone in London regarding 
draft-claise-opsawg-collected-data-manifest.

Clearly, there is a need to preserve context to be able to correctly interpret 
data after it has been collected.  That being said, as currently stated, the 
draft appears to overspecify some of those things, defining some YANG data that 
IMHO is not actually needed as the same can already be accomplished.  This 
concerns the specifics about the subscription itself.

RFC 8641 includes a YANG model that reflects for each subscription how it is 
configured (whether configured directly or established by RPC), including the 
selection filter, the update trigger, the period and anchor time (in case of 
periodic subscription), dampening periods and excluded changes (in case of 
on-change subscription), etc. The corresponding YANG data can be itself be 
subscribed to, or retrieved on demand, just like any other kind of YANG data.

I am therefore not quite sure what the proposed manifest would provide that 
couldn't be accomplished already.  The suggestion to retain the subscription 
data along with the subscribed data makes a lot of sense but would appear to be 
a practice that will be up to the management application to implement, with the 
mechanism already provided.  (This could of course be included as a description 
of a recommended practice in the draft.)  Or is there something else that is 
missing?

If there is indeed a delta that cannot be otherwise accomplished, my suggestion 
would be to add text to the draft that clearly describes the possibility of 
subscribing to subscription configuration data, then explaining the functional 
delta that your draft covers in addition to that.

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

Re: [OPSAWG] [ippm] New Version Notification for draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt

[Tianran Zhou]

Hi Benoit,

Transit is just transit. It’s clear enough. There is no need to say IOAM 
transit. And I do not see the need to reinvent.
We see these IPFIX extensions are generic for hybrid measurement. So do not use 
a specific term like IOAM.

Best,
Tianran




Sent from WeLink
发件人： Benoit 
Claisemailto:benoit.claise=40huawei@dmarc.ietf.org>>
收件人： Tianran 
Zhoumailto:zhoutianran=40huawei@dmarc.ietf.org>>;Thomas.Grafmailto:thomas.g...@swisscom.com>>;opsawgmailto:opsawg@ietf.org>>;ippmmailto:i...@ietf.org>>
抄送： 
pierre.francoismailto:pierre.franc...@insa-lyon.fr>>
主题： Re: [ippm] New Version Notification for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt
时间： 2022-10-22 15:18:40

Hi Tianran,

IPFIX is composed of two components:
1. The IPFIX Metering Process
2. The IPFIX Exporting Process

This draft focuses only on 2.
However, we needed some specific terms to express the IPIFX Metering
Process location. As an example, see "transit" in the abstract.
It does not make sense to re-invent some new terms to be "independent of
specific on-path telemetry protocols.", as you wrote.
Hence we selected the IOAM terminology.

I hope this clarifies.

Regards, Benoit
On 10/21/2022 9:29 AM, Tianran Zhou wrote:
> Hi Thomas,
>
> Only looking at the abstraction, I think you do not get Greg's comment on 
> on-path telemetry.
> IMO, this IPFIX extension should only focus on the data export, while 
> independent of specific on-path telemetry protocols.
> The following draft is a very useful reference for on path telemetry:
> https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/18/
>
> " On-Path Telemetry (OPT) refers to data-plane telemetry techniques that 
> directly tap and
> measure network traffic by embedding instructions or metadata into
> user packets. "
>
> " It is essential to recognize that existing work on this topic includes a 
> variety of on-path telemetry
> techniques, including In-situ OAM (IOAM) [RFC9197], IOAM Direct Export 
> (DEX) [I-D.ietf-ippm-ioam-direct-export], Marking-based
> Postcard-based Telemetry (PBT-M)[I-D.song-ippm-postcard-based-telemetry], 
> Enhanced Alternate Marking
> (EAM) [I-D.zhou-ippm-enhanced-alternate-marking], and Hybrid Two-Step 
> (HTS) [I-D.mirsky-ippm-hybrid-two-step], have been developed or
> proposed. "
>
> Hope this is useful for you.
>
> Cheers,
> Tianran
> -Original Message-
> From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of 
> thomas.g...@swisscom.com
> Sent: Thursday, October 20, 2022 9:42 PM
> To: opsawg@ietf.org; i...@ietf.org
> Cc: pierre.franc...@insa-lyon.fr
> Subject: Re: [ippm] New Version Notification for 
> draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt
>
> Dear OPSAWG and IPPM,
>
> On behalf of the authors. Thank you very much for the comments at IETF 114 in 
> Philadelphia and on the list.
>
> We addressed your feedback in a new document version and renamed the draft 
> document from draft-tgraf-opsawg-ipfix-inband-telemetry to 
> draft-tgraf-opsawg-ipfix-on-path-telemetry. Thanks Greg for the input.
>
> Looking forward to your reviews and comments.
>
> Best wishes
> Thomas
>
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Thursday, October 20, 2022 3:32 PM
> To: Alex Feng ; Alex Huang Feng 
> ; Benoit Claise ; 
> Graf Thomas, INI-NET-TCZ-ZH1 
> Subject: New Version Notification for 
> draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt
>
>
> A new version of I-D, draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt
> has been successfully submitted by Thomas Graf and posted to the IETF 
> repository.
>
> Name: draft-tgraf-opsawg-ipfix-on-path-telemetry
> Revision: 00
> Title:Export of On-Path Delay in IPFIX
> Document date:2022-10-20
> Group:Individual Submission
> Pages:22
> URL:
> https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry
> Diff:  
> https://www.ietf.org/rfcdiff?url1=draft-tgraf-opsawg-ipfix-inband-telemetry-01=draft-tgraf-opsawg-ipfix-on-path-telemetry-00=--html
>
> Abstract:
> This document introduces new IP Flow Information Export (IPFIX)
> information elements to expose the On-Path Telemetry measured delay
> on the IOAM transit and decapsulation nodes.
>
>
>
>
> The IETF Secretariat
>
> ___
> ippm mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm

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

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

[OPSAWG] OPSAWG Preliminary Agenda

[Tianran Zhou]

Hi WG,

The preliminary agenda is just posted.
https://datatracker.ietf.org/meeting/115/materials/agenda-115-opsawg-00

Please see if there is anything missing.
The speakers please send over your slides before the meeting.
Look forward to seeing you in London.

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

Re: [OPSAWG] New Version Notification for draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt

[Tianran Zhou]

Hi Thomas,

Only looking at the abstraction, I think you do not get Greg's comment on 
on-path telemetry.
IMO, this IPFIX extension should only focus on the data export, while 
independent of specific on-path telemetry protocols.
The following draft is a very useful reference for on path telemetry:
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/18/

" On-Path Telemetry (OPT) refers to data-plane telemetry techniques that 
directly tap and
   measure network traffic by embedding instructions or metadata into
   user packets. "

" It is essential to recognize that existing work on this topic includes a 
variety of on-path telemetry
   techniques, including In-situ OAM (IOAM) [RFC9197], IOAM Direct Export (DEX) 
[I-D.ietf-ippm-ioam-direct-export], Marking-based
   Postcard-based Telemetry (PBT-M)[I-D.song-ippm-postcard-based-telemetry], 
Enhanced Alternate Marking
   (EAM) [I-D.zhou-ippm-enhanced-alternate-marking], and Hybrid Two-Step (HTS) 
[I-D.mirsky-ippm-hybrid-two-step], have been developed or
   proposed. "

Hope this is useful for you.

Cheers,
Tianran
-Original Message-
From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of thomas.g...@swisscom.com
Sent: Thursday, October 20, 2022 9:42 PM
To: opsawg@ietf.org; i...@ietf.org
Cc: pierre.franc...@insa-lyon.fr
Subject: Re: [ippm] New Version Notification for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt

Dear OPSAWG and IPPM,

On behalf of the authors. Thank you very much for the comments at IETF 114 in 
Philadelphia and on the list. 

We addressed your feedback in a new document version and renamed the draft 
document from draft-tgraf-opsawg-ipfix-inband-telemetry to 
draft-tgraf-opsawg-ipfix-on-path-telemetry. Thanks Greg for the input.

Looking forward to your reviews and comments.

Best wishes
Thomas

-Original Message-
From: internet-dra...@ietf.org  
Sent: Thursday, October 20, 2022 3:32 PM
To: Alex Feng ; Alex Huang Feng 
; Benoit Claise ; Graf 
Thomas, INI-NET-TCZ-ZH1 
Subject: New Version Notification for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt


A new version of I-D, draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt
has been successfully submitted by Thomas Graf and posted to the IETF 
repository.

Name:   draft-tgraf-opsawg-ipfix-on-path-telemetry
Revision:   00
Title:  Export of On-Path Delay in IPFIX
Document date:  2022-10-20
Group:  Individual Submission
Pages:  22
URL:
https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry
Diff:  
https://www.ietf.org/rfcdiff?url1=draft-tgraf-opsawg-ipfix-inband-telemetry-01=draft-tgraf-opsawg-ipfix-on-path-telemetry-00=--html

Abstract:
   This document introduces new IP Flow Information Export (IPFIX)
   information elements to expose the On-Path Telemetry measured delay
   on the IOAM transit and decapsulation nodes.


  


The IETF Secretariat

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

Re: [OPSAWG] Call for presentation//FW: IETF 115 Preliminary Agenda

[Tianran Zhou]

Hi Michael,

Your request is received. I think this is good to discuss.
What’s the slot you need for this?

Cheers,
Tianran






Sent from WeLink
发件人： Michael Richardsonmailto:mcr+i...@sandelman.ca>>
收件人： Tianran 
Zhoumailto:zhoutian...@huawei.com>>;opsawgmailto:opsawg@ietf.org>>;OpsAWG-Chairsmailto:opsawg-cha...@ietf.org>>
主题： Re: [OPSAWG] Call for presentation//FW: IETF 115 Preliminary Agenda
时间： 2022-10-12 04:23:59


Tianran Zhou  wrote:
> The IETF 115 preliminary agenda is posted.
> The OPSAWG meeting is currently scheduled at 09:30-11:30 Wednesday 
Session I.
> We open the call for presentation.
> Please send over your request to the chairs.
> And please arrange your travel if you are going to join the meeting 
on-site.

I would like to talk about the MUD documents that have been lingering.

Would the WG like to proceed with:
1. 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/
-and/or-
2. https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-acceptable-urls/

The second has less controversy, and it updates 8520 in an important way.
I feel that both have had extensive review.

The first has had a number of reviews that essentially question the entire
RFC8520 process, how IoT device are deployed, and asks us to restart IoT
deployment from scratch.   All good ideas, but the barn doors have been open
for a decade, and the horses are long gone.  This document simply tries to
keep the horses from jumping off cliffs.






--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide




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

[OPSAWG] Call for presentation//FW: IETF 115 Preliminary Agenda

[Tianran Zhou]

Hi WG,

The IETF 115 preliminary agenda is posted.
The OPSAWG meeting is currently scheduled at 09:30-11:30 Wednesday Session I.
We open the call for presentation.
Please send over your request to the chairs.
And please arrange your travel if you are going to join the meeting on-site.

Cheers,
Tianran

-Original Message-
From: WGChairs [mailto:wgchairs-boun...@ietf.org] On Behalf Of IETF Agenda
Sent: Saturday, October 8, 2022 5:49 AM
To: Working Group Chairs 
Subject: IETF 115 Preliminary Agenda

IETF 115
London, UK
November 5-11, 2022
Hosted By: Cisco


The IETF 115 preliminary agenda has been posted. The final agenda will be 
published on Friday, October 14, 2022.  

If you would like to request a change to the preliminary agenda, please send a 
message to supp...@ietf.org and copy all relevant Area Directors.

https://datatracker.ietf.org/meeting/115/agenda.html
https://datatracker.ietf.org/meeting/115/agenda.txt


The preliminary agenda includes all planned WG, RG, and BoF sessions. 
Information about side meetings will be available when the final agenda is 
posted. 

Thank you!

IETF Secretariat

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

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

[Tianran Zhou]

Hi Michael,

Thank you very much for your contribution!

Cheers,
Tianran






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

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

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


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

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

[Tianran Zhou via Datatracker]

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

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


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

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

[Tianran Zhou via Datatracker]

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

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


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

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

[Tianran Zhou]

Thanks Med for your contribution!
Let’s move forward.

Cheers,
Tianran



Sent from WeLink
发件人： 
mohamed.boucadairmailto:mohamed.boucad...@orange.com>>
收件人： Jean 
Quilbeufmailto:jean.quilbeuf=40huawei@dmarc.ietf.org>>
抄送： opsawgmailto:opsawg@ietf.org>>
主题： Re: [OPSAWG] I-D Action: draft-ietf-opsawg-service-assurance-yang-07.txt
时间： 2022-08-29 20:13:32

Hi Jean,

The new version fixes the pending issues I had with -06. This version is ready 
to move forward. Thanks for your effort.

Cheers,
Med

PS: Apologies for the delay to check the changes (out of office).

> -Message d'origine-
> De : OPSAWG  De la part de Jean Quilbeuf
> Envoyé : mercredi 10 août 2022 15:09
> À : opsawg@ietf.org; i-d-annou...@ietf.org
> Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-service-
> assurance-yang-07.txt
>
> Dear OPSAWG,
> This new version addresses the comments from Mohamed Boucadair and
> from the YANG doctor early review.
>
> Best,
> Jean
>
> > -Original Message-
> > From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of
> internet-
> > dra...@ietf.org
> > Sent: Wednesday 10 August 2022 14:07
> > To: i-d-annou...@ietf.org
> > Cc: opsawg@ietf.org
> > Subject: [OPSAWG] I-D Action:
> > draft-ietf-opsawg-service-assurance-yang-
> > 07.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   : YANG Modules for Service Assurance
> > Authors : Benoit Claise
> >   Jean Quilbeuf
> >   Paolo Lucente
> >   Paolo Fasano
> >   Thangam Arumugam
> >   Filename: draft-ietf-opsawg-service-assurance-yang-
> 07.txt
> >   Pages   : 42
> >   Date: 2022-08-10
> >
> > Abstract:
> >This document specifies YANG modules for representing
> assurance
> >graphs.  These graphs represent the assurance of a given
> service by
> >decomposing it into atomic assurance elements called
> subservices.  A
> >companion document, Service Assurance for Intent-based
> Networking
> >Architecture, presents an architecture for implementing the
> assurance
> >of such services.
> >
> >The YANG data models in this document conforms to the Network
> >Management Datastore Architecture (NMDA) defined in RFC 8342.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-
> assurance-y
> > ang/
> >
> > There is also an htmlized version available at:
> > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-
> assura
> > nce-
> > yang-07
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-
> assurance-
> > yang-07
> >
> >
> > Internet-Drafts are also available by rsync at
> > rsync.ietf.org::internet-drafts
> >
> >
> > ___
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

_

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

Re: [OPSAWG] [spring] FW: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-04.txt

[Tianran Zhou]

Hi Thomas,
Thanks for your reply.
Please see inline.

Cheers,
Tianran

-Original Message-
From: thomas.g...@swisscom.com [mailto:thomas.g...@swisscom.com] 
Sent: Tuesday, July 26, 2022 4:32 AM
To: Tianran Zhou ; 
benoit.claise=40huawei@dmarc.ietf.org; spr...@ietf.org; opsawg@ietf.org
Cc: pierre.franc...@insa-lyon.fr
Subject: RE: [spring] FW: New Version Notification for 
draft-tgraf-opsawg-ipfix-srv6-srh-04.txt

Hi Tianran,

Thanks a lot for the review and comments. 

Regarding your question why it is a standards and not a informational document. 
We consulted with the IPFIX IE doctors and went for a standards document 
because we create a new IPFIX registry: "IPFIX IPv6 SRH Flags" subregistry. We 
will follow the recommendations from the WG chair, IPFIX IE doctors, and AD.

ZTR> Yes, I noticed this. I tend to agree with you on a standard track.

As per your suggestion we found two cases were it should be "MUST" instead of 
"must" and will address it in the next draft version and do a normative 
reference to RFC 2119. 

Before: This doesn't impose any data flow manipulation on the exporter, 
facilitating the immediate export. However, the data collection must be able to 
decode the IPv6 addresses according the SR specifications. Compared to the 
srhSegmentIPv6BasicList, the srhSegmentIPv6ListSection flow records length is 
slightly reduced.
New: This doesn't impose any data flow manipulation on the exporter, 
facilitating the immediate export. However, the data collection MUST be able to 
decode the IPv6 addresses according the SR specifications. Compared to the 
srhSegmentIPv6BasicList, the srhSegmentIPv6ListSection flow records length is 
slightly reduced.

Before: The Length must be calculated to include the optional Type Length Value 
objects.
New: The Length MUST be calculated to include the optional Type Length Value 
objects.

ZTR> Thanks for considering my suggestions. I am OK with this.

Best wishes
Thomas

-Original Message-
From: Tianran Zhou  
Sent: Monday, July 25, 2022 5:16 AM
To: Benoit Claise ; Graf Thomas, 
INI-NET-TCZ-ZH1 ; spr...@ietf.org; opsawg@ietf.org
Cc: pierre.franc...@insa-lyon.fr
Subject: RE: [spring] FW: New Version Notification for 
draft-tgraf-opsawg-ipfix-srv6-srh-04.txt

Hi Benoit,

Thanks for bringing this up.
I have been monitoring the discussions on this draft in SPRING and OPSAWG.
As I suggested, please copy your discussions to OPSAWG also, so that we know 
the progress.

Basically, this draft is simple and straight forward. It's quite similar to 
rfc9160 also produced by OPSAWG. 
Here are some of my comments:
1. I see the use case section is still rather simple. I am not sure if you have 
plan to expand. IMO, more details on how to use the proposed IEs is very useful 
and builds an important part of this document.
2. We can discuss the "Intended status" of this draft, as a similar document 
rfc9160 is informational. I searched the shepherd review of rfc9160, and there 
is the following record:
 The intended status is justified given that the document includes
 informative use cases to illustrate the use of the new types
 and it does not include any normative statements. Moreover, the
 registration policy for the target IANA registry (MPLS label types)
 is "Expert Review".

So, if it's the same situation here?

3. I see many lowercase "must" appears in the draft. Please check if some of 
them should be "MUST".

Cheers,
Tianran

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Benoit Claise
Sent: Tuesday, July 19, 2022 2:42 PM
To: thomas.g...@swisscom.com; spr...@ietf.org
Cc: pierre.franc...@insa-lyon.fr
Subject: Re: [spring] FW: New Version Notification for 
draft-tgraf-opsawg-ipfix-srv6-srh-04.txt

Dear all,

Note that the authors will request WG adoption in the OPSAWG next week.
So feel free to join that meeting and/or post your comments via email.

Regards, Benoit

On 6/29/2022 6:53 AM, thomas.g...@swisscom.com wrote:
> Dear spring working group,
>
> draft-tgraf-opsawg-ipfix-srv6-srh defines new IPFIX entities where the SRH 
> and associated control-plane related dimensions are exposed to enable SRv6 
> data-plane visibility.
>
> The draft has been introduced and presented at IETF 113 to OPSAWG and SPRING 
> where we collected the first comments and requested adoption at OPSAWG.
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F113%2Fmaterials%2Fslides-113-opsawg-export-of-segment-routing-ipv6-information-in-ipfix-01data=05%7C01%7CThomas.Graf%40swisscom.com%7Cc18fbb1e9fda48b71c6408da6e1e5884%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637943373849634565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=mCoyzP3JTr5Nw8OtAEQMjHiZMnS9sQ%2BiqOcQ7WqCIO8%3Dreserved=0
>
> We j

[OPSAWG] FW: Full list of volunteers so far

[Tianran Zhou]

You support is really appreciated.


Tianran


Sent from WeLink
发件人： NomCom Chair 
2022mailto:nomcom-chair-2...@ietf.org>>
收件人： IETF Announcement 
Listmailto:ietf-annou...@ietf.org>>
抄送： ietfmailto:i...@ietf.org>>
主题： Full list of volunteers so far
时间： 2022-07-16 01:53:11

With help from Robert Sparks of the tools team, and Ryan Cross of AMS, here is 
the full list of people who have volunteered to be on NomCom. This is both 
those who signed up via the link [1] and those who checked the box when they 
registered for the upcoming meeting.

There are 284 volunteers, and FYI all but six qualified under at least the 
"path 1" option.  I am posting the interim list because multiple people 
suggested it might give others incentive to volunteer. The final call will be 
issued next week, and closes next Friday. Early next week I will announce the 
random seeds. Choices will be made during IETF week, and the challenge period 
will then begin.

[1] https://datatracker.ietf.org/nomcom/volunteer

Plain Name,Affiliation,Qualifications
Aaron Ding,TU Delft,1
Aaron Falk,Akamai Technologies,1+2
Adam W. Montville,Center for Internet Security,1
Adnan Rashid,University of Florence,1
Afzal Ali S,Hrblock,1
Ahmed Abdelsalam,Cisco,1
Aihua Liu,Shenzhen Zhongxing Software Company Limited,1
Aijun Wang,China Telecom,1+3
Akira Tsukamoto,AIST (The National Institute of Advanced Industrial Science and 
Technology Japan),1
AlbertoRodriguezNatal,Cisco,1
Alexander Clemm,Futurewei,1+3
Alissa Cooper,Cisco,1
Allison Mankin,Salesforce,1+2+3
Ameya Deshpande,NITK Surathkal,1
Andrew Campling,419 Consulting Ltd,1
Ani Arya,,1
Annajiat_Alim Rasel,Brac University,1
Anthony Nadalin,Pacific Northwest University,3
Anuj Budhiraja,Cisco,1
Ari Keranen,Ericsson,1+2+3
Barry Leiba,Futurewei Technologies,1+2+3
Behcet Sarikaya,None,1+3
Benjamin Kaduk,Akamai Technologies,1+2
Benjamin M. Schwartz,Google / Jigsaw,1+2
Benno Overeinder,NLnet Labs,1+2
Bernard Aboba,Microsoft Corporation,1+2
Bill Woodcock,Packet Clearing House,1
Bingyang Liu,Huawei,1
Bo Wu,Huawei Technologies,1
Bob Briscoe,Independent (bobbriscoe.net Ltd),1
Brian Rosen,,1+2+3
Bron Gondwana,Fastmail,1+2+3
Bruno Teixeira,,1
Cedric Westphal,Futurewei USA,1
Charles Eckel,Cisco,1+2
Cheng Li,Huawei,1+3
Chi-Yuan Chen,National Ilan University,1
Ching-Heng Ku,Taiwan Network Information Center,1
Chonggang Wang,InterDigital,1
Chris Box,BT,1+2
Chris Lemmons,Comcast,1
Christian Hopps,"LabN Consulting, LLC",1+2+3
Christian Huitema,Private Octopus Inc.,1+3
Christopher Inacio,Carnegie Mellon,1
Colin Whorlow,NCSC,1
Corinna Schmitt,"Universitaet der Bundeswehr Muenchen, RI CODE",1
Daniel Havey,Microsoft,1
Daniel Huang,Nanjing Zhongxing Software Company Limited,1
Daniel King,Lancaster University,1+3
Daniel Migault,Ericsson,1+2+3
Daniele Ceccarelli,Ericsson AB,1+2+3
Darren Dukes,Cisco Systems,1
David Guzman,Technische Universitaet Muenchen,1
David Lake,DELL Technologies,1
David Sinicrope,Ericsson,1+2
Dawei Fan,Huawei,1
Dean Bogdanovic,"Alef Edge, Inc.",1+3
Dhruv Dhody,Huawei Technologies India Pvt. Ltd.,1+2+3
Dieter Beller,Nokia,1
Dimitris Maroulidis,Technical University of Crete,1
Donald E. Eastlake 3rd,Futurewei Technologies,1+2+3
eanas,no,1
Eberhard Lisse,Namibian Network Information Center (Pty) Ltd,1
Ehsan Rezaaifar,Nokia,1
Eliot Lear,Cisco,1+3
Emiliano Spinella,Syndeno,1
Eric Brunner-Williams,none,1
Eric Rescorla,Mozilla,1+3
Fady,,1
Fan Yang,Huawei Technologies,1
Fanghong Duan,Huawei,1
Fernando Gont,SI6 Networks,3
Francois Clad,Cisco Systems,1
Frank Anati,Ghana Health Service,1
Fred Baker,ISC,1+2+3
Gabriel Montenegro,Samsung Research America (consultant),1
Geoff Huston,APN IC,1+3
George G. Michaelson,APNIC P/L,1+3
Georgios Karagiannis,Huawei,1
Giuseppe Fioccola,Huawei Technologies,1+3
GNANAJEYARAMAN RAJARAM,SBM COLLEGE OF ENGINEERING AND TECHNOLOGY,1
Goeran Selander,Ericsson,1+3
Gonzalo Salgueiro,Cisco,1+2+3
Greg Mirsky,Ericsson,1+3
Greg Shepherd,,1+2
Guangpeng Li,Huawei,1
Haibo Wang,Huawei,1
Haiyang Su,"Huawei Technologies Co.,Ltd",1
Hannes Tschofenig,Arm Limited,1+2+3
Hannu Flinck,Nokia,1
Haomian Zheng,"Huawei Technologies Co., Ltd.",1+3
Haoyu Song,Futurewei Technologies,1
Henk Birkholz,Fraunhofer SIT,1+2+3
Herman Ramos,Inaglobe,1
Hooman Bidgoli,Nokia,1
Huaimo Chen,Futurewei,1+3
Ian Swett,Google,1+2
Ignas Bagdonas,Equinix,1
Ines Robles,,1+2
Italo Busi,Huawei,1
Jaehoon Paul Jeong,Sungkyunkwan University,1+3
Jaime Jimenez,Ericsson,1+2
James Cumming,Nokia,1
James Gruessing,Nederlandse Publiek Omroep,1+2
Jason Sterne,Nokia,1
Jeff Tantsura,Microsoft,1+2+3
Jeffrey Haas,Juniper Networks,1+2+3
Jeffrey Yasskin,Google Chrome,1
Jenny Bui,AMSL,1
Jianfei(Jeffrey) HE,City University of Hong Kong,1
Jie Dong,Huawei Technologies,1+2+3
Jim Guichard,,1+2
Jim Reid,,1
Jingrong Xie,Huawei,1
Joel Jaeggli,fastly,1+2
Joey Salazar,n/a,1+2
John Drake,Juniper Networks,1+3
John Preuss Mattsson,Ericsson,1+3
Jon Hudson,Desnet Industries & Spaced Out Radio,1
Jordan Head,Juniper Networks,1
Jorge 

Re: [OPSAWG] Call for presentation

[Tianran Zhou]

Hi WG,

I just uploaded our preliminary agenda.
https://datatracker.ietf.org/meeting/114/materials/agenda-114-opsawg-00

Please contact me if there is anything missing.
The speakers please send over your slides before the meeting.

Cheers,
Tianran


From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Monday, June 27, 2022 10:35 AM
To: opsawg@ietf.org
Subject: [OPSAWG] Call for presentation

Hi WG,

IETF 114 Preliminary Agenda is posted.
https://datatracker.ietf.org/meeting/114/agenda.html

OPSAWG meeting is at 10:00-12:00 Friday Session I.

Please send over your request for time slot to the chairs.

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

[OPSAWG] call for document shepherd//RE: Conclude the WGLC for SAIN

[Tianran Zhou]

Hi WG,

We also seek for document shepherd for the both SAIN drafts.
Please contact me if you have interest.
Your help and contribution are really appreciated.

Cheers,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Monday, July 11, 2022 2:11 PM
To: opsawg@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: [OPSAWG] Conclude the WGLC for SAIN

Hi WG,

This mail we conclude the working group last call for:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-architecture/
and
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Both drafts received many comments. And there were good discussions which 
really help the improvement of the drafts.
We see people support the progress.
Let's move forward both drafts and send to AD review.

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

[OPSAWG] Conclude the WGLC for SAIN

[Tianran Zhou]

Hi WG,

This mail we conclude the working group last call for:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-architecture/
and
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Both drafts received many comments. And there were good discussions which 
really help the improvement of the drafts.
We see people support the progress.
Let's move forward both drafts and send to AD review.

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

Re: [OPSAWG] Call for presentation

[Tianran Zhou]

When you request a time slot, please include the following information:
The presentation name;
The speaker;
The draft;
The request time.

Best,
Tianran

From: Tianran Zhou
Sent: Monday, June 27, 2022 10:35 AM
To: opsawg@ietf.org
Subject: Call for presentation

Hi WG,

IETF 114 Preliminary Agenda is posted.
https://datatracker.ietf.org/meeting/114/agenda.html

OPSAWG meeting is at 10:00-12:00 Friday Session I.

Please send over your request for time slot to the chairs.

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

[OPSAWG] Call for presentation

[Tianran Zhou]

Hi WG,

IETF 114 Preliminary Agenda is posted.
https://datatracker.ietf.org/meeting/114/agenda.html

OPSAWG meeting is at 10:00-12:00 Friday Session I.

Please send over your request for time slot to the chairs.

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

[OPSAWG] IPR poll for draft-ietf-opsawg-service-assurance-yang-05 and draft-ietf-opsawg-service-assurance-architecture-03

[Tianran Zhou]

Dear authors and contributors,



As part of the working group last call, please respond on-list as to whether or 
not you are aware of any IPR that pertains to

draft-ietf-opsawg-service-assurance-yang-05

and

draft-ietf-opsawg-service-assurance-architecture-03.



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





For the OPAWG co-chairs,



Tianran

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

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

[Tianran Zhou]

Hi WG,

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

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

Cheers,
Tianran, on behalf of chairs

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

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

[Tianran Zhou]

Hi WG,

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

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

Re: [OPSAWG] RFC 9232 on Network Telemetry Framework

[Tianran Zhou]

Congratulations to the authors and the wg!

Cheers,
Tianran






Sent from WeLink
发件人： rfc-editormailto:rfc-edi...@rfc-editor.org>>
收件人： 
ietf-announcemailto:ietf-annou...@ietf.org>>;rfc-distmailto:rfc-d...@rfc-editor.org>>
抄送： 
rfc-editormailto:rfc-edi...@rfc-editor.org>>;drafts-update-refmailto:drafts-update-...@iana.org>>;opsawgmailto:opsawg@ietf.org>>
主题： [OPSAWG] RFC 9232 on Network Telemetry Framework
时间： 2022-05-27 23:18:10

A new Request for Comments is now available in online RFC libraries.


RFC 9232

Title:  Network Telemetry Framework
Author: H. Song,
F. Qin,
P. Martinez-Julia,
L. Ciavaglia,
A. Wang
Status: Informational
Stream: IETF
Date:   May 2022
Mailbox:haoyu.s...@futurewei.com,
qinfeng...@chinamobile.com,
pe...@nict.go.jp,
laurent.ciavag...@rakuten.com,
wang...@chinatelecom.cn
Pages:  33
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-opsawg-ntf-13.txt

URL:https://www.rfc-editor.org/info/rfc9232

DOI:10.17487/RFC9232

Network telemetry is a technology for gaining network insight and
facilitating efficient and automated network management. It
encompasses various techniques for remote data generation,
collection, correlation, and consumption. This document describes an
architectural framework for network telemetry, motivated by
challenges that are encountered as part of the operation of networks
and by the requirements that ensue. This document clarifies the
terminology and classifies the modules and components of a network
telemetry system from different perspectives. The framework and
taxonomy help to set a common ground for the collection of related
work and provide guidance for related technique and standard
developments.

This document is a product of the Operations and Management Area Working Group 
Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
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] Specifying protocols in draft-claise-opsawg-collected-data-manifest

[Tianran Zhou]

Thanks for taking my suggestion.
This revision looks good for me.

Cheers,
Tianran






Sent from WeLink
发件人： Benoit 
Claisemailto:benoit.claise=40huawei@dmarc.ietf.org>>
收件人： Tianran 
Zhoumailto:zhoutianran=40huawei@dmarc.ietf.org>>;Benoit
 
Claisemailto:benoit.claise=40huawei@dmarc.ietf.org>>;Jean
 
Quilbeufmailto:jean.quilbeuf=40huawei@dmarc.ietf.org>>;opsawgmailto:opsawg@ietf.org>>
主题： Re: [OPSAWG] Specifying protocols in 
draft-claise-opsawg-collected-data-manifest
时间： 2022-03-19 22:47:16

Hi Tianran,

Thanks for your feedback.
I have added the required extra justification in the temp version:
The goal behind this specification is not to expose new information via YANG 
objects but rather to define what needs to be kept as metadata (the data 
manifest) to ensure that the collected data can still be interpreted correctly, 
even if the source device is not accesible (from the collection system), or if 
the device has been updated (new operating system or new configuration).
https://github.com/JeanQuilbeufHuawei/draft-collected-data-manifest

Regards, Benoit

On 2/10/2022 2:46 AM, Tianran Zhou wrote:
Thanks Jean and Benoit for your clarification.
I think this manifest information is useful.
One more justification IMO might be useful.
When controller and collector are on separate servers, which is a very common 
deployment, collector may not have access to the device configuration.

T.
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Benoit Claise
Sent: Wednesday, February 9, 2022 10:42 PM
To: Tianran Zhou 
<mailto:zhoutianran=40huawei@dmarc.ietf.org>;
 Jean Quilbeuf 
<mailto:jean.quilbeuf=40huawei@dmarc.ietf.org>;
 opsawg <mailto:opsawg@ietf.org>
Subject: Re: [OPSAWG] Specifying protocols in 
draft-claise-opsawg-collected-data-manifest

Hi Tianran,
On 2/9/2022 2:04 PM, Tianran Zhou wrote:
Hi Jean,
I am a little confused about this manifest?
Can we just read from the device about the configuration? We can get all the 
running information.
I'm not sure whether this is a generic question or whether your question 
relates to the message below.
Let me answer the generic question. We don't always want to read the devices 
information from the closed-loop automation systems or the database. Once known 
...


   "This data manifest instance file MUST be streamed all with the data

   and stored along with the collected data.  In case the data are moved

   to different place (typically a database), the data manifest MUST

   follow the collected data.  This can render the data unusable if that

   context is lost, for instance when the data is stored without the

   relevent information."
Also the context might be lost, so  not available any longer from the device 
Ex: how was it metered?

This is what we were trying to say with this generic sentence in the charter: 
"This can render the data unusable if that context is lost, for instance when 
the data is stored without the relevent information."

There is some more justifications in the introduction (section 2).

Regards, Benoit

Best,
Tianran





Sent from WeLink
发件人： Jean 
Quilbeufmailto:jean.quilbeuf=40huawei@dmarc.ietf.org>>
收件人： opsawgmailto:opsawg@ietf.org>>
主题： [OPSAWG] Specifying protocols in draft-claise-opsawg-collected-data-manifest
时间： 2022-02-09 20:33:06

Dear All,
We are wondering whether to add information about protocols in the data 
manifest draft 
https://datatracker.ietf.org/doc/draft-claise-opsawg-collected-data-manifest/

Details are here 
https://github.com/JeanQuilbeufHuawei/draft-collected-data-manifest/issues/9  
(that git repo contains a pre-01 version of the draft).

The data manifest should contain the information that a device able to stream 
telemetry can gather to allow a posteriori understanding of values stored in a 
time series database for instance. In that context, knowing the protocol would 
enable to understand whether some metrics can be missed (for instance if UDP 
push is used) and explain some gaps in the time serie.

1 - In the model, do we want to encode that fact as a Boolean (such as 
unreliable_subscription) that would be attached to a particular MDT 
subscription or do we want to specify the protocol used for subscription and 
let the consumer of the model draw the conclusion themselves?

2 - Another point is about the encoding used, do we need to specify it in the 
data-manifest or do we leave this as a responsibility of the collector/database 
system?

For the second question, not that he collector/database system still  has the 
responsibility to modify the data manifest if that encoding is changed.

Any suggestions?

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



__

Re: [OPSAWG] Specifying protocols in draft-claise-opsawg-collected-data-manifest

[Tianran Zhou]

Thanks Jean and Benoit for your clarification.
I think this manifest information is useful.
One more justification IMO might be useful.
When controller and collector are on separate servers, which is a very common 
deployment, collector may not have access to the device configuration.

T.
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Benoit Claise
Sent: Wednesday, February 9, 2022 10:42 PM
To: Tianran Zhou ; Jean Quilbeuf 
; opsawg 
Subject: Re: [OPSAWG] Specifying protocols in 
draft-claise-opsawg-collected-data-manifest

Hi Tianran,
On 2/9/2022 2:04 PM, Tianran Zhou wrote:
Hi Jean,
I am a little confused about this manifest?
Can we just read from the device about the configuration? We can get all the 
running information.
I'm not sure whether this is a generic question or whether your question 
relates to the message below.
Let me answer the generic question. We don't always want to read the devices 
information from the closed-loop automation systems or the database. Once known 
...


   "This data manifest instance file MUST be streamed all with the data

   and stored along with the collected data.  In case the data are moved

   to different place (typically a database), the data manifest MUST

   follow the collected data.  This can render the data unusable if that

   context is lost, for instance when the data is stored without the

   relevent information."
Also the context might be lost, so  not available any longer from the device 
Ex: how was it metered?

This is what we were trying to say with this generic sentence in the charter: 
"This can render the data unusable if that context is lost, for instance when 
the data is stored without the relevent information."

There is some more justifications in the introduction (section 2).

Regards, Benoit

Best,
Tianran





Sent from WeLink
发件人： Jean 
Quilbeufmailto:jean.quilbeuf=40huawei@dmarc.ietf.org>>
收件人： opsawgmailto:opsawg@ietf.org>>
主题： [OPSAWG] Specifying protocols in draft-claise-opsawg-collected-data-manifest
时间： 2022-02-09 20:33:06

Dear All,
We are wondering whether to add information about protocols in the data 
manifest draft 
https://datatracker.ietf.org/doc/draft-claise-opsawg-collected-data-manifest/

Details are here 
https://github.com/JeanQuilbeufHuawei/draft-collected-data-manifest/issues/9  
(that git repo contains a pre-01 version of the draft).

The data manifest should contain the information that a device able to stream 
telemetry can gather to allow a posteriori understanding of values stored in a 
time series database for instance. In that context, knowing the protocol would 
enable to understand whether some metrics can be missed (for instance if UDP 
push is used) and explain some gaps in the time serie.

1 - In the model, do we want to encode that fact as a Boolean (such as 
unreliable_subscription) that would be attached to a particular MDT 
subscription or do we want to specify the protocol used for subscription and 
let the consumer of the model draw the conclusion themselves?

2 - Another point is about the encoding used, do we need to specify it in the 
data-manifest or do we leave this as a responsibility of the collector/database 
system?

For the second question, not that he collector/database system still  has the 
responsibility to modify the data manifest if that encoding is changed.

Any suggestions?

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



___

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] Specifying protocols in draft-claise-opsawg-collected-data-manifest

[Tianran Zhou]

Hi Jean,
I am a little confused about this manifest?
Can we just read from the device about the configuration? We can get all the 
running information.
Best,
Tianran






Sent from WeLink
发件人： Jean 
Quilbeufmailto:jean.quilbeuf=40huawei@dmarc.ietf.org>>
收件人： opsawgmailto:opsawg@ietf.org>>
主题： [OPSAWG] Specifying protocols in draft-claise-opsawg-collected-data-manifest
时间： 2022-02-09 20:33:06

Dear All,
We are wondering whether to add information about protocols in the data 
manifest draft 
https://datatracker.ietf.org/doc/draft-claise-opsawg-collected-data-manifest/

Details are here 
https://github.com/JeanQuilbeufHuawei/draft-collected-data-manifest/issues/9  
(that git repo contains a pre-01 version of the draft).

The data manifest should contain the information that a device able to stream 
telemetry can gather to allow a posteriori understanding of values stored in a 
time series database for instance. In that context, knowing the protocol would 
enable to understand whether some metrics can be missed (for instance if UDP 
push is used) and explain some gaps in the time serie.

1 - In the model, do we want to encode that fact as a Boolean (such as 
unreliable_subscription) that would be attached to a particular MDT 
subscription or do we want to specify the protocol used for subscription and 
let the consumer of the model draw the conclusion themselves?

2 - Another point is about the encoding used, do we need to specify it in the 
data-manifest or do we leave this as a responsibility of the collector/database 
system?

For the second question, not that he collector/database system still  has the 
responsibility to modify the data manifest if that encoding is changed.

Any suggestions?

Best,
Jean
___
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] Conclusion//RE: WG Adoption Call for draft-dbwb-opsawg-sap-00

[Tianran Zhou]

Hi WG,

Thanks very much for your comments and contributions.
We conclude the adoption call of this draft.
We see sufficient supports and interests. There is no objection.
So the OPSAWG will adopt this draft.
The authors please rename the draft to draft-ietf-opsawg-sap-00, and upload.
The authors please incorporate the suggestions during the call in the later 
revision.


Cheers,
Tianran, as co-chair

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Wednesday, January 5, 2022 10:12 AM
To: opsawg@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: [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

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

[Tianran Zhou]

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

[OPSAWG] FW: NomCom 2021-2022 Call for Nominations

[Tianran Zhou]

FYI

-Original Message-
From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of NomCom Chair 2021
Sent: Monday, August 30, 2021 10:04 PM
To: IETF Announcement List 
Cc: i...@ietf.org
Subject: NomCom 2021-2022 Call for Nominations

Finally! The moment we've all been waiting for:

   C A L L   F O R   N O M I N A T I O N S  ! ! !

The 2021-22 IETF Nominating Committee (NomCom) is seeking nominations from now 
until Monday, October 11, 2021. 

The open positions and more information are found at the NomCom web site:

https://datatracker.ietf.org/nomcom/2021/ 

They are also included below for convenience.

Nominations may be made by selecting the Nominate link at the top of the NomCom 
2021 home page, or by visiting the following URL: 

https://datatracker.ietf.org/nomcom/2021/nominate/

Self-nomination is welcome! 

Note:  Nominations made using the web tool require an ietf.org datatracker 
account. You can create a datatracker ietf.org account if you don't have one 
already by visiting the following URL: 

https://datatracker.ietf.org/accounts/create/

If you are unable to use the web form, nominations may instead be made by email 
to nomcom-2021 at ietf dot org. If using email, please include the word 
"Nominate" 
in the Subject and indicate in the email who is being nominated, their email 
address (to confirm acceptance of the nomination), and the position for which 
you are making the nomination. If you are nominating someone other than 
yourself, please tell us if we may tell the nominee that you were the one who 
made the nomination. If you wish to nominate someone via email for more than 
one position, please use separate emails to do so.

Willing nominees will be asked to fill out a questionnaire specific to the 
position for which they are nominated. The finalized questionnaires will be 
available no later than Monday, September 6, 2021 (preliminary versions are 
already posted) and have a submission deadline of Monday, October 18, 2021. 

NomCom 2021-22 will follow the policy for "Open Disclosure of Willing Nominees" 
described in BCP 10/RFC 8713: "The list of nominees willing to be considered 
for positions under review in the current NomCom cycle is not confidential". 
Willing nominees for each position will be listed in a publicly accessible way, 
e.g., anyone with a datatracker account may access the lists. Additionally, the 
nomination form asks if we may share your own name with the nominee. In all 
other ways, the confidentiality requirements of BCP
10 remain in effect. All feedback and all NomCom deliberations will remain 
confidential and will not be disclosed.

There is a field on the form you can mark in order to allow the NomCom to tell 
the nominee that you were the one who made the nomination. This defaults to 
“no” - so if you don't mark the field we won’t tell.

In order to ensure time to collect sufficient community feedback about each of 
the willing nominees, nominations must be received by the NomCom on or before 
Monday, October 11, 2021.

Please submit your nominations as early as possible for the sake of your 
nominees. Note that nominations should not wait for nominee management 
permission, as it is easier to decline the nomination than put one in late.

The NomCom appoints individuals to fill open slots on the IAB, IESG, the IETF 
Trust and the LLC Board:

ART AD: 1 position
INT AD: 1 position
OPS AD: 1 position
RTG AD: 1 position
SEC AD: 1 position
TSV AD: 1 position
IETF Trust: 1 position
IETF LLC: 1 position
IAB: 6 positions

The list of people and posts whose terms end with the March 2022 IETF meeting, 
and thus the positions for which this NomCom is responsible, is:

[An asterisk (*) next to a person's name indicates they do not intend to accept 
renomination.]

LLC Board (3-year term)
Jason Livingood

IETF Trust (3-year term)
Kathleen Moriarty

IAB (2-year term)
Ben Campbell *
Cullen Jennings
Mirja Kühlewind
Jared Mauch
Tommy Pauly
Jiankang Yao

IESG (2-year term)
Murray Kucherawy, ART AD
Erik Kline, INT AD
Robert Wilton, OPS AD
Martin Vigoureux, RTG AD
Benjamin Kaduk, SEC AD *
Martin Duke, TSV AD

Please be resourceful in identifying possible candidates for these positions, 
as developing our talent is a very crucial requirement for the IETF, and also, 
please consider accepting a nomination. You'll find extensive information about 
specific positions, in individual tabs at: 

https://datatracker.ietf.org/nomcom/2021/requirements/ 

In addition to nominations, the NomCom seeks community input on the positions 
themselves. We need and welcome the community's views and input on the 

Re: [OPSAWG] A question about relationship between draft-song-opsawg-ifit-framework and draft-wang-idr-bgp-ifit-capabilities

[Tianran Zhou]

Hi Greg,

Thanks very much for you interest on the draft-song-opsawg-ifit-framework.
Yes, it would be great if we can get it progressed.
Let’s see how we can pick up this work.

Regards,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Monday, August 23, 2021 11:53 AM
To: idr wg ; opsawg 
Subject: [OPSAWG] A question about relationship between 
draft-song-opsawg-ifit-framework and draft-wang-idr-bgp-ifit-capabilities

Dear OPSAWG and IDR WGs,
I've been following the discussion of 
draft-song-opsawg-ifit-framework
 in the OPSAWG. The on-path telemetry is a very important element of the OAM 
toolset. The IFIT framework discussion is helping to better understand how the 
op-path telemetry can help operators. As you can see, that document is not yet 
been adopted by the WG.
I've read draft-wang-idr-bgp-ifit-capabilities and have noticed that though it 
defines elements of the control plane for the IFIT, it does not reference the 
IFIT Framework document. That seems like an unfortunate omission. Also, it 
might be appropriate to get the IFIT framework progressed before advancing 
documents on the control plane extensions supporting functionalities defined in 
the framework.
What are your opinions?

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

[OPSAWG] OPSAWG & OPS Area joint meeting agenda

[Tianran Zhou]

Hi WG,

We posted the agenda for the IETF 111 meeting.
https://datatracker.ietf.org/doc/agenda-111-opsawg/

Thanks for your contribution.
Please check if we have missed anything.

The speakers please send over your slides to the chairs before the online 
meeting on Friday.
Or you can directly upload the material to the DT by yourself.
https://datatracker.ietf.org/meeting/111/session/opsawg

Cheers,
Tianran, Joe, Henk


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

[OPSAWG] Call for presentation

[Tianran Zhou]

Hi WG,

The OPSAWG meeting is now in the preliminary 111 agenda at 16:00-18:00 Friday 
Session III.
We now open the call for presentation.
Please send over your request to the chairs.

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

[OPSAWG] Publication has been requested for draft-ietf-opsawg-ipfix-mpls-sr-label-type-05

[Tianran Zhou via Datatracker]

Tianran Zhou has requested publication of 
draft-ietf-opsawg-ipfix-mpls-sr-label-type-05 as Informational on behalf of the 
OPSAWG working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-label-type/


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

Re: [OPSAWG] Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

[Tianran Zhou]

Hi Med,

Your capture is correct.
Let's go through the more complete definition of "informational", but ignore 
the "consensus" part.
"An "Informational" specification is published for the general
information of the Internet community, and does not represent an
Internet community consensus or recommendation. The Informational
designation is intended to provide for the timely publication of a
very broad range of responsible informational documents from many
sources, subject only to editorial considerations and to verification
that there has been adequate coordination with the standards process
(see section 4.2.3)."

It seems this draft is not intended only to provide information as described in 
the further explanation.
What's your thoughts?

Best,
Tianran

From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
Sent: Thursday, June 24, 2021 1:24 PM
To: Tianran Zhou ; 
draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; opsawg-cha...@ietf.org
Cc: opsawg@ietf.org
Subject: RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Tianran, all,

Please see inline.

Cheers,
Med

De : Tianran Zhou [mailto:zhoutian...@huawei.com]
Envoyé : jeudi 24 juin 2021 05:09
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; 
draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org<mailto:draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org>;
 opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
Cc : opsawg@ietf.org<mailto:opsawg@ietf.org>
Objet : RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Med,

>>Why the document is in the "Standard Track"?
>>I failed to see any valid reason especially that:
>>* The IANA policy for the target registry is Expert Review.
>>* We don't have any normative statements in the document.

The registry does not require the standard track document. But this is not the 
reason why this document should so not be standard track.
[Med] Yeah, if we don't have the second bullet above.

If not standard track, should it be informational? Look at the "informational" 
draft definition in RFC2026. I do not think this draft falls into the 
informational track.
"An "Informational" specification is published for the general
information of the Internet community, and does not represent an
Internet community consensus or recommendation."
[Med] Please note that the consensus thing was updated as per: 
https://datatracker.ietf.org/doc/rfc8789/.

In addition, this working group published rfc8549 as standard track, which is 
similar to draft-ietf-opsawg-ipfix-mpls-sr-label-type, for IPFIX IE.
https://datatracker.ietf.org/doc/rfc8549/
[Med] This is document is not similar as it includes many normative statements.

IMO, it seems standard track is a suitable type for this draft .

Cheers,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Sent: Wednesday, June 23, 2021 11:47 PM
To: 
draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org<mailto:draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org>;
 opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: [OPSAWG] Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Thomas, all,

I made a shepherd review of the document. The review can be found at:


· pdf: 
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-drip-reqs-06-rev%20Med.pdf

· doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-drip-reqs-06-rev%20Med.docx

Almost all the comments are minor. These are basically to enhance the 
readability of the document (shorten long sentences, etc.) and make idnits 
happy.

There is one "procedural" comment that it is better to discuss now as I suspect 
it will pop up in the process: Why the document is in the "Standard Track"?

I failed to see any valid reason especially that:
* The IANA policy for the target registry is Expert Review.
* We don't have any normative statements in the document.

Are there any reasons why the document should be in "Standards Track"?

Once these comments are fixed, I will start preparing the write-up.

Thank you.

Cheers,
Med

_



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

Re: [OPSAWG] Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

[Tianran Zhou]

Hi Med,

>>Why the document is in the "Standard Track"?
>>I failed to see any valid reason especially that:
>>* The IANA policy for the target registry is Expert Review.
>>* We don't have any normative statements in the document.

The registry does not require the standard track document. But this is not the 
reason why this document should so not be standard track.
If not standard track, should it be informational? Look at the "informational" 
draft definition in RFC2026. I do not think this draft falls into the 
informational track.
"An "Informational" specification is published for the general
information of the Internet community, and does not represent an
Internet community consensus or recommendation."

In addition, this working group published rfc8549 as standard track, which is 
similar to draft-ietf-opsawg-ipfix-mpls-sr-label-type, for IPFIX IE.
https://datatracker.ietf.org/doc/rfc8549/

IMO, it seems standard track is a suitable type for this draft .

Cheers,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Wednesday, June 23, 2021 11:47 PM
To: draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; opsawg-cha...@ietf.org
Cc: opsawg@ietf.org
Subject: [OPSAWG] Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Thomas, all,

I made a shepherd review of the document. The review can be found at:


* pdf: 
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-drip-reqs-06-rev%20Med.pdf

* doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-drip-reqs-06-rev%20Med.docx

Almost all the comments are minor. These are basically to enhance the 
readability of the document (shorten long sentences, etc.) and make idnits 
happy.

There is one "procedural" comment that it is better to discuss now as I suspect 
it will pop up in the process: Why the document is in the "Standard Track"?

I failed to see any valid reason especially that:
* The IANA policy for the target registry is Expert Review.
* We don't have any normative statements in the document.

Are there any reasons why the document should be in "Standards Track"?

Once these comments are fixed, I will start preparing the write-up.

Thank you.

Cheers,
Med

_



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] Shepherd//RE: Conclusion//RE: WG Last call for draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

[Tianran Zhou]

Hi Med,

Thanks very much for your volunteer.
I will assign you as the doc shepherd in the DT.

Cheers,
Tianran


From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
Sent: Tuesday, June 22, 2021 9:43 PM
To: Tianran Zhou ; opsawg@ietf.org
Subject: RE: Shepherd//RE: Conclusion//RE: WG Last call for 
draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

Hi Tianran,

As I reviewed this document, and unless you already have a volunteer, I will be 
happy to be the doc shepherd.

Cheers,
Med

De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de Tianran Zhou
Envoyé : mardi 22 juin 2021 05:48
À : opsawg@ietf.org<mailto:opsawg@ietf.org>
Objet : [OPSAWG] Shepherd//RE: Conclusion//RE: WG Last call for 
draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

Hi WG,

We seek volunteers for the document shepherd.
It would be really appreciate if you would like to contribute.

Thanks,
Tianran

From: Tianran Zhou
Sent: Tuesday, June 22, 2021 11:44 AM
To: Tianran Zhou mailto:zhoutian...@huawei.com>>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: Conclusion//RE: WG Last call for 
draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

Hi WG,

We conclude the last call for draft-ietf-opsawg-ipfix-mpls-sr-label-type-01.
We are going to move it forward.
Thanks all the comments and discussions on this work.
The author please revise the draft based on the suggestions and discussion in 
the mailing list.

Cheers,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Tuesday, June 8, 2021 8:56 AM
To: opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: [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

_



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] Shepherd//RE: Conclusion//RE: WG Last call for draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

[Tianran Zhou]

Hi WG,

We seek volunteers for the document shepherd.
It would be really appreciate if you would like to contribute.

Thanks,
Tianran

From: Tianran Zhou
Sent: Tuesday, June 22, 2021 11:44 AM
To: Tianran Zhou ; opsawg@ietf.org
Subject: Conclusion//RE: WG Last call for 
draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

Hi WG,

We conclude the last call for draft-ietf-opsawg-ipfix-mpls-sr-label-type-01.
We are going to move it forward.
Thanks all the comments and discussions on this work.
The author please revise the draft based on the suggestions and discussion in 
the mailing list.

Cheers,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Tuesday, June 8, 2021 8:56 AM
To: opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: [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

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

[Tianran Zhou]

Hi WG,

We conclude the last call for draft-ietf-opsawg-ipfix-mpls-sr-label-type-01.
We are going to move it forward.
Thanks all the comments and discussions on this work.
The author please revise the draft based on the suggestions and discussion in 
the mailing list.

Cheers,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Tuesday, June 8, 2021 8:56 AM
To: opsawg@ietf.org
Subject: [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

[OPSAWG] IPR question//RE: WG Last call for draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

[Tianran Zhou]

Hi Thomas and the WG,

Do you aware of any IPR related to this document?

Best,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Tuesday, June 8, 2021 8:56 AM
To: opsawg@ietf.org
Subject: [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

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

[Tianran Zhou]

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

[OPSAWG] Conclusion//Re: Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07

[Tianran Zhou]

Hi WG,

This mail we conclude the adoption call.
We got supports from IPFIX expert, vendors, operators. And there is no 
objection.
We believe the working group has consensus to work on this draft and want to 
quickly proceed.
So the working group adopts this document.

The authors, please submit your draft as it was with only the name changed to 
draft-ietf-opsawg-ipfix-mpls-sr-label-type-00.

Cheers,
Tianran

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2021年3月24日 14:23
收件人: opsawg@ietf.org
主题: [OPSAWG] Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07

Hi WG,

As discussed in the IETF110 meeting, we start a two weeks adoption call on 
draft-tgraf-ipfix-mpls-sr-label-type-07:
https://datatracker.ietf.org/doc/draft-tgraf-ipfix-mpls-sr-label-type/


Please respond with your comments and thoughts on this draft.

We will conclude on April 7, 2021.

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

Re: [OPSAWG] New Version Notification for draft-tgraf-ipfix-mpls-sr-label-type-07.txt

[Tianran Zhou]

Hi Benoit,

Thanks for your review comments.
I count your message as supportive in the adoption call.
:)

Cheers,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Benoit Claise
Sent: Wednesday, March 24, 2021 3:36 PM
To: rwil...@cisco.com
Cc: opsawg@ietf.org
Subject: [OPSAWG] New Version Notification for 
draft-tgraf-ipfix-mpls-sr-label-type-07.txt

Hi Rob,

During the OPSAWG meeting, you asked me about 
draft-tgraf-ipfix-mpls-sr-label-type
https://datatracker.ietf.org/doc/minutes-110-opsawg/

Rob: this registry allows anyone to add them.

Benoit: still worth publishing a doc to explain background.  Benoit will review.

Thomas: First went directly to IANA.  IANA requested an official document.



Rob: adopting this is the right thing to do.

Joe: Benoit is on the hook to review.
So I did review the document and the new version is the outcome of it.

Considering that:
- This document has some value. Even if a document is not required to request 
IANA IPFIX Information Elements, documenting how multiple IPFIX IEs work 
together is a beneficial
- The IPFIX doctors (Paul Aitken and Andrew Feren) reviewed the document
- IANA (Michelle Coton) reviewed the document. Btw, they found a mistake in the 
IANA registry
- I now reviewed the document

I believe that:
- The document is ready today, even for WG LC IMO
- Since most key IFPIX players reviewed the document, you might not receive 
more additional reviews (that's somehow typical from OPSAWG, which consists of 
diverse OPS documents)
- Going through the normal WG process (call for adoption, call for reviews, ... 
) might produce silence and give the wrong impression that nobody cares, except 
Thomas :-)

Therefore, I suggest to expedite the document processing, either within the WG 
by adopting and WG LC'ing the document today, or via AD sponsor.
Indeed, waiting some more will not provide any benefits IMO ... on the contrary.

Regards, Benoit


 Forwarded Message 
Subject:

FW: New Version Notification for draft-tgraf-ipfix-mpls-sr-label-type-07.txt

Date:

Wed, 24 Mar 2021 05:25:23 +

From:

thomas.g...@swisscom.com

To:

opsawg@ietf.org

CC:

benoit.cla...@huawei.com



Dear OPSAWG,

As discussed at IETF 110. draft-tgraf-ipfix-mpls-sr-label-type has received a 
review from Benoit Claise and been updated to -07 version accordingly. Many 
thanks Benoit!

I am looking forward for adoption.

Best wishes
Thomas

-Original Message-
From: internet-dra...@ietf.org 
 Sent: Wednesday, 
March 24, 2021 6:11 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 

Subject: New Version Notification for 
draft-tgraf-ipfix-mpls-sr-label-type-07.txt


A new version of I-D, draft-tgraf-ipfix-mpls-sr-label-type-07.txt
has been successfully submitted by Thomas Graf and posted to the IETF 
repository.

Name: draft-tgraf-ipfix-mpls-sr-label-type
Revision: 07
Title: Export of MPLS Segment Routing Label Type Information in IP Flow 
Information Export (IPFIX)
Document date: 2021-03-24
Group: Individual Submission
Pages: 6
URL: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tgraf-ipfix-mpls-sr-label-type-07.txtdata=04%7C01%7CThomas.Graf%40swisscom.com%7C0e25812c1e9743fcdd4708d8ee832fa7%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637521594492563807%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=sBjtPcTp5Z34yKZiB1BOl5%2FBLpgcH3tdR6cnPss3dd4%3Dreserved=0
Status: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-ipfix-mpls-sr-label-type%2Fdata=04%7C01%7CThomas.Graf%40swisscom.com%7C0e25812c1e9743fcdd4708d8ee832fa7%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637521594492563807%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Bxaf5YiQBxvUUKWZMSsQClkxfCcWbeIV2L1INq4t1JQ%3Dreserved=0
Htmlized: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-ipfix-mpls-sr-label-typedata=04%7C01%7CThomas.Graf%40swisscom.com%7C0e25812c1e9743fcdd4708d8ee832fa7%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637521594492563807%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2BkJKWPCEK1JstdqNCs16WUc3a7s9LllZjOQtjlXZAr4%3Dreserved=0
Htmlized: 

[OPSAWG] Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07

[Tianran Zhou]

Hi WG,

As discussed in the IETF110 meeting, we start a two weeks adoption call on 
draft-tgraf-ipfix-mpls-sr-label-type-07:
https://datatracker.ietf.org/doc/draft-tgraf-ipfix-mpls-sr-label-type/


Please respond with your comments and thoughts on this draft.

We will conclude on April 7, 2021.

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

Re: [OPSAWG] [Fwd: Your thoughts on draft-richardson-mud-qrcode]

[Tianran Zhou]

Hi Michael,

Sorry for not being clear.
My statement is on the following context from your previous mail.
"I got very little interest at all."
And
"I think that the OPSAWG has very little available bandwidth for MUD related 
things, and the mud-qrcode document is not where I would want to spend the 
limited bandwidth of OPSAWG, since I think that there is very little for the WG"

So my preliminary suggestion is
"I think it would be a good idea to collect more interest in IOTOPS, and bring 
to OPSAWG."

The chairs will discuss more about the next.

Cheers,
Tianran

-Original Message-
From: Michael Richardson [mailto:mcr+i...@sandelman.ca] 
Sent: Sunday, March 21, 2021 4:52 AM
To: Tianran Zhou ; rfc-...@rfc-editor.org; 
opsawg-cha...@ietf.org; opsawg@ietf.org; iot...@ietf.org
Subject: Re: [OPSAWG] [Fwd: Your thoughts on draft-richardson-mud-qrcode]


Tianran Zhou  wrote:
> Now we have IOTOPS for more bandwidth to discussion on MUD.
> I think it would be a good idea to collect more interest in IOTOPS, and 
bring to OPSAWG.

I'm rather mystified by the meaning of this statement.
As WG chairs you are empowered to use your judgement, and you can run any 
process you like to decide whether to adopt work, including, I like to remind, 
doing it by fiat.  The "two week adoption call" is just a common process.

So, clearly you are suggesting some other process.
Perhaps you could explain to me what process you have envisioned here so that I 
can follow it?

---

To those in the WGs, perhaps you could read:
  https://datatracker.ietf.org/doc/draft-richardson-mud-qrcode/

Editorial changes most welcome at 
https://github.com/CIRALabs/securehomegateway-mud/tree/ietf

I should note that there is almost no content in this document which the IETF 
will have change control on. (I say almost, because I could say none, but I 
might be wrong)

This is an application of a Reverse Logistics Association profile of the
MH10.8.2 Committee QR code control protocol to include an RFC8520 entry.


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide




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

Re: [OPSAWG] [Fwd: Your thoughts on draft-richardson-mud-qrcode]

[Tianran Zhou]

Hi Michael,

I am sorry for missing that mail.
Now we have IOTOPS for more bandwidth to discussion on MUD.
I think it would be a good idea to collect more interest in IOTOPS, and bring 
to OPSAWG.

Tianran


-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Michael Richardson
Sent: Wednesday, March 17, 2021 4:17 AM
To: rfc-...@rfc-editor.org; opsawg-cha...@ietf.org; opsawg@ietf.org
Subject: Re: [OPSAWG] [Fwd: Your thoughts on draft-richardson-mud-qrcode]


Tianran Zhou  wrote:
> IMO, whether to apply ISE or WG adoption depends on the authors 
themselves.
> If I recall right, we did not get the adoption request from the
> authors.

I actually did post back in 2020
  https://mailarchive.ietf.org/arch/msg/opsawg/w22FWi_D5586H_LK2UXtzXLhx88/

I got very little interest at all.

The document was then simplified, all the DPP integration was removed, and I 
approached the Return Logistics Association (RLA.org) for a code that would 
integrate into their system.

I think that the OPSAWG has very little available bandwidth for MUD related 
things, and the mud-qrcode document is not where I would want to spend the 
limited bandwidth of OPSAWG, since I think that there is very little for the
WG.   But, if the WG wants it, that's fine with me.

RFC ISE (Adrian Farrel)  wrote:
> In my opinion, work that is in scope for an existing working group must
> first be offered to that working group. If the working group has no
> interest in pursuing it, that is OK and it can be brought to the
> Independent Stream provided it does not conflict with ongoing work in the
> working group.

> Of course, I can form my own opinion on whether there is interest in the
> working group, and I can make my own judgement about conflict, but it is
> helpful if the working group chairs can give advice because they should
> have a better understanding of what the working group thinks.

Unlike my other two MUD related documents, this document does not make any 
changes at all to RFC8520.

The mud-acceptable-urls document an Update (Amends), for RFC8520, and needs WG 
review.
The mud-iot-dns-considerations document is a BCP, and it is getting cross-area 
review (and a dnsop presentation last week), and I have a number of issues to 
deal with.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Fwd: Your thoughts on draft-richardson-mud-qrcode]

[Tianran Zhou]

Hi Adrian,

IMO, whether to apply ISE or WG adoption depends on the authors themselves.
If I recall right, we did not get the adoption request from the authors.
We welcome MUD related work, and we will consider from many aspects, like:
1. any conflict to existing solution
2. wg interests
...

But anyway, the WG mailing list could always be the place we can discuss about 
this technique.

Best,
Tianran
-Original Message-
From: RFC ISE (Adrian Farrel) [mailto:rfc-...@rfc-editor.org] 
Sent: Monday, March 15, 2021 6:20 PM
To: opsawg-cha...@ietf.org
Cc: opsawg@ietf.org; rfc-...@rfc-editor.org
Subject: [Fwd: Your thoughts on draft-richardson-mud-qrcode]

Hi OPSAWG chairs,

I wrote to you at the start of Janusary about draft-richardson-mud-qrcode/  
which is derived from draft-richardson-opsawg-securehomegateway-mud

My question was whether, in your opinion, this should be in the OPSAWG or it is 
OK for it to be published in the Independent Stream.

I also wondered if you are aware of any history related to the document that 
you could share with me.

I see from the mailing list that Michael has raised the draft on the list a 
couple of times, but without any follow-up.

What I'd like to know (and the WG can contribute to this discussion) is whether 
this is something that the WG would like to complete and publish in the IETF 
stream.

Any thoughts?

Thanks,
Adrian
--
Adrian Farrel (Independent Stream Editor), rfc-...@rfc-editor.org

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

[OPSAWG] Publication has been requested for draft-ietf-opsawg-ntf-07

[Tianran Zhou via Datatracker]

Tianran Zhou has requested publication of draft-ietf-opsawg-ntf-07 as 
Informational on behalf of the OPSAWG working group.

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


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

[OPSAWG] OPSAWG meeting agenda

[Tianran Zhou]

Hi WG,

The IETF110 agenda is posted:
https://datatracker.ietf.org/doc/agenda-110-opsawg/

Please see if there is anything missing.
The speakers, please send over your presentation slides before March 7.

Look forward to your attending.

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

[OPSAWG] Call for presentation//FW: IETF 110 Preliminary Agenda

[Tianran Zhou]

Hi WG,

The preliminary agenda is posted. 
OPSAWG meeting is scheduled on FRIDAY, March 12, 2021, at 1300-1500  Session I.
We now open the call for presentation.
Please send over your request to the chairs for the time slot.

Cheers,
Tianran

-Original Message-
From: WGChairs [mailto:wgchairs-boun...@ietf.org] On Behalf Of IETF Agenda
Sent: Saturday, February 6, 2021 8:49 AM
To: Working Group Chairs 
Subject: IETF 110 Preliminary Agenda

The IETF 110 preliminary agenda has been posted. The final agenda will be 
published on Friday, February 12, 2021.  

If you would like to request a change to the preliminary agenda, please send a 
message to supp...@ietf.org with “Agenda” in the subject line and copy all 
relevant Area Directors.

https://datatracker.ietf.org/meeting/110/agenda.html
https://datatracker.ietf.org/meeting/110/agenda.txt


The preliminary agenda includes all planned WG, RG, and BoF sessions. We are 
still finalizing details for a few of our usual meeting-adjacent events, so 
please look out for further details about those. Information about side meeting 
signups will be available when the final agenda is posted.

Please note the agenda times are listed in CET (UTC +1) by default. You may 
select which time zone is displayed on the HTML version of the agenda with a 
menu on the right side of the page. Choose “Meeting Timezone” for CET, “Local 
Timezone” for your own current time zone, “UTC” for UTC, or choose any other 
time zone from the drop down list. 

Thank you!

IETF Secretariat

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

[OPSAWG] Conclusion//RE: WGLC for draft-ietf-opsawg-ntf [CORRECT]

[Tianran Zhou]

Hi WG,

This mail we conclude the WGLC and the IPR call for draft-ietf-opsawg-ntf.
During the WGLC, we have received many supports and comments. The consensus we 
read is the draft is ready to move forward.
We especially thank the reviewers who spent time on it and provided valuable 
suggestions and comments helping improve the draft.
At the meantime, we are seeking a shepherd for this draft. Volunteer is welcome 
and please contact the chairs.

Cheers,
Tianran, Joe, Henk


From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Thursday, September 24, 2020 2:39 PM
To: opsawg 
Cc: draft-ietf-opsawg-...@ietf.org
Subject: [OPSAWG] 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] IPR Poll for draft-ietf-opsawg-ntf [CORRECT]

[Tianran Zhou]

Hi All,

As a contributor, I am not aware of any IPR for this draft.

Cheers,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Thursday, September 24, 2020 2:43 PM
To: opsawg 
Cc: draft-ietf-opsawg-...@ietf.org
Subject: [OPSAWG] IPR Poll for draft-ietf-opsawg-ntf [CORRECT]


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



Hi Authors,



Accompany with the WG LC, this mail starts the IPR poll.



Are you aware of any IPR that applies to draft-ietf-opsawg-ntf-04?



If you own or are aware of any IPR that applies to draft-ietf-opsawg-ntf-04, 
please clarify whether this IPR been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as a document author or contributor please respond to this 
email in OPSAWG mailing list regardless of whether or not you are aware of any 
relevant IPR. The document will not advance to the next stage until a response 
has been received from each author and contributor.



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



Thanks,

Tianran

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

[OPSAWG] IPR Poll for draft-ietf-opsawg-ntf [CORRECT]

[Tianran Zhou]

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



Hi Authors,



Accompany with the WG LC, this mail starts the IPR poll.



Are you aware of any IPR that applies to draft-ietf-opsawg-ntf-04?



If you own or are aware of any IPR that applies to draft-ietf-opsawg-ntf-04, 
please clarify whether this IPR been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as a document author or contributor please respond to this 
email in OPSAWG mailing list regardless of whether or not you are aware of any 
relevant IPR. The document will not advance to the next stage until a response 
has been received from each author and contributor.



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



Thanks,

Tianran

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

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

[Tianran Zhou]

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

[OPSAWG] IPR Poll for draft-opsawg-ntf

[Tianran Zhou]

Hi Authors,



Accompany with the WG LC, this mail starts the IPR poll.



Are you aware of any IPR that applies to draft-opsawg-ntf-04?



If you own or are aware of any IPR that applies to draft-opsawg-ntf-04, please 
clarify whether this IPR been disclosed in compliance with IETF IPR rules (see 
RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as a document author or contributor please respond to this 
email in OPSAWG mailing list regardless of whether or not you are aware of any 
relevant IPR. The document will not advance to the next stage until a response 
has been received from each author and contributor.



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



Thanks,

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

[OPSAWG] WGLC for draft-opsawg-ntf

[Tianran Zhou]

Hi WG,



This email starts a working group last call for draft-opsawg-ntf.
https://datatracker.ietf.org/doc/draft-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