[ppml] Resurrecting ULA Central [was: Re: Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure - to be revised ]

Tue Apr 25 14:57:51 EDT 2006

However, in the long run, tying IP Address to Topology as a definition would
further cement what I believe is an error in the protocol design.  The
IP address should be strictly an End System Identifier. Overloading topology
onto it is part of why we are worried about scaling limits in routing
tables.

Owen

--On April 25, 2006 10:56:49 AM -0700 Peter Sherbin <pesherb at yahoo.com>
wrote:

>> ... the PI/PA debate is or should be pointless.
> 
> Perhaps a consesus definition of an IP address could help, e.g.:
> An IP address is a unique topological identifier of the interface where
> the number of bits in the address determines the version of IP.
> 
> This would remove the ownership topic because no one owns the whole or a
> part of any particular version of the protocol.
> 
> Peter
>  
> 
> --- bmanning at vacation.karoshi.com wrote:
> 
>> On Mon, Apr 24, 2006 at 04:27:06PM -0400, Jason Schiller
>> (schiller at uu.net) wrote:
>> > Bill,
>> > 
>> > Are you saying the right place to solve the private addressing issue
>> > is in the individual RIRs?
>> 
>> 	perhaps i was unclear.  the ULA proposal from the IETF
>> 	create property rights in IP address space, a concept that
>> 	to date, is antithical to the RIR premise that IP space
>> 	is roughly analogous to frequencies... e.g. can I OWN
>> 	the frequency band between 10.8GHz and 11.2Ghz and require
>> 	anyone who uses it to pay me royalties on a global basis?
>> 	
>> 	the IETF proposal allows entities to claim ownership, via
>> 	first come, first served, of IP space.  There is some precident
>> 	at least in the US system of law, which argues against the
>> 	ability to own numbers.  My fears may be unfounded in this
>> 	regard.
>> 
>> 	but the ULA central proposal does create yet another registry,
>> 	the "central" thing that is supposed to track who is holding what.
>> 	And there is no plan to provide a viaable businsess model for such
>> 	a "central" holder.  And there is no current way that "central"
>> 	can or would coordinate with the other RIRs.
>> 
>> 	-MY- assertion is that there is or should be  no distinction
>> 	on an address delegation... the PI/PA debate is or should be 
>> 	pointless.  You get a delegation or not.  You can chose to make
>> 	subsiquent delegations from your delegated space or not.  
>> 	And it is reasonable to place conditions on a delegation such that
>> 	it is recoverable... presuming the horse has not left the barn.
>> 
>> 	that said, ARIN policy is created through the the open policy
>> 	process.  if you -WANT- to add more policies, go for it.  
>> 	I'd prefer to revamp most of the policies and come up wiht 
>> 	a few core things and not build up a big policy analysis group.
>> 
>> --bill
>> 
>> > 
>> > I just want to be clear on this point so I can determine the best
>> > place to focus my efforts.
>> > 
>> > I thought what I heard at the last ARIN meeting was that the ARIN
>> > policy on should not supercede and RFC on unique local addressing.
>> > 
>> > This is troubling as it is my understing of the history of
>> > draft-ietf-ipv6-ula-central-01.txt is that in got 7/8s finished and
>> > then  it died at the ARIN stage, but one of the things holding up the
>> > ARIN policy 2006-2 was that it really should be pursued in the IETF
>> > first.
>> > 
>> > Many people who previuosly worked on draft-ietf-ipv6-ula-central-01.txt
>> > are not intrested in reviving the draft if it is just going to die at
>> > ateh ARIN stage.  I would hate to invest time on the ARIN policy if
>> > people are not likely to accept it without an RFC.
>> > 
>> > So the question I have for you and everyone is where is the best place
>> > to pursue this?
>> > 
>> > ___Jason
>> > ======================================================================
>> > ==== Jason Schiller
>> > (703)886.6648 Senior Internet Network Engineer
>> > fax:(703)886.0512 Public IP Global Network Engineering
>> > schiller at uu.net UUNET / Verizon
>> > jason.schiller at verizonbusiness.com
>> > 
>> > The good news about having an email address that is twice as long is
>> > that it increases traffic on the Internet.
>> > 
>> > On Sat, 22 Apr 2006 bmanning at vacation.karoshi.com wrote:
>> > 
>> > > On Thu, Apr 20, 2006 at 04:36:37PM -0400, Thomas Narten wrote:
>> > > > Cons:
>> > > > 
>> > > > 1) ARIN pretty vocally shot down the document a year or more ago,
>> > > > and the IETF basically decided "we don't need this so badly as to
>> > > >    have a showdown with the ARIN community". Having said that, I
>> > > >    (and others) still think the idea has some merit and would be
>> > > >    willing to push on it on the IETF end, assuming we wouldn't get
>> > > >    a repeat reaction at future meetings for our efforts...
>> > > 
>> > > 	the reasons, imho, that ARIN gave this the thumbs down was A) that
>> > >	it creates property rights,  and B) has the IETF creating an other
>> > >	address registry out of whole cloth - not following the defined
>> > >	RIR creation
>> > > 	process.  For me, the first is fundamentally fatal.
>> > > 
>> > > > 
>> > > >    Note: AFAIK, no such reaction seemed to come out of APNIC or
>> > > >    RIPE.
>> > > > 
>> > > > I know that there is at least one person willing to resurrect the
>> > > > ula-central document, but I (personally) don't want to invest
>> > > > cycles in it if it's going to get a frosty reception in ARIN
>> > > > again. Been there, done that.
>> > > >    
>> > > > Thomas
>> > 
>> _______________________________________________
>> PPML mailing list
>> PPML at arin.net
>> http://lists.arin.net/mailman/listinfo/ppml
>> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060425/2b86e4d6/attachment.sig>