RE: I-D Action: draft-ietf-6man-multicast-addr-arch-update-03.txt

[<[e-mail]>]

Dear Tatuya,

A new version including your proposed wording is available online:
http://www.ietf.org/rfcdiff?url1=draft-ietf-6man-multicast-addr-arch-update-03&url2=draft-ietf-6man-multicast-addr-arch-update-04 

Thanks for the review.

Cheers,
Med

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] De la part
>de ????
>Envoyé : mercredi 26 février 2014 18:32
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : [e-mail]
>Objet : Re: I-D Action: draft-ietf-6man-multicast-addr-arch-update-03.txt
>
>Sorry for the delayed response, I've been effectively offline for a
>while.
>
>At Fri, 14 Feb 2014 07:59:41 +0100,
><[e-mail]> wrote:
>
>> >This point in my original comment doesn't seem to be fully addressed:
>> >
>> >- In the NEW format of Section 4.2, this sentence may need to be
>> >  revisited:
>> >
>> >      In this case, the last 4
>> >      bits of the previously reserved field are interpreted as embedding
>> >      the RP interface ID, as specified in this memo.
>> >
>> >In 03, the corresponding part is
>> >
>> >   [..] When the
>> >   R-bit is set, the last 4 bits of the previously reserved field are
>> >   interpreted as embedding the RP interface ID, as specified in this
>memo.
>> >
>> >but it doesn't address my concern since the point is "the previously
>> >reserved" can be ambiguous.
>>
>> [Med] But that sentence is almost the same as in RFC3956:
>>
>> "...the last 4
>>    bits of the previously reserved field are interpreted as embedding
>>    the RP interface ID, as specified in this memo. "
>>
>> That text should be interpreted in the context of RFC3956.
>
>I'm not sure if I understand your logic here, but is there any problem
>with my suggested text?
>
>      In this case, the last 4 bits of the field that were reserved in
>      [RFC3306] are interpreted as embedding the RP interface ID, as
>      specified in this memo.
>
>I believe it's still in the context of RFC3956 (RFC3306 was published
>before RFC3956, and the original RFC3956 actually refers to RFC3306
>already), and yet addresses my point.  This is relatively a minor
>point, and I'm not insisting on adopting the suggestion, but I simply
>don't see the reason for not doing so.
>
>> >I also noticed this (weak) suggestion wasn't adopted:
>> >
>> >: Ah, okay.  Maybe it's a distraction, but I'd consider adding a
>> >: "TERMINOLOGY" section or something, where we clarify the point (i.e.,
>> >: the draft generally follows RFC 5952 to represent IPv6 addresses
>> >: except in citation of already published documents).  But I'd leave it
>> >: to you.
>> >
>> >If ignoring it was your intent, that's fine.  I'm pointing it out just
>> >in case it's overlooked.
>> [Med] This comment was included: see http://tools.ietf.org/html/draft-
>ietf-6man-multicast-addr-arch-update-03#section-1
>>
>>    Textual representation of IPv6 addresses included in the RFC updates
>>    follows the recommendation in [RFC5952].
>
>Ah, okay, I missed that part.
>
>--
>JINMEI, Tatuya