Unicast-Prefix-Based IPv4 Multicast Addresses
RFC 6034

Note: This ballot was opened for revision 06 and is now closed.

(Ron Bonica) Yes

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

Comment (2010-06-16)
No email
send info
I share Tim's concern that we need to explore the extent of IETF consensus on this proposal. 

In particular there are not many m/c /8 left so we need to make sure the allocation is well used.

One limitation of the proposed method is that a small organization has an extremely limited number of m/c addresses that that can create by this mechanism. Did the WG consider, for example, the creation of a registry of organizations that wanted m/c addresses but which did not have a 16bit AS number, since this would have allowed greater flexibility in the number of m/c addresses an organization could own?

Also I had to stare at this figure 

   Bits:  |  8  | Unicast Prefix Length | 24 - Unicast Prefix Length |
   Value: | TBD | Unicast Prefix        | Group ID                   |

for a while before I understood it and wonder if there is a better way to show this.

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

(David Harrington) No Objection

(Russ Housley) No Objection

Comment (2010-06-16)
No email
send info
  Please consider the Gen-ART Review by Francis Dupont on 2010-05-12:

  - 1 page 3: assignment ... need -> assignments?
    (please reread the statement and improve it)

(Alexey Melnikov) No Objection

(Tim Polk) (was Discuss) No Objection

Comment (2010-07-08)
No email
send info
The draft seems to imply that an organization must choose between these allocation methods.  
I don’t see why that is the case.  Is there any reason that an AS can’t take advantage of both 
GLOP and the mechanism specified in this I-D?  The idea that these mechanisms are 
complementary is no where to be found.

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection