Re: Fwd: Re: Gen-ART review of draft-ietf-ccamp-assoc-ext-04

[Lou Berger <[e-mail]>]

Eek,
     I somehow managed to broadcast this!  My apologies.

Lou

On 8/30/2012 10:27 AM, Lou Berger wrote:
>
> Adrian,
>       Shout (or change the ID state) when you're ready for the update to
> be submitted.
>
> Thanks,
> Lou
> -------- Original Message --------
> Subject: 	Re: Gen-ART review of draft-ietf-ccamp-assoc-ext-04
> Date: 	Thu, 30 Aug 2012 10:25:19 -0400
> From: 	Lou Berger <[e-mail]>
> To: 	Peter Yee <[e-mail]>
> CC: 	[e-mail], [e-mail],
> [e-mail]
>
>
>
> Peter,
> 	Thank you for the comments.  Please see below for responses in-line.
>
>
> On 8/29/2012 11:31 PM, Peter Yee wrote:
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART,
>> please see the FAQ at <
>> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>>
>> 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
>> ASSOCIATION
>> object as well as providing an extended ASSOCIATION object capable of
>> handling
>> a longer Association ID.
>>
>> Nits:
>>
>> In the last example (Symmetric NAT), last sentence: "mechanisms" ->
>> "mechanism".
>>
>> Section 2, 4th paragraph (the replacement text): "the the" -> "the".
>>
>> Section 3.2.1, 2nd paragraph, 1st sentence: "are" -> "is".  Alternatively,
>> you
>> 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".
>>
> Thank you!
>
>> Questions:
>>
>> 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?
> The latter (as the text says.)
>
>> 2) Section 4.2, 5th bullet, you make a first and only mention of padding
>> bytes.
>> Are you using a specific method for generating these padding bytes or are
>> they random?
> No, as it is completely up to the creator of the object to use it
> consistently.
>
>> 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.
> I'll add ", without modification," to the last sentence of 3.1.2 and 3.2.2.
>
> Thank you for the comments!
>
> Lou
>
>
>
>