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 <[email protected]> > Sent: Freitag, 20. Dezember 2019 19:00 > To: Frank Brockners (fbrockne) <[email protected]>; opsawg > <[email protected]>; draft-song-opsawg-ifit-framework.authors <draft-song- > [email protected]> > Cc: opsawg-chairs <[email protected]> > 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) <[email protected]>; opsawg > <[email protected]>; draft-song-opsawg-ifit-framework.authors <draft-song- > [email protected]> > Cc: opsawg-chairs <[email protected]> > 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) <[email protected]> > Sent: Thursday, December 19, 2019 11:10 PM > To: Haoyu Song <[email protected]>; opsawg <[email protected]>; > draft-song-opsawg-ifit-framework.authors <draft-song-opsawg-ifit- > [email protected]> > Cc: opsawg-chairs <[email protected]> > 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 <[email protected]> > > Sent: Donnerstag, 19. Dezember 2019 19:01 > > To: Frank Brockners (fbrockne) <[email protected]>; opsawg > > <[email protected]>; draft-song-opsawg-ifit-framework.authors > > <draft-song- [email protected]> > > Cc: opsawg-chairs <[email protected]> > > 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) <[email protected]> > > Sent: Thursday, December 19, 2019 6:23 AM > > To: Haoyu Song <[email protected]>; opsawg <[email protected]>; > > draft-song-opsawg-ifit-framework.authors <draft-song-opsawg-ifit- > > [email protected]> > > Cc: opsawg-chairs <[email protected]> > > 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%2Fwww- > > ctc.huawei.com%2Fke%2Fpress-events%2Fnews%2F2019%2F6%2Ffirst-ifit- > > pilot-5g-transport-network-beijing-unicom- > > > huawei&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c > > > 2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0 > > > %7C637123622155305143&sdata=vlsft6Tj%2BuI2rH6NCdZO0qf2O7%2BR9 > > KSI0b%2FF0bjEkoY%3D&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 <[email protected]> > > Sent: Donnerstag, 19. Dezember 2019 02:09 > > To: Frank Brockners (fbrockne) <[email protected]>; opsawg > > <[email protected]>; draft-song-opsawg-ifit-framework.authors > > <draft-song- [email protected]> > > Cc: opsawg-chairs <[email protected]> > > 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%2Faka. > > ms > > > %2Fghei36&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6 > > > a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1% > > > 7C0%7C637123622155305143&sdata=JL2%2BLWYc04fnRBAOUcsUByjP6e > > UFmD8KW6XbYiDGd0s%3D&reserved=0 > > > > ________________________________________ > > 发件人: Frank Brockners (fbrockne) <mailto:[email protected]> > > 发送时间: 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%2Fdat > > atra > > cker.ietf.org%2Fmeeting%2F106%2Fmaterials%2Fminutes-106-opsawg- > > > 01&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f > > > 90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6 > > > 37123622155305143&sdata=1GNq52BxnTLejtyH17quH%2FaNHPodQS4Yuk > > znPvQZq6w%3D&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%2Fyout > > u.b > > e%2FrY- > > > u8177wpU%3Ft%3D3785&data=02%7C01%7Chaoyu.song%40futurewei.co > > > m%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d55 > > > 91fedc%7C1%7C0%7C637123622155305143&sdata=X%2Fj2PSaoQSNFy1xT > > FNjfhUwt4KXjJY8ol3oKYVG2UH8%3D&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%2Fyou > > tu.b > > e%2FrY- > > > u8177wpU%3Ft%3D3867&data=02%7C01%7Chaoyu.song%40futurewei.co > > > m%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d55 > > > 91fedc%7C1%7C0%7C637123622155305143&sdata=A2UP99wRCzNTk9OP > > ci0%2FLE3KvzQQD%2FBJJHPmfhVqh8c%3D&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&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c > > > 2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0 > > > %7C637123622155315140&sdata=btJwYOUGtJnA8RKntlXXV5F0Xsu4H7rVO > > 5gacId%2FgYg%3D&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:[email protected]> On Behalf Of Benoit > > Claise > > Sent: Dienstag, 17. Dezember 2019 14:43 > > To: Tianran Zhou <mailto:[email protected]>; opsawg > > <mailto:[email protected]>; draft-song-opsawg-ifit-framework.authors > > <mailto:[email protected]> > > Cc: opsawg-chairs <mailto:[email protected]> > > 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:[email protected]> > > 收件人： Tianran > > > Zhou<mailto:[email protected]>;opsawg<mailto:[email protected]>;dra > > ft-song-opsawg-ifit-framework.authors<mailto:draft-song-opsawg-ifit- > > [email protected]> > > 抄送： opsawg-chairs<mailto:[email protected]> > > 主题： 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%2Fwww. > > y > > outube.com%2Fwatch%3Fv%3DrY- > > > u8177wpU&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6 > > > a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1% > > > 7C0%7C637123622155315140&sdata=qfSNeIXLJRJo1WRh40SUF0K76wU8p > > i%2B5O1kIanyXXj8%3D&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%2Fdata > > tra > > cker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit- > > > framework%2F&data=02%7C01%7Chaoyu.song%40futurewei.com%7C524 > > > 7a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7 > > > C1%7C0%7C637123622155315140&sdata=K5azjOJhUbN3NDUhuwbV92cxc > > DKCPO9%2FubsdFBAObdY%3D&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:[email protected] > > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > ie > tf.org%2Fmailman%2Flistinfo%2Fopsawg&data=02%7C01%7Chaoyu.song > > > %40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b2 > > > 40189c753a1d5591fedc%7C1%7C0%7C637123622155315140&sdata=GOk > > 5SIXxkgomuo7yxv1p9Qs4%2BcfgRjEGN13j8q40zjo%3D&reserved=0 > > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
