Hi Richard, Thanks for the review of this draft!
> Section 2.1. Would be helpful to either include the old formats and/or say > explicitly what is changing. Added the original format of Config, ConfigAck and ConfigNack messages which are defined in RFC4204. > Section 2.2. > "Nodes which support" -> "nodes that support" > "Ordering of CONFIG objects" -> "... With different C-type values" Updated the text as suggested. > 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.) OLD: The remaining bits in the flags field MUST be set to zero (0). 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: The remaining bits in the flags field MUST be set to zero (0). 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 the number of bits MUST be a multiple of 32. > 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? There is no other exception, so I just removed the word "likely". I will hold the new version until I get the further instruction from my document shepherd or AD. Best regards, Dan -----邮件原件----- 发件人: Richard Barnes [mailto:rbar...@bbn.com] 发送时间: 2013年2月4日 3:14 收件人: ietf@ietf.org; The IESG 抄送: draft-ietf-ccamp-lmp-behavior-negotiat...@tools.ietf.org; gen-...@ietf.org 主题: Gen-ART review of draft-ietf-ccamp-lmp-behavior-negotiation-10 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.) 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?
