[arin-ppml] update section 203 proposal
Rudolph Daniel
rudi.daniel at gmail.com
Sun Feb 23 11:50:06 EST 2014
This may seem a stupid question, but since we now want to accept that
accuracy is a principle task of registries, what measure are we to use as
an acceptable measure of an accurate 'whois' or at the macro level, ' an
accurate registry service' ?......% of legacy holders participating on the
registry?
Rudi Daniel
(information technologist)
784 430 9235
On Feb 22, 2014 7:10 PM, <arin-ppml-request at arin.net> wrote:
Send ARIN-PPML mailing list submissions to
arin-ppml at arin.net
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
arin-ppml-request at arin.net
You can reach the person managing the list at
arin-ppml-owner at arin.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Update to Prop 203 (Martin Hannigan)
2. Weekly posting summary for ppml at arin.net (Thomas Narten)
3. ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip Language
(Bill Darte)
4. NANOG 61 - Bellevue - Call For Presentations is open! (Greg Dendy)
5. 2014-2 8.4 Anti-flip Language (Owen DeLong)
----------------------------------------------------------------------
Message: 1
Date: Thu, 20 Feb 2014 14:16:23 -0500
From: Martin Hannigan <hannigan at gmail.com>
To: Public Policy Mailing List <ppml at arin.net>
Subject: [arin-ppml] Update to Prop 203
Message-ID:
<CAMDXq5NhjJANcgctz3YfrRvJuivLSo8Gk0MjP5vAtLP+m1YPiA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Einar,
Please update Section 203 Proposal with:
Problem Statement
The importance of maintaining accurate records in the ARIN database is
recognized as the Registries principal task and is not being debated.
The Registry is unable to responsibly fulfill this task. Many resource
holders are not incented through mutual benefits to participate in the
registry, the process or the community and instead operate
successfully outside of its bounds further hampering the mission of
accuracy.
Intent
To create a sustainable RIPE 605-like environment in the ARIN region that
provides mutual benefits to legacy holders and ARIN and in support of
vastly improved and accurate registry service.
Policy Changes
Section 1, Adds to "Principles"
Accuracy
The principle of Accuracy guarantees stakeholders that all reasonable
and mutually beneficial steps will be take to insure that the Registry
is as accurate as possible.
Fairness
The principle of Fairness guarantees stakeholders that they will be
treated fairly with respect to whatever class of resources they hold,
whether they are pre or post RIR assigned addresses.
Value Add
The principle of Value Add guarantees that the Registry, in its effort
to insure that all of the principles are applied equitably, will seek
to add value to all resource holders regardless of class by insuring
such thing as rapid update functionalities and reasonably easy
transfer administration.
Mutual Benefit
The principle of Mutual Benefit guarantees that ARIN will enter into
or dissolve contracts related to legacy resource holders in like
fashion of comparable Registries.
Section 2, Adds to "Definitions"
Legacy Internet Resource
Any Internet Resource obtained prior to or otherwise outside the
current system of hierarchical distribution (by allocation or
assignment) through the Regional Internet Registries.
Legacy Internet Resource Holder
The holder of a Legacy Internet Resource. Either by receiving these
resources directly or by receiving (part of) Legacy Internet Resources
from a Legacy Internet Resource Holder.
Registry Service Element
In practice, any Legacy Resource Holder actually avails of a subset of
the Registry Services mentioned above. Where it is necessary to
distinguish between the entire class of Registry Services and the
specific Registry Services actually provided in a particular case, the
latter are described as Registry Service Elements.
------------------------------
Message: 2
Date: Fri, 21 Feb 2014 00:53:02 -0500
From: Thomas Narten <narten at us.ibm.com>
To: arin-ppml at arin.net
Subject: [arin-ppml] Weekly posting summary for ppml at arin.net
Message-ID: <201402210553.s1L5r2Sh013158 at rotala.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii
Total of 33 messages in the last 7 days.
script run at: Fri Feb 21 00:53:02 EST 2014
Messages | Bytes | Who
--------+------+--------+----------+------------------------
33.33% | 11 | 22.14% | 102922 | jcurran at arin.net
24.24% | 8 | 18.42% | 85630 | hannigan at gmail.com
9.09% | 3 | 19.83% | 92205 | mlindsey at lb3law.com
9.09% | 3 | 13.33% | 61983 | john.sweeting at twcable.com
6.06% | 2 | 10.25% | 47633 | snoble at sonn.com
6.06% | 2 | 4.30% | 19979 | drc at virtualized.org
3.03% | 1 | 3.65% | 16949 | scottleibrand at gmail.com
3.03% | 1 | 3.35% | 15553 | keith at jcc.com
3.03% | 1 | 3.06% | 14222 | sryerse at eclipse-networks.com
3.03% | 1 | 1.68% | 7822 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% | 33 |100.00% | 464898 | Total
------------------------------
Message: 3
Date: Fri, 21 Feb 2014 10:53:12 -0600
From: Bill Darte <billdarte at gmail.com>
To: "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
Language
Message-ID:
<CAMApp34bqyS=uQETQXsabBsO16x+TLz2qZfCMU+9WDkjFcmkkA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
At the Advisory Council's meeting of Feb 20, discussion about Draft Policy
2014-2 concluded that there is a real issue with transfer restrictions of
address blocks between RIR jurisdictions for organizations having received
a different block of addresses from ARIN within the last 12 months (per
existing policy).
The current Draft Policy language is as follows with only the last sentence
being added from what is current ARIN policy:
"Source entities within the ARIN region must not have received a transfer,
allocation, or assignment of IPv4 number resources from ARIN for the 12
months prior to the approval of a transfer request. This restriction does
not include M&A transfers. Restrictions related to recent receipt of blocks
shall not apply to inter-RIR transfers within the same organization and its
subsidiaries."
The last sentence of this language was added to mitigate the problems
related by the author in the problem statement and from experience. The
author supported this change, however, some concern has been expressed on
the PPML and within the AC about the possibility of 'rinse and repeat'
abuse associated with the ease of establishing new subsidiaries and using
those transfers to get around the restrictions of the existing transfer
policy.
Three alternatives were primarily discussed and I wish to elicit feedback
from the community relative to each.
1. Use the existing last sentence as is and ask ARIN staff to be
particularly watchful for seeming abuse and to bring such back to the
community through regular Policy Experience Reports. There was discussion
about this option suggesting that by the time abuse was recognized and
reported, and given limited existing free pool stocks and the extended
policy development cycle....this option may be moot.
2. Remove the clause 'and its subsidiaries' or modify it in such a way as
to mitigate the risk of a laundering of addresses through fraudulent
transfers, but this may still potentially limit the utility to
organizations who may have complex organizational structures in use
internationally.
3. Take an alternative tack and simply restrict transfers on a per-block
rather than a per-organization basis. e.g. 'No block acquired within the
past 24 months would be eligible for transfer.' (The time frame is of
course an arbitrary number at this point.)
If you believe this Draft Policy is improved most significantly by one of
the above alternatives, or through another alternative you can pose....I,
and the community would benefit from your input. Thanks,
Bill Darte
Policy Shepherd for 2014-2 and
Advisory Council member
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.arin.net/pipermail/arin-ppml/attachments/20140221/77d17c87/attachment-0001.html
>
------------------------------
Message: 4
Date: Fri, 21 Feb 2014 21:20:54 -0800
From: Greg Dendy <gdendy at equinix.com>
To: "North American Network Operators' Group" <nanog at nanog.org>,
"nanog-announce at nanog.org" <nanog-announce at nanog.org>,
"arin-ppml at arin.net" <arin-ppml at arin.net>, "ripe-list at ripe.net"
<ripe-list at ripe.net>
Cc: NANOG Program Committee <nanogpc at nanog.org>, "board at nanog.org"
<board at nanog.org>
Subject: [arin-ppml] NANOG 61 - Bellevue - Call For Presentations is
open!
Message-ID: <5A388661-CDD4-4146-9F99-9EFD1ACAE3AE at equinix.com>
Content-Type: text/plain; charset="windows-1252"
NANOG Community-
I hope everyone enjoyed NANOG 60, NANOG?s largest attended winter meeting.
Fresh off a great meeting, and post our NANOG Icelanta Reception, we are
ready start the process for NANOG 61 in Bellevue. NANOG 61 will be NANOG?s
20th year serving the network operator community and helping to make the
Internet better. If you have a topic you'd like to speak about, the
program committee would love to consider it. Please read
http://www.nanog.org/meetings/nanog61/callforpresentations for more
information.
We will continue with the Monday-Wednesday format, with Tracks on Monday
and Wednesday afternoons and Tutorials to be scheduled on Tuesday morning.
The program will begin on Monday morning at 10:00AM followed by our
popular Newcomers Lunch. The exact schedule layout can be found at
http://www.nanog.org/meetings/nanog60/preagenda, please take this into
account as you plan travel. If you wish to submit a presentation, please
keep these important dates in mind:
* Presentation Abstracts and Draft Slides Due: April 7, 2014
* Slides Due:
May 5, 2014
* Topic List Posted:
April 21, 2014
* Agenda Published:
May 12, 2014
Please submit your materials to http://pc.nanog.org<http://pc.nanog.org/>.
Looking forward to seeing everyone in Bellevue!
Thanks,
Greg Dendy
Chair, NANOG Program Committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.arin.net/pipermail/arin-ppml/attachments/20140221/e08292a6/attachment-0001.html
>
------------------------------
Message: 5
Date: Sat, 22 Feb 2014 15:06:22 -0800
From: Owen DeLong <owen at delong.com>
To: ARIN-PPML List <arin-ppml at arin.net>
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
Message-ID: <2CB940E2-1465-4FED-A6F3-7172849A90EA at delong.com>
Content-Type: text/plain; charset="windows-1252"
Several options are being discussed regarding this proposal:
1. Use the existing last sentence as is and ask ARIN staff to be
particularly watchful for seeming abuse and to bring such back to the
community through regular Policy Experience Reports. There was discussion
about this option suggesting that by the time abuse was recognized and
reported, and given limited existing free pool stocks and the extended
policy development cycle....this option is mute.
2. Remove the clause 'and its subsidiaries' and or modify it in such a way
as to mitigate the risk of a laundering of addresses through fraudulent
transfers, but potentially limit the utility of organizations who may have
complex organizations structures in use internationally.
3. Take an alternative tack and simply restrict the Inter-RIR re-org
transfer of the 'recently issued block' only, allowing other existing
blocks to be transferred without restriction by recent block acquisition.
This alternative seems to have been expressed and supported in the recent
Atlanta Public Policy Consultation.
It is my opinion that option 3 is perilous in that it allows a large
resource holder to sell off their address space out of region while
backfilling from the ARIN free pool.
As such, I am much more comfortable with option 2. One set of language that
was suggested which I like is:
??subsidiaries having been operational for a minimum of 18 months.?
While this might not prevent all possible subsidiary-based rinse-repeat
abuse scenarios, it would at least prevent the obvious subsidiary created
for this purpose scenario and certainly provides better protections than
proposal number 3.
I think option 1 is probably an unfair burden for the ARIN staff and makes
policy vague in a way that would be difficult, if not impossible, to
reliably enforce and may be even harder to defend in the event of
litigation. This is strictly my own opinion as a member of the community
and I have not discussed the matter with legal council or even the other
members of the AC.
Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.arin.net/pipermail/arin-ppml/attachments/20140222/ebff8f89/attachment.html
>
------------------------------
_______________________________________________
ARIN-PPML mailing list
ARIN-PPML at arin.net
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 104, Issue 41
******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140223/8a1e01a5/attachment.htm>
More information about the ARIN-PPML
mailing list