1. Summary
The document shepherd is Evangelos Haleplidis <ehalep@ece.upatras.gr>
The responsible Area Director is Adrian Farrel <adrian@olddog.co.uk>
This document extends the ForCES protocol document (RFC 5810) to
allow table ranges for operations, introduces additional error codes,
adds a new TLV for extended replies and clarifies how a message is handled
when that does not fit within a single protocol message.
2. Review and Consensus
The extensions are straightforward, and there was no difficulty in coming
to consensus on all points described. There were suggested extensions for
earlier versions of the document that were not included based on discussions
in the WG for the sake of simplicity. At least one implementation has
validated some of the features described in the document.
We believe the working group is solidly behind this document.
3. Intellectual Property
The author has confirmed conformance with BCP 78/79.
There are no IPR disclosures on the document.
4. Other Points
a) There a number of spelling errors. Please use
https://tools.ietf.org/tools/idspell/webservice to fix.
b) This document updates RFC5810.
1. Please write in the abstract also how it updates it.
2. Please specify in the introduction as well that this document updates
RFC5810. Right now it reads that "this document describes a few extensions to
the ForCES Protocol".
c) Similar to the Adrian's comments on the model extension draft:
1. Please put the introduction in section 1.
2. Please don't repeat material from RFC5810. Specify that you're using
terminology from RFC5810 and specify which terms (in a bullet format without
any content) that the reader should be familiar with
d) This document says that it updates RFC7121.
However the only change for RFC7121 is the FEPO LFB which change is backwards
compatible - therefore all the mechanics in RFC7121 are still the same. Please
clarify whether a change in the LFB results in the update of the RFC as well.
e) While it already has been discussed in the mailing list (see thread:
http://www.ietf.org/mail-archive/web/forces/current/msg04823.html) you have to
make clear 1. Whether KEYSELECTOR TLV and RANGE TLV can coexist (Mailing list
consensus was NO for simplicity reasons) 2. Whether multiple RANGE TLVs can
coexist within the same PATHDATA TLV 3. Whether after a PATHDATA TLV which has
a RANGE (or KEYSELECTOR for that matter) there can be another PATHDATA TLV
f) There is a text marked with XXX in the IANA considerations.
g) Please make the IANA considerations sections similar to the section in
RFC5810 since you're requesting different types of reservation in order to make
IANA's work easier.