Re: [MBONED] addrarch: IANA assignment policies and eGLOP

[Marshall Eubanks <[e-mail]>]

Hello;



On Jan 26, 2007, at 9:46 AM, Leonard Giuliano wrote:

>
> Pekka- the suggestions you make here sound reasonable to me.
>
> On Wed, 24 Jan 2007, Pekka Savola wrote:
>
> -) (Lenny's message has not appeared to the archives, I wonder if  
> you posed from
> -) a different address than the one you've subscribed, or the list  
> is hosed..)
> -)
> -) On Mon, 22 Jan 2007, Leonard Giuliano wrote:
> -) > On Fri, 19 Jan 2007, Pekka Savola wrote:
> -) > -) Questions to the group (first one mainly to Marshall):
> -) > -)
> -) > -)  1) Marshall's initiative on getting eGLOP started.  What  
> was it
> -) > -)     exactly and what's the status?

I am preparing to submit a proposal to APNIC to instantiate eGLOP  
before the deadline (one week from today)
and, since I am attending the Apricot meeting, will attend the Apnic  
meeting to discuss it. (I believe that Dave Meyer will be there as  
well.)

Assuming that this meets a positive response, I would send the same  
to ARIN and RIPE.

For whatever reason, there is now substantial interest in eGlop and I  
see no reason to instantiate it along
the lines of the RFC.


> -) > -)
> -) > -)  2) Is it even possible for IANA (if instructed by the  
> IETF) to stop
> -) > -)     making multicast assignments (or tighten the policy) on  
> specific
> -) > -)     ranges?
> -) > -)
> -) >
> -) > Why not?  If I went to IANA and requested a Class A network of  
> unicast
> -) > space, I'm pretty sure I know what answer they would give me.   
> Pointing
> -) > out that Class A blocks were given out in the past would  
> probably not
> -) > change their answer.
> -)
> -) Personally I agree with you.  Just trying to figure out if any  
> WG member
> -) disagrees with this.
> -)
> -) > -)  3) If we end up using eGLOP, how should that change IANA's
> -) > -)     traditional assignments (if answer is 'yes' to 2)?
> -) > -)
> -) >
> -) > IANA should not make static assignments anymore (unless it is for
> -) > protocol use- eg, 224.0.0/24 stuff).
> -)
> -) OK, looking at http://www.iana.org/assignments/multicast- 
> addresses. More
> -) specifically, I suppose your recommendation is (referring to  
> IANA guidelines
> -) defined in RFC2434):
> -)
> -) - IANA policy for 224.0.0.0/24 (Local network control block)  
> should be
> -)   FOO (what would that be? Specification Required?  Is Expert  
> Review
> -)   enough?  Should this range be usable for non-IETF protocols as it
> -)   currently has been used?)
> -)

I agree.

> -) - What about 224.0.1.0/24 (Internetwork control block)?   
> Specification
> -)   required, expert review, something else?
> -)
> -) - I suppose for 224.0.[2-255].0/24 (Adhoc block) you suggest  
> stopping
> -)   altogether or making sufficiently strong requirement  
> (specification
> -)   required, with further qualifiers on the number of available
> -)   addresses per assignee?) that it would not be exercised so much
> -)   anymore.

I agree.

> -)
> -) - What about the rest of 224.0.0.0/8? (e.g., recent allocation to
> -)   london stock exchange)?   Require Standards Action or  
> something very
> -)   strong?
> -)
> -) > -)  4) Should we try to defer all the questions about IANA  
> policies,
> -) > -)     eGLOP, etc. to some other document in order to get this  
> one
> -) > -)     finished (and this one being vague on the topic)?
> -) > -)
> -) >
> -) > This seems like an eminently solvable problem to me and  
> something that has
> -) > been discussed for years.  I believe it would be worthwhile to  
> finally
> -) > resolve this once and for all now instead of punting and  
> having to resolve
> -) > it later.  We all seem to agree on the solution.  Our goal  
> here is to
> -) > solve problems, not just publish expedient documents.
> -) >
> -) > Must this be taken on by a RIR?  I would happily do this  
> myself if there's
> -) > a fee involved.
> -)
> -) Well, for some reason, the attempts to write new IANA guidelines  
> were dropped
> -) at least twice, in 2002 and in 2004.  Either there was no  
> sufficient interest
> -) or time or there were some issues (e.g., about what the policy  
> should be)
> -) which weren't easily solvable.
> -)

I think it was really both.

> -) Personally, I'd be glad to see us finally properly write down  
> the IANA
> -) policies, regardless of what those policies would end up being.  
> AFAICS,
> -) currently there are basically no policies whatsoever.
> -)

I agree, and will forward the Apnic draft to the list as soon as I  
have it done.

Marshall

> -) --
> -) 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mboned


_______________________________________________
MBONED mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mboned