[address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies)

Hi all,

(all hats off)

While I am highly sympathetic to harmonising transfer policies across all resources, I object to the proposal as written.

The really short reason is as follows (and I quote)

[The following policy will replace:

- Sections 5.5 and 6.4 in ripe-649, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"
- Section 4.0 in ripe-638, "Autonomous System (AS) Number Assignment Policies"
- Section 8. in ripe-655, "IPv6 Address Allocation and Assignment Policy"
- ripe-644, "Policy for Inter-RIR Transfers of Internet Resources"

Accordingly, these sections or policy documents will be deleted.]

(end quote)

Up until this policy proposal, the structure of RIPE policy documents has always been very much resource aligned, not process aligned. There's a document for IPv4, for IPv6, for ASNs. This policy proposal changes that structure in a material way, and inadvertently creates a matrix of resource-oriented and activity-oriented policies, in an attempt to harmonise and simplify.

While laudable goals, this matrix created the loophole I discovered in the previous version of the policy text, and the fix to that loophole in this version is to remove most of the simplification that was introduced. This is in my opinion inherent to a matrix structure for policies, and while I can't find a new loophole in this text right now, we'll introduce the risk for similar-sized loopholes in all future policy proposals. The one in this proposal was caught. We're likely to miss others.

So what's left is policy harmonisation between resources. I don't think that warrants restructuring our policies.

Of course, we've already had activity-oriented policies (the inter-RIR one, mergers and closures, resources for the RIPE NCC) but those were in very specific, well-defined areas that didn't stipulate specific requirements for resources, which is where the loophole potential comes in.

I'd be much more in favour of taking the proposed policy text, and merge it into the various existing resource policies instead of creating a separate document. If we DO keep it as a separate document, I must insist that instead of removing sections from other policy documents altogether, reference is made to this new policy instead.

On a broader scale, perhaps it's time to look at the structure of RIPE policy as a whole. The problem is, I don't have a clue where that discussion belongs, and whether even the PDP applies to that kind of discussion :)

Kind regards,

Remco


> On 03 Feb 2016, at 19:00 , Gert Doering <gert at space.net> wrote:
> 
> Dear Working Group,
> 
> On Wed, Feb 03, 2016 at 02:59:06PM +0100, Marco Schmidt wrote:
>> The draft documents for version 3.0 of the policy proposal 2015-04,
>> "RIPE Resource Transfer Policies"
>> have now been published, along with an impact analysis conducted by the
>> RIPE NCC.
> 
> So this is the impact analysis you have been waiting for :-)
> 
> Please read, think about, and comment
> 
> [ ] yes, this makes sense, go there
> [ ] I agree with the general direction of having a single document, but
>     I disagree with changing _______________, because...
> [ ] I think we should be organizing this differently, and totally not
>     group the policy documents "by activity" but "by resource" (= transfer
>     policy section in the IPv4, IPv6 and AS number policy documents)
> 
> Gert Doering
>        -- APWG chair
> --
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160203/2ca28885/attachment.sig>