Subject: [Gen-art] Gen-ART LC review of draft-ietf-forces-protoextension-04

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Aug 2014 17:08:51 +1200

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.

-------------
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.

-------------
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...

Nits:
-----

Abbreviations FE and CE should be expanded when first used.

-----

"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..."?

-----

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?

-----

Is the RFC Editor supposed to remove the "XXX: comment to IANA..." sentences?
If so, this should be clearly stated.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Aug 2014 08:18:01 +1200

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-masked]> wrote:
> Updated
> 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]....."
> 
> 
>> -------------
> Thanks for catching that - updated.
> 
>> Nits:
>> -----
>>
> Updated the "Definitions" section to introduce those two (since they
> are common terms).
> 
>> -----
>>
>> "3.2.1.  New Codes
>>
> Thanks for catching this. Fixed.
> 
>> -----
>>
> The emphasis was intended to be primarily on the programmatic unfriendliness and
> secondarily on innefficiency. How about:
> 
> ------
>     retrieving or deleting a sizeable number of table rows to be both
>     programmatically tedious and inefficient on utilization of both compute
>     and wire resources.
> ----
> 
>> -----
>>
> 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
>