Re: [Gen-art] Gen-ART Last Call review of draft-ietf-netvc-requirements-09

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 <pkyzivat@alum.mit.edu> 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
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art