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

* Gert Doering

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

[x] yes, this makes sense, go there I think it makes a lot of sense to consolidate all the transfer-related policies in a single document, rather than having mostly redundant/duplicated text scattered around various other documents. In my opinion, this makes the policy more approachable and easy to understand for the casual reader or resource holder [to be]. I've read through the NCC's Impact Analysis and it seems eminently sensible to me - confirming that the entire proposal is for the most part editorial, i.e., causing no major changes to transfer policy. The adjustments that do happen seem non-controversial to me. Remco suggested adding references to the new policy document in lieu of the removed sections in ripe-638, ripe-649, and ripe-655. I would not object to that. Tore

Hi Sascha, The policy proposal states :

2.2 Transfer Restrictions

Scarce resources, which are understood as those resources that are allocated or assigned >by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs), cannot be >transferred for 24 months from the date the resource was received by the resource holder. >This restriction also applies if the resource was received due to a change in the >organisation’s business (such as a merger or acquisition).

Point 2.2 already states what is to be understood by scares resources. All RIPE NCC issued IPv4 and 16bit ASNs. That means indeed as the IA states : PI IPv4 and IPv4 PA space and 16 bit ASNs .. Is there something missing ? Regards, Erik Bais

Op 6 feb. 2016 om 19:57 heeft Sascha Luck [ml] <apwg@c4inet.net> het volgende geschreven:

...

On Sat, Feb 06, 2016 at 02:54:33PM +0100, Tore Anderson wrote: [x] yes, this makes sense, go there

+1 However: I'd like to see a paragraph defining which resources are "scarce resources" That way, it is immediately clear which resources are covered by hold times etc, and more importantly there is a formal process by which a resource is declared "scarce" (through the PDP). The impact statement currently states:

"The RIPE NCC understands "scarce resources" to include IPv4 PA, IPv4 PI and 16-bit AS Numbers. If the community declares other resources to be scarce, the list of resources for which the holding period will apply will be adjusted accordingly."

This needs to be part of the policy to avoid doubt and increase clarity to both NCC personnel and resource holders.

...

Remco suggested adding references to the new policy document in lieu of the removed sections in ripe-638, ripe-649, and ripe-655. I would not object to that.

Sensible addition. rgds, Sascha Luck

On Sat, 6 Feb 2016, Sascha Luck [ml] wrote:

On Sat, Feb 06, 2016 at 08:55:45PM +0100, Erik Bais - A2B Internet wrote:

...

The policy proposal states :

...

2.2 Transfer Restrictions

...

Scarce resources, which are understood as those resources that are allocated or assigned >by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs), cannot be >transferred for 24 months from the date the resource was received by the resource holder. >This restriction also applies if the resource was received due to a change in the organisation???s business (such as a merger or acquisition).

Point 2.2 already states what is to be understood by scares resources. All RIPE NCC issued IPv4 and 16bit ASNs.

In that case, there is a conflict between the proposal and the impact statement. 2.2 seems to suggest that the NCC unilaterally declares a resource "scarce" and the impact statement says the Community does that - presumably through policy. Why not re-word 2.2 to be the authoritative list of "scarce" resources and any additions/rmovals can be done via the PDP?

I agree with Sascha that if we go in this direction the therm "scarce" should be well defined in an authoritative way and also the proces for updating the list. Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm

Hello all, Just before the review phase ends, I'd like to express my agreement with this proposal. [X] yes, this makes sense, go there Keeping all transfer policies in a single document is much more convenient than searching within scattered documents. I also strongly support Remco's suggestion to reference this policy in the other policy documents -- George On Mon, Feb 8, 2016 at 4:17 PM, Erik Bais <erik@bais.name> wrote:

Hi Sascha & Daniel,

The reason for using the term "scares resource", is because we can't/shouldn't use the term "depleted'..

If one would use the term "Depleted' the NCC might say that the pool isn't completely empty yet.. so it isn't depleted yet.. Which would mean that there is, until it is really empty, no transfer restriction. ( that is a different discussion.. )

The community suggested in the last 2 RIPE meetings that the transfer restrictions should not apply for 32 bits ASN and IPv6..

The policy proposal states :

...

2.2 Transfer Restrictions Scarce resources, which are understood as those resources that are allocated or assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs), cannot be transferred for 24 months from the date the resource was received by the resource holder.

The Impact Analyses states :

...

Holding Period for Scarce Resources The RIPE NCC understands “scarce resources” to include IPv4 PA, IPv4 PI and 16-bit AS Numbers. If the community declares other resources to be scarce, the list of resources for which the holding period will apply will be adjusted accordingly.

The policy proposal dictates what a scares resource is (after community discussion in the last 2 RIPE meetings) and it is the policy that is leading here..

The Impact Analyses of the RIPE NCC, is what the RIPE NCC thinks what is written and intended by the policy.. and they are re-hashing what we did and how additional 'future' scares resources might need to be defined in the future.

If the community declares other resources to be scarce, the list of resources for which the holding period will apply will be adjusted accordingly.. And as that is a policy change, it should go through the PDP process.

I think that what you are asking is what is already in the proposal and what you are looking for in a procedure, is already what is the used process ...

If not, what are we missing ?

Regards, Erik Bais

On Wed, Feb 03, 2016 at 07:00:53PM +0100, Gert Doering wrote:

[X] 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)

while I understand the desire, I believe there are better ways to "explain" things to the audience than re-grouping part of the policy documents. A non-normative introductory text on the NCC's website would be one such better way. Generally I'm always nervous when policy/legislation is "streamlined" by "just editorial changes", and also recent experience here would suggest extreme caution. Things get complicated when they are taken out of their respective context (tempus and locus). At least, the work is incomplete as proposed now, simply because the affected policies will have to be re-published with a new number and timestamp, so the (outdated) references will have to be adjusted (this includes evaluation and thus is more than a simple editorial change) and now obsolete text ought to be dealt with accordingly. The necessity to add normative references to a new omnibus document has already been mentioned. -Peter