Unicast-Prefix-Based IPv4 Multicast Addresses
RFC 6034

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

Lars Eggert No Objection

(Ron Bonica; former steering group member) Yes

Yes ()
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ()
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection ()
No email
send info

(Dan Romascanu; former steering group member) No Objection

No Objection ()
No email
send info

(David Harrington; former steering group member) No Objection

No Objection ()
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ()
No email
send info

(Peter Saint-Andre; former steering group member) No Objection

No Objection ()
No email
send info

(Ralph Droms; former steering group member) No Objection

No Objection ()
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection ()
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection (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)

(Sean Turner; former steering group member) No Objection

No Objection ()
No email
send info

(Stewart Bryant; former steering group member) No Objection

No Objection (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.

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection (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.