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

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 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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------