[arin-ppml] Against 2013-4

[Jason Schiller]

Milton, Owen, John, Bill,

I'm not sure a discussion of merits of needs based allocation / assignment
is useful
at this point in the discussion.

Discussing what constitutes justified need, and how that has changed over
time is
also not helpful at this point in the discussion.

Neither is it helpful to discuss alternate flavors of
conservation at this time.

What we need at this point is a high level discussion, about the general
direction.
With that in mind I'd like to address these points:

MM>  it seems obvious to me that a lot of the thinking that went into this
2013-4
MM> is an attempt to rigidify obsolete thinking rather than to update
things. This
MM> is a backwards-looking revision that has little support in the real
world.
MM> It seems to me that the proposer of this policy thinks that
fundamentally
MM> nothing has changed in 25 years.

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.

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.

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.

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)

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.

Wait for the staff assessment, see how this policy could change things,
then
argue if these changes should or shouldn't happen, and how to modify this
draft to support current ARIN policy and operations, or how to modify
current
ARIN policy and operations to support these principles, or let both stand
in
conflict and provide advice to ARIN to keep doing what it is doing.

MM> > 0.4. Stewardship
MM> This section is also inappropriate for a principles document. It
purports to
MM> tell the current community, as well as all future deliberations for the
next
MM> 20-odd years, how to make policy tradeoffs. That is the kind of thing
that
MM> should be left to the community itself.

The base principles have always had advice about this thing that that
should be
considered, and what the trade offs are.  It has always been up to the
community
to consider how to dial these knobs when crafting specific policy.  This is
not
changing, except that the advice text will not be part of the PDP this
community
uses, so potentially easier to change than getting folks who attend IETF to
whistle.

__Jason



On Mon, Jun 3, 2013 at 9:50 AM, Milton L Mueller <mueller at syr.edu> wrote:

> I would have to oppose most of the statements in this proposed revision of
> the RIR principles.
> While it is a good idea to update a document written literally a
> generation ago for a different IPv4 world, it seems obvious to me that a
> lot of the thinking that went into this 2013-4 is an attempt to rigidify
> obsolete thinking rather than to update things. This is a backwards-looking
> revision that has little support in the real world.
> It seems to me that the proposer of this policy thinks that fundamentally
> nothing has changed in 25 years.
>
> Here are some examples:
>
> > -----Original Message-----
> > Policy Statement:
> >
> > Section 0: Principles and Goals of the Internet Registry System
> >
> > 0.1. Efficient utilization based on need (Conservation)
>
> This represents confused thinking. Conservation as a principle does NOT
> necessarily mean needs-based allocation. There are many ways to conserve
> number resources without the fiction of technical needs assessment. For
> example, pricing or fees graduated to the number of addresses used is a
> form of conservation. Market trading, in which you bid a scarcity-based
> price for number blocks, is a form of conservation. Technical needs
> assessment as currently performed for IPv4 is another form of conservation,
> but it is arbitrary and often discriminates against specific technologies.
> I would not want to see this "update" used to rationalize obsolete methods
> of conservation.
>
> IPv6 allocations as I understand them are not actually based on
> demonstrated need in the same way as IPv4. Whatever your position on the
> needs assessment debate in IPv4, any "principle" regarding conservation
> should be formulated in a way that is FORWARD-LOOKING, flexible and leaves
> the door open for the community to change its definition of the best way to
> avoid wasting number resources. In a nutshell: efficiency and needs
> assessment are NOT equivalent. This draft clearly doesn't get that.
>
> > Policies for managing Internet number resources must support fair
> > distribution of globally unique Internet address space according to the
> > operational needs of the end-users and Internet Service Providers
>
> Again, "fairness" and "operational need" are distinct concepts.
> Operational need may justify giving all the available resources to a large
> provider, which some may find unfair. This statement is essentially
> meaningless in that it introduces to potentially conflicting standards.
>
> > operating networks using this address space. The registry should prevent
> > stockpiling in order to maximize the conservation and efficient
> > utilization of the Internet address space.
>
> I cannot ever support such an economically vague statement. It would
> authorize a huge expansion in the role of RIRs. "The registry should
> prevent stockpiling" means what exactly? What does "stockpiling" actually
> mean in an IPv6 world, anyway? If I use 1/1000th of a /48 assigned to me am
> I "stockpiling"? Is there any evidence that "stockpiling" is a problem? If
> so, where is this evidence?
>
> > 0.1.1. Documented Justified Need (Needs Based)
>
> This section attempts to codify and make permanent a set of policies that
> were developed in the final death throes of IPv4. What a waste of time.
> The idea of authorizing intrusive "accounting of resources" is precisely
> the opposite of the way we need to be going, both in IPv4 and IPv6. We
> should let the market allocate transfers of the fully-allocated IPv4
> numbers, and current policies, which give organizations blocks based on the
> number of networks they claim and some fill ratio, for IPv6. There should
>  be flexibility in the methods of conservation used. There is no need to
> specify concrete methods and practices in a principles document. That is
> just a mistake.
>
> > All Internet number resource requests are subject to audit and
> > verification by any means deemed appropriate by the regional registry.
>
> Reveals a scarcity mentality appropriate to the last decade.
>
> > 0.2. Hierarchical aggregation (Routability)
>
> I agree with the comments Bill Herrin made about this earlier. " Policies
> for managing Internet number resources must facilitate scalable routing."
> Scalability is what we care about, not necessarily hierarchical aggregation
> or anything more specific. Remember, these are supposed to be long-lasting
> principles, not a codification of what we are doing now, and not a specific
> set of policies. Let the community set the specific policies flexibly going
> forward.
>
> Also agree with Bill that we should have an explicit principle that "ARIN
> does not set Internet Routing Policy"
>
> > 0.3. Uniqueness (Registration)
>
> This aspect of the proposed revisions really went off the rails.
> First, uniqueness should be valorized as the single most fundamental and
> important principle of stewardship, the one to which all the other
> principles are subordinate. It is the most important justification for
> having a registry.
>
> Second, the purpose of uniqueness is NOT to aid law enforcement but to
> maintain the technical integrity of the address space. Law enforcement is,
> as the term implies, guided by law and if the world's governments want to
> require certain forms of identification they can do so, subject to due
> process, legislative checks and balances, constitutional constraints, and
> so on. We don't need to be doing that job; indeed it is illegitimate and
> dangerous for us to attempt to insert an address registry into that role.
> The person who wrote the uniqueness aspect of this document doesn't seem to
> understand this.
>
> > 0.4. Stewardship
> >
> > It should be noted that efficient utilization and hierarchical
> > aggregation are often conflicting goals. All the above goals may
> > sometimes be in conflict with the interests of individual end-users or
> > Internet Service Providers. Care must be taken to ensure balance with
> > these conflicting goals given the resource availability, relative size
> > of the resource, and number resource specific technical dynamics, for
> > each type of number resource. For example, efficient utilization becomes
> > a more prominent issue than aggregation as the IPv4 free pool depletes
> > and IPv4 resource availability in any transfer market decreases.
> > Conversely, because the IPv6 number space is orders of magnitude larger
> > than the IPv4 number space, the scale tips away from efficient
> > utilization towards hierarchical aggregation for IPv6 number resources.
>
> This section is also inappropriate for a principles document. It purports
> to tell the current community, as well as all future deliberations for the
> next 20-odd years, how to make policy tradeoffs. That is the kind of thing
> that should be left to the community itself.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130603/813faea4/attachment.htm>