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

From: Ronald Bonica <[email-masked]>
Date: Fri, 20 Jan 2012 11:58:41 -0500

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

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."

3) For reasons stated above, Sections A.1, A.2 and A.5 can be deleted.

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.

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.

6) The IANA considerations section must be completed. **This is a blocking item for the document**.

7) Remove all unused reference

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

---

From: <[email-masked]>
Date: Mon, 23 Jan 2012 13:54:34 +0100

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:[email-masked]] 
> Envoyé : vendredi 20 janvier 2012 17:59
> À : 
> [email-masked].
> 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:
> 

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.

> is a blocking item for the document**.

I updated this section.

> 7) Remove all unused reference

Done.

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 23 Jan 2012 14:30:39 -0500

Med,

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

                         Ron

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, January 23, 2012 7:55 AM
> To: Ronald Bonica; draft-boucadair-behave-64-multicast-address-
> [email-masked]; 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:
> 
> I removed A.1 and A.2. I maintained A.5 which explains why only one
> format is defined for both encap and translation.
> 
> >