Re: [MBONED] Mail regarding draft-boucadair-behave-64-multicast-address-format

[Ronald Bonica <[e-mail]>]

Med,

Thanks much. Could I ask for a few others to look at the draft?

                         Ron

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Monday, January 23, 2012 7:55 AM
> To: Ronald Bonica; draft-boucadair-behave-64-multicast-address-
> [e-mail]; MBONED WG
> Subject: RE: Mail regarding draft-boucadair-behave-64-multicast-
> address-format
> 
> Dear Ron,
> 
> Thank you for your review. An updated version taking into account your
> comments has been submitted; it is available at:
> 
> http://tools.ietf.org/html/draft-boucadair-64-multicast-address-format-
> 00.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> 
> > -----Message d'origine-----
> > De : Ronald Bonica [mailto:[e-mail]]
> > Envoyé : vendredi 20 janvier 2012 17:59
> > À :
> > [e-mail].
> > org; MBONED WG
> > Objet : Mail regarding
> > draft-boucadair-behave-64-multicast-address-format
> >
> > Folks,
> >
> > The following are a few comments regarding
> > draft-boucadair-behave-64-multicast-address-format:
> >
> > 1) Please change the filename so that people won't think that
> > this draft is somehow associated with the behave WG
> 
> Done.
> 
> >
> > 2) This document addresses a generic address mapping
> > strategy. It updates RFC 4291, which is a very generic
> > document. It should not concern itself too much with the
> > BEHAVE and MBONED issues that motivated the document. It is
> > sufficient to say that, "This document specifies an extension
> > to the IPv6 multicast addressing architecture to be used in
> > the context of IPv4-IPv6 interconnection." While many BEHAVE
> > and MBONED documents may refer to this document, this
> > document does not need to refer back to them.
> >
> > Therefore, Section 1.1 can be removed entirely. All of the
> > text in Section 1 can be replaced with the following:
> >
> >   "This document specifies an extension to the IPv6 multicast
> > addressing
> >    architecture to be used in the context of IPv4-IPv6
> > interconnection.
> >    In particular, this document defines an address format for IPv4-
> >    embedded IPv6 multicast addresses.  This address format can be
> used
> >    for IPv4-IPv6 translation or encapsulation schemes.
> >
> >    This document updates [RFC4291].
> >
> >    This specification can be used in conjunction with other
> extensions
> >    such as building unicast prefix-based multicast IPv6 address
> >    [RFC3306] or embedding the rendezvous point [RFC3956].
> >
> >    This document is a companion document to [RFC6052] which focuses
> >    exclusively on IPv4-embedded IPv6 unicast addresses.
> >
> >    Details about design choices are documented in Appendix A."
> 
> Done, thanks.
> 
> >
> > 3) For reasons stated above, Sections A.1, A.2 and A.5 can be
> deleted.
> 
> I removed A.1 and A.2. I maintained A.5 which explains why only one
> format is defined for both encap and translation.
> 
> >
> > 4) In Section 2, the term "IPv4-IPv6 Interconnection
> > Function" can be deleted. It is reference only in Sections
> > A.1 and A.2, which can also be delete.
> 
> Done.
> 
> >
> > 5) If you take my advice about deleting Sections A.1 and A.2,
> > please make sure that the reference to A.4 in Section 3 is
> > still correct.
> 
> Checked.
> 
> >
> > 6) The IANA considerations section must be completed. **This
> > is a blocking item for the document**.
> 
> I updated this section.
> 
> >
> > 7) Remove all unused reference
> 
> Done.
> 
> >
> >
> > These changes should make the document significantly shorter
> > (an a smaller target for reviewer!)
> >
> >
> > //speaking as individual contributor
> >
> > --------------------------
> > Ron Bonica
> > vcard:       www.bonica.org/ron/ronbonica.vcf
> >
> >
> >