Fwd: Re: Gen-ART review of draft-ietf-ccamp-assoc-ext-04
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 lber...@labn.net To: Peter Yee pe...@akayla.com CC: draft-ietf-ccamp-assoc-ext@tools.ietf.org, gen-...@ietf.org, ietf@ietf.org 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
Re: Fwd: Re: Gen-ART review of draft-ietf-ccamp-assoc-ext-04
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 lber...@labn.net To: Peter Yee pe...@akayla.com CC: draft-ietf-ccamp-assoc-ext@tools.ietf.org, gen-...@ietf.org, ietf@ietf.org 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