Paul, thanks for your review. IMO the shepherd write-up gives adequate if unsatisfying justification for publishing this document as an RFC. I entered a No Objection ballot.
Alissa > On May 29, 2019, at 10:40 AM, Paul Kyzivat <[email protected]> wrote: > > 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
