Last Call Review of draft-boydseda-ipfix-psamp-bulk-data-yang-model-02
review-boydseda-ipfix-psamp-bulk-data-yang-model-02-opsdir-lc-clarke-2019-12-20-00

Request Review of draft-boydseda-ipfix-psamp-bulk-data-yang-model
Requested revision No specific revision (document currently at 03)
Type IETF Last Call Review
Team Ops Directorate (opsdir)
Deadline 2019-12-23
Requested 2019-11-19
Requested by Ignas Bagdonas
Authors Joey Boyd , Marta Seda
I-D last updated 2020-10-27 (Latest revision 2020-03-09)
Completed reviews Genart IETF Last Call review of -02 by Paul Kyzivat (diff)
Opsdir IETF Last Call review of -02 by Mehmet Ersue (diff)
Opsdir IETF Last Call review of -02 by Joe Clarke (diff)
Yangdoctors IETF Last Call review of -02 by Martin Björklund (diff)
Comments 
Hi there,

draft-boydseda-ipfix-psamp-bulk-data-yang-model will be an AD sponsored document, LC expected for mid-December. 

Thank you.
Assignment Reviewer Joe Clarke
State Partially completed
Request IETF Last Call review on draft-boydseda-ipfix-psamp-bulk-data-yang-model by Ops Directorate Overtaken by Events
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/HkR3gMNqBVV2qauqpkJZAU2xhmM
Reviewed revision 02 (document currently at 03)
Result Not ready
Completed 2019-12-20
review-boydseda-ipfix-psamp-bulk-data-yang-model-02-opsdir-lc-clarke-2019-12-20-00
I have been assigned as a secondary reviewer on behalf of the ops directorate
to review this draft.  This draft defines YANG modules for PSAMP with bulk
export via IPFIX.  It contends that RFC 6728 defines a single YANG module that
couples IPFIX export with PSAMP sampling.  It also puts an overly onerous
requirement that a device support SCTP.  The aim of this draft is to decouple
the sampling and exporting and allow for other export transports.

I think Mehmet raised some valid points in his review around why this is being
done as an AD-sponsored document.  While I am not a PSAMP/IPFIX expert, the
document and approach seem reasonable to me, and I wonder why this wasn't
discussed more in opsawg as a replacement for 6728.  I also agree with Mehmet
that the 6728 authors should be included on this for a deeper technical review.

One other point that struck me as I read this document was that 6728 is being
obsoleted by this, but there are references to things defined within it.  I
would think that anything that this new document will use in a normative
fashion should be explicitly stated in this document.  Such examples are found
in Section 3 where text like "based on [RFC6728]" is used.