Hi Vijay, all, Thank you for your review.
The nits can be addressed, presumably by the RFC editor (unless more are found). As for your “minor” point: Clearly, a normative document can contain informative material. Compared to certain other SDOs, IETF RFCs commonly contain a lot of explanatory text, examples and such, which is most often purely informative. If such text were collected in distinct sections, I believe it is a good (and unfortunately underutilized) idea to label those sections as informative. We have done so in the past, for example in the RTP payload format for H.264/SVC, which is referenced by the subject draft (see section 13 of https://tools.ietf.org/html/rfc6184). It’s also common practice in ITU and ISO/IEC/MPEG media coding standard documents, and implementers of the subject draft are likely familiar with those media coding documents. Insofar, my preference would be to leave that headline as is. However, that preference is a weak one, and if others suggest removal of the word “informative”, we could certainly do so with minimal effort. Regards, Stephan On 11/30/16, 09:06, "Vijay K.Gurbani" <[email protected]> wrote: >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please see the FAQ at ><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > >Please resolve these comments along with any other Last Call comments >you may receive. > >Document: draft-ietf-avtext-avpf-ccm-layered-03 >Reviewer: Vijay K. Gurbani >Review Date: Nov-30-2016 >IETF LC End Date: Dec-14-2016 >IESG Telechat date: Unknown > >This document is ready as an Proposed Standard (modulo a couple of >minor and nit comments below). > >Major: 0 >Minor: 1 >Nits: 2 > >Minor: >- S5, S6: This is a standards-track document. As such, I am not sure > what the "(Informative)" moniker implies in the section heading. > Since there is no RFC-2119 type of exhortations in the sections, it > seems reasonable to simply remove the "(Informative)" tag in the > section headings without loosing any material context while reading > the paragraph. The presence of the tag renders ambiguity. > >Nits: >- S1: s/which the FIR request/that the FIR request/ >- S1: In this section and rest of the document, you sometimes use FIR > and at other times Full Intra Request. Once you have defined Full > Intra Request as FIR, I would suggest using FIR for consistency. > >Thanks, > >- vijay >-- >Vijay K. Gurbani, Bell Laboratories, Nokia Networks >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) >Email: [email protected] / [email protected] >Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
