<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Sandra,<br>
    <br>
    I see that the status of this proposal on the RIPE website is
    "Awaiting Decision from Proposer". The status has not changed since
    02 July 2014 :)<br>
    <br>
    Do you have any updates on this policy proposal?<br>
    <br>
    @WG-chairs - is this proposal frozen now, waiting the result of
    2014-02 or will it move to the next PDP step anytime soon?<br>
    <br>
    Kind regards,<br>
    Elvis<br>
    <br>
    <meta charset="utf-8">
    <meta charset="utf-8">
    <div class="moz-cite-prefix">On 23/06/14 23:02,
      <a class="moz-txt-link-abbreviated" href="mailto:sandrabrown@ipv4marketgroup.com">sandrabrown@ipv4marketgroup.com</a> wrote:<br>
    </div>
    <blockquote
cite="mid:20140623060243.ec289651d84890fcbef5f195936e1217.161ac2a47c.wbe@email17.secureserver.net"
      type="cite">
      <pre wrap="">
Tore, Thanks for your feedback.  See below for comments.

From: Tore Anderson <a class="moz-txt-link-rfc2396E" href="mailto:tore@fud.no"><tore@fud.no></a>
Subject: Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy
 for Inter-RIR Transfers of Internet Resources)
To: <a class="moz-txt-link-abbreviated" href="mailto:address-policy-wg@ripe.net">address-policy-wg@ripe.net</a>
Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:53A7ECB6.60108@fud.no"><53A7ECB6.60108@fud.no></a>
Content-Type: text/plain; charset=ISO-8859-1


I like it, overall. Clearly there are a few who are interested in
engaging in inter-RIR transfers, and if we can facilitate for this
without imposing any cost or burden on those who are not interested, I
can see no reason to not do this.

With regards to the proposals second argument against (regarding the
re-introduction of "need" if another RIR insists), I do not consider
that to be problematic at all, as it would be a burden that would be
borne in its entirety by the entity voluntarily taking part in a
transfer involving a "needy" RIR.

I have some comments/suggested improvements though:

1) I concur with other posters that the use of ?LIR? should be avoided.
However, I'd also like to add that suggested replacement ?organisation?
could potentially also be problematic, as a resource holder could be a
natural person rather than an organisation. It would be preferable to
avoid getting in a situation where non-organsation resource holders
would be prevented from engaging in inter-RIR transfers even though the
resource-specific policy would allow for that.

Therefore I would suggest using even more general language, such as
?resource holder?/?resource holder to be? or ?entity?.


**** I think this is a very good point, thanks.  Sandra

2) The proposal seeks to add the following paragraphs to ripe-606
section 5.5:

?When Internet number resources are transferred to another RIR, the RIPE
NCC will work with the destination RIR to allow the transfer to the
receiving LIR.

When Internet number resources are transferred from another RIR, the
RIPE NCC will work with its member LIR to fulfil any requirements of the
sending RIR.?

These additions seem completely redundant to me, as the new policy
document says pretty much the same thing in sections 2.0 and 3.0.

(Also, ?fulfill? is incorrectly spelled.)

*** Thanks for pointing out this redundancy issue.
*** Let me look into it with Marco and the Chairs, as to whether we
*** would add the text or were making a statement of fact.
*** Agree on spelling of fulfill.  Thanks. Sandra

3) Also in ripe-606 section 5.5 the proposal seeks to add the following:

?If resources are transferred as legacy resources, the RIPE NCC will
apply the legacy policy when accepting these resources.?

This statement seems out of place to me:

* ripe-606 does not apply to legacy resources, a fact which is implied
by the new paragraph as well. The statement therefore voids itself.

* Even if disregarding the above, ripe-606 only covers IPv4. Legacy
resources also include ASNs. So if the resource is to be transferred is
a legacy ASN, this transfer would be regulated by a piece of policy text
located in the non-legacy IPv4 policy....which would to me be a
completely nonsensical outcome.

IMHO, the only sensible place to locate a statement that essentially
says "legacy resources are governed by the legacy policy" is in, you
guessed it, the legacy policy itself (ripe-605). We're in luck, because
it already does just that. :-)

*** I am not sure we will add that statement to the policy or if it is
*** just a statement of fact:  that legacy policy will apply, as you
say.
*** Let me check with Marco, as what you say makes total sense to 
*** me.  Sandra

So in summary, all of the additions 2014-05 seeks to do in ripe-605 seem
redundant or out of place to me, accomplishing no actual policy change
beyond adding bloat. Am I missing something? If not, I'd much rather
prefer that ripe-605 is left alone by 2014-05.

*** Yes the intention is not to add bloat but perhaps to re-confirm what

*** is already there.  Thanks a ton for your feedback, and of course for
*** your support for the intent.

*** Sandra

Tore



End of address-policy-wg Digest, Vol 34, Issue 15
*************************************************

</pre>
    </blockquote>
    <br>
  </body>
</html>