Subject: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

From: Tianran Zhou <[email-masked]>
Date: Mon, 9 Dec 2019 05:27:04 +0000

Hi WG,

On IETF 106 meeting, we saw predominant interest and support to this draft, especially from operators. The authors then resolved all the open issues.
As requested by the authors, this email starts a 2 weeks working group adoption call for draft-song-opsawg-ifit-framework-09.
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/

If you support adopting this document please say so, and please give an indication of why you think it is important. Also please say if you will be willing to review and help the draft.
If you do not support adopting this document as a starting point to work on, please say why.
This poll will run until Dec 23.

Thanks,
Tianran as co-chair

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Mon, 9 Dec 2019 16:32:44 +0900

> This poll will run until Dec 23.

Dear Tianran and others,

I support the adoption of this draft and offer myself to review it and
contribute to it. I think it is important to separate the concepts from
this and NTF but some degree of overlapping would be required to ensure
that data plane notifications, such as those coming from external /data/
sources, are well integrated with control plane elements.

> Tianran as co-chair

Regards,
Pedro

-- 
Pedro Martinez-Julia
Network Science and Convergence Device Technology Laboratory
Network System Research Institute
National Institute of Information and Communications Technology (NICT)
4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan
Email: [email-masked]
---------------------------------------------------------
*** Entia non sunt multiplicanda praeter necessitatem ***

---

From: "qinfengwei" <[email-masked]>
Date: Mon, 9 Dec 2019 16:01:09 +0800

WG,

         I support the adoption poll as a co-author.

         I have read this doc, and think it is very important and mature
enough to be a WG doc.

 

Thanks & BR

Fengwei Qin

发件人: Tianran Zhou [mailto:[email-masked]] 
发送时间: 2019年12月9日 13:27
收件人: [email-masked]; [email-masked]
抄送: [email-masked]
主题: WG adoption call for draft-song-opsawg-ifit-framework-09

Hi WG,

On IETF 106 meeting, we saw predominant interest and support to this draft,
especially from operators. The authors then resolved all the open issues.

As requested by the authors, this email starts a 2 weeks working group
adoption call for draft-song-opsawg-ifit-framework-09.

If you support adopting this document please say so, and please give an
indication of why you think it is important. Also please say if you will be
willing to review and help the draft.

If you do not support adopting this document as a starting point to work on,
please say why.

Thanks,

Tianran as co-chair

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 9 Dec 2019 10:12:41 +0000

Hi All,
Yes, I support its adoption as contributor.

Best Regards,

Giuseppe

From: OPSAWG [mailto:[email-masked]] On Behalf Of Tianran Zhou
Sent: Monday, December 9, 2019 6:27 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Hi WG,

If you support adopting this document please say so, and please give an indication of why you think it is important. Also please say if you will be willing to review and help the draft.
If you do not support adopting this document as a starting point to work on, please say why.
This poll will run until Dec 23..

Thanks,
Tianran as co-chair

---

From: "吴畏虹" <[email-masked]>
Date: Mon, 9 Dec 2019 18:59:44 +0800

Hi WG,
&nbsp; &nbsp; I support this adoption and believe it will be useful.
&nbsp; &nbsp; Besides I'm interested in this topic so I'm doing an open-source project about the prototype of iFIT based on P4.
&nbsp; &nbsp; I hope we can show the implementation on the Hackathon in March 2020.

Regards,
Weihong Wu

------------------

Weihong Wu
State Key Laboratory of Networking and Switching Technology
, Beijing University of Posts and Telecommunications

&nbsp;
&nbsp;
&nbsp;
------------------&nbsp;Original&nbsp;------------------
From: &nbsp;"Tianran Zhou"<[email-masked]&gt;;
Date: &nbsp;Mon, Dec 9, 2019 01:27 PM
To: &nbsp;"[email-masked]"<[email-masked]&gt;; "[email-masked]"<[email-masked]&gt;; 
Cc: &nbsp;"[email-masked]"<[email-masked]&gt;; 
Subject: &nbsp;[OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

&nbsp;

Hi WG,
 
&nbsp;

 
 
&nbsp;

 
 
&nbsp;
 
Thanks,
 
Tianran as co-chair

---

From: Cociglio Mauro <[email-masked]>
Date: Mon, 9 Dec 2019 13:38:01 +0000

Dear all.
I support this draft.
>From an operator's point of view I think it will be useful.
Regards.
Mauro
_____________________
Mauro Cociglio
Telecom Italia-TIM
Via G. Reiss Romoli, 274
10148 - Torino (Italy)
Tel.: +390112285028
Mobile: +393357669751
_____________________

From: OPSAWG [mailto:[email-masked]] On Behalf Of Tianran Zhou
Sent: Monday, December 9, 2019 6:27 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Hi WG,

Thanks,
Tianran as co-chair

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: 신종윤님 <[email-masked]>
Date: Mon, 9 Dec 2019 14:17:08 +0000

Dear all,

I support this draft for WG adoption.
As a co-author and an operator, this document will help us apply data plane on-path telemetry solution in multi-protocol network domains.

Best regards,
Jongyoon

From: Cociglio Mauro <[email-masked]>
Sent: Monday, December 9, 2019 10:38 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: R: WG adoption call for draft-song-opsawg-ifit-framework-09

Dear all.
I support this draft.
From an operator’s point of view I think it will be useful.
Regards.
Mauro
_____________________
Mauro Cociglio
Telecom Italia-TIM
Via G. Reiss Romoli, 274
10148 - Torino (Italy)
Tel.: +390112285028
Mobile: +393357669751
_____________________

Hi WG,

Thanks,
Tianran as co-chair
[보낸 사람이 제거한 이미지입니다.]<https://on.tim.it/banner-mail-dip>
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 9 Dec 2019 16:16:50 +0000

Support,

Linda Dunbar

From: OPSAWG <[email-masked]> On Behalf Of Tianran Zhou
Sent: Sunday, December 08, 2019 11:27 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Hi WG,

On IETF 106 meeting, we saw predominant interest and support to this draft, especially from operators. The authors then resolved all the open issues.
As requested by the authors, this email starts a 2 weeks working group adoption call for draft-song-opsawg-ifit-framework-09.
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit-framework%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce232928dc296486cc65808d77c687772%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637114660455572968&sdata=Q3Kjx0EZZKoM0%2BkdtSoLO3g2%2FrfrTfwhlfZ08p4hyhg%3D&reserved=0>

Thanks,
Tianran as co-chair

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 10 Dec 2019 08:51:55 +0800

Hi WG,

 I support the adoption poll as a co-author.
 The iFit is very useful for us to do the network automatic operation. 
 AS WG had already discussed it very broadly，this dratf is ready to adopted as WG DOC. 

HUANAN CHEN（陈华南）
Data Communication Research Department
Guangdong Research Institute of China Telecom Co.,Ltd.
Tel：020-3863-9346
PH：133-1609-7163
QQ：17335837
Mail：[email-masked]
   [email-masked] 
 
From: Tianran Zhou
Date: 2019-12-09 13:27
To: [email-masked]; [email-masked]
CC: [email-masked]
Subject: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09
Hi WG,

 
Thanks,
Tianran as co-chair

---

From: Alexander L Clemm <[email-masked]>
Date: Tue, 10 Dec 2019 09:03:26 -0800

I have read the document and I support its adoption.   I do have a 
number of review comments that I will share in a separate email but 
those can be addressed later and should not hold up working group 
adoption.   --- Alex

On 12/8/2019 9:27 PM, Tianran Zhou wrote:
>
> Hi WG,
>
> On IETF 106 meeting, wesaw predominant interest and support to this 
> draft, especially from operators. The authors then resolved all the 
> open issues.
>
> If you support adopting this document please say so, and please give 
> an indication of why you think it is important. Also please say if you 
> will be willing to review and help the draft.
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: <[email-masked]>
Date: Tue, 10 Dec 2019 20:03:49 -0000

Hi All, 

I reviewed the document a few revisions ago and posted my thoughts on the list. The authors have done a good job to address my comments, and also the issues highlighted before and during IETF 106. 

The document is not perfect and will need further work. I feel it is suitable in its latest version and would benefit from WG development and contributions; I support the adoption. 

BR, Dan. 

From: OPSAWG <[email-masked]> On Behalf Of [email-masked]
Sent: 10 December 2019 00:52
To: 周天然@华为 <[email-masked]>; opsawg <[email-masked]>; [email-masked]
Cc: opsawg-chairs <[email-masked]>
Subject: Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Hi WG,

  _____  

HUANAN CHEN（陈华南）

Tel：020-3863-9346

PH：133-1609-7163

QQ：17335837

Mail：[email-masked] <mailto:[email-masked]> 

   [email-masked] <mailto:[email-masked]>  

From:  <mailto:[email-masked]> Tianran Zhou

Date: 2019-12-09 13:27

To:  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]

CC:  <mailto:[email-masked]> [email-masked]

Hi WG,

 <https://datatracker..ietf.org/doc/draft-song-opsawg-ifit-framework/> https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/ 

Thanks,

Tianran as co-chair

---

From: 진재환/팀장 <[email-masked]>
Date: Wed, 11 Dec 2019 14:42:14 +0900 (KST)

Dear all,
I support this draft for WG adoption.I believe this document povides a solution to solving operation issues that are difficult to manage.
This draft is a way to solve the problem of no alarms(traffic forwarding issue) in network.
Best regards,Jaehwan

 │ E-Mail : [email-masked] ------------------- Original Message -------------------From    :  "신종윤님" ([email-masked])To      :  "Cociglio Mauro" ([email-masked])
        "[email-masked]" ([email-masked])
        "[email-masked]" ([email-masked])
        "[email-masked]" ([email-masked])Date    :  2019/12/09 월요일 오후 11:17:08Subject :  RE: WG adoption call for draft-song-opsawg-ifit-framework-09

Dear all, I support this draft for WG adoption.As a co-author and an operator, this document will help us apply data plane on-path telemetry solution in multi-protocol network domains. Best regards,Jongyoon  From: Cociglio Mauro <[email-masked]>
Sent: Monday, December 9, 2019 10:38 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: R: WG adoption call for draft-song-opsawg-ifit-framework-09 Dear all.I support this draft.From an operator’s point of view I think it will be useful.Regards.Mauro_____________________Mauro CociglioTelecom Italia-TIMVia G. Reiss Romoli, 27410148 - Torino (Italy)Tel.: +390112285028Mobile: +393357669751_____________________    From: OPSAWG [mailto:[email-masked]]On Behalf Of Tianran Zhou
Sent: Monday, December 9, 2019 6:27 AM
To: [email-masked];[email-masked]
Cc: [email-masked]
Subject: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09 Hi WG, On IETF 106 meeting, we saw predominant interest and support to this draft, especially from operators. The authors then resolved all the open issues.As requested by the authors, this email starts a 2 weeks working group adoption call for draft-song-opsawg-ifit-framework-09.https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/ If you support adopting this document please say so, and please give an indication of why you think it is important. Also please say if you will be willing to review and help the draft.If you do not support adopting this document as a starting point to work on, please say why.This poll will run until Dec 23.. Thanks,Tianran as co-chairQuesto messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dallaconoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto 
 questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete thismessage and any attachments and advise the sender by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.  </blockquote

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 11 Dec 2019 14:33:27 -0000

Hi,

I sent the authors comments on a previous version of the document and

the authors made updates to address my concerns.

Considering this adoption poll, I have done another review of the draft.

I think it provides a useful overview of in-situ telemetry approaches and

Will serve the WG well. I'm glad that the authors have included section

3.2 because draft-ietf-opsawg-ntf is also important work and we need to

progress the two documents in close relationship. I am also glad there 

are good and clear references to the iOAM work.

I support adoption of the draft and commit to review it during WG

progress. I also have a few comments below: I don't think they need to

be addressed before adoption so long as they are picked up some time.

Thanks,

Adrian

===

The Abstract is about 10 lines too long. We should be aiming at no more

than 25 lines. 

I would remove the first sentence. It is out of place and begs the

question of what "telemetry" means.

---

The style guide says that the "Requirements Language" should be placed

in the body of the document. I suggest you create Section 2.1 for it.

---

A couple of things with Section 4.4 worry me. Proposing new extension

headers for IPv4 is unlikely to go down well in the IETF where new work

on IPv4 is now frowned upon, and where IPv4 extension headers are 

considered somewhat fragile. Additionally, I think you need to be very

careful with proposals around the Router Alert, and you shouldn't 

mention it or RFC 2113 without also mentioning RFC 6398. Lastly, I think

that you may be giving too much attention to individual drafts that 

possibly do not yet have a body of support in the IETF: in particular,

referencing draft-herbert-ipv4-eh may be premature.

---

I think we will need to give more attention to discussing security in

section 8. It is true that the details of the security for different

mechanisms are contained in the individual referenced documents. Our

focus in this document should be considering the overall security of

IFIT approaches. This should serve as a guide to the developers of the

various referenced documents, and it should provide observations on how

(or even if) to use IFIT systems.

Sent: 09 December 2019 05:27

Hi WG,

Thanks,

Tianran as co-chair

---

From: Lizhenbin <[email-masked]>
Date: Mon, 16 Dec 2019 14:49:55 +0000

I support the adoption of the draft. It setup an architecture view of In-situ Flow Telemetry which is very helpful.

Best Regards,
Zhenbin (Robin)

Sent: Monday, December 09, 2019 1:27 PM

Hi WG,

Thanks,
Tianran as co-chair

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 16 Dec 2019 16:17:44 +0000

Support.

Best Regards,

Huaimo

Hi WG,

https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit-framework%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C09cbee783c4549dc90bf08d782374272%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637121046170692448&sdata=ONdDwavcK6qUuDOq2UQ9vpFQIwTPSdLfFntS4B17YGM%3D&reserved=0>

This poll will run until Dec 23...

Thanks,

Tianran as co-chair

---

From: Haoyu Song <[email-masked]>
Date: Mon, 16 Dec 2019 18:33:50 +0000

Hi Adrian,

Thank you for your support! Your suggestions for improvement are noted and will be reflected in the next revision.

Best,
Haoyu

From: Adrian Farrel <[email-masked]>
Sent: Wednesday, December 11, 2019 6:33 AM
To: 'Tianran Zhou' <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Hi,

Thanks,
Adrian

===

---

---

---

From: OPSAWG <[email-masked]<mailto:[email-masked]>> On Behalf Of Tianran Zhou

Hi WG,

On IETF 106 meeting, we saw predominant interest and support to this draft, especially from operators. The authors then resolved all the open issues.
As requested by the authors, this email starts a 2 weeks working group adoption call for draft-song-opsawg-ifit-framework-09.
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit-framework%2F&data=02%7C01%7Chaoyu.song%40futurewei.com%7C2e5ca8b5f29c41b9b59e08d77e472fc3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637116716543648909&sdata=t42ssFcgSVLkM2V3x6e2Z5qeppa1rcNIvK60S%2FkVAt8%3D&reserved=0>

Thanks,
Tianran as co-chair

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Dec 2019 13:56:27 +0100

Dear all,

After reviewing themeeting minutes 
<https://datatracker.ietf.org/doc/minutes-106-opsawg/>, I was a little 
bit puzzled. From my recollection, Joe and Frank had some good feedback 
on the draft.
Also, in the minutes, I did not see any mention of Joe's feedback. And 
Frank's feedback on the draft is summarized as 4 words: "the scope is large"
So I went back and reviewed the youtube video 
<https://www.youtube.com/watch?v=rY-u8177wpU>.

I support Frank's feedback that this document scope is too large: a mix 
of an inventory of what exists, a set of requirements, and 
specifications/framework. I'm wondering: what is the scope of this 
document? Before we clarify this, I don't think we should adopt this 
document.

The OPSAWG chair questions at the end of the presentation were:

	Chair: How many of you have read this document? quite a lot.
	Chair: How many of you think this is a useful work and the working group could
	work on it? still many, 20+.

I was waiting for the negative question but to my surprise, it never came...

	Chair: How many of you don't think ...

If that question would have been asked, I would have come to mic. or at 
least raised my hand.

It's important to make a distinction between the interest to solve those 
problems (I believe we have full agreement) and whether this document is 
a good starting point. I object to the latter, with the document in the 
current form.

Regards, Benoit

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 17 Dec 2019 13:25:47 +0000

Hi Benoit,

My last question was only to check if there is enough interest on this work, not an adoption call. There was q&a after the presentation. And Joe cut the line because of the time.

Now this is an adoption call. You are free to suggest or object. And we believe debate is really helpful.

Cheers,
Tianran

________________________________
Sent from WeLink

发件人： Benoit Claise<[email-masked]<mailto:[email-masked]>>
收件人： Tianran Zhou<[email-masked]<mailto:[email-masked]>>;opsawg<[email-masked]<mailto:[email-masked]>>;draft-song-opsawg-ifit-framework.authors<[email-masked]<mailto:[email-masked]>>
抄送： opsawg-chairs<[email-masked]<mailto:[email-masked]>>
主题： Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09
时间： 2019-12-17 20:56:58

Dear all,

After reviewing the meeting minutes<https://datatracker.ietf.org/doc/minutes-106-opsawg/>, I was a little bit puzzled. From my recollection, Joe and Frank had some good feedback on the draft.
Also, in the minutes, I did not see any mention of Joe's feedback. And Frank's feedback on the draft is summarized as 4 words: "the scope is large"
So I went back and reviewed the youtube video<https://www.youtube.com/watch?v=rY-u8177wpU>.

I support Frank's feedback that this document scope is too large: a mix of an inventory of what exists, a set of requirements, and specifications/framework. I'm wondering: what is the scope of this document? Before we clarify this, I don't think we should adopt this document.

If that question would have been asked, I would have come to mic. or at least raised my hand.

It's important to make a distinction between the interest to solve those problems (I believe we have full agreement) and whether this document is a good starting point. I object to the latter, with the document in the current form.

Regards, Benoit
Hi WG,

Thanks,
Tianran as co-chair

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Dec 2019 14:43:12 +0100

Hi Tianran,
> Hi Benoit,
>
> My last question was only to check if there is enough interest on this 
> work, not an adoption call. There was q&a after the presentation. And 
> Joe cut the line because of the time.
>
> Now this is an adoption call. You are free to suggest or object.
I just did :-)

Regards, B.
> And we believe debate is really helpful.
>
> Cheers,
> Tianran
>
>
> ------------------------------------------------------------------------
> Sent from WeLink
>
> *发件人： *Benoit Claise<[email-masked] <mailto:[email-masked]>>
> *收件人： *Tianran Zhou<[email-masked] 
> <mailto:[email-masked]>>;opsawg<[email-masked] 
> <mailto:[email-masked]>>;draft-song-opsawg-ifit-framework.authors<[email-masked] 
> <mailto:[email-masked]>>
> *抄送： *opsawg-chairs<[email-masked] 
> <mailto:[email-masked]>>
> *主题： *Re: [OPSAWG] WG adoption call for 
> draft-song-opsawg-ifit-framework-09
> *时间： *2019-12-17 20:56:58
>
> Dear all,
>
> bit puzzled. From my recollection, Joe and Frank had some good 
> feedback on the draft.
> I support Frank's feedback that this document scope is too large: a 
> mix of an inventory of what exists, a set of requirements, and 
> It's important to make a distinction between the interest to solve 
> those problems (I believe we have full agreement) and whether this 
> document is a good starting point. I object to the latter, with the 
> document in the current form.
>
> Regards, Benoit
>>
>> Hi WG,
>>
>> As requested by the authors, this email starts a 2 weeks working 
>> group adoption call for draft-song-opsawg-ifit-framework-09.
>>
>> an indication of why you think it is important. Also please say if 
>> you will be willing to review and help the draft.
>>

---

From: Haoyu Song <[email-masked]>
Date: Tue, 17 Dec 2019 18:24:34 +0000

Hi Benoit,

Did you read my summary email? In it I summarized all the questions raised during the meeting and I asked if there was anything missed and promised to address or clarify them in draft revisions.

I have updated the draft two times since then and I believe I have addressed all the issues.  Please take a look at it and specifically point out why you think some issues are still not addressed. If you have other concerns, please also be specific. Thank you very much!

Haoyu

获取 Outlook for Android<https://aka.ms/ghei36>

________________________________
发件人: Benoit Claise <[email-masked]>
发送时间: 2019年12月17日星期二 上午4:56
收件人: Tianran Zhou; [email-masked]; [email-masked]
抄送: [email-masked]
主题: Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Dear all,

After reviewing the meeting minutes<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fminutes-106-opsawg%2F&data=02%7C01%7Chaoyu.song%40futurewei.com%7Ca3128704007e42e662f608d782f08eae%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637121842029952673&sdata=euXQxEzZrhghAme0Iv1LrFRYsqnmSN5xbhp4CNC5Q1E%3D&reserved=0>, I was a little bit puzzled. From my recollection, Joe and Frank had some good feedback on the draft.
Also, in the minutes, I did not see any mention of Joe's feedback. And Frank's feedback on the draft is summarized as 4 words: "the scope is large"
So I went back and reviewed the youtube video<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DrY-u8177wpU&data=02%7C01%7Chaoyu.song%40futurewei.com%7Ca3128704007e42e662f608d782f08eae%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637121842029962668&sdata=PGD1nUvH2a0QWwjmRQ54%2FcVi2k3LNDR39o4PP0NfY7U%3D&reserved=0>.

Regards, Benoit
Hi WG,

On IETF 106 meeting, we saw predominant interest and support to this draft, especially from operators. The authors then resolved all the open issues.
As requested by the authors, this email starts a 2 weeks working group adoption call for draft-song-opsawg-ifit-framework-09.
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit-framework%2F&data=02%7C01%7Chaoyu.song%40futurewei.com%7Ca3128704007e42e662f608d782f08eae%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637121842029962668&sdata=m%2FIqZwn7ARorYqGwXx%2FCqRaF6U%2BMFM7vxfegiEND8Ig%3D&reserved=0>

Thanks,
Tianran as co-chair

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg&data=02%7C01%7Chaoyu.song%40futurewei.com%7Ca3128704007e42e662f608d782f08eae%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637121842029972664&sdata=lMy2W1NoojeqhUVp2AvtBa8QZCzeLHliGzUAyz5EWUA%3D&reserved=0>

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 18 Dec 2019 21:00:53 +0000

Are we following our practices and procedures properly? For the record, in case others are equally puzzled about this call for adoption:

* Different from what the co-chair states in his WG adoption call below (“The authors then resolved all the open issues”), draft-song-opsawg-ifit-framework-09 does NOT resolve all open issues nor does the document reflect all the WG feedback received at IETF 106.

* The WG minutes (https://datatracker.ietf.org/meeting/106/materials/minutes-106-opsawg-01) miss a significant portion of comments and feedback as Benoit rightly points out below. E.g. Joe Clarke’s (as individual) comments are NOT mentioned at all, my comments are misrepresented.

* The authors did NOT reflect any of the comments made by myself (see https://youtu.be/rY-u8177wpU?t=3785) or by Joe Clarke. IMHO this is NOT appropriate for editors of a “soon to be” WG document. 

* draft-song-opsawg-ifit-framework-09 introduces a lot of new entities, e.g. IFIT Applications, IFIT Domain, IFIT Node, IFIT End-Node, etc. None of these entities are specified in the document, which means that the IETF would endorse a framework without even understanding the components/entities of the framework. The presenter responded (https://youtu.be/rY-u8177wpU?t=3867 ) that it would be just a “very high level framework” that should fit any existing solution. If everything fits, i.e. “I FIT”, “You FIT”, “We all Fit”, … then why do we even need the definition of new entities? There is NO need to define “empty shells” for a lot of new entities, if all what the authors intend to do is compare different solutions.

* Different from what the presenter claimed, IFIT is NOT just “a high-level framework”, but IFIT is a proprietary Huawei technology, see e.g. https://www-ctc.huawei.com/ke/press-events/news/2019/6/first-ifit-pilot-5g-transport-network-beijing-unicom-huawei. Public specifications for IFIT don’t seem to be available, with the exception of draft-li-6man-ipv6-sfc-ifit-02 which introduces new encapsulations. I.e. IFIT-Nodes, IFIT-End-Nodes etc. do exist – we just don’t know what they do. Looking at the people who responded to the adoption thread so far, one could also read the responses as a desire for a detailed documentation of the specification and lessons learned from deployments of Huawei’s IFIT.

Different from draft-song-opsawg-ifit-framework-09, which I do NOT support the adoption of, the following documents might be worthwhile documents (especially given the broad interest) to create/share:
- requirements
- comprehensive industry technology survey
- specification and deployment experiences of Huawei’s IFIT
I already made this suggestion back in the WG meeting at IETF 106 – but per the above it was ignored at multiple levels.

Regards, Frank

From: OPSAWG <[email-masked]> On Behalf Of Benoit Claise
Sent: Dienstag, 17. Dezember 2019 14:43
To: Tianran Zhou <[email-masked]>; opsawg <[email-masked]>; draft-song-opsawg-ifit-framework.authors <[email-masked]>
Cc: opsawg-chairs <[email-masked]>
Subject: Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Hi Tianran,
Hi Benoit,

Regards, B.

Cheers,
Tianran 

________________________________________
Sent from WeLink
发件人： Benoit Claise<mailto:[email-masked]>
收件人： Tianran Zhou<mailto:[email-masked]>;opsawg<mailto:[email-masked]>;draft-song-opsawg-ifit-framework.authors<mailto:[email-masked]>
抄送： opsawg-chairs<mailto:[email-masked]>
主题： Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09
时间： 2019-12-17 20:56:58

Dear all,

After reviewing thehttps://datatracker.ietf.org/doc/minutes-106-opsawg/, I was a little bit puzzled. From my recollection, Joe and Frank had some good feedback on the draft.
Also, in the minutes, I did not see any mention of Joe's feedback. And Frank's feedback on the draft is summarized as 4 words: "the scope is large"
So I went back and reviewed the https://www.youtube.com/watch?v=rY-u8177wpU. 

Hi WG,

 
Thanks,
Tianran as co-chair

mailto:[email-masked]

---

From: Haoyu Song <[email-masked]>
Date: Thu, 19 Dec 2019 01:09:17 +0000

Again, I need to point out the fact that I have listed all the questions raised during the meeting (including Frank's and Joe's) and I asked if I missed anything or misunderstood anything in an email to the list. But I didn't got any feedback from the queationers, so I believed  I had correctly understood the questions and then made updates accordingly. So, I don't understand why Frank still use the meeting video to question the draft. Please read and answer my email and draft, and let me know what you are not agree with based on that.

Alos, we have specified all the terms we used in the draft. Please take time to read it.

IFIT is NOT a proprietary solution.  Period.  I  don't think anybody can gain such a feeling from reading it.   There's no solution but requirement, challenges, a high level framework, examples, and standard gap analysis. How can it be a solution?

Other documents might also be needed but they are out of scope of this one.  I firmly believe this one is also needed for the reason we clearly stated in the draft.

Thanks!

Haoyu

________________________________
发件人: Frank Brockners (fbrockne) <[email-masked]>
发送时间: 2019年12月18日星期三 下午1:01
收件人: opsawg; draft-song-opsawg-ifit-framework.authors
抄送: opsawg-chairs
主题: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

* The WG minutes (https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F106%2Fmaterials%2Fminutes-106-opsawg-01&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7Cd612052cb289412e17f208d783fd63b3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637122996651740817&amp;sdata=i%2F4PXRzCKeMFFazIxZID0MAg6rvAUmK6VcY8vZiEbcg%3D&amp;reserved=0) miss a significant portion of comments and feedback as Benoit rightly points out below. E.g. Joe Clarke’s (as individual) comments are NOT mentioned at all, my comments are misrepresented.

* The authors did NOT reflect any of the comments made by myself (see https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2FrY-u8177wpU%3Ft%3D3785&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7Cd612052cb289412e17f208d783fd63b3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637122996651740817&amp;sdata=sSqjl1ZmiBhcwyxiFb%2B1dXsti4ChmS%2BXBuZ0HoWqlj0%3D&amp;reserved=0) or by Joe Clarke. IMHO this is NOT appropriate for editors of a “soon to be” WG document.

* draft-song-opsawg-ifit-framework-09 introduces a lot of new entities, e.g. IFIT Applications, IFIT Domain, IFIT Node, IFIT End-Node, etc. None of these entities are specified in the document, which means that the IETF would endorse a framework without even understanding the components/entities of the framework. The presenter responded (https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2FrY-u8177wpU%3Ft%3D3867&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7Cd612052cb289412e17f208d783fd63b3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637122996651740817&amp;sdata=HUmKp9GhOKybPjVCjCqcMBG3iRv6pyeUq93JR%2FHNMGQ%3D&amp;reserved=0 ) that it would be just a “very high level framework” that should fit any existing solution. If everything fits, i.e. “I FIT”, “You FIT”, “We all Fit”, … then why do we even need the definition of new entities? There is NO need to define “empty shells” for a lot of new entities, if all what the authors intend to do is compare different solutions.

* Different from what the presenter claimed, IFIT is NOT just “a high-level framework”, but IFIT is a proprietary Huawei technology, see e.g. https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-ctc.huawei.com%2Fke%2Fpress-events%2Fnews%2F2019%2F6%2Ffirst-ifit-pilot-5g-transport-network-beijing-unicom-huawei&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7Cd612052cb289412e17f208d783fd63b3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637122996651740817&amp;sdata=qeAPmV9PDxmq%2FeJ07mQO1%2BYc7bCdfrkfYF4peyhzqUw%3D&amp;reserved=0. Public specifications for IFIT don’t seem to be available, with the exception of draft-li-6man-ipv6-sfc-ifit-02 which introduces new encapsulations. I.e. IFIT-Nodes, IFIT-End-Nodes etc. do exist – we just don’t know what they do. Looking at the people who responded to the adoption thread so far, one could also read the responses as a desire for a detailed documentation of the specification and lessons learned from deployments of Huawei’s IFIT.

Regards, Frank

Hi Tianran,
Hi Benoit,

Regards, B.

Cheers,
Tianran

Dear all,

After reviewing thehttps://datatracker.ietf.org/doc/minutes-106-opsawg/, I was a little bit puzzled. From my recollection, Joe and Frank had some good feedback on the draft.
Also, in the minutes, I did not see any mention of Joe's feedback. And Frank's feedback on the draft is summarized as 4 words: "the scope is large"
So I went back and reviewed the https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DrY-u8177wpU&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7Cd612052cb289412e17f208d783fd63b3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637122996651740817&amp;sdata=yfzc4QsMk3swayAGObqSZ9cRjp2Yrgs8Ogto4pCMoIc%3D&amp;reserved=0.

Hi WG,

On IETF 106 meeting, we saw predominant interest and support to this draft, especially from operators. The authors then resolved all the open issues.
As requested by the authors, this email starts a 2 weeks working group adoption call for draft-song-opsawg-ifit-framework-09.
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit-framework%2F&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7Cd612052cb289412e17f208d783fd63b3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637122996651750815&amp;sdata=7ylx7NeAqro0DK3wzKWANb17PHZiLekxMDwBf6JDJMg%3D&amp;reserved=0

Thanks,
Tianran as co-chair

_______________________________________________
OPSAWG mailing list
mailto:[email-masked]
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7Cd612052cb289412e17f208d783fd63b3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637122996651750815&amp;sdata=2JT4bx%2Bg9J10eEYHeT94SlQt9F0YOFutGiXrzXRcJnI%3D&amp;reserved=0

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 19 Dec 2019 14:23:25 +0000

Haoyu,

you and your co-authors need to decide what the document is intended to be: A requirements document, an industry implementation survey, or a specification? Right now the document is a bit of everything – with nothing is appropriately spelled out and detailed for a standards document.

Depending on that decision, here is how you could evolve the document:
If the document is intended as a requirements document:
 - expand the requirements part of section 1
 - remove all references to iFIT and similar – none of this is needed to articulate requirements
If the document is intended as an industry survey:
 - provide comprehensive inventory of available implementation
 - focus on what is available / deployed and discuss experiences 
 - remove all references to iFIT and similar that try to specify things – none of this is needed to for an industry survey
If the document is intended as a specification or case study
 - provide technical specifications for IFIT node, IFIT application, IFIT Head Node, IFIT End Node, etc. I.e. explain how these “things” work and operate. What is their control plane, what is their data plane, etc.? Make sure that you’re not creating “empty shells” that are to be defined at a later stage. An approach to create forward references to currently non existing documents like “Other documents might also be needed but they are out of scope of this one” (see your message below) are not appropriate for a specification.
 - if you believe that your IFIT specification has nothing to do with Huawei’s IFIT proprietary implementation (i.e. https://www-ctc.huawei.com/ke/press-events/news/2019/6/first-ifit-pilot-5g-transport-network-beijing-unicom-huawei) then I strongly suggest that you choose a different name for your implementation. 

Just to highlight that different from what you say, the specification of IFIT elements neither helps in articulating requirements nor does it support different industry solutions: If you take the example of an “IFIT Node” – there is a total of 8 occurrences in the document, with 5 of them in the main part of the document. The document defines “iFIT Node” as “a network node that is in an iFIT domain and is capable of iFIT-specific functions”. None of the 5 occurrences in the document is used for comparison or requirements definition, neither do they detail what IFIT specific functions are carried out by an IFIT node. Reading through the 5 occurrences,  one learns that iFIT nodes seem to be configured by a controller (what is a controller?), they seem to be able to do some form of data collection (how?, what data?), they seem to be able to export data using IPFIX and protobuf (what data is exported?), they seem to be able to cache data, and they seem to contain DNP. Reading through this, I still don’t know what IFIT Nodes are… Do they forward traffic? Do they process traffic? If so how? ... 

Just for reference, here are the 5 occurrences of “IFIT Node” I found in the main part of the document:
- An iFIT application uses a controller to configure the iFIT nodes.
- After the telemetry data processing and analyzing, the iFIT application may instruct the controller to modify the iFIT node configuration and affect the future telemetry data collection.
- In addition to efficient export data encoding (e.g., IPFIX [RFC7011] or protobuf [1]), iFIT nodes have several other ways to reduce the export data by taking advantage of network device's capability and programmability. 
- iFIT nodes can cache the data and send the accumulated data in batch if the data is not time sensitive.
- The controller translates an intent and configure the corresponding DNPs in iFIT nodes which collect necessary network information.

Frank

From: Haoyu Song <[email-masked]> 
Sent: Donnerstag, 19. Dezember 2019 02:09
To: Frank Brockners (fbrockne) <[email-masked]>; opsawg <[email-masked]>; draft-song-opsawg-ifit-framework.authors <[email-masked]>
Cc: opsawg-chairs <[email-masked]>
Subject: Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Thanks!

Haoyu

获取 https://aka.ms/ghei36

发件人: Frank Brockners (fbrockne) <mailto:[email-masked]>

Regards, Frank

From: OPSAWG <mailto:[email-masked]> On Behalf Of Benoit Claise
Sent: Dienstag, 17. Dezember 2019 14:43
To: Tianran Zhou <mailto:[email-masked]>; opsawg <mailto:[email-masked]>; draft-song-opsawg-ifit-framework.authors <mailto:[email-masked]>
Cc: opsawg-chairs <mailto:[email-masked]>
Subject: Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Hi Tianran,
Hi Benoit,

Regards, B.

Cheers,
Tianran 

Dear all,

Hi WG,

 
Thanks,
Tianran as co-chair

---

From: Haoyu Song <[email-masked]>
Date: Thu, 19 Dec 2019 18:00:51 +0000

Hi Frank,

Thank you very much for the feedback. However I want to clarify a few things.

The core of the draft is a framework for data plane on-path telemetry. It's not a dedicated requirement document, neither a survey. The challenges we described are just used to motivate the framework. The standard gap analysis is also necessary to show how this framework can be implemented in the future.  While I agree the document is not perfect and still need to improve, I think the main information and logic flow are clear. I also think the document is self-sufficient. It's just a high level guide for future development but doesn't intend to put any constraints. 

I said “Other documents might also be needed but they are out of scope of this one”, not to reference some non-existing document, but to respond to your previous email in which you suggest other documents like survey and deployment experience etc.  This document does not server those purpose.

While you ask for detailed specification (up to the level about how the controller to configure the nodes and what data to export, etc.) , you may still think from a perspective that this document is a solution specification, but it's not. I'm very sorry for that impression. We already emphasized in the document that we don’t intend to specify any interface and implementation details, but to describe high level functions. To server that purpose, a loose definition for the terms is enough and proper.

For example, we define iFIT Node as "a network node that is in an iFIT domain and is capable of iFIT-specific functions." So yes it forwards and processes traffic. I don't think anybody will misunderstand this. You ask how,  for which we can only provide high level function descriptions but won't specify any detail because we have made it very clear that's not the intention of this document.

So let's just focus on the current scope and content of the document, to see if it's useful and valuable to the community as a whole. From the majority responses, mostly from real network operators, the feedbacks are so far very positive and they all support the adoption of this document. I think that says something.

Best regards,
Haoyu  

-----Original Message-----
From: Frank Brockners (fbrockne) <[email-masked]> 
Sent: Thursday, December 19, 2019 6:23 AM
To: Haoyu Song <[email-masked]>; opsawg <[email-masked]>; draft-song-opsawg-ifit-framework.authors <[email-masked]>
Cc: opsawg-chairs <[email-masked]>
Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Haoyu,

Depending on that decision, here is how you could evolve the document:
If the document is intended as a requirements document:
 - expand the requirements part of section 1
 - remove all references to iFIT and similar – none of this is needed to articulate requirements If the document is intended as an industry survey:
 - provide comprehensive inventory of available implementation
 - focus on what is available / deployed and discuss experiences
 - remove all references to iFIT and similar that try to specify things – none of this is needed to for an industry survey If the document is intended as a specification or case study
 - provide technical specifications for IFIT node, IFIT application, IFIT Head Node, IFIT End Node, etc. I.e. explain how these “things” work and operate. What is their control plane, what is their data plane, etc.? Make sure that you’re not creating “empty shells” that are to be defined at a later stage. An approach to create forward references to currently non existing documents like “Other documents might also be needed but they are out of scope of this one” (see your message below) are not appropriate for a specification.
 - if you believe that your IFIT specification has nothing to do with Huawei’s IFIT proprietary implementation (i.e. https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-ctc.huawei.com%2Fke%2Fpress-events%2Fnews%2F2019%2F6%2Ffirst-ifit-pilot-5g-transport-network-beijing-unicom-huawei&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155305143&amp;sdata=vlsft6Tj%2BuI2rH6NCdZO0qf2O7%2BR9KSI0b%2FF0bjEkoY%3D&amp;reserved=0) then I strongly suggest that you choose a different name for your implementation. 

Frank

Thanks!

Haoyu

获取 https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fghei36&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155305143&amp;sdata=JL2%2BLWYc04fnRBAOUcsUByjP6eUFmD8KW6XbYiDGd0s%3D&amp;reserved=0

* The WG minutes (https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F106%2Fmaterials%2Fminutes-106-opsawg-01&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155305143&amp;sdata=1GNq52BxnTLejtyH17quH%2FaNHPodQS4YukznPvQZq6w%3D&amp;reserved=0) miss a significant portion of comments and feedback as Benoit rightly points out below. E.g. Joe Clarke’s (as individual) comments are NOT mentioned at all, my comments are misrepresented.

* The authors did NOT reflect any of the comments made by myself (see https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2FrY-u8177wpU%3Ft%3D3785&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155305143&amp;sdata=X%2Fj2PSaoQSNFy1xTFNjfhUwt4KXjJY8ol3oKYVG2UH8%3D&amp;reserved=0) or by Joe Clarke. IMHO this is NOT appropriate for editors of a “soon to be” WG document. 

* draft-song-opsawg-ifit-framework-09 introduces a lot of new entities, e.g. IFIT Applications, IFIT Domain, IFIT Node, IFIT End-Node, etc. None of these entities are specified in the document, which means that the IETF would endorse a framework without even understanding the components/entities of the framework. The presenter responded (https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2FrY-u8177wpU%3Ft%3D3867&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155305143&amp;sdata=A2UP99wRCzNTk9OPci0%2FLE3KvzQQD%2FBJJHPmfhVqh8c%3D&amp;reserved=0 ) that it would be just a “very high level framework” that should fit any existing solution. If everything fits, i.e. “I FIT”, “You FIT”, “We all Fit”, … then why do we even need the definition of new entities? There is NO need to define “empty shells” for a lot of new entities, if all what the authors intend to do is compare different solutions.

* Different from what the presenter claimed, IFIT is NOT just “a high-level framework”, but IFIT is a proprietary Huawei technology, see e.g. https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-ctc.huawei.com%2Fke%2Fpress-events%2Fnews%2F2019%2F6%2Ffirst-ifit-pilot-5g-transport-network-beijing-unicom-huawei&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155315140&amp;sdata=btJwYOUGtJnA8RKntlXXV5F0Xsu4H7rVO5gacId%2FgYg%3D&amp;reserved=0. Public specifications for IFIT don’t seem to be available, with the exception of draft-li-6man-ipv6-sfc-ifit-02 which introduces new encapsulations. I.e. IFIT-Nodes, IFIT-End-Nodes etc. do exist – we just don’t know what they do. Looking at the people who responded to the adoption thread so far, one could also read the responses as a desire for a detailed documentation of the specification and lessons learned from deployments of Huawei’s IFIT.

Different from draft-song-opsawg-ifit-framework-09, which I do NOT support the adoption of, the following documents might be worthwhile documents (especially given the broad interest) to create/share:
- requirements
- comprehensive industry technology survey
- specification and deployment experiences of Huawei’s IFIT I already made this suggestion back in the WG meeting at IETF 106 – but per the above it was ignored at multiple levels.

Regards, Frank

Hi Tianran,
Hi Benoit,

Regards, B.

Cheers,
Tianran 

Dear all,

After reviewing thehttps://datatracker.ietf.org/doc/minutes-106-opsawg/, I was a little bit puzzled. From my recollection, Joe and Frank had some good feedback on the draft.
Also, in the minutes, I did not see any mention of Joe's feedback. And Frank's feedback on the draft is summarized as 4 words: "the scope is large"
So I went back and reviewed the https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DrY-u8177wpU&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155315140&amp;sdata=qfSNeIXLJRJo1WRh40SUF0K76wU8pi%2B5O1kIanyXXj8%3D&amp;reserved=0. 

Hi WG,
 
On IETF 106 meeting, we saw predominant interest and support to this draft, especially from operators. The authors then resolved all the open issues.
As requested by the authors, this email starts a 2 weeks working group adoption call for draft-song-opsawg-ifit-framework-09.
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit-framework%2F&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155315140&amp;sdata=K5azjOJhUbN3NDUhuwbV92cxcDKCPO9%2FubsdFBAObdY%3D&amp;reserved=0 

Thanks,
Tianran as co-chair

_______________________________________________
OPSAWG mailing list
mailto:[email-masked]
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155315140&amp;sdata=GOk5SIXxkgomuo7yxv1p9Qs4%2BcfgRjEGN13j8q40zjo%3D&amp;reserved=0

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Fri, 20 Dec 2019 07:10:16 +0000

Haoyu,

Thanks. Reading through your response below, you still don't seem to follow what I say. The document in its current form isn't appropriate as a standards document. That is why I suggested a couple of options to make it one - which you seem to ignore. The fact that several people find it useful does make it an appropriate standards document. E.g. a Huawei whitepaper might also be considered useful by several people, still a whitepaper is not a standards document. 

And per what I said earlier, if you decide to evolve your document towards a properly scoped specification, make sure that you choose a proper and non-confusing name. If your IFIT is really different from Huawei's IFIT, then just call it something else. Even your co-worker Alex Clemm was suggesting a name change.

Happy holidays.

Frank

> Sent: Donnerstag, 19. Dezember 2019 19:01
> To: Frank Brockners (fbrockne) <[email-masked]>; opsawg
> <[email-masked]>; draft-song-opsawg-ifit-framework.authors <draft-song-
> [email-masked]>
> The core of the draft is a framework for data plane on-path telemetry. It's not a
> dedicated requirement document, neither a survey. The challenges we described
> are just used to motivate the framework. The standard gap analysis is also
> necessary to show how this framework can be implemented in the future.  While
> I agree the document is not perfect and still need to improve, I think the main
> information and logic flow are clear. I also think the document is self-sufficient.
> It's just a high level guide for future development but doesn't intend to put any
> constraints.
> 
> I said “Other documents might also be needed but they are out of scope of this
> one”, not to reference some non-existing document, but to respond to your
> previous email in which you suggest other documents like survey and
> deployment experience etc.  This document does not server those purpose.
> 
> While you ask for detailed specification (up to the level about how the controller
> to configure the nodes and what data to export, etc.) , you may still think from a
> perspective that this document is a solution specification, but it's not. I'm very
> sorry for that impression. We already emphasized in the document that we don’t
> intend to specify any interface and implementation details, but to describe high
> level functions. To server that purpose, a loose definition for the terms is
> enough and proper.
> 
> For example, we define iFIT Node as "a network node that is in an iFIT domain
> and is capable of iFIT-specific functions." So yes it forwards and processes
> traffic. I don't think anybody will misunderstand this. You ask how,  for which we
> can only provide high level function descriptions but won't specify any detail
> because we have made it very clear that's not the intention of this document.
> 
> So let's just focus on the current scope and content of the document, to see if
> it's useful and valuable to the community as a whole. From the majority
> responses, mostly from real network operators, the feedbacks are so far very
> positive and they all support the adoption of this document. I think that says
> something.
> 
> Best regards,
> Haoyu
> 
> 
> 
> To: Haoyu Song <[email-masked]>; opsawg <[email-masked]>;
> draft-song-opsawg-ifit-framework.authors <draft-song-opsawg-ifit-
> [email-masked]>
> you and your co-authors need to decide what the document is intended to be: A
> requirements document, an industry implementation survey, or a specification?
> Right now the document is a bit of everything – with nothing is appropriately
> spelled out and detailed for a standards document.
> 
>  - remove all references to iFIT and similar – none of this is needed to articulate
> requirements If the document is intended as an industry survey:
>  - remove all references to iFIT and similar that try to specify things – none of
> this is needed to for an industry survey If the document is intended as a
> specification or case study
>  - provide technical specifications for IFIT node, IFIT application, IFIT Head
> Node, IFIT End Node, etc. I.e. explain how these “things” work and operate.
> What is their control plane, what is their data plane, etc.? Make sure that you’re
> not creating “empty shells” that are to be defined at a later stage. An approach
> to create forward references to currently non existing documents like “Other
> documents might also be needed but they are out of scope of this one” (see
> your message below) are not appropriate for a specification.
>  - if you believe that your IFIT specification has nothing to do with Huawei’s IFIT
> proprietary implementation (i.e.
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-
> ctc.huawei.com%2Fke%2Fpress-events%2Fnews%2F2019%2F6%2Ffirst-ifit-
> pilot-5g-transport-network-beijing-unicom-
> huawei&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c
> 2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0
> %7C637123622155305143&amp;sdata=vlsft6Tj%2BuI2rH6NCdZO0qf2O7%2BR9
> KSI0b%2FF0bjEkoY%3D&amp;reserved=0) then I strongly suggest that you
> choose a different name for your implementation.
> 
> Just to highlight that different from what you say, the specification of IFIT
> elements neither helps in articulating requirements nor does it support different
> industry solutions: If you take the example of an “IFIT Node” – there is a total of
> 8 occurrences in the document, with 5 of them in the main part of the
> document. The document defines “iFIT Node” as “a network node that is in an
> iFIT domain and is capable of iFIT-specific functions”. None of the 5 occurrences
> in the document is used for comparison or requirements definition, neither do
> they detail what IFIT specific functions are carried out by an IFIT node. Reading
> through the 5 occurrences,  one learns that iFIT nodes seem to be configured by
> a controller (what is a controller?), they seem to be able to do some form of
> data collection (how?, what data?), they seem to be able to export data using
> IPFIX and protobuf (what data is exported?), they seem to be able to cache data,
> and they seem to contain DNP. Reading through this, I still don’t know what IFIT
> Nodes are… Do they forward traffic? Do they process traffic? If so how? ...
> 
> - After the telemetry data processing and analyzing, the iFIT application may
> instruct the controller to modify the iFIT node configuration and affect the
> future telemetry data collection.
> - In addition to efficient export data encoding (e.g., IPFIX [RFC7011] or protobuf
> [1]), iFIT nodes have several other ways to reduce the export data by taking
> advantage of network device's capability and programmability.
> - The controller translates an intent and configure the corresponding DNPs in
> iFIT nodes which collect necessary network information.
> 
> Frank
> 
> To: Frank Brockners (fbrockne) <[email-masked]>; opsawg
> <[email-masked]>; draft-song-opsawg-ifit-framework.authors <draft-song-
> [email-masked]>
> Again, I need to point out the fact that I have listed all the questions raised
> during the meeting (including Frank's and Joe's) and I asked if I missed anything
> or misunderstood anything in an email to the list. But I didn't got any feedback
> from the queationers, so I believed  I had correctly understood the questions
> and then made updates accordingly. So, I don't understand why Frank still use
> the meeting video to question the draft. Please read and answer my email and
> draft, and let me know what you are not agree with based on that.
> 
> IFIT is NOT a proprietary solution.  Period.  I  don't think anybody can gain such a
> feeling from reading it.   There's no solution but requirement, challenges, a high
> level framework, examples, and standard gap analysis. How can it be a solution?
> 
> 
> Other documents might also be needed but they are out of scope of this one.  I
> firmly believe this one is also needed for the reason we clearly stated in the
> draft.
> 
> Thanks!
> 
> Haoyu
> 
> 
> 获取
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms
> %2Fghei36&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6
> a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%
> 7C0%7C637123622155305143&amp;sdata=JL2%2BLWYc04fnRBAOUcsUByjP6e
> UFmD8KW6XbYiDGd0s%3D&amp;reserved=0
> 
> Are we following our practices and procedures properly? For the record, in case
> others are equally puzzled about this call for adoption:
> 
> * Different from what the co-chair states in his WG adoption call below (“The
> authors then resolved all the open issues”), draft-song-opsawg-ifit-framework-
> 09 does NOT resolve all open issues nor does the document reflect all the WG
> feedback received at IETF 106.
> 
> * The WG minutes
> (https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatra
> cker.ietf.org%2Fmeeting%2F106%2Fmaterials%2Fminutes-106-opsawg-
> 01&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f
> 90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6
> 37123622155305143&amp;sdata=1GNq52BxnTLejtyH17quH%2FaNHPodQS4Yuk
> znPvQZq6w%3D&amp;reserved=0) miss a significant portion of comments and
> feedback as Benoit rightly points out below. E.g. Joe Clarke’s (as individual)
> comments are NOT mentioned at all, my comments are misrepresented.
> 
> * The authors did NOT reflect any of the comments made by myself (see
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.b
> e%2FrY-
> u8177wpU%3Ft%3D3785&amp;data=02%7C01%7Chaoyu.song%40futurewei.co
> m%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d55
> 91fedc%7C1%7C0%7C637123622155305143&amp;sdata=X%2Fj2PSaoQSNFy1xT
> FNjfhUwt4KXjJY8ol3oKYVG2UH8%3D&amp;reserved=0) or by Joe Clarke. IMHO
> this is NOT appropriate for editors of a “soon to be” WG document.
> 
> * draft-song-opsawg-ifit-framework-09 introduces a lot of new entities, e.g.
> IFIT Applications, IFIT Domain, IFIT Node, IFIT End-Node, etc. None of these
> entities are specified in the document, which means that the IETF would endorse
> a framework without even understanding the components/entities of the
> framework. The presenter responded
> (https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.b
> e%2FrY-
> u8177wpU%3Ft%3D3867&amp;data=02%7C01%7Chaoyu.song%40futurewei.co
> m%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d55
> 91fedc%7C1%7C0%7C637123622155305143&amp;sdata=A2UP99wRCzNTk9OP
> ci0%2FLE3KvzQQD%2FBJJHPmfhVqh8c%3D&amp;reserved=0 ) that it would be
> just a “very high level framework” that should fit any existing solution. If
> everything fits, i.e. “I FIT”, “You FIT”, “We all Fit”, … then why do we even need
> the definition of new entities? There is NO need to define “empty shells” for a
> lot of new entities, if all what the authors intend to do is compare different
> solutions.
> 
> * Different from what the presenter claimed, IFIT is NOT just “a high-level
> framework”, but IFIT is a proprietary Huawei technology, see e.g.
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-
> ctc.huawei.com%2Fke%2Fpress-events%2Fnews%2F2019%2F6%2Ffirst-ifit-
> pilot-5g-transport-network-beijing-unicom-
> huawei&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c
> 2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0
> %7C637123622155315140&amp;sdata=btJwYOUGtJnA8RKntlXXV5F0Xsu4H7rVO
> 5gacId%2FgYg%3D&amp;reserved=0. Public specifications for IFIT don’t seem to
> be available, with the exception of draft-li-6man-ipv6-sfc-ifit-02 which
> introduces new encapsulations. I.e. IFIT-Nodes, IFIT-End-Nodes etc. do exist –
> we just don’t know what they do. Looking at the people who responded to the
> adoption thread so far, one could also read the responses as a desire for a
> detailed documentation of the specification and lessons learned from
> deployments of Huawei’s IFIT.
> 
> Different from draft-song-opsawg-ifit-framework-09, which I do NOT support
> the adoption of, the following documents might be worthwhile documents
> (especially given the broad interest) to create/share:
> - requirements
> - specification and deployment experiences of Huawei’s IFIT I already made this
> suggestion back in the WG meeting at IETF 106 – but per the above it was
> ignored at multiple levels.
> 
> Regards, Frank
> 
> To: Tianran Zhou <mailto:[email-masked]>; opsawg
> <mailto:[email-masked]>; draft-song-opsawg-ifit-framework.authors
> <mailto:[email-masked]>
> My last question was only to check if there is enough interest on this work, not
> an adoption call. There was q&a after the presentation. And Joe cut the line
> because of the time.
> 
> 收件人： Tianran
> Zhou<mailto:[email-masked]>;opsawg<mailto:[email-masked]>;dra
> ft-song-opsawg-ifit-framework.authors<mailto:draft-song-opsawg-ifit-
> [email-masked]>
> After reviewing thehttps://datatracker.ietf.org/doc/minutes-106-opsawg/, I
> was a little bit puzzled. From my recollection, Joe and Frank had some good
> feedback on the draft.
> Also, in the minutes, I did not see any mention of Joe's feedback. And Frank's
> feedback on the draft is summarized as 4 words: "the scope is large"
> So I went back and reviewed the
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.y
> outube.com%2Fwatch%3Fv%3DrY-
> u8177wpU&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6
> a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%
> 7C0%7C637123622155315140&amp;sdata=qfSNeIXLJRJo1WRh40SUF0K76wU8p
> i%2B5O1kIanyXXj8%3D&amp;reserved=0.
> 
> I support Frank's feedback that this document scope is too large: a mix of an
> inventory of what exists, a set of requirements, and specifications/framework.
> I'm wondering: what is the scope of this document? Before we clarify this, I
> don't think we should adopt this document.
> 
> problems (I believe we have full agreement) and whether this document is a
> good starting point. I object to the latter, with the document in the current
> form.
> Regards, Benoit
> 
> Hi WG,
> 
> As requested by the authors, this email starts a 2 weeks working group adoption
> call for draft-song-opsawg-ifit-framework-09.
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatra
> cker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit-
> framework%2F&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C524
> 7a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7
> C1%7C0%7C637123622155315140&amp;sdata=K5azjOJhUbN3NDUhuwbV92cxc
> DKCPO9%2FubsdFBAObdY%3D&amp;reserved=0
> 
> indication of why you think it is important. Also please say if you will be willing
> to review and help the draft.
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Fmailman%2Flistinfo%2Fopsawg&amp;data=02%7C01%7Chaoyu.song
> %40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b2
> 40189c753a1d5591fedc%7C1%7C0%7C637123622155315140&amp;sdata=GOk
> 5SIXxkgomuo7yxv1p9Qs4%2BcfgRjEGN13j8q40zjo%3D&amp;reserved=0
>

---

From: Haoyu Song <[email-masked]>
Date: Fri, 20 Dec 2019 17:44:34 +0000

Frank,

This status of this document is "informational", not "standard". Please show me what's and what's not appropriate for an informational document. 

Haoyu
-----Original Message-----
From: Frank Brockners (fbrockne) <[email-masked]> 
Sent: Thursday, December 19, 2019 11:10 PM
To: Haoyu Song <[email-masked]>; opsawg <[email-masked]>; draft-song-opsawg-ifit-framework.authors <[email-masked]>
Cc: opsawg-chairs <[email-masked]>
Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Haoyu,

Happy holidays.

Frank

> <[email-masked]>; draft-song-opsawg-ifit-framework.authors 
> <draft-song- [email-masked]>
> Subject: RE: [OPSAWG] WG adoption call for 
> The core of the draft is a framework for data plane on-path telemetry. 
> It's not a dedicated requirement document, neither a survey. The 
> challenges we described are just used to motivate the framework. The 
> standard gap analysis is also necessary to show how this framework can 
> be implemented in the future.  While I agree the document is not 
> perfect and still need to improve, I think the main information and logic flow are clear. I also think the document is self-sufficient.
> It's just a high level guide for future development but doesn't intend 
> to put any constraints.
> 
> I said “Other documents might also be needed but they are out of scope 
> of this one”, not to reference some non-existing document, but to 
> respond to your previous email in which you suggest other documents 
> like survey and deployment experience etc.  This document does not server those purpose.
> 
> While you ask for detailed specification (up to the level about how 
> the controller to configure the nodes and what data to export, etc.) , 
> you may still think from a perspective that this document is a 
> solution specification, but it's not. I'm very sorry for that 
> impression. We already emphasized in the document that we don’t intend 
> to specify any interface and implementation details, but to describe 
> high level functions. To server that purpose, a loose definition for the terms is enough and proper.
> 
> For example, we define iFIT Node as "a network node that is in an iFIT 
> domain and is capable of iFIT-specific functions." So yes it forwards 
> and processes traffic. I don't think anybody will misunderstand this. 
> You ask how,  for which we can only provide high level function 
> descriptions but won't specify any detail because we have made it very clear that's not the intention of this document.
> 
> So let's just focus on the current scope and content of the document, 
> to see if it's useful and valuable to the community as a whole. From 
> the majority responses, mostly from real network operators, the 
> feedbacks are so far very positive and they all support the adoption 
> of this document. I think that says something.
> 
> Best regards,
> Haoyu
> 
> 
> 
> Subject: RE: [OPSAWG] WG adoption call for 
> you and your co-authors need to decide what the document is intended 
> to be: A requirements document, an industry implementation survey, or a specification?
> Right now the document is a bit of everything – with nothing is 
> appropriately spelled out and detailed for a standards document.
> 
>  - remove all references to iFIT and similar – none of this is needed 
> to articulate requirements If the document is intended as an industry survey:
>  - remove all references to iFIT and similar that try to specify 
> things – none of this is needed to for an industry survey If the 
> document is intended as a specification or case study
>  - provide technical specifications for IFIT node, IFIT application, 
> IFIT Head Node, IFIT End Node, etc. I.e. explain how these “things” work and operate.
> What is their control plane, what is their data plane, etc.? Make sure 
> that you’re not creating “empty shells” that are to be defined at a 
> later stage. An approach to create forward references to currently non 
> existing documents like “Other documents might also be needed but they 
> are out of scope of this one” (see your message below) are not appropriate for a specification.
>  - if you believe that your IFIT specification has nothing to do with 
> Huawei’s IFIT proprietary implementation (i.e.
> Just to highlight that different from what you say, the specification 
> of IFIT elements neither helps in articulating requirements nor does 
> it support different industry solutions: If you take the example of an 
> “IFIT Node” – there is a total of
> document. The document defines “iFIT Node” as “a network node that is 
> in an iFIT domain and is capable of iFIT-specific functions”. None of 
> the 5 occurrences in the document is used for comparison or 
> requirements definition, neither do they detail what IFIT specific 
> functions are carried out by an IFIT node. Reading through the 5 
> occurrences,  one learns that iFIT nodes seem to be configured by a 
> controller (what is a controller?), they seem to be able to do some 
> form of data collection (how?, what data?), they seem to be able to 
> export data using IPFIX and protobuf (what data is exported?), they 
> seem to be able to cache data, and they seem to contain DNP. Reading through this, I still don’t know what IFIT Nodes are… Do they forward traffic? Do they process traffic? If so how? ...
> 
> - After the telemetry data processing and analyzing, the iFIT 
> application may instruct the controller to modify the iFIT node 
> configuration and affect the future telemetry data collection.
> - In addition to efficient export data encoding (e.g., IPFIX [RFC7011] 
> or protobuf [1]), iFIT nodes have several other ways to reduce the 
> export data by taking advantage of network device's capability and programmability.
> - The controller translates an intent and configure the corresponding 
> DNPs in iFIT nodes which collect necessary network information.
> 
> Frank
> 
> <[email-masked]>; draft-song-opsawg-ifit-framework.authors 
> <draft-song- [email-masked]>
> Subject: Re: [OPSAWG] WG adoption call for 
> Again, I need to point out the fact that I have listed all the 
> questions raised during the meeting (including Frank's and Joe's) and 
> I asked if I missed anything or misunderstood anything in an email to 
> the list. But I didn't got any feedback from the queationers, so I 
> believed  I had correctly understood the questions and then made 
> updates accordingly. So, I don't understand why Frank still use the 
> meeting video to question the draft. Please read and answer my email and draft, and let me know what you are not agree with based on that.
> 
> IFIT is NOT a proprietary solution.  Period.  I  don't think anybody 
> can gain such a feeling from reading it.   There's no solution but 
> requirement, challenges, a high level framework, examples, and standard gap analysis. How can it be a solution?
> 
> 
> Other documents might also be needed but they are out of scope of this 
> one.  I firmly believe this one is also needed for the reason we 
> clearly stated in the draft.
> 
> Thanks!
> 
> Haoyu
> 
> 
> 获取
> Are we following our practices and procedures properly? For the 
> record, in case others are equally puzzled about this call for adoption:
> 
> * Different from what the co-chair states in his WG adoption call 
> below (“The authors then resolved all the open issues”), 
> draft-song-opsawg-ifit-framework-
> 09 does NOT resolve all open issues nor does the document reflect all 
> the WG feedback received at IETF 106.
> 
> * The WG minutes
> znPvQZq6w%3D&amp;reserved=0) miss a significant portion of comments 
> and feedback as Benoit rightly points out below. E.g. Joe Clarke’s (as 
> individual) comments are NOT mentioned at all, my comments are misrepresented.
> 
> IFIT Applications, IFIT Domain, IFIT Node, IFIT End-Node, etc. None of 
> these entities are specified in the document, which means that the 
> IETF would endorse a framework without even understanding the 
> components/entities of the framework. The presenter responded 
> just a “very high level framework” that should fit any existing 
> solution. If everything fits, i.e. “I FIT”, “You FIT”, “We all Fit”, … 
> then why do we even need the definition of new entities? There is NO 
> need to define “empty shells” for a lot of new entities, if all what 
> the authors intend to do is compare different solutions.
> 
> * Different from what the presenter claimed, IFIT is NOT just “a 
> high-level framework”, but IFIT is a proprietary Huawei technology, see e.g.
> 5gacId%2FgYg%3D&amp;reserved=0. Public specifications for IFIT don’t 
> seem to be available, with the exception of 
> draft-li-6man-ipv6-sfc-ifit-02 which introduces new encapsulations. 
> I.e. IFIT-Nodes, IFIT-End-Nodes etc. do exist – we just don’t know 
> what they do. Looking at the people who responded to the adoption 
> thread so far, one could also read the responses as a desire for a 
> detailed documentation of the specification and lessons learned from deployments of Huawei’s IFIT.
> 
> Different from draft-song-opsawg-ifit-framework-09, which I do NOT 
> support the adoption of, the following documents might be worthwhile 
> documents (especially given the broad interest) to create/share:
> - requirements
> - specification and deployment experiences of Huawei’s IFIT I already 
> made this suggestion back in the WG meeting at IETF 106 – but per the 
> above it was ignored at multiple levels.
> 
> Regards, Frank
> 
> Subject: Re: [OPSAWG] WG adoption call for 
> 主题： Re: [OPSAWG] WG adoption call for 
> After reviewing 
> thehttps://datatracker.ietf.org/doc/minutes-106-opsawg/, I was a 
> little bit puzzled. From my recollection, Joe and Frank had some good feedback on the draft.
> mix of an inventory of what exists, a set of requirements, and specifications/framework.
> I'm wondering: what is the scope of this document? Before we clarify 
> this, I don't think we should adopt this document.
> 
> On IETF 106 meeting, we saw predominant interest and support to this 
> draft, especially from operators. The authors then resolved all the open issues.
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ie tf.org%2Fmailman%2Flistinfo%2Fopsawg&amp;data=02%7C01%7Chaoyu.song

---

From: Haoyu Song <[email-masked]>
Date: Fri, 20 Dec 2019 18:00:13 +0000

FYI,  the text below is quoted form RFC2026:
"
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).

Specifications that have been prepared outside of the Internet community and are not incorporated into the Internet Standards Process by any of the provisions of section 10 may be published as Informational RFCs, with the permission of the owner and the concurrence of the RFC Editor.
"
-----Original Message-----
From: Haoyu Song 
Sent: Friday, December 20, 2019 9:45 AM
To: Frank Brockners (fbrockne) <[email-masked]>; opsawg <[email-masked]>; draft-song-opsawg-ifit-framework.authors <[email-masked]>
Cc: opsawg-chairs <[email-masked]>
Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Frank,

Haoyu
-----Original Message-----
From: Frank Brockners (fbrockne) <[email-masked]>
Sent: Thursday, December 19, 2019 11:10 PM
To: Haoyu Song <[email-masked]>; opsawg <[email-masked]>; draft-song-opsawg-ifit-framework.authors <[email-masked]>
Cc: opsawg-chairs <[email-masked]>
Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Haoyu,

Happy holidays.

Frank

> 09
> 09
> 09
> 09
> 09
> y

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Sat, 21 Dec 2019 18:16:19 +0000

Haoyu,

thanks for clarifying publication objective - this indeed changes things quite a bit; i.e. you're planning to publish your document as part of the independent submission stream (per RFC 7841). Given that your document is not aimed at the IETF stream, there is indeed no need for IETF consensus - and also no need for WG adoption of the document. In other words, the current adoption call and my earlier comments are pointless. I still suggest that you consider the feedback received - it'll improve whatever you'd end up publishing.

Happy holidays - I'll be offline for the next couple of days.

Frank

> Sent: Freitag, 20. Dezember 2019 19:00
> 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).
> 
> Specifications that have been prepared outside of the Internet community and
> are not incorporated into the Internet Standards Process by any of the
> provisions of section 10 may be published as Informational RFCs, with the
> permission of the owner and the concurrence of the RFC Editor.
> "
> This status of this document is "informational", not "standard". Please show me
> what's and what's not appropriate for an informational document.
> 
> Haoyu
> Thanks. Reading through your response below, you still don't seem to follow
> what I say. The document in its current form isn't appropriate as a standards
> document. That is why I suggested a couple of options to make it one - which
> you seem to ignore. The fact that several people find it useful does make it an
> appropriate standards document. E.g. a Huawei whitepaper might also be
> considered useful by several people, still a whitepaper is not a standards
> document.
> 
> And per what I said earlier, if you decide to evolve your document towards a
> properly scoped specification, make sure that you choose a proper and non-
> confusing name. If your IFIT is really different from Huawei's IFIT, then just call it
> something else. Even your co-worker Alex Clemm was suggesting a name
> change.
> 
> Happy holidays.
> 
> Frank
> 
> > perfect and still need to improve, I think the main information and logic flow
> are clear. I also think the document is self-sufficient.
> > descriptions but won't specify any detail because we have made it very clear
> that's not the intention of this document.
> >
> > seem to be able to cache data, and they seem to contain DNP. Reading
> through this, I still don’t know what IFIT Nodes are… Do they forward traffic? Do
> they process traffic? If so how? ...
> >
> > meeting video to question the draft. Please read and answer my email and
> specifications/framework.
> > ie

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 21 Dec 2019 22:46:38 -0000

I think this discussion might have gotten a little out of hand!

Frank is clearly upset that his comments at the microphone did not make it into the minutes. I think we all have a responsibility to review draft minutes when we have made comments and check that they have been captured correctly. We should also attempt to capture important discussion points on the mailing list where they can be processed carefully by everyone, but especially by those for whom handling comments spoken in English may be a challenge.

But Frank has gone on to type up some of his concerns, and that is clearly helpful. It will give the authors something to work on as a result of the adoption call.

I think that there may be some confusion about the intended status of the document. Frank made several comments about "standards documents" and I believe that Haoyu was attempting to observe that the document is targeted as an Informational document, not a Standards Track document. Quoting from 2026 on this matter is not helpful because the shape and origin of Informational RFCs has changed a lot since those days. Thus, the quote allows Frank to think that the document is intended for publication on the Independent Submission Stream. But clearly that is not the intention, and a moment's thought would indicate that authors asking for adoption in an IETF working group would not be consistent with publication as an Independent Submission.

Indeed, it might be best if we all follow Frank's advice to work to improve the document. Snarky comments are not helpful, and attempting to represent the IETF process without a good grasp of it is also not valuable. But careful and constructive reviews are helpful and should be listened to. So should the considered responses to the reviews.

Lastly, the clarity about the intent of the document is important. This document needs to set out its purpose and deliver that (and no more than that). At the same time, it will not get us anywhere to say, "This is not the document I thought it was," or even "This is not the document I wanted to read." If you want to see something additional in a document you probably have to write it 😊

Hoping that peace and goodwill can break out of the holiday period.

Adrian

-----Original Message-----
From: OPSAWG <[email-masked]> On Behalf Of Frank Brockners (fbrockne)
Sent: 21 December 2019 18:16
To: Haoyu Song <[email-masked]>; opsawg <[email-masked]>; draft-song-opsawg-ifit-framework.authors <[email-masked]>
Cc: opsawg-chairs <[email-masked]>
Subject: Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Haoyu,

Frank

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 22 Dec 2019 01:13:29 +0000

Hi OPSAWG, and IPPM WG,

The adoption call for this draft is somewhat
controversial, so I looked into a few details and 
background discussions, especially the e-mail thread
for the call for adoption and the draft itself.

I have read messages expressing concern over the scope of this 
work, and note that the draft does not have a Scope section
(or material that fulfils this need concisely).
It would certainly be easier for the WG to reach
consensus whether to adopt or not if the scope was clear.

From the OPSAWG Charter:
    The focus of the work will be on topics that govern the behavior or WGs
    in the O&M area (e.g., manageability requirements) and on *small,
    highly focused projects that don't merit a WG of their own* or belong
    to WGs that have already concluded (e.g. advancement of documents on
    the standards track, application statements, extensions of MIB
    modules).
This seems to be the relevant paragraph under which the
draft might be considered as in-scope, but I don't see a direct
match here, especially recognizing the additional work to fill
gaps described in Section 6. A draft with wide scope seems 
better positioned as a new WG-level effort, if it is undertaken 
by IETF, IMO.

I have cross-posted this message to the IPPM WG, where 
work-in-progress includes 4 IOAM-related drafts. The topic
origins go back to 2016, with the first IPPM WG adoption almost
3 years ago. Later, this general Framework draft appears (2018)
having overlap with the IPPM work and discussing some of the 
same problems (even hinting at solutions in various places).
IMO, there is more coordination needed here before another
IETF Area adopts work with clear relevance/overlap (see the
4th paragraph of Section 1, Requirements and Challenges 
and its many references).

Also, I note this draft's attempt to define a new category of methods
of measurement (4th paragraph of Section 1, last 2 sentences):

   ... These on-path telemetry techniques are
   very different from the previous active and passive OAM schemes in
   that they directly modify the user packets and can guarantee 100%
   accuracy.  These on-path telemetry techniques can be classified as
   the hybrid OAM type III, supplementing the classification defined in
   [RFC7799].

There isn't enough information supplied to make such a decision,
especially since the RFC 7799 categories were agreed to be fairly 
exhaustive, and IOAM discussions agreed on one of the existing 
classifications (Hybrid Type I).

For these reasons, I support further discussion of this draft and
cannot recommend OPSAWG adoption at this point in time. I believe
this topic needs wider coordination now.

Finally, I echo Adrian's wishes for peace and goodwill as the 
holidays approach.

Al

> From: OPSAWG [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Saturday, December 21, 2019 5:47 PM
> To: 'Frank Brockners (fbrockne)' <[email-masked]>; 'Haoyu Song'
> <[email-masked]>; 'opsawg' <[email-masked]>; 'draft-song-
> opsawg-ifit-framework.authors' <draft-song-opsawg-ifit-
> Cc: 'opsawg-chairs' <[email-masked]>
> Frank is clearly upset that his comments at the microphone did not make it
> into the minutes. I think we all have a responsibility to review draft
> minutes when we have made comments and check that they have been captured
> correctly. We should also attempt to capture important discussion points
> on the mailing list where they can be processed carefully by everyone, but
> especially by those for whom handling comments spoken in English may be a
> challenge.
> 
> But Frank has gone on to type up some of his concerns, and that is clearly
> helpful. It will give the authors something to work on as a result of the
> adoption call.
> 
> I think that there may be some confusion about the intended status of the
> document. Frank made several comments about "standards documents" and I
> believe that Haoyu was attempting to observe that the document is targeted
> as an Informational document, not a Standards Track document. Quoting from
> 2026 on this matter is not helpful because the shape and origin of
> Informational RFCs has changed a lot since those days. Thus, the quote
> allows Frank to think that the document is intended for publication on the
> Independent Submission Stream. But clearly that is not the intention, and
> a moment's thought would indicate that authors asking for adoption in an
> IETF working group would not be consistent with publication as an
> Independent Submission.
> 
> Indeed, it might be best if we all follow Frank's advice to work to
> improve the document. Snarky comments are not helpful, and attempting to
> represent the IETF process without a good grasp of it is also not
> valuable. But careful and constructive reviews are helpful and should be
> listened to. So should the considered responses to the reviews.
> 
> Lastly, the clarity about the intent of the document is important. This
> document needs to set out its purpose and deliver that (and no more than
> that). At the same time, it will not get us anywhere to say, "This is not
> the document I thought it was," or even "This is not the document I wanted
> to read." If you want to see something additional in a document you
> probably have to write it 😊
> 
> thanks for clarifying publication objective - this indeed changes things
> quite a bit; i.e. you're planning to publish your document as part of the
> independent submission stream (per RFC 7841). Given that your document is
> not aimed at the IETF stream, there is indeed no need for IETF consensus -
> and also no need for WG adoption of the document. In other words, the
> current adoption call and my earlier comments are pointless. I still
> suggest that you consider the feedback received - it'll improve whatever
> you'd end up publishing.
> 
> > Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-
> framework-
> > 09
> >
> > Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-
> framework-
> > 09
> >
> > Frank,
> >
> > Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-
> framework-
> > 09
> >
> > Haoyu,
> >
> > > like survey and deployment experience etc.  This document does not
> server
> > those purpose.
> > >
> > > high level functions. To server that purpose, a loose definition for
> the terms is
> > enough and proper.
> > >
> > > to be: A requirements document, an industry implementation survey, or
> a
> > specification?
> > > IFIT Head Node, IFIT End Node, etc. I.e. explain how these “things”
> work and
> > operate.
> > > are out of scope of this one” (see your message below) are not
> appropriate
> > for a specification.
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-
> 252Fwww-2D&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-
> e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=t3Pj9_3hNXIpYPxvpewchS-
> XGOEVh6Dlpui4Q7JH_aw&s=3xlVh2xaSl-nuvZNdyBxgiU6xENZhtdBPZPCyeveoXM&e=
> > > requirement, challenges, a high level framework, examples, and
> standard gap
> > analysis. How can it be a solution?
> > >
> > >
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-
> 252Faka&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-
> e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=t3Pj9_3hNXIpYPxvpewchS-
> XGOEVh6Dlpui4Q7JH_aw&s=UiYW-15S8kZi-vIEEsGgdTSeAzwFm-06OVBcATkI_y8&e= .
> > > ms
> > >
> > > (https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-
> 252Fdat&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-
> e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=t3Pj9_3hNXIpYPxvpewchS-
> XGOEVh6Dlpui4Q7JH_aw&s=FCWt1wpkIdOpsVl78Hyr5OxR2DyxkezIn_834S8w5q0&e=
> > > atra
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-
> 252Fyout&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-
> e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=t3Pj9_3hNXIpYPxvpewchS-
> XGOEVh6Dlpui4Q7JH_aw&s=De-hUklV0D7H7TD1_3zqZ_ZdYUcgAXXAxGhz71tVT_c&e=
> > > u.b
> > > e%2FrY-
> > >
> > > (https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-
> 252Fyou&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-
> e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=t3Pj9_3hNXIpYPxvpewchS-
> XGOEVh6Dlpui4Q7JH_aw&s=NGTZHZ1ekyw8TqfF_-z2K5c4U3y45lj04Lm6qor8dfQ&e=
> > > tu.b
> > > e%2FrY-
> > >
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-
> 252Fwww-2D&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-
> e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=t3Pj9_3hNXIpYPxvpewchS-
> XGOEVh6Dlpui4Q7JH_aw&s=3xlVh2xaSl-nuvZNdyBxgiU6xENZhtdBPZPCyeveoXM&e=
> > > little bit puzzled. From my recollection, Joe and Frank had some good
> feedback
> > on the draft.
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-
> 252Fwww&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-
> e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=t3Pj9_3hNXIpYPxvpewchS-
> XGOEVh6Dlpui4Q7JH_aw&s=eJnZzm6aTxQB2clTWjdViOC-31tdJ9c3Tz_hjoSyweo&e= .
> > > y
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-
> 252Fdata&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-
> e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=t3Pj9_3hNXIpYPxvpewchS-
> XGOEVh6Dlpui4Q7JH_aw&s=gkpvYp8pV3-INleyUi2mQI9YdsntNlPI_PB60Zwv4ko&e=
> > > tra
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-
> 252Fwww&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-
> e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=t3Pj9_3hNXIpYPxvpewchS-
> XGOEVh6Dlpui4Q7JH_aw&s=eJnZzm6aTxQB2clTWjdViOC-31tdJ9c3Tz_hjoSyweo&e= .
> > > ie
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_opsawg&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-
> 6zYMI&m=t3Pj9_3hNXIpYPxvpewchS-XGOEVh6Dlpui4Q7JH_aw&s=-
> hTNT3Bpn64Vf_F5NZlFlwx7ssFsOVPkk_Psp_AJ-04&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_opsawg&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-
> 6zYMI&m=t3Pj9_3hNXIpYPxvpewchS-XGOEVh6Dlpui4Q7JH_aw&s=-
> hTNT3Bpn64Vf_F5NZlFlwx7ssFsOVPkk_Psp_AJ-04&e=

---

From: Haoyu Song <[email-masked]>
Date: Thu, 26 Dec 2019 19:10:59 +0000

Hi Al,

Thank you very much for the comments. Please see my inline response marked with [HSong]. Happy Holidays!

Best regards,
Haoyu

-----Original Message-----
From: ippm <[email-masked]> On Behalf Of MORTON, ALFRED C (AL)
Sent: Saturday, December 21, 2019 5:13 PM
To: [email-masked]; 'Frank Brockners (fbrockne)' <[email-masked]>; 'opsawg' <[email-masked]>
Cc: [email-masked]; [email-masked]; 'opsawg-chairs' <[email-masked]>; Mirja Kühlewind (IETF) <[email-masked]>; Warren Kumari <[email-masked]>
Subject: Re: [ippm] [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

Hi OPSAWG, and IPPM WG,

The adoption call for this draft is somewhat controversial, so I looked into a few details and background discussions, especially the e-mail thread for the call for adoption and the draft itself.

I have read messages expressing concern over the scope of this work, and note that the draft does not have a Scope section (or material that fulfils this need concisely).
It would certainly be easier for the WG to reach consensus whether to adopt or not if the scope was clear.

From the OPSAWG Charter:
This seems to be the relevant paragraph under which the draft might be considered as in-scope, but I don't see a direct match here, especially recognizing the additional work to fill gaps described in Section 6. A draft with wide scope seems better positioned as a new WG-level effort, if it is undertaken by IETF, IMO.

[HSong]  I'll add a scope section to clearly define the scope of the draft. Although the draft discussed some potential standard gaps but the draft itself won't serve to fill the gap but to inspire possible future works. 

I have cross-posted this message to the IPPM WG, where work-in-progress includes 4 IOAM-related drafts. The topic origins go back to 2016, with the first IPPM WG adoption almost
3 years ago. Later, this general Framework draft appears (2018) having overlap with the IPPM work and discussing some of the same problems (even hinting at solutions in various places).
IMO, there is more coordination needed here before another IETF Area adopts work with clear relevance/overlap (see the 4th paragraph of Section 1, Requirements and Challenges and its many references).

[HSong] This draft describes a high level framework and doesn't introduce any new underlying measurement technique. It's akin to the NTF draft which was adopted by OPSAWG. It just discuss in a general way how to apply a specific set of techniques developed in IPPM WG.  

Also, I note this draft's attempt to define a new category of methods of measurement (4th paragraph of Section 1, last 2 sentences):

There isn't enough information supplied to make such a decision, especially since the RFC 7799 categories were agreed to be fairly exhaustive, and IOAM discussions agreed on one of the existing classifications (Hybrid Type I).

[HSong] After carefully reading  RFC7799, I think it is very likely these techniques should be categorized as Hybrid Type I  
“With respect to a *single* stream of interest, Hybrid Type I methods fit in the continuum as follows, in terms of what happens at the Source (or Observation Point nearby): Augmentation or modification of the stream of interest, or employment of methods that modify the treatment of the stream =>  Hybrid Type I”. 
If we have consensus on this, since this draft covers a class of closely related techniques, I think we should document it here.   

For these reasons, I support further discussion of this draft and cannot recommend OPSAWG adoption at this point in time. I believe this topic needs wider coordination now.

Finally, I echo Adrian's wishes for peace and goodwill as the holidays approach.

Al

> Frank is clearly upset that his comments at the microphone did not 
> make it into the minutes. I think we all have a responsibility to 
> review draft minutes when we have made comments and check that they 
> have been captured correctly. We should also attempt to capture 
> important discussion points on the mailing list where they can be 
> processed carefully by everyone, but especially by those for whom 
> handling comments spoken in English may be a challenge.
> 
> But Frank has gone on to type up some of his concerns, and that is 
> clearly helpful. It will give the authors something to work on as a 
> result of the adoption call.
> 
> I think that there may be some confusion about the intended status of 
> the document. Frank made several comments about "standards documents" 
> and I believe that Haoyu was attempting to observe that the document 
> is targeted as an Informational document, not a Standards Track 
> document. Quoting from
> allows Frank to think that the document is intended for publication on 
> the Independent Submission Stream. But clearly that is not the 
> intention, and a moment's thought would indicate that authors asking 
> for adoption in an IETF working group would not be consistent with 
> publication as an Independent Submission.
> 
> improve the document. Snarky comments are not helpful, and attempting 
> to represent the IETF process without a good grasp of it is also not 
> valuable. But careful and constructive reviews are helpful and should 
> be listened to. So should the considered responses to the reviews.
> 
> Lastly, the clarity about the intent of the document is important. 
> This document needs to set out its purpose and deliver that (and no 
> more than that). At the same time, it will not get us anywhere to say, 
> "This is not the document I thought it was," or even "This is not the 
> document I wanted to read." If you want to see something additional in 
> a document you probably have to write it 😊
> 
> thanks for clarifying publication objective - this indeed changes 
> things quite a bit; i.e. you're planning to publish your document as 
> part of the independent submission stream (per RFC 7841). Given that 
> your document is not aimed at the IETF stream, there is indeed no need 
> for IETF consensus - and also no need for WG adoption of the document. 
> In other words, the current adoption call and my earlier comments are 
> pointless. I still suggest that you consider the feedback received - 
> it'll improve whatever you'd end up publishing.
> 
> > or recommendation. The Informational designation is intended to 
> > provide
> for
> > documents from many sources, subject only to editorial 
> > considerations
> and to
> > Specifications that have been prepared outside of the Internet 
> > community
> and
> > are not incorporated into the Internet Standards Process by any of 
> > the provisions of section 10 may be published as Informational RFCs, 
> > with
> the
> > This status of this document is "informational", not "standard". 
> > Please
> show me
> > document. That is why I suggested a couple of options to make it one 
> > -
> which
> > appropriate standards document. E.g. a Huawei whitepaper might also 
> > be considered useful by several people, still a whitepaper is not a
> standards
> > document.
> >
> > properly scoped specification, make sure that you choose a proper 
> > and
> non-
> > > Thank you very much for the feedback. However I want to clarify a 
> > > few
> things.
> > >
> > > challenges we described are just used to motivate the framework. 
> > > The standard gap analysis is also necessary to show how this 
> > > framework can be implemented in the future.  While I agree the 
> > > document is not perfect and still need to improve, I think the 
> > > main information and
> logic flow
> > > It's just a high level guide for future development but doesn't 
> > > intend to put any constraints.
> > >
> > > I said “Other documents might also be needed but they are out of 
> > > scope of this one”, not to reference some non-existing document, 
> > > but to respond to your previous email in which you suggest other 
> > > documents like survey and deployment experience etc.  This 
> > > document does not
> server
> > those purpose.
> > >
> > > While you ask for detailed specification (up to the level about 
> > > how the controller to configure the nodes and what data to export, 
> > > etc.) , you may still think from a perspective that this document 
> > > is a solution specification, but it's not. I'm very sorry for that 
> > > impression. We already emphasized in the document that we don’t 
> > > intend to specify any interface and implementation details, but to 
> > > describe high level functions. To server that purpose, a loose 
> > > definition for
> the terms is
> > enough and proper.
> > >
> > > For example, we define iFIT Node as "a network node that is in an 
> > > iFIT domain and is capable of iFIT-specific functions." So yes it 
> > > forwards and processes traffic. I don't think anybody will misunderstand this.
> > > descriptions but won't specify any detail because we have made it 
> > > very
> clear
> > > So let's just focus on the current scope and content of the 
> > > document, to see if it's useful and valuable to the community as a 
> > > whole. From the majority responses, mostly from real network 
> > > operators, the feedbacks are so far very positive and they all 
> > > support the adoption of this document. I think that says something.
> > >
> > > Best regards,
> > > Haoyu
> > >
> > >
> > >
> > > To: Haoyu Song <[email-masked]>; opsawg 
> > > <draft-song-opsawg-ifit- [email-masked]>
> > > you and your co-authors need to decide what the document is 
> > > intended to be: A requirements document, an industry 
> > > implementation survey, or
> a
> > specification?
> > >  - remove all references to iFIT and similar – none of this is 
> > > needed to articulate requirements If the document is intended as 
> > > an industry
> survey:
> > >  - provide technical specifications for IFIT node, IFIT 
> > > application, IFIT Head Node, IFIT End Node, etc. I.e. explain how these “things”
> work and
> > operate.
> > > What is their control plane, what is their data plane, etc.? Make 
> > > sure that you’re not creating “empty shells” that are to be 
> > > defined at a later stage. An approach to create forward references 
> > > to currently non existing documents like “Other documents might 
> > > also be needed but they are out of scope of this one” (see your 
> > > message below) are not
> appropriate
> > for a specification.
> > >  - if you believe that your IFIT specification has nothing to do 
> > > with Huawei’s IFIT proprietary implementation (i.e.
> > > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > urldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-&amp;data=02%7C01
> > > %7Chaoyu.song%40futurewei.com%7C74a7031af7f14d07096408d7867c4af8%7
> > > C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637125740757653808&amp
> > > ;sdata=elDktrrJ2HLcuVoBnoV7YJ%2Bo0oK6Osuuiy2nCFl7VTI%3D&amp;reserv
> > > ed=0
> > > KSI0b%2FF0bjEkoY%3D&amp;reserved=0) then I strongly suggest that 
> > > you choose a different name for your implementation.
> > >
> > > Just to highlight that different from what you say, the 
> > > specification of IFIT elements neither helps in articulating 
> > > requirements nor does it support different industry solutions: If 
> > > you take the example of an “IFIT Node” – there is a total of
> > > 8 occurrences in the document, with 5 of them in the main part of 
> > > the document. The document defines “iFIT Node” as “a network node 
> > > that is in an iFIT domain and is capable of iFIT-specific 
> > > functions”. None of the 5 occurrences in the document is used for 
> > > comparison or requirements definition, neither do they detail what 
> > > IFIT specific functions are carried out by an IFIT node. Reading 
> > > through the 5 occurrences,  one learns that iFIT nodes seem to be 
> > > configured by a controller (what is a controller?), they seem to 
> > > be able to do some form of data collection (how?, what data?), 
> > > they seem to be able to export data using IPFIX and protobuf (what 
> > > data is exported?), they seem to be able to cache data, and they 
> > > seem to contain DNP. Reading
> > through this, I still don’t know what IFIT Nodes are… Do they 
> > forward
> traffic? Do
> > > - In addition to efficient export data encoding (e.g., IPFIX 
> > > [RFC7011] or protobuf [1]), iFIT nodes have several other ways to 
> > > reduce the export data by taking advantage of network device's 
> > > capability and
> > programmability.
> > > - The controller translates an intent and configure the 
> > > corresponding DNPs in iFIT nodes which collect necessary network information.
> > >
> > > Frank
> > >
> > > questions raised during the meeting (including Frank's and Joe's) 
> > > and I asked if I missed anything or misunderstood anything in an 
> > > email to the list. But I didn't got any feedback from the 
> > > queationers, so I believed  I had correctly understood the 
> > > questions and then made updates accordingly. So, I don't 
> > > understand why Frank still use the meeting video to question the 
> > > draft. Please read and answer my email
> and
> > > Other documents might also be needed but they are out of scope of 
> > > this one.  I firmly believe this one is also needed for the reason 
> > > we clearly stated in the draft.
> > >
> > > Thanks!
> > >
> > > Haoyu
> > >
> > >
> > > 获取
> > > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > urldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-&amp;data=02%7C01
> > > %7Chaoyu.song%40futurewei.com%7C74a7031af7f14d07096408d7867c4af8%7
> > > C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637125740757653808&amp
> > > ;sdata=elDktrrJ2HLcuVoBnoV7YJ%2Bo0oK6Osuuiy2nCFl7VTI%3D&amp;reserv
> > > ed=0
> > > 09 does NOT resolve all open issues nor does the document reflect 
> > > all the WG feedback received at IETF 106.
> > >
> > > * The WG minutes
> > > (https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-&amp;data=02%7C0
> > > 1%7Chaoyu.song%40futurewei.com%7C74a7031af7f14d07096408d7867c4af8%
> > > 7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637125740757653808&am
> > > p;sdata=elDktrrJ2HLcuVoBnoV7YJ%2Bo0oK6Osuuiy2nCFl7VTI%3D&amp;reser
> > > ved=0
> > > znPvQZq6w%3D&amp;reserved=0) miss a significant portion of 
> > > comments and feedback as Benoit rightly points out below. E.g. Joe 
> > > Clarke’s (as
> > > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > urldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-&amp;data=02%7C01
> > > %7Chaoyu.song%40futurewei.com%7C74a7031af7f14d07096408d7867c4af8%7
> > > C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637125740757653808&amp
> > > ;sdata=elDktrrJ2HLcuVoBnoV7YJ%2Bo0oK6Osuuiy2nCFl7VTI%3D&amp;reserv
> > > ed=0
> > > IFIT Applications, IFIT Domain, IFIT Node, IFIT End-Node, etc. 
> > > None of these entities are specified in the document, which means 
> > > that the IETF would endorse a framework without even understanding 
> > > the components/entities of the framework. The presenter responded
> > > (https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-&amp;data=02%7C0
> > > 1%7Chaoyu.song%40futurewei.com%7C74a7031af7f14d07096408d7867c4af8%
> > > 7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637125740757653808&am
> > > p;sdata=elDktrrJ2HLcuVoBnoV7YJ%2Bo0oK6Osuuiy2nCFl7VTI%3D&amp;reser
> > > ved=0
> > > ci0%2FLE3KvzQQD%2FBJJHPmfhVqh8c%3D&amp;reserved=0 ) that it would 
> > > be just a “very high level framework” that should fit any existing 
> > > solution. If everything fits, i.e. “I FIT”, “You FIT”, “We all 
> > > Fit”, … then why do we even need the definition of new entities? 
> > > There is NO need to define “empty shells” for a lot of new 
> > > entities, if all what the authors intend to do is compare different solutions.
> > >
> > > high-level framework”, but IFIT is a proprietary Huawei 
> > > technology,
> see e.g.
> > > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > urldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-&amp;data=02%7C01
> > > %7Chaoyu.song%40futurewei.com%7C74a7031af7f14d07096408d7867c4af8%7
> > > C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637125740757653808&amp
> > > ;sdata=elDktrrJ2HLcuVoBnoV7YJ%2Bo0oK6Osuuiy2nCFl7VTI%3D&amp;reserv
> > > ed=0
> > > 5gacId%2FgYg%3D&amp;reserved=0. Public specifications for IFIT 
> > > don’t seem to be available, with the exception of
> > > support the adoption of, the following documents might be 
> > > worthwhile documents (especially given the broad interest) to create/share:
> > > - requirements
> > > - specification and deployment experiences of Huawei’s IFIT I 
> > > already made this suggestion back in the WG meeting at IETF 106 – 
> > > but per the above it was ignored at multiple levels.
> > >
> > > Regards, Frank
> > >
> > > My last question was only to check if there is enough interest on 
> > > this work, not an adoption call. There was q&a after the 
> > > presentation. And Joe cut the line because of the time.
> > >
> > > Also, in the minutes, I did not see any mention of Joe's feedback. 
> > > And Frank's feedback on the draft is summarized as 4 words: "the 
> > > scope is
> large"
> > > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > urldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-&amp;data=02%7C01
> > > %7Chaoyu.song%40futurewei.com%7C74a7031af7f14d07096408d7867c4af8%7
> > > C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637125740757653808&amp
> > > ;sdata=elDktrrJ2HLcuVoBnoV7YJ%2Bo0oK6Osuuiy2nCFl7VTI%3D&amp;reserv
> > > ed=0
> > > I support Frank's feedback that this document scope is too large: 
> > > a mix of an inventory of what exists, a set of requirements, and
> > > I'm wondering: what is the scope of this document? Before we 
> > > clarify this, I don't think we should adopt this document.
> > >
> > > I was waiting for the negative question but to my surprise, it 
> > > never
> came...
> > > document is a good starting point. I object to the latter, with 
> > > the document in the current form.
> > > Regards, Benoit
> > >
> > > Hi WG,
> > >
> > > On IETF 106 meeting, we saw predominant interest and support to 
> > > this draft, especially from operators. The authors then resolved 
> > > all the
> open issues.
> > > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > urldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-&amp;data=02%7C01
> > > %7Chaoyu.song%40futurewei.com%7C74a7031af7f14d07096408d7867c4af8%7
> > > C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637125740757653808&amp
> > > ;sdata=elDktrrJ2HLcuVoBnoV7YJ%2Bo0oK6Osuuiy2nCFl7VTI%3D&amp;reserv
> > > ed=0
> > > If you support adopting this document please say so, and please 
> > > give an indication of why you think it is important. Also please 
> > > say if you will be willing to review and help the draft.
> > > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > urldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-&amp;data=02%7C01
> > > %7Chaoyu.song%40futurewei.com%7C74a7031af7f14d07096408d7867c4af8%7
> > > C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637125740757653808&amp
> > > ;sdata=elDktrrJ2HLcuVoBnoV7YJ%2Bo0oK6Osuuiy2nCFl7VTI%3D&amp;reserv
> > > ed=0
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-&amp;data=02%7C01%7Chaoyu
> .song%40futurewei.com%7C74a7031af7f14d07096408d7867c4af8%7C0fee8ff2a3b
> 240189c753a1d5591fedc%7C1%7C0%7C637125740757653808&amp;sdata=elDktrrJ2
> HLcuVoBnoV7YJ%2Bo0oK6Osuuiy2nCFl7VTI%3D&amp;reserved=0
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-&amp;data=02%7C01%7Chaoyu
> .song%40futurewei.com%7C74a7031af7f14d07096408d7867c4af8%7C0fee8ff2a3b
> 240189c753a1d5591fedc%7C1%7C0%7C637125740757653808&amp;sdata=elDktrrJ2
> HLcuVoBnoV7YJ%2Bo0oK6Osuuiy2nCFl7VTI%3D&amp;reserved=0
_______________________________________________
ippm mailing list
[email-masked]
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C74a7031af7f14d07096408d7867c4af8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637125740757653808&amp;sdata=YitRsVPsz71ktUhWWVmZTTp%2Fxk1r2cbDNM%2BNtVLH8Ak%3D&amp;reserved=0