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

From: "ian Farrer" <[email-masked]>
Date: Wed, 12 Mar 2014 15:26:29 +0100

Hi,

To try and move the discussion on the m/l forward, what about the following wording tweak?:

Lightweight 4over6 is a solution designed specifically for complete independence between IPv6 subnet prefix and IPv4 address with/without v4 address sharing.

Let me know if you like it.

Cheers,
Ian
----- Original Message -----
From: [email-masked]
Sent: 03/12/14 09:05 AM
To: [email-masked]
Subject: RE: I-D Action: draft-ietf-6man-multicast-addr-arch-update-03.txt

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 : [email-masked] [mailto:[email-masked]] De la part >de ???? >Envoyé : mercredi 26 février 2014 18:32 >À : BOUCADAIR Mohamed IMT/OLN >Cc : [email-masked] >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, ><[email-masked]> 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 re
 fers 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 ----------------------------
 ---------------------------------------- IETF IPv6 working group mailing list [email-masked] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------

---

From: Ian Farrer <[email-masked]>
Date: Wed, 12 Mar 2014 15:36:49 +0100

Posted to wrong list. Please ignore.

Ian

On 12 Mar 2014, at 15:26, ian Farrer <[email-masked]> wrote:

>> 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 : [email-masked] [mailto:[email-masked]] De la part 
>> 
>> >de ???? 
>> 
>> >Envoyé : mercredi 26 février 2014 18:32 
>> 
>> >À : BOUCADAIR Mohamed IMT/OLN 
>> 
>> >Cc : [email-masked] 
>> 
>> >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, 
>> 
>> ><[email-masked]> 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 
>> 
>> -------------------------------------------------------------------- 
>> IETF IPv6 working group mailing list 
>> [email-masked] 
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 
>> --------------------------------------------------------------------
>  
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------