[ppml] Allocation and reallocation

[Mury]

I guess that depends on if you find it more helpful to spell out whether
the space is portable or not, or if it's more helpful to know where the
space came from.  If the consensus is that most people just need to know
if the space is portable than it is to know where to return it to or where
it came from then you could use the following notation:

RIR	Space held by a RIR
LIR(P)	Space allocated to a LIR from a RIR
LIR(N)	Space allocated to a LIR from another LIR
END(P)	Space assigned to an end user from a RIR
END(N)	Space assigned to an end user from a LIR

Regards,

Mury

On Mon, 27 Oct 2003 william at elan.net wrote:

>
> I did not want to get into this "wording" debate before, because I often
> do not use correct language as is, but seems to me Mury's terms here are
> the best ones so for mentioned, in particular we can easily replace
> "ALLOCATED" by "ASSIGNED TO LIR" or just "LIR IP Block" (no matter from
> if its assigned from RIR or from another LIR) and "ASSIGNED" can be
> "ASSIGNED TO END-USER" or "END-User IP Block". I did not particularly like
> how he introduced who assigned the block, and still prefer indication if
> ip block is portable or not. So to me the following looks like the best if
> we want to find replacement for "ALLOCATION" and "ASSIGNMENT":
>
> PORTABLE LIR IP BLOCK = ALLOCATED by ARIN to ISP
> NON-PORTABLE LIR IP BLOCK = ALLOCATED from one ISP to another
> PORTABLE END-USER IP BLOCK = ASSIGNED by ARIN directly to Organization
> NON-PORTABLE END-USER IP BLOCK = ASSIGNED by ISP to end-user
>
> With LIR defined as any organization that is making allocations or
> assignments of ip space.
>
> On Mon, 27 Oct 2003, Mury wrote:
>
> >
> > I can't remember who proposed what, so forgive me for not giving
> > appropriate credit, but besides the generic argument wanting to leave
> > things as is, what are the arguments against something like the following:
> >
> > "LIR" IPs (Currently assignable and allocatable - forgive the grammar/sp)
> > "END" user IPs (Currently assignments)
> >
> > >From there you could use notation such as:
> >
> > LIR(L) Space that has been further allocated from an ISP to an ISP
> > LIR(R) Space from a RIR to an ISP
> > END(L) Space from a LIR to an end user
> > END(R) Space from a RIR to an end user
> >
> > This would be consistant with the current RIR/LIR language being used.  It
> > would also be easy to identify the properties and responsibities that go
> > hand and hand with being a LIR, such as you must swip your space and you
> > may further divide your space.
> >
> > My two cents is that the usage requirements of space to an end user from
> > either a LIR or a RIR should be the same.  But, if you wanted to
> > distinguish a difference you could do so with the (L) and (R) syntax.
> > This of course is helpful in determining if the space is "portable..."
> > meaing assignments having been made from a RIR.
> >
> > If that is viewed as messy, two fields could be used.  One being the type
> > of space (LIR or END), and the other being what the "upstream" entity is
> > (LIR or RIR).
> >
> > Mury
> >
> > On Mon, 27 Oct 2003, Leo Bicknell wrote:
> >
> > >
> > > This all comes back to the reason I started this thread.  The policy
> > > is not clear.  The policy needs to be made clear so we can't have
> > > these arguments as to what it means.  An ISP shouldn't have to guess
> > > what the requirements will be, or really even ask for clarification.
> > > They should be spelled out clearly.
> > >
> > > The problem is as soon as you try to clarify the policy two things
> > > happen.  People think you're trying to change the policy (in this
> > > case I don't want to change it, just make it clear) because today
> > > there are multiple ways to view it, and there should only be one.
> > > That represents change to the people who have the other (wrong?)
> > > opinion.  The other is that many other people jump in expressly to
> > > change the policy.
> > >
> > > If the people who care about policy and have joined this list can't
> > > agree on what it says how can we expect the average ARIN member or
> > > staffer to get it right?
> > >
> > > --
> > >        Leo Bicknell - bicknell at ufp.org - CCIE 3440
> > >         PGP keys at http://www.ufp.org/~bicknell/
> > > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
>