Skip to main content

Last Call Review of draft-boydseda-ipfix-psamp-bulk-data-yang-model-02
review-boydseda-ipfix-psamp-bulk-data-yang-model-02-genart-lc-kyzivat-2019-12-16-00

Request Review of draft-boydseda-ipfix-psamp-bulk-data-yang-model
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-12-23
Requested 2019-11-19
Requested by Ignas Bagdonas
Authors Joey Boyd , Marta Seda
I-D last updated 2019-12-16
Completed reviews Genart Last Call review of -02 by Paul Kyzivat (diff)
Opsdir Last Call review of -02 by Mehmet Ersue (diff)
Opsdir Last Call review of -02 by Joe Clarke (diff)
Yangdoctors 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 Paul Kyzivat
State Completed
Request Last Call review on draft-boydseda-ipfix-psamp-bulk-data-yang-model by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/BCEfI-dqfSRmQlRHqXl-Zo6WNYI
Reviewed revision 02 (document currently at 03)
Result Ready w/issues
Completed 2019-12-16
review-boydseda-ipfix-psamp-bulk-data-yang-model-02-genart-lc-kyzivat-2019-12-16-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-boydseda-ipfix-psamp-bulk-data-yang-model-02
Reviewer: Paul Kyzivat
Review Date: 2019-12-16
IETF LC End Date: 2019-12-23
IESG Telechat date: (if known)

Summary:

This draft is on the right track but has open issues, described in the 
review.

Disclaimer:

I didn't review the actual YANG content in any meaningful way as I'm not 
fluent in it and assume the Yang Doctor will do that.

Issues:

Major: 0
Minor: 5
Nits:  1

1) MINOR:

This document will obsolete RFC6728 but it isn't evident to me whether 
it is backward compatible with the predecessor. Is there a plan for 
migration, or coexistence? It seems like this needs some discussion.

2) MINOR:

Section 1.1 says it contains a historical timeline. But the events in 
this timeline are not in chronological order. It would be easier to 
understand if you actually enumerated the events in chronological order.

3) MINOR:

Section 3 says that the document describes reference models based on 
RFC6728. But this document obsoletes RFC6728. This seems to set up a 
situation where there is a dependency on an obsoleted document. I 
presume this is not the intent.

I'm guessing that the models in this document have been derived from 
those in RFC6728, presumably in a way that is backward compatible in 
some sense. Can the relationship be described more precisely?

4) MINOR:

In sections 4.4.4 and 4.5.4 the file is identified by a URI. Are there 
limitations on the sort of URI this may be?

It seems to me this should be constrained in some way.

5) MINOR:

Some of the IP addresses and DNS names used in examples are not suitable 
for use in documentation:

In Appendix A:

- The IP address 192.100.2.1 used is not one of those reserved for 
documentation.

- The DNS names "proxy1.sys.com", "collect1.sys.com", "coll-1.ex.net", 
"coll-2.ex.net" are not among those reserved for documentation.

6) NIT:

In section 5 there are two uses of the word "proportions" where I think 
you mean "portions":

    ... As Exporters and Collectors implement different functions, the
    corresponding proportions of the model are conditional on the
    following features:

and:

    ... Therefore,
    the corresponding proportions of the model are conditional on the
    following feature:

(THE END)