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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
