thnx I was hoping for a routing directorate review (Dimitri) but it hasn't showed
Give it a couple of days and then we will move on w/o it. If the review comes in late we will cross the bridge. Aiming for telechat on 9/13 A > -----Original Message----- > From: Lou Berger [mailto:lber...@labn.net] > Sent: 30 August 2012 15:28 > To: Adrian Farrel > Cc: draft-ietf-ccamp-assoc-ext....@tools.ietf.org; gen-...@ietf.org; ietf@ietf.org > Subject: 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 > >
