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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:lberger@xxxxxxxx]
> Sent: 30 August 2012 15:28
> To: Adrian Farrel
> Cc: draft-ietf-ccamp-assoc-ext.all@xxxxxxxxxxxxxx; gen-art@xxxxxxxx;
ietf@xxxxxxxx
> 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 <lberger@xxxxxxxx>
> To: 	Peter Yee <peter@xxxxxxxxxx>
> CC: 	draft-ietf-ccamp-assoc-ext.all@xxxxxxxxxxxxxx, gen-art@xxxxxxxx,
> ietf@xxxxxxxx
> 
> 
> 
> 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
> 
> 




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]