Re: [sig-policy] prop-045: Proposal to modify "end site"definition and a
definition ? Any specific suggestions ?
Regards,
Jordi
> De: Leo Vegoda <leo.vegoda at icann dot org>
> Responder a: <leo.vegoda at icann dot org>
> Fecha: Wed, 24 Jan 2007 19:36:58 +0100
> Para: <jordi.palet at consulintel dot es>
> CC: "sig-policy at lists dot apnic dot net" <sig-policy at lists dot apnic dot net>
> Asunto: Re: [sig-policy] prop-045: Proposal to modify "end site"definition and
> allow end sites to receive IPv6 allocations
>
> Hi Jordi,
>
> On Jan 24, 2007, at 6:34 PM, JORDI PALET MARTINEZ wrote:
>
> [...]
>
>>> I agree that making address space available to networks that need it
>>> is good. My concern isn't the goal but the phrasing of the policy. I
>>> think the proposal is phrased in a way that would allow almost any
>>> organisation where one department 'bills' another for a service to
>>> qualify for a /32 allocation. You implied that the membership fees
>>> are the main deterrent. As the APNIC Fees WG is reviewing the fee
>>> structure I think it might not be a good idea to rely on it when
>>> designing policy.
>>
>> I think it should be on the other way around. I guess the fees
>> can't be
>> changed each time a new policy is passed, but the fees should make
>> sure that
>> "in general", fees are charged in a fair way in order to cover APNIC
>> costs+budget provision for continued operation for a certain number of
>> years, etc.
>>
>> So policies should be "fee agnostic", but somehow fees should be
>> coherent.
>
> My point isn't that the fee schedule will change radically but that
> if the policy uses a particular aspect of the fee schedule it may
> find that things work quite differently if the fee schedule does
> change. For that reason I would suggest aiming for a policy that does
> not rely on fees to stimulate or limit demand.
>
>> What I meant is that even if the cost is low, not all the companies
>> will go
>> for this addressing space, but just in case, fee structure should
>> consider
>> this. I guess the questions are should an ISP which is making
>> business pay
>> more for addresses than an enterprise which is using those for its own
>> infrastructure ? Or the other way around ? Should this space
>> considered a
>> luxury and thus need to pay more ? Or is a need and should pay
>> less ? Or
>> should the cost reflect somehow the extra "slot" in the routing
>> tables which
>> in this case is for a single company (while the one for an ISP is
>> for many)
>> and consequently be more expensive ? Should the cost be used to
>> discourage
>> using extra routing slots/addressing blocks when it is a need ?.
>>
>> And of course, we can keep moving on that direction, but it will be a
>> totally different topic and probably scope of the fees WG ...
>
> I think discussion of fees should take place in the Fees WG. I don't
> want to argue for any particular model for the fees, though.
>
>>> I think your goal is to ensure that multi-site enterprise networks
>>> can receive portable address space from APNIC. If that is the case,
>>> maybe it would be useful to ensure that 'site' is less vaguely
>>> defined and change the policy to allow multi-site networks under
>>> common ownership and operation to qualify for an allocation?
>>
>> It depends on what we consider is a multi-site network. A
>> university may be
>> split in many buildings in a single campus, or many buildings in
>> several
>> campuses. I think the policy should cover both cases.
>
> I think you are conflating 'enterprise' and 'site'. I agree that a
> single enterprise might comprise multiple sites. It might be
> appropriate for (some?) multi-site enterprises to receive a /32
> allocation. My concern is that the current definition of 'site' is
> vague and this makes it difficult to amend the policy in the way you
> want. If 'site' is clearly defined it will make it much easier to
> write policy text that is really clear on who qualifies for a /32
> allocation.
>
> Regards,
>
> --
> Leo Vegoda
> IANA Numbers Liaison
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.