Richard,
Thank you for the review. I have one additional question/response on
your comments:
On 2/3/2013 2:13 PM, Richard Barnes wrote:
I have been selected as the General Area Review Team (Gen-ART) reviewer for
this draft (for background on Gen-ART, please
seehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd or AD before posting a
new version of the draft.
Document: draft-ietf-ccamp-lmp-behavior-negotiation-10
Reviewer: Richard Barnes
Review Date: 2013-02-02
IETF LC End Date: 2012-01-21
IESG Telechat date: 2012-02-07
Summary: Ready, with a couple of minor questions / clarifications.
Comment:
Overall, this document seems very clear and readable. Thanks! The one
concern I have is over the use of "likely" in the discussion of backward
compatibility; I would like to see more precise language there.
Section 2.1. Would be helpful to either include the old formats and/or say
explicitly what is changing.
Section 2.2.
"Nodes which support" -> "nodes that support"
"Ordering of CONFIG objects" -> "... With different C-type values"
Section 3.1.MBZ. Might help to clarify that this means that the
number of bits MUST be a multiple of 32. (I got a little confused
between bits and bytes here.)
I think you're right. The current text can easily result in confision
between the size of the MBZ field and the setting of the length field
define in RFC4204. It's probably best to just remove the reference to
the length field. How about this:
OLD
The number of bits present is based on the Length field of the LMP
object header and MUST include enough bits so the Length field MUST be
at least 8, and MUST be a multiple of 4.
NEW
This field MUST be sized to ensure 32 bit alignment of the object.
Lou
(co-author)
Section 4. "Likely"
Is it possible for a 4204-compliant implementation to not do one of these?
If so then remove "likely". If not, then why happens on the exceptional case?