Last Call Review of draft-ietf-netvc-requirements-09
review-ietf-netvc-requirements-09-genart-lc-kyzivat-2019-05-29-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 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-netvc-requirements-09
Reviewer: Paul Kyzivat
Review Date: 2019-05-29
IETF LC End Date: 2019-06-04
IESG Telechat date: ?

Summary:

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

Disclaimer:

I have very little understanding of the subject matter of this document, 
so this review is limited to the form and structure of the document.

General:

The Abstract and Introduction are written in the abstract, implying (to 
me) that the requirements here are intended to be broadly applicable for 
the stated purposes, over an extended period of time. On the other hand, 
I get the impression that requirements in this document are actually 
more focused, intended for use in a one-time selection of an Internet 
video codec to be a successor to HEVC and VP9.

If this document is intended only for one-time use then it isn't evident 
to me why it ever needs to become an RFC.

Issues:

Major: 0
Minor: 2
Nits:  4

1) Minor:

In section 1, there is no indication here of where these requirements 
came from, and why they should be considered to be the proper 
requirements for the purpose. I think that is important to state.

2) Minor:

In the following passage in section 3.2.2:

       The real-time encoder tools subset should provide
       meaningful improvement in compression efficiency at reasonable
       complexity of hardware and software encoder implementations as
       compared to current real-time implementations of state-of-the-art
       video compression technologies such as HEVC/H.265 and VP9.

the use of "current" is problematic in a document that will become an 
RFC, because the implied time frame may not be apparent to a reader of 
the RFC.

3) NIT:

Section 4.2 references the NETVC WG. Referencing an IETF work group is 
rarely appropriate in an RFC. This adds to my inference that this 
document is intended as one-time input to an evaluation to be carried 
out by this WG. That again brings into question whether this document 
should be intended to progress to RFC.

4) NIT:

I don't see the point of section 6. These aren't *conclusions*. This is 
more like a summary, and seems redundant with section 1.

5) NIT:

In section 8, references [6] and [14] are solely URLs. According to 
RFC7322 this is not allowed:

    Note that URIs may not be the sole information provided for a
    reference entry.

And while [8] has some description, it is too cryptic to understand what 
it is about without first following the link. Nor is its significance 
explained at the point of reference. (If I understand correctly, the 
point is to identify requirements for upload to Utube to be a significant.)

These references need to be beefed up to describe what is being referenced.

6) NIT:

I find it strange that Appendices A & B are not referenced in the body 
of the document, except for the table of contents.

In my experience most documents that have lists of terminology put them 
in a section early in the body of the document, so they will be seen 
before the terminology is used in the document.

THE END