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.hin...@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.boucad...@orange.com> ><mohamed.boucad...@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-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] De >la part de mohamed.boucad...@orange.com >> Envoyé : vendredi 4 mai 2012 14:50 >> À : mboned-cha...@ietf.org; ipv6@ietf.org >> Cc : Brian Haberman; >draft-ietf-mboned-64-multicast-address-for...@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 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
