Subject: Re: [OPSAWG] Call for adoption: draft-boydseda-ipfix-psamp-bulk-data-yang-model

From: Marta Seda <[email-masked]>
Date: Tue, 11 Aug 2020 16:54:24 +0000

Hello,
I wanted to address the points/questions/concerns raised in this email thread about https://tools.ietf.org/html/draft-boydseda-ipfix-psamp-bulk-data-yang-model-03<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-boydseda-ipfix-psamp-bulk-data-yang-model-03&data=02%7C01%7CMarta.Seda%40calix.com%7Cd5e32c860e464132014408d83e0e5908%7C8ffae2e56ff04510bbf3ca842d7ca55e%7C1%7C0%7C637327578724992272&sdata=PUtKiZsXFjlOZNjC7oGDYcu0P4JmJ%2Bchr5Rb7NnQ%2F4E%3D&reserved=0>

1.   5-15-2020 (Rob Wilton):  > Would it be feasible to split this work up into smaller chunks that would make it easier to review.  E.g. to put the packet-sampling and bulk-data-export into separate drafts?  Perhaps pare back some optional functionality.

Answer:  The YANG design is modularized into 3 modules:
 *            ietf-ipfix (IPFIX collector and exporter)
*             ietf-ipfix-packet-sampling (sampling/psamp templates)
*             ietf-ipfix-bulk-data-export (bulk data templates)

The question asked "assumes" it is less work to review multiple small documents instead of one document (even if it is being reviewed by the same individuals).  If you split the sections of the documents into separate documents, it means you now have to add a dependency section (the total number of pages that needs to be reviewed increments).  If the review team is the same, well, there will be more to read.  This request falls more in the bucket of personal preference but as an author it could be done.  "WHO would commit to reviewing the document if it was split?"

Some notes that may help you understand the level of review that this document has had:

  *   The original draft has been worked on by multiple interested parties (Adtran, Calix, Nokia).
  *   The original authors of RFC 6728 were approached and their comments incorporated (e.g., Benoit Claise and Gerhard Muenz provided feedback/comments).
  *   The draft has gone through YANG doctor review.
Some notes on "proof" that there is interest in this draft:

  *   I am one of the editors of TR-352 Multi-wavelength PON Inter-Channel-Termination Protocol (ICTP) Specification protocol.   ICTP defines a handy protocol used by XGS-PON and NG-PON2 systems for sharing information when handing off an ONU on a PON system (thus avoiding the need to re-range an ONU on a handoff).   ICTP uses IPFIX to stream some of its data.  A method to configure the ICTP IPFIX template is needed and this particular draft addresses it.
     *   I could understand if IETF was not interested in ICTP IPFIX.  If IETF does not pick this draft up, the problem still exists and will need to be solved elsewhere (outside of IETF).
  *   The draft in addition to help with ICTP IPFIX supports bulk data streaming for statistics already defined in other YANG modules.
Sincerely
Marta Seda

---

From: William Lupton <[email-masked]>
Date: Fri, 14 Aug 2020 17:05:16 +0100

All,

Having seen some renewed discussion of this ID on the OPSAWG mailing list
(and speaking as document shepherd) I'd like to give a brief reminder of
some of the steps already taken.

Ref:
https://datatracker.ietf.org/doc/draft-boydseda-ipfix-psamp-bulk-data-yang-model/

   - Yang Validation
      - 0 errors, 0 warnings.
   - Reviews
      - OPSDIR Last Call Review (of -02): Not Ready (partially completed)
      - YANGDOCTORS Last Call Review (of -02): Ready with Nits
      - GENART Last Call Review (of -02): Ready with Issues
      - OPSDIR Last Call Review (of -02): Not Ready (partially completed)
   - Document shepherd William Lupton
      - Shepherd write-up (last changed 2019-11-13)
      <https://datatracker.ietf.org/doc/draft-boydseda-ipfix-psamp-bulk-data-yang-model/shepherdwriteup/>

Here are a few quotes from the shepherd write-up (which predates some of
the more recent discussion, e.g., re breaking up the draft or not
obsoleting RFC 6728):

   - The shepherd feels that the document is mature, and that it does
   indeed (as promised) contain all the RFC 6728 material. However, RFC 6728
   was quite an early YANG RFC, and the shepherd would appreciate feedback on
   whether a "modern" YANG RFC should put so much emphasis on UML diagrams and
   classes (it could instead refer more directly to YANG concepts)
   - idnits has been run and all fixes arising from examining its output
   have been applied
   - YANG has been validated using recent versions of pyang, yanger and
   yanglint. XML examples have been validated using yanglint

Thanks,
William