Skip to main content

Telechat Review of draft-ietf-ccamp-lmp-behavior-negotiation-10
review-ietf-ccamp-lmp-behavior-negotiation-10-genart-telechat-barnes-2015-12-31-00

Request Review of draft-ietf-ccamp-lmp-behavior-negotiation
Requested revision No specific revision (document currently at 11)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-02-05
Requested 2013-01-28
Authors Dan Li , Daniele Ceccarelli , Lou Berger
I-D last updated 2015-12-31
Completed reviews Genart Telechat review of -10 by Richard Barnes (diff)
Assignment Reviewer Richard Barnes
State Completed
Request Telechat review on draft-ietf-ccamp-lmp-behavior-negotiation by General Area Review Team (Gen-ART) Assigned
Reviewed revision 10 (document currently at 11)
Result Ready w/issues
Completed 2015-12-31
review-ietf-ccamp-lmp-behavior-negotiation-10-genart-telechat-barnes-2015-12-31-00
I have been selected as the General Area Review Team (Gen-ART) reviewer for
this draft (for background on Gen-ART, please see

http://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?