[address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy)

Hi Leo,

See below.

Regards,
Jordi




> De: Leo Vegoda <leo.vegoda at icann.org>
> Responder a: <address-policy-wg-admin at ripe.net>
> Fecha: Thu, 21 Jun 2007 21:51:04 +0200
> Para: <jordi.palet at consulintel.es>
> CC: <address-policy-wg at ripe.net>
> Asunto: Re: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address
> Allocation and Assignment Policy)
> 
> Hi Jordi,
> 
> On 21 Jun 2007, at 7:38am, JORDI PALET MARTINEZ wrote:
>> 
>> We are talking about two different things/cases.
>> 
>> Both proposals may seem as related, but actually they are not.
>> 
>> In fact, we can't relate both policy proposals also, because it is
>> not clear
>> that 2006-01 will go further (at least not with the actual text), as I
>> didn't got inputs to my last replies to previous inputs :-( So it is
>> difficult for me to keep going w/o community review.
> 
> 2006-01 seems to have had a couple of dozen comments on it over the
> last month, actually. Are you referring to something else?

I posted some answers to the 2006-1 comments, but never got them replied
back (I will check again in case I'm missing anything).

> 
>> 2006-02 is intended for entities that have their own network with
>> multiple
>> sites.
> 
> I think the intention makes sense but the phrasing of the policy text
> needs some work.
> 
> It looks like you want an end site to qualify for a /32 IPv6
> allocation if it needs to make *any* size of assignment to multiple
> internal sites. But the text doesn't actually define what one of
> these internal sites is. That creates a problem for anyone that wants
> one of these /32 allocations because they can't work out if they
> qualify for it or ought to try and get a /47 (or whatever) under the
> IPv6 PI policy.

We can't base this policy proposal in the existence of the IPv6 PI one,
because it is not the case.

Also, I'm not modifying the way hostsmasters will evaluate the need. If this
needs to be fine tuned, my view is that should be done in an alternative
proposal (we already discussed in this list about this point before the last
call, and I believe the consensus was "let's move ahead and if we need to
improve it, let's make it in further reviews").

> 
> If the policy text is confusing it's going to create lots of extra
> work for the requesters and the RIPE NCC.

I don't really think it is the case. It will be the same right now for
anyone, requesting space because "plan for 200 sites" is basically a lie. We
have removed this in other regions, I don't see why we are still willing to
set a new barrier, which may become artificial again.

> 
>> Those sites behave as end-sites to the "internal" ISP. This is for
>> example the case of Universities, or NATO (just to mention a clear
>> case)
>> that already have indicated in the list their need. I don't see
>> those as PI
>> cases, because they are by their own real ISPs, even if for the
>> same entity,
>> they have their own NOC, staff, etc. to manage the network.
>> 
>> Instead 2006-01 is looking for PI cases, for example a data center.
>> 
>> So I don't see the need to stop 2006-02, and what it is really
>> needed is to
>> get more input on 2006-01 !
> 
> I think the issue still remains: 2006-01 and 2006-02 need to work
> together closely. Presumably, a network that does not qualify for a /
> 47 should not qualify to receive a /32. Or should it?

It is not a matter of the size of the prefix. It is a matter of
understanding if we are talking about an ISP or something different. An ISP,
even if it is an ISP for a specific organization (one that has several sites
and consequently need to assign space to them), requires PA. The other cases
requires PI.

> 
> If it should not then how does this policy text ensure that? Because
> as far as I can tell there isn't a good definition of what one of
> these 'final' sites is, so anyone can claim that every /64 in their
> internal network is a site and get a /32 allocation.

Same as today. I still believe we should move ahead, and if required improve
it in following cycles, not be stuck forever.

> 
> 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.