Re: [OPSAWG] extend the call//RE: WG adoption call for draft-song-opsawg-ifit-framework-09

[Alan DeKok <[e-mail]>]

On Jan 6, 2020, at 1:31 PM, Haoyu Song <[e-mail]> wrote:
> [HS] I've added more details in the latest version but as I said, this draft is not a standard specification, so I just described the high level function modules and how they can be assembled to form a complete solution.

  If the draft is a "solution", it should describe how to implement that solution.  This draft does not do that.  it describes *motivation* for a solution.

> I've talked with many people and they told me they had no difficulty to understand this and found many of the components are already common practices. For the flow sketch, we provided a reference in the draft but we didn't describe it extensively, because it's just used as an example in our discussion and interested readers should directly read the reference for more information. As for how to deploy such data structure, we actually consider this as a standard gap. We briefly discussed it in the gap analysis and will release several other drafts to cover those issues. 

  Then this draft should be titled "architecture" or "motivation".  And it should explicitly say that it does not describe a solution.  Instead, it should describe a problem, and a proposed architecture.

> [HS] We write this draft from purely neutral and technical perspective. I don't know from where you sense the marketing tone. If so, please kindly point it out specifically so we can improve it. 

  From the abstract:

   With the advent of
   programmable data-plane, emerging on-path telemetry techniques
   provide unprecedented flow insight and realtime notification of
   network issues.

  This is 100% marketing speak.  IETF standards typically do not talk about how the technology is wonderful, or is "unprecedented".  The documents instead describe a technical problem, followed by a technical solution.

  Further, the "programmable data plane" has been standardized extensively in the ForCES working group since at least 2003:

https://datatracker.ietf.org/wg/forces/documents/

 The first ForCES BoF was held at IETF 49, in December 2000.  That work standardized prior discussions in  CPIX / CSIX (then Network Processing Forum, now defunct).  I was involved in that work for many years before moving on to other things.

  Quoting further from the abstract of this document:

   iFIT includes several
   essential functional components that can be materialized and
   assembled to implement a complete solution for on-path telemetry.

  There is no need to say "materialized and assembled".  It's fine to just say "used".

  The common practice in the IETF (and in other science and engineering disciplines) is to avoid "enthusiastic" words.  Keep the words simple.  i.e. "used" versus "materialized and assembled".

  The more complex the words, the less trustworthy the document appears.  

  Quoting again:

   It also helps to inspire innovative network
   telemetry applications supporting advanced network operations. 

  Words like "inspire" are again marketing excitement, and not boring technical engineering.

  My concern here is that I read the document, and I'm happy and enthusiastic.  But I don't know what to *do*.  As a result, this document is not appropriate for the IETF.

  Alan DeKok.