Skip to main content

Last Call Review of draft-ietf-forces-protoextension-04
review-ietf-forces-protoextension-04-opsdir-lc-brownlee-2014-08-08-00

Request Review of draft-ietf-forces-protoextension
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-08-13
Requested 2014-08-05
Authors Jamal Hadi Salim
I-D last updated 2014-08-08
Completed reviews Genart Last Call review of -04 by Brian E. Carpenter (diff)
Genart Telechat review of -05 by Brian E. Carpenter (diff)
Secdir Last Call review of -04 by Tobias Gondrom (diff)
Opsdir Last Call review of -04 by Nevil Brownlee (diff)
Assignment Reviewer Nevil Brownlee
State Completed
Request Last Call review on draft-ietf-forces-protoextension by Ops Directorate Assigned
Reviewed revision 04 (document currently at 06)
Result Has nits
Completed 2014-08-08
review-ietf-forces-protoextension-04-opsdir-lc-brownlee-2014-08-08-00
Hi all:

I have performed an Operations Directorate review of
  draft-ietf-forces-protoextension-04

  "Experience in implementing and deploying ForCES architecture has
   demonstrated need for a few small extensions both to ease
   programmability and to improve wire efficiency of some transactions.
   This documents updates both RFC 5810 and RFC 7121 semantics to
   achieve that end goal."

This draft is 'ready with nits' (which are easily fixed by the authors).

- - - -

1. Is the specification complete?  Can multiple interoperable
     implementations be built based on the specification?

This draft specifies two straightforward extensions to ForCES,
 . the ability to request an arbitrary range of table rows
 . an extended set of error codes to provide more detail
     for failing requests
It also clarifies describes in detail how large tables should be
     retrieved using a sequence of GET requests

The draft is short, and explains the above clearly.

2. Is the proposed specification deployable?  If not, how could it be
     improved?

These are extensions to ForCES, existing implementations should
continue to operate as usual.

3. Does the proposed approach have any scaling issues that could
     affect usability for large scale operation?

No.

4. Are there any backward compatibility issues?

No.

5. Do you anticipate any manageability issues with the specification?

No

6. Does the specification introduce new potential security risks or
     avenues for fraud?

No.


Some comments:

Figure 1 doesn't show clearly that each row is 32 bits wide, though
  that is made clear in the text following the Figure.
  Consider adding bit numbers at the top.

The section on TABLERANGE-TLV has a 64-bit hex constant for the
  last entry in the table, but that's for a 32-bit field!

Appendix A only gives the new version of the FEPO.
  It would be better to have an introductory sentence saying that
  "This version updates the earlier one given in RFC 7121."


A few typos:

p6  s/Path flag of/The Path flag of/
    s/implies the beggining/implies the begining/
    s/contain the row(s)/contains the row(s)/
s2.3.1 New Codes
    unfinished sentence: 'common to both old' ...
    perhaps 'old and extended Result Values' ?

s3.2.3 Extended Result TLV
    s/now have 32 bit/now have a 32 bit/
    s/old 8 bit/old 8 bit value/
    s/Utf-8/UTF-8/
    s/string../string./


Cheers, Nevil
Co-chair, IPFIX and EMAN WGs

--
---------------------------------------------------------------------
 Nevil Brownlee                          Computer Science Department
 Phone: +64 9 373 7599 x88941             The University of Auckland
 FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand