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