Re: [MBONED] WGLC for <draft-ietf-mboned-ipv4-uni-based-mcast-04.txt>

I was wondering whether the thread would ever end and chairs could 
figure out what are the next steps, but it's always nice to see a good 
review after mostly offtopic discussion.

My take..

On Tue, 29 Jan 2008, Peter Koch wrote:
>> This Last Call will end on January 11, 2008 at 1400 EST (UTC/GMT-4).  We
>> set the WGLC period longer than usual considering we have holiday season
>> during this WGLC period.
>
> apologies for the late reply.  I have no strong preference one way or another,
> but I think there's text in the document that could benefit from external
> review from the RIR/LIR community maybe even prior to IETF Last Call.

Good point, I have no strong feelings about the timing.  Document 
requires a revision in any case (the experiment or at least the length 
of it).  If a rev could be done before the I-D cutoffs close, RIR/LIR 
community could review it during IETF LC.  If not, RIR/LIR community 
could review a non-final suggestion earlier.

> First, unicast addresses are distributed through the IANA->RIR[->NIR]->LIR
> channel, so a particular /24 may end up being allocated (to an LIR)
> but not assigned to a single end user.  Since address policies are
> developed in the five RIR regions, is this something the bodies concerned
> need to address?  Is the multicast group address for the LIR to
> assign/distribute?

Maybe a clarification is needed.  The intent is that this document 
provides a "mapping function" that each network can employ on their 
own, just like they can employ for GLOP address space.  No assignment 
or allocation action by LIR or RIR is needed.

> The term "owner of address space" is likely incompatible with current
> assignment policy documents (at least for the RIPE region, it isn't used,
> if not avoided).

Good point, this could probably be fixed based on specific comments 
from the regions.

> Is there any intention to support DNS reverse mapping for the /8-to-be?
> If the decision is up to the RIRs, the document might want to explicitly
> defer this.

My personal belief is "no", because I don't see this compatible with 
the "mapping function" nature of address space and the overhead caused 
by reverse delegation in this kind of context.

> Since everybody "owns" 10/8 and the other RFC 1918 addresses, what happens
> to these and all the other parts of the multicast /8, e.g. XX.127/16
> and XX.224/12?

Maybe some warning here would be useful.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
MBONED mailing list
MBONED@ietf.org
https://www1.ietf.org/mailman/listinfo/mboned