Thank you, all! Jari
On 07 Aug 2014, at 23:18, Brian E Carpenter <[email protected]> wrote: > Jamal, > > I am OK with all your suggested changes. > > Thanks > Brian Carpenter > > On 07/08/2014 23:07, Jamal Hadi Salim wrote: >> Hi Brian, >> Thanks for taking the time to review. Responses inline.. >> >> On Thu, Aug 7, 2014 at 1:08 AM, Brian E Carpenter >> <[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-forces-protoextension-04.txt >>> Reviewer: Brian Carpenter >>> Review Date: 2014-08-07 >>> IETF LC End Date: 2014-08-13 >>> IESG Telechat date: >>> >>> Summary: Almost ready >>> -------- >>> >>> Minor issues: >>> ------------- >>> >>> "3. Protocol Update Proposal >>> >>> This section describes proposals..." >>> >>> Actually, these are not proposals: they are normative updates. >>> >> >> Updated >> >>> ------------- >>> The Abstract says "This documents updates both RFC 5810 and RFC 7121 >>> semantics..." >>> but this is not repeated in the Introduction, and the text makes no further >>> reference to RFC 7121. The text should state what is updated in RFC 7121. >>> >> >> Are you requesting to add extra text on top of the intro text >> "... As a result the (FE Protocol Object) FEPO LFB is updated over the >> definition in [RFC7121]....." >> >> >>> ------------- >>> In Appendix A of RFC 7121, I find this statement: >>> "The xml has been validated against the schema defined in [RFC5812]." >>> >>> Is that also true of the new version? If so, it should be stated. If not, >>> there could be a problem... >>> >> >> Thanks for catching that - updated. >> >>> Nits: >>> ----- >>> >>> Abbreviations FE and CE should be expanded when first used. >>> >> >> Updated the "Definitions" section to introduce those two (since they >> are common terms). >> >>> ----- >>> >>> "3.2.1. New Codes >>> >>> EXTENDEDRESULT-TLV Result Value is 32 bits and is a superset of RFC >>> 5810 Result TLV Result Value. The new version code space is 32 bits >>> as opposed to the RFC 5810 code size of 8 bits. The first 8 bit >>> values are common to both old " >>> >>> The last sentence is truncated. And do you mean "the first 256 code >>> values are common..."? >>> >> >> Thanks for catching this. Fixed. >> >>> ----- >>> >>> There are quite a lot of small grammatical errors (missing articles etc.) >>> which I assume will be caught by the RFC Editor. There are also various >>> examples of convoluted phrasing that could surely be shorter and simpler. >>> For example, I found the following sentence in section 2.1 very hard to >>> understand: >>> >>> "Implementation experience has shown that existing approaches for >>> retrieving or deleting a sizeable number of table rows is at the >>> programmatically level (from an application point of view) >>> unfriendly, tedious, and abusive of both compute and bandwidth >>> resources." >>> >>> Does this mean >>> >>> Implementation experience has shown that existing approaches for >>> retrieving or deleting a sizeable number of table rows are >>> inefficient. >>> >>> or something more subtle? >>> >> >> The emphasis was intended to be primarily on the programmatic unfriendliness >> and >> secondarily on innefficiency. How about: >> >> ------ >> Implementation experience has shown that existing approaches for >> retrieving or deleting a sizeable number of table rows to be both >> programmatically tedious and inefficient on utilization of both compute >> and wire resources. >> ---- >> >>> ----- >>> >>> Is the RFC Editor supposed to remove the "XXX: comment to IANA..." >>> sentences? >>> If so, this should be clearly stated. >> >> Evangelos brought up this issue as well. >> The text is intended to catch IANA's attention. IANA always calls, and they >> updated text to read "IANA has created .." - I was hoping when they >> call I will ask >> for that text to be removed. Does that sound unreasonable? >> >> Thanks again for your review Brian. >> >> cheers, >> jamal >> > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
