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
