Send ARIN-PPML mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Re: Against 2013-4 (John Osmon)
2. Re: Against 2013-4 (John Curran)
3. Re: Against 2013-4 (William Herrin)
4. Re: Against 2013-4 (Steven Ryerse)
5. Re: Against 2013-4 (William Herrin)
----------------------------------------------------------------------
Message: 1
Date: Mon, 3 Jun 2013 14:24:48 -0600
From: John Osmon <[email protected]>
To: Milton L Mueller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Mon, Jun 03, 2013 at 02:51:01PM +0000, Milton L Mueller wrote:
[... needs based assessments have always been used...]
> No, I challenge this on a factual basis. The main legacy holders from
> the mid-1980s - MIT, GE, the military, etc. - were not subject to
> needs assessments as we use that term today.
> If they were, you have to explain how MIT and a few others have ended
> up giving back large chunks, effectively admitting that they did not
> need them? If they did not need them, how did they get them? This is
> probably not a very fruitful argument in that it is not
> forward-looking, but I do want to make it clear that claims that "we
> have always done it this way" are just false.
When (say) MIT asked for space, Class B was too small their needs and
Class A was the only larger size available. They didn't request a /8,
they requested a netblock that fit their needs and got a Class A. The
needs assessment at the time was simply different.
Just because CIDR allowed us to dole out netblocks in a more
conservative fashion doesn't mean need wasn't a factor when early
adopters got large blocks.
------------------------------
Message: 2
Date: Mon, 3 Jun 2013 20:38:13 +0000
From: John Curran <[email protected]>
To: Jason Schiller <[email protected]>
Cc: "[email protected] List" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
On Jun 3, 2013, at 1:58 PM, Jason Schiller
<[email protected]<mailto:[email protected]>> wrote:
The point of this policy is to preserve our principles of stewardship. Up until
now,
the source of these principles has been RFC 2050. Many things reference it
and it's principles when considering stewardship.
If RFC 205bis passes, all of the stewardship language will be deprecated.
This policy attempts to take those principles and place them in the NRPM.
Jason -
RFC 2050 contained both "goals" (Conservation, Routability, Registration)
and "allocation guidelines"... You have taken components of both "goals"
and "allocation guidelines" and put them together into a set of RIR
principles.
Given that we know that much of the "allocation guidelines" section has
been overtaken by community-based policy in each of the regions, it is a
valid question as to whether any language from the "allocation guidelines"
section should now suddenly be brought forward 15 years and made into
current policy in the region as "RIR Principles".
My attempt was not to be backwards looking, nor to revert current policy to
what it was in 1996. In theory these principles have and continue to guide
our policy making, and are still true, so we can simply copy them over.
Note that RFC2050bis still contains Goals for the Internet Number Registry
System <http://www.ietf.org/id/draft-housley-rfc2050bis-01.txt>, and these
include Allocation Pool Management, Hierarchical Allocation, and
Registration
Accuracy, so it is not necessary to have a draft policy if the RIR
Principles
that you are are covered by these goals.
I made a conscious effort minimize modernizing the policy and believe I
did so only where the language we use has clarified the principle and is
consistent with current ARIN policy and operations.
The thought here was to not change the status quo, and simply document
what is the already agreed upon basis of the current state of things.
The problem is that in some cases policy and practice has evolved
beyond the current RFC 2050 language, and based on some
interpretations conflicts with these principles.
I believe any conflicts are the result of incorporating "allocation policy"
from 15 years ago into your RIR principles, and that debate on what
additional principles (if any) are needed for the ARIN registry is indeed
a reasonable discussion for this mailing list independent of language
in the draft policy.
Should ARIN policy and operations be changed to match the principle?
(Did we make a wrong term and abandon a principle we should not have?)
Should the principle be modified to make holes for the ARIN practice?
(The principle is true, but it doesn't apply here due to this history)
Should the principle be documented as is, but ARIN to continue its practice
unchanged? (this is what we have now with the current state of RFC 2050)
I am unaware of any conflict between the three goals in RFC 2050
(Conservation, Routability, Registration) and ARIN's existing policies
and practices. I am also unaware of any conflict in the proposed
RFC2050bis Goals and ARIN's existing policies and practices.
These questions can only be answered once the staff assessment is complete,
and we understand to what extent this draft policy could influence current
ARIN policy and operations.
We will perform a staff assessment to determine what conflicts with existing
practices would be created by adoption of the draft policy. It is likely
that
any such conflicts are result of language from the "allocation guidelines"
portion of the RFC2050 which is being refreshed as "RIR Principles" via
the draft policy.
FYI,
/John
John Curran
President and CEO
ARIN
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130603/323b3a51/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 3 Jun 2013 16:45:19 -0400
From: William Herrin <[email protected]>
To: Jason Schiller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID:
<cap-gugw3ugvinfxuo6_+scwse3oapudvmhrhnveac5jt0jt...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Jun 3, 2013 at 2:58 PM, Jason Schiller <[email protected]> wrote:
> What we need at this point is a high level discussion, about the general
> direction.
Hi Jason,
Agreed.
> I'm not sure a discussion of merits of needs based allocation / assignment
> is useful at this point in the discussion.
>
> Neither is it helpful to discuss alternate flavors of
> conservation at this time.
Disagree. We have to decide whether these are core on ancillary. As
written they're a part of the high-level principles. I don't think
they belong there.
> I made a conscious effort minimize modernizing the policy and believe I
> did so only where the language we use has clarified the principle and is
> consistent with current ARIN policy and operations.
> The thought here
> was to not change the status quo, and simply document what is the
> already agreed upon basis of the current state of things.
That's exactly the problem. If we don't want to change the status quo
then we can't start from RFC 2050 because we've moved way beyond it
and are on the precipice of moving far further.
> Should ARIN policy and operations be changed to match the principle?
> (Did we make a wrong term and abandon a principle we should not have?)
In time. The principles should apply to new policy as we find it
needful to write.
> Should the principle be modified to make holes for the ARIN practice?
> (The principle is true, but it doesn't apply here due to this history)
If we get the principles right then there shouldn't be any holes that
we actively want to preserve. The presence of a hole highlights an
error in the proposed principles.
Take Legacy Registrants for example. Are they a hole in the
principles? Or is the principle missing or miswritten? Why isn't the
principle, "We leave the early adoption registrations alone until they
change."
Regards,
Bill Herrin
--
William D. Herrin ................ [email protected] [email protected]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
------------------------------
Message: 4
Date: Mon, 3 Jun 2013 20:45:19 +0000
From: Steven Ryerse <[email protected]>
To: John Curran <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID:
<5b9e90747fa2974d91a54fcfa1b8ad120135e72...@eni-mail.eclipse-networks.com>
Content-Type: text/plain; charset="utf-8"
I wouldn't begin to know what terms a Legacy Allocation has been
sold/transferred with outside of ARIN. I don't know anything about this
auction site other than it exists and I have not researched it or contacted
them.
http://www.hilcobid.net/auction/listOffers.htm?auction_id=13186&elementsPerPage=25#barranavegacaoleilao
I do know that I have received offers to purchase Legacy Allocations outside of
ARIN.
Steven L Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
770.656.1460 - Cell
770.399.9099 - Office
770.392-0076 - Fax
? Eclipse Networks, Inc.
??????? Conquering Complex Networks?
-----Original Message-----
From: John Curran [mailto:[email protected]]
Sent: Monday, June 03, 2013 3:57 PM
To: Steven Ryerse
Cc: Milton L Mueller; Owen DeLong; [email protected]
Subject: Re: [arin-ppml] Against 2013-4
On Jun 3, 2013, at 2:37 PM, Steven Ryerse <[email protected]> wrote:
> Some just decide to go around "this community" and skip ARIN altogether and
> purchase their IPv4 needs from a third party or a broker like this site does
> http://www.hilcobid.net/auction/listOffers.htm?auction_id=13186&elementsPerPage=25#barranavegacaoleilao
> .
Steven -
Note that your example is a broker whom to the best of my knowledge requires
the applicable RIR to approve any transfer -
"? Sale subject to approval of applicable Regional Internet Registries (ARIN,
APNIC or RIPE NCC)."
So that is not actually a case of going around "this community" as much as it
is working to successfully utilize the transfer policies developed and adopted
by this community.
(I have no view on the draft policy under discussion, and am providing this
information solely for accuracy of the community discussion of same.)
FYI,
/John
John Curran
President and CEO
ARIN
------------------------------
Message: 5
Date: Mon, 3 Jun 2013 16:52:39 -0400
From: William Herrin <[email protected]>
To: John Osmon <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID:
<CAP-guGWCmn+wduZ=zotzFiJxcDn5O0vya0nZ=tjdckxhdgc...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Jun 3, 2013 at 4:24 PM, John Osmon <[email protected]> wrote:
> When (say) MIT asked for space, Class B was too small their needs and
> Class A was the only larger size available. They didn't request a /8,
> they requested a netblock that fit their needs and got a Class A. The
> needs assessment at the time was simply different.
Hi John,
Not exactly. IIRC (and the old fogies are free to correct me here) the
predecessor to IPv4 had exactly 256 addresses. When IPv4 was deployed,
each prior user was automatically assigned the /8 corresponding to
their prior address. MIT is one of the organizations which had a
computer using the prior Internet protocol, so they automatically
received a /8.
Very few /8's were assigned after that. Anybody who wanted more than a
class B received multiple class B's, not a class A.
Regards,
Bill Herrin
--
William D. Herrin ................ [email protected] [email protected]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 96, Issue 8
****************************************
