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

[Haoyu Song <[e-mail]>]

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 <[e-mail]> On Behalf Of MORTON, ALFRED C (AL)
Sent: Saturday, December 21, 2019 5:13 PM
To: [e-mail]; 'Frank Brockners (fbrockne)' <[e-mail]>; 'opsawg' <[e-mail]>
Cc: [e-mail]; [e-mail]; 'opsawg-chairs' <[e-mail]>; Mirja Kühlewind (IETF) <[e-mail]>; Warren Kumari <[e-mail]>
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:
    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.

[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):

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

[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


> -----Original Message-----
> From: OPSAWG [mailto:[e-mail]] On Behalf Of Adrian 
> Farrel
> Sent: Saturday, December 21, 2019 5:47 PM
> To: 'Frank Brockners (fbrockne)' <[e-mail]>; 'Haoyu Song'
> <[e-mail]>; 'opsawg' <[e-mail]>; 'draft-song- 
> opsawg-ifit-framework.authors' <draft-song-opsawg-ifit- 
> [e-mail]>
> Cc: 'opsawg-chairs' <[e-mail]>
> Subject: Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-
> framework-09
> 
> 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 <[e-mail]> On Behalf Of Frank Brockners
> (fbrockne)
> Sent: 21 December 2019 18:16
> To: Haoyu Song <[e-mail]>; opsawg <[e-mail]>; 
> draft-song-opsawg-ifit-framework.authors <draft-song-opsawg-ifit- 
> [e-mail]>
> Cc: opsawg-chairs <[e-mail]>
> Subject: Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-
> framework-09
> 
> 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
> 
> > -----Original Message-----
> > From: Haoyu Song <[e-mail]>
> > Sent: Freitag, 20. Dezember 2019 19:00
> > To: Frank Brockners (fbrockne) <[e-mail]>; opsawg 
> > <[e-mail]>; draft-song-opsawg-ifit-framework.authors 
> > <draft-song- [e-mail]>
> > Cc: opsawg-chairs <[e-mail]>
> > Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-
> framework-
> > 09
> >
> > 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) <[e-mail]>; opsawg 
> > <[e-mail]>; draft-song-opsawg-ifit-framework.authors 
> > <draft-song- [e-mail]>
> > Cc: opsawg-chairs <[e-mail]>
> > Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-
> framework-
> > 09
> >
> > 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) <[e-mail]>
> > Sent: Thursday, December 19, 2019 11:10 PM
> > To: Haoyu Song <[e-mail]>; opsawg <[e-mail]>; 
> > draft-song-opsawg-ifit-framework.authors <draft-song-opsawg-ifit- 
> > [e-mail]>
> > Cc: opsawg-chairs <[e-mail]>
> > Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-
> framework-
> > 09
> >
> > 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
> >
> > > -----Original Message-----
> > > From: Haoyu Song <[e-mail]>
> > > Sent: Donnerstag, 19. Dezember 2019 19:01
> > > To: Frank Brockners (fbrockne) <[e-mail]>; opsawg 
> > > <[e-mail]>; draft-song-opsawg-ifit-framework.authors
> > > <draft-song- [e-mail]>
> > > Cc: opsawg-chairs <[e-mail]>
> > > Subject: RE: [OPSAWG] WG adoption call for
> > > draft-song-opsawg-ifit-framework-
> > > 09
> > >
> > > 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) <[e-mail]>
> > > Sent: Thursday, December 19, 2019 6:23 AM
> > > To: Haoyu Song <[e-mail]>; opsawg 
> > > <[e-mail]>; draft-song-opsawg-ifit-framework.authors 
> > > <draft-song-opsawg-ifit- [e-mail]>
> > > Cc: opsawg-chairs <[e-mail]>
> > > Subject: RE: [OPSAWG] WG adoption call for
> > > draft-song-opsawg-ifit-framework-
> > > 09
> > >
> > > 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://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
> 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=
> > > 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? ...
> > >
> > > 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 <[e-mail]>
> > > Sent: Donnerstag, 19. Dezember 2019 02:09
> > > To: Frank Brockners (fbrockne) <[e-mail]>; opsawg 
> > > <[e-mail]>; draft-song-opsawg-ifit-framework.authors
> > > <draft-song- [e-mail]>
> > > Cc: opsawg-chairs <[e-mail]>
> > > Subject: Re: [OPSAWG] WG adoption call for
> > > draft-song-opsawg-ifit-framework-
> > > 09
> > >
> > > 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
> > >
> > >
> > > 获取
> > > 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
> 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
> > >
> > %2Fghei36&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6
> > >
> > a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%
> > >
> > 7C0%7C637123622155305143&amp;sdata=JL2%2BLWYc04fnRBAOUcsUByjP6e
> > > UFmD8KW6XbYiDGd0s%3D&amp;reserved=0
> > >
> > > ________________________________________
> > > 发件人: Frank Brockners (fbrockne) <mailto:[e-mail]>
> > > 发送时间: 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
> > >
> > >
> > > 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%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
> 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
> > > 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%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
> 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-
> > >
> > 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%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
> 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-
> > >
> > 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%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
> 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=
> > > 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
> > > - 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 <mailto:[e-mail]> On Behalf Of Benoit 
> > > Claise
> > > Sent: Dienstag, 17. Dezember 2019 14:43
> > > To: Tianran Zhou <mailto:[e-mail]>; opsawg 
> > > <mailto:[e-mail]>; draft-song-opsawg-ifit-framework.authors
> > > <mailto:[e-mail]>
> > > Cc: opsawg-chairs <mailto:[e-mail]>
> > > Subject: Re: [OPSAWG] WG adoption call for
> > > draft-song-opsawg-ifit-framework-
> > > 09
> > >
> > > 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<mailto:[e-mail]>
> > > 收件人： Tianran
> > >
> > Zhou<mailto:[e-mail]>;opsawg<mailto:[e-mail]>;d
> > ra
> > > ft-song-opsawg-ifit-framework.authors<mailto:draft-song-opsawg-ifi
> > > t-
> > > [e-mail]>
> > > 抄送： opsawg-chairs<mailto:[e-mail]>
> > > 主题： 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://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
> 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
> > > 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.
> > >
> > > 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
> > >
> > > 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%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
> 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
> > > 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
> > >
> > > 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
> > >
> > >
> > > _______________________________________________
> > > OPSAWG mailing list
> > > mailto:[e-mail]
> > > 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
> 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
> > 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
> > >
> 
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> 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
> 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=
> 
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> 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
> 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=
_______________________________________________
ippm mailing list
[e-mail]
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