Skip to main content

Last Call Review of draft-ietf-ccamp-assoc-ext-04

Request Review of draft-ietf-ccamp-assoc-ext
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-08-29
Requested 2012-08-20
Authors Lou Berger , Fran├žois Le Faucheur , Ashok Narayanan
I-D last updated 2012-08-30
Completed reviews Genart Last Call review of -04 by Peter E. Yee (diff)
Genart Telechat review of -05 by Peter E. Yee (diff)
Secdir Last Call review of -?? by Leif Johansson
Assignment Reviewer Peter E. Yee
State Completed
Request Last Call review on draft-ietf-ccamp-assoc-ext by General Area Review Team (Gen-ART) Assigned
Reviewed revision 04 (document currently at 06)
Result Ready w/nits
Completed 2012-08-30
I am the assigned Gen-ART reviewer for this draft. For background on
please see the FAQ at <>

Document: draft-ietf-ccamp-assoc-ext-04
Reviewer: Peter Yee
Review Date: Aug-28-2012
IETF LC End Date: Aug-29-2012
IESG Telechat date: Not known

Summary: This draft is basically ready for publication, but has nits that
should be
fixed before publication. [Ready with nits.]

This document provides extensions to the scope of use of the RSVP
object as well as providing an extended ASSOCIATION object capable of
a longer Association ID.


In the last example (Symmetric NAT), last sentence: "mechanisms" ->

Section 2, 4th paragraph (the replacement text): "the the" -> "the".

Section 3.2.1, 2nd paragraph, 1st sentence: "are" -> "is".  Alternatively,
could change "format" to "formats".

Section 3.2.2, 1st sentence: "apply" -> "applies".

Section 4.2, 1st sentence: "a" -> "an" in both occurrences.

Section 4.2, last paragraph, 2nd sentence: "a" -> "an".


These are questions you may wish to answer but the draft is acceptable
without response:

1) In Section 4.2, 4th bullet, is there any implied relationship between the
Extended Association ID and the Association ID?  Or are they independent
values that simply must be matched?

2) Section 4.2, 5th bullet, you make a first and only mention of padding
Are you using a specific method for generating these padding bytes or are
they random?  Given the matching requirement on ASSOCIATION objects,
it might be best to specify the padding generation so that if the object is
regenerated, it will still be matched by intermediary nodes.  I've presumed
that the padding bytes are for meeting the 4-byte multiple requirement,
but I don't know if implementations would ever be free to regenerate the
object for subsequent transmissions of that object.