RE: draft-ietf-mboned-64-multicast-address-format

Dear Bob,

Yes, I read that message. It is one of reasons I added two appendixes to explain:

* Why an Address Format is Needed for Multicast IPv4-IPv6 Interconnection? (http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-02#appendix-A.1)
* Why Identifying an IPv4-Embedded IPv6 Multicast Address is Required? (http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-02#appendix-A.2)

You may also refer to slide 7 of http://www.ietf.org/proceedings/83/slides/slides-83-mboned-5.pdf for the overall approach.

Could you please check the new text and let me know if it solves your concerns? Thanks.

Cheers
Med

>-----Message d'origine-----
>De : Bob Hinden [mailto:bob.hinden@gmail.com] 
>Envoyé : mercredi 23 mai 2012 18:38
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : Bob Hinden; ipv6@ietf.org
>Objet : Re: draft-ietf-mboned-64-multicast-address-format
>
>Med,
>
>On May 23, 2012, at 6:20 AM, <mohamed.boucadair@orange.com> 
><mohamed.boucadair@orange.com> wrote:
>
>> Dear all,
>>  
>> Many thanks for the individuals who read the draft and 
>provided some comment.
>>  
>> My read of the the answers received in this thread is there 
>is no strong reasons to question the design choices as 
>documented in the draft.
>
>Did you see my comments sent on 5/5/2012?  I continue to think 
>that there are alternatives that do not require any change to 
>the IPv6 addressing architecture, nor use such a big 
>percentage of the multicast group ID space.
>
>Bob
>
>
>>  
>> FWIW, I just submitted a updated version taking into account 
>the comments received during the IETF LC:
>>  
>> * Editorial changes as suggested in SM's review
>> * Title change (comment from C. Bormann)
>> * Added a new section to describe the algorithm to 
>embed/extract the IPv4 address (comment from C. Bormann)
>> * Added some pointers to documents making use of the address 
>format (comment from C. Bormann)
>> * Added an appendix to explain why an M-bit is needed 
>(comment from C. Bormann)
>> * Added an appendix to explain why an address format is 
>needed (comment from C. Bormann)
>> * Added examples of means to provision the MPREFIX64 
>(comment from C. Bormann)
>> 
>> Diff from previous version:
>> 
>http://tools.ietf.org/rfcdiff?url2=draft-ietf-mboned-64-multica
>st-address-format-02
>> 
>> Cheers,
>> Med
>>  
>> 
>> De : ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] De 
>la part de mohamed.boucadair@orange.com
>> Envoyé : vendredi 4 mai 2012 14:50
>> À : mboned-chairs@ietf.org; ipv6@ietf.org
>> Cc : Brian Haberman; 
>draft-ietf-mboned-64-multicast-address-format@tools.ietf.org
>> Objet : draft-ietf-mboned-64-multicast-address-format
>> 
>> 
>> Dear all,
>>  
>> During the IETF LC for 
>draft-ietf-mboned-64-multicast-address-format, Brian suggested 
>to use the remaining flag instead of reserving ff3x:0:8000/33 
>(SSM) and ffxx:8000/17 (ASM) blocks. FYI, we have considered 
>that approach in an early version of the document but it has 
>been abandoned because of comments we received at that time. 
>We recorded the rationale behind our design choice in:
>> 
>http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-addre
>ss-format-01#appendix-A.2.
>>  
>> We are seeking more feedback from 6man and mboned on the following:
>>  
>> (1) Should we maintain the current design choice
>> (2) Or adopt the suggestion from Brian?
>>  
>> FWIW, discussion related to this issue can be found here: 
>http://www.ietf.org/mail-archive/web/mboned/current/msg01508.html.
>> The latest version of the draft is available at: 
>http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-addre
>ss-format-01
>>  
>> Your help is appreciated.
>>  
>> Cheers,
>> Med
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>