Hi Brian,

Thanks for the quick response. We have just submitted the -05 revision.

Thanks,

Carlos

On Fri, 2013-10-18 at 13:43 -0400, Brian Haberman wrote:
> Hi Carlos,
>      I have pared down the points to just those needing a response...
> 
> On 10/18/13 6:29 AM, Carlos Jesús Bernardos Cano wrote:
> > 
> >>
> >> * The last paragraph is not needed and can be deleted.
> > 
> > [Authors] OK, done. We originally added this because during the IESG
> > evaluation of RFC7028 we got a comment requesting to add such a
> > paragraph there.
> > 
> 
> This time around, I will do my best to stop such silliness. :)
> 
> > 
> >>
> >> 5. Section 4.1.2 : It would be clearer if the description of the message
> >> formats that are borrowed from 2710 and 3810 refer to those formats by
> >> the terms used in the RFC.  For example, the Multicast Membership
> >> Context field should refer to (or be called) the Multicast Address
> >> Record (from 3810).
> > 
> > [Authors] We think we already do this:
> > 
> >    Multicast Membership Context:
> > 
> >       Multicast subscription information corresponding to a single
> >       subscribed multicast address.  For MLDv2, the format of this field
> >       follows the Multicast Address Record format as defined in
> >       [RFC3810].
> > 
> > [Authors] But if you think that it is clearer to just use the RFC 3810
> > name (Multicast Address Record) for the field, we can update it.
> > 
> 
> You are right.  The existing text is sufficient.
> 
> >>
> >> 6. Sections 4.3.1.2 and 4.3.2.2
> >>
> >> * Why are the sequence numbers 8-bit fields?  The sequence fields in
> >> other PMIPv6 messages are 16-bit.
> > 
> > [Authors] We believe that 8 bits are enough for this sequence space,
> > which is enough for the purpose of the subscription query/response, as
> > it is not expected to be used as often as PBU/PBA. Using 16-bit values
> > would require at least extending the size of the Subscription Response
> > message, and we thought that it was a better trade-off to use a 8-bit
> > value.
> > 
> 
> Ok.  This is nothing to worry about now.  Don't be surprised if someone
> during IETF Last Call or IESG Review asks for text in the document
> explaining why the sequence number spaces have different sized.
> 
> Go ahead and submit the new version and I will move it along in the
> publication process.
> 
> Regards,
> Brian
> 


_______________________________________________
multimob mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/multimob

Reply via email to