[Last-Call] Fwd: YANG glitches Re: Opsdir last call partial review of draft-boydseda-ipfix-psamp-bulk-data-yang-model-02

[tom petch <[e-mail]>]

Try again (dumb MUA)

-------- Forwarded Message --------
Subject: YANG glitches Re: [Last-Call] Opsdir last call partial review 
of draft-boydseda-ipfix-psamp-bulk-data-yang-model-02


Drawn to my attention by the Opsdir review, I looked at the YANG in this
but believe that I will never have the time to review such a large I-D
as I would wish.  I did note the following glitches in the YANG modules

import statements lack reference statements, ietf-interfaces, ietf-hardware

references from the YANG module should be Normative; 3871, 5280 are
Informative

references must appear in the I-D references - I cannot find 4133, 5101,
5102

IANA Considerations TBD should have the same reference as the YANG
revision statement

I like the YANG Reference statements for the YANG data items - I would
like more for the feature and identity statements.

I did find the reuse of the Entity MIB surprising and will look some
more if I have time

Tom Petch






On 20/12/2019 18:23, Joe Clarke via Datatracker wrote:
>
> Review is partially done. Another assignment may be needed to complete it.
>
> Reviewer: Joe Clarke
> Review result: Not Ready
>
> 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.
>