[Apwg-ipv6-papi] The Picture / Re: first draft?

[Elvis Velea]

Hi Sander,

please see my comments inline:

On 8/12/13 4:07 PM, Sander Steffann wrote:
[...]
>> There are still some open questions/comments:
>>
>> 1. To which WG should we send the policy proposal? AP-WG or IPv6-WG?
>
> This belongs in APWG.

ok

>
>> 2. What should be the rationale? I haven't yet compiled these.
>
> I think it should boil down to: 'IP addresses are just numbers. Creating different flavours/colours/types of addresses creates problems because reality never completely aligns with the (fictional) types created by policy. And even if it does align today future developments (either in technology or in business structure) will cause mis-alignment again.'
>

ok

any rationale against it?

what about:

- if this is accepted, the organisations that can receive a /32 (or 
larger) allocations via a Sponsoring LIR will no longer see an incentive 
to become an LIR

>> 3. Is it ok to consider that everyone who makes an allocation is an IR?
>
> I'm not happy with the distinction between Allocate and Assign in the current text. It creates different colours again. If my ISP assigns addresses to me and I want to host my cousins server in my address space then I violate the policy as that would be a (very small) sub-assignment. The whole idea of the PAPI proposal was to fix this.
>

true, but the RIPE NCC has always considered assigned address space as 
in use, (sub-)allocated address space is only considered to be used if 
assignments/aggregations are registered within.

An additional problem I would see, if we remove the differences, is.. 
what if an LIR makes an allocation to a customer. How to calculate the 
HD-ratio if not by looking at which assignments/aggregations are 
registered within?

If your ISP assigns address space to you and you need to host a server, 
you can ask him to change the status of the address space to 
sub-allocated and then you can make assignments, one to yourself and one 
to your cousin.

>> 4. Is it ok to consider that an LIR should not make a sub-allocation
>> smaller than /48?
>
> I think this is a bad idea. The operator decides on how to run his network, and introducing artificial limits should only be done as a last resort.

the idea, as far as I understand, is to try "not to encourage assignment 
of /64 or single addresses to end users".

If an LIR sub-allocates something something smaller than a /48.. let's 
say a /56, and then the customer starts assigning a /64, then we will 
not reach this goal.

I was thinking that if someone needs to sub-allocate, a /48 should be 
the minimum.

Let's continue the discussion and if you still think this limit should 
be removed, I'll gladly remove it :)

>
>> 5. Is it ok to request LIRs that make sub-allocations bigger than /32 to
>> send a request to the RIPE NCC for approval?
>
> That is ok, but explain the reasons.

Well, if an LIR makes a sub-allocation larger than a /32, then I think 
the RIPE NCC should be the one approving the request. If an organisation 
needs an allocation larger than a /32 (64K /48s), then I think that an 
evaluation should be made.

>
>> 6. Is the definition of a Sponsoring LIR good enough?
>
> I see some issues. What about: "Members of the RIPE NCC (LIRs) can request portable address space on behalf of third parties. The RIPE NCC allocates resources directly to the third party. The role of the LIR is to facilitate the administrative processes and to maintain a link between the RIPE NCC and the third party that holds the resources. An LIR fulfilling this role is called the Sponsoring LIR for the third party. Third parties can choose another LIR to be their sponsoring LIR at any time."
>

sounds good, I've updated the text.

>> 7. Can someone come up with a better definition of an end-site?
>
> Not me :-)
>

ok

>> 8. Is it ok to have all the information required for registration in the
>> registration goal?
>
> No. The goal should describe "why" not "how"

I see, I'll try to keep the goal simple and include the registration 
requirement in the policy text.

>
>> 9. Is it ok to have a minimum allocation of a /32? For both LIRs and the
>> customers that previously used to receive a PI assignment?
>
> No, if someone only needs a /48 they should be able to get it.

ok, can you have a look at 5.1.2 in the policy proposal text and see if 
it makes sense?

Minimum allocation is a /32 and the NCC can make /48s upon request.

>
>> 10. Is it ok to specifically mention in the policy that current PI
>> holders can extend their /48 PI assignment/now allocation (upon request)
>> to a /32 and where this is not possible, they can return the /48 and
>> receive a /32 instead?
>
> I wouldn't limit the text to current holders. Try to keep it generic.

ok, I'll work on re-writing this part.

>
>> 11. In the 10th paragraph, ATTRIBUTION, next to those mentioned by
>> Emilio in the CSP document, I've also added the three of us working
>> currently at the policy proposal.
>> Olaf and Daniel, if you do not want to be mentioned, please delete
>> yourselves from the document.
>> Emilio - I suppose it's fine to mention ourselves in that paragraph.
>
> I think that that is the idea of that section :-)

:)

>
>> Looking forward to your feedback.
>
>
> Thanks for all the hard work!
>
> Cheers,
> Sander
>

cheers,
elvis