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 (Jason Schiller)
2. Re: Against 2013-4 (Bill Darte)
3. Re: Against 2013-4 (David Farmer)
----------------------------------------------------------------------
Message: 1
Date: Mon, 3 Jun 2013 17:01:02 -0400
From: Jason Schiller <[email protected]>
To: William Herrin <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID:
<cac4yj2v1sz1_bofpxq1xcghynruaj1qjrk6eusdeuazgngd...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Bill,
I think I see the crux of the issue here.
If people want to throw out the current principles of stewardship,
and create a new set of principles that are better than the ones
we already have (maybe we got it wrong the first time), I support
that, and wish you the best of luck, but believe this to be a very
contentious and difficult to make progress.
I am trying to simply document our current stewardship principles,
and have mostly lifted text from RFC 2050, the NRPM and the
PDP, such that these guiding ideas do not get lost if RFC 2050
is deprecated.
Maybe a better way to phrase this question is:
If this draft policy is passed, what changes to the current ARIN
practices do you oppose?
___Jason
On Mon, Jun 3, 2013 at 4:45 PM, William Herrin <[email protected]> wrote:
> 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
>
--
_______________________________________________________
Jason Schiller|NetOps|[email protected]|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130603/8fef20f4/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 3 Jun 2013 17:32:48 -0500
From: Bill Darte <[email protected]>
To: Jason Schiller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID:
<camapp35zl1txku8jqyqvosjuofyms0ra5-do_uaqksjik7g...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I think the experience prior to 2050 is mute. I believe that 2050 is out
of date. I think this conversation is exactly the conversation that need
be engaged around this Draft Policy and around the subject of new needs
basis. I do wish to point out that all of the current NRPM policy has been
created by the broader community and changing the needs-basis of IP address
allocations/assignments means gaining a community consensus for this
through the Policy Development Process.
Simply saying there is no longer community support for this principle seems
insupportable by the overwhelming and continuing support shown in the
policy development process since at least 1997. I detect no similar
support in opposition. But, I'm hopeful that those supporting both
positions speak on the subject.
bd
On Mon, Jun 3, 2013 at 4:01 PM, Jason Schiller <[email protected]> wrote:
> Bill,
>
> I think I see the crux of the issue here.
>
> If people want to throw out the current principles of stewardship,
> and create a new set of principles that are better than the ones
> we already have (maybe we got it wrong the first time), I support
> that, and wish you the best of luck, but believe this to be a very
> contentious and difficult to make progress.
>
> I am trying to simply document our current stewardship principles,
> and have mostly lifted text from RFC 2050, the NRPM and the
> PDP, such that these guiding ideas do not get lost if RFC 2050
> is deprecated.
>
>
>
> Maybe a better way to phrase this question is:
>
> If this draft policy is passed, what changes to the current ARIN
> practices do you oppose?
>
> ___Jason
>
>
>
>
>
>
>
>
> On Mon, Jun 3, 2013 at 4:45 PM, William Herrin <[email protected]> wrote:
>
>> 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
>>
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|[email protected]|571-266-0006
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130603/dad1e26f/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 03 Jun 2013 18:11:06 -0500
From: David Farmer <[email protected]>
To: William Herrin <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 6/3/13 15:52 , William Herrin wrote:
> 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
I'm not really an old fogie, at least I don't think I am. However,
since I work for an organization with significant Legacy resources, I've
done a bit of research looking through the RFCs that document the
earliest IPv4 assignments, including several for my employer. See, RFCs
790, 820, 870, 900, 923, 943, 960, 990, 997, 1020, 1166.
Comparing RFC 776 <http://tools.ietf.org/html/rfc776> and RFC 790
<http://tools.ietf.org/html/rfc790> it is easy to infer what you say is
what happened in MIT's case, and a few others. However, John is also
right, if you demonstrated need you could get a class A, at least for a
some while. This can also be inferred by comparing RFC 790
<http://tools.ietf.org/html/rfc790> and RFC 820
<http://tools.ietf.org/html/rfc820>, note several class As were assigned
between these two RFCs. Also, along the way through this series RFCs
class As were assigned, RFC 1166 <http://tools.ietf.org/html/rfc1166> is
I think the last RFC that documented address assignments in an RFC.
> 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.
Eventually, yes that was the case, and was definitely the case by the
time RFC 1366 <http://tools.ietf.org/html/rfc1366> was published,
However it was still technically possible to get a class A even then,
look at Section 4.1 <http://tools.ietf.org/html/rfc1366#section-4.1>.
Finally, as was pointed out earlier, operational need was required for
all assignments. It was noted that even for a class C you had to
estimate how many hosts were going to be connected, initially, and at
one, two and five years. As a thought experiment, what do you think
John Postel would have said, if you answered that question with zero(0),
especially for the one, two and five year parts of the question. Do you
think it might have been "come back later"?
The bar was low, but there was a bar even for class Cs, and that bar was
that you were going to use them in a network, "operational need"
Therefore, I believe operational need is a principle that MUST be
included. There are valid policy questions of what the proper measure
of operational need for the current times and current protocols are. I
believe the measure of operational need will properly change over time,
and for IPv4 such a time is likely here or upon us very soon. But, a
principle that assignments or allocations are made for operational need
is valid and technically necessary. Equally, we need policies and
procedure that interpret this principle in the light of today's
protocols and operational realities, is also valid and necessary, and
the whole point of documenting operational need as principle.
--
================================================
David Farmer Email: [email protected]
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130603/fba06b7c/attachment.html>
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 96, Issue 9
****************************************
