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

Posted to wrong list. Please ignore.

Ian

On 12 Mar 2014, at 15:26, ian Farrer <ianfarrer@gmx.com> wrote:

> 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: mohamed.boucadair@orange.com
>> Sent: 03/12/14 09:05 AM
>> To: jinmei@wide.ad.jp
>> 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 : jinmei.tatuya@gmail.com [mailto:jinmei.tatuya@gmail.com] De la part 
>> 
>> >de ???? 
>> 
>> >Envoyé : mercredi 26 février 2014 18:32 
>> 
>> >À : BOUCADAIR Mohamed IMT/OLN 
>> 
>> >Cc : ipv6@ietf.org 
>> 
>> >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, 
>> 
>> ><mohamed.boucadair@orange.com> 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 
>> ipv6@ietf.org 
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 
>> --------------------------------------------------------------------
>  
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------