في الثلاثاء، ١٨ أغسطس، ٢٠١٥, <address-policy-wg-request@ripe.net> كتب:
Send address-policy-wg mailing list submissions to address-policy-wg@ripe.net <javascript:;>
To subscribe or unsubscribe via the World Wide Web, visit https://www.ripe.net/mailman/listinfo/address-policy-wg or, via email, send a message with subject or body 'help' to address-policy-wg-request@ripe.net <javascript:;>
You can reach the person managing the list at address-policy-wg-owner@ripe.net <javascript:;>
When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..."
Today's Topics:
1. Re: 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) (Jan Ingvoldstad)
----------------------------------------------------------------------
Message: 1 Date: Mon, 17 Aug 2015 18:26:30 +0200 From: Jan Ingvoldstad <frettled@gmail.com <javascript:;>> To: Address Policy Working Group <address-policy-wg@ripe.net <javascript:;>> Subject: Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) Message-ID: < CAEffzkzzpKA1aqUtUzESDJpLggLbOUdfMhaETmStDcRddPmUjg@mail.gmail.com <javascript:;>> Content-Type: text/plain; charset="utf-8"
On Fri, Aug 14, 2015 at 12:17 PM, James Blessing < james.blessing@despres.co.uk <javascript:;>> wrote:
On 14 August 2015 at 10:54, Marco Schmidt <mschmidt@ripe.net <javascript:;>> wrote:
Thanks for putting in the time and effort, Erik!
Couple of questions/comments...
From 1.0
Shouldn't the scope be explicit as to what is/isn't included
I agree that this would help.
From 2.1
"Transfers can be on a permanent or non-permanent basis."
How is this going to be recorded and managed within the context of reflecting it being a non-permanent transfer?
Wouldn't that be up to the RIPE NCC?
From 2.2
"assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs)"
Rather than "such as" this needs to be a definitive list of what is classed as a restricted resource
I concur, but I don't think it should be listed in the same document.
My first thought is that this list should be maintained by the RIPE NCC.
Keeping that list in a separate document means changing fewer documents when policy changes, or reality reaches a pre-set limit set in policy.
That separate list should reference the policy documents enabling the restrictions.
From 3.1
Again a list of conditions or references to policies that impose restrictions needed
I'm a bit confused both by the point and by your response to it, maybe I'm just tired, but I think both could be clearer. :)
From 4.0
M&A process is mentioned, should there be other references to this? Especially as M&A (as I understand it) allows 2.2 to be overridden
"The document proposes to include the transfer restrictions to mergers and acquisitions. This is done to make the policy more in line with the intention of the transfer policy restrictions when proposed."
General
- As this is about transfers should this also cover returning resources to ripe NCC so all types of transfers be included
I'm not sure that this would be useful, but 2015-04 could 1) include a reference to the policy for that, and 2) make it even clearer that this is a document for transfers between resource holders.
I don't think it's useful to consider the RIR a resource holder in this context.
- broadly support the unification of transfer policy into a single
document, just things bits are missing or muddy
Agreed, but the document is largely clarifying more than muddying, IMHO. -- Jan