[arin-ppml] Advisory Council Meeting Results - March 2011

Wed Mar 23 20:40:55 EDT 2011

As I've done a couple times now, I'd like to expand on my own personal
opinions on some of the proposals inline below.  I'm not speaking for
the AC or anyone else: the AC's actions are captured well below, and
further detail on the discussion leading up to them will be available
in the minutes.

On Mar 23, 2011, at 7:47 AM, ARIN <info at arin.net> wrote:

> In accordance with the ARIN Policy Development Process (PDP), the ARIN
> Advisory Council (AC) held a meeting on 17 March 2011 and made decisions
> about several policy proposals.
>
> The AC abandoned the following proposals:
>
>  ARIN-prop-132 ISP Sub-assignments Do Not Require Specific Customer
> Relationships
>
>  ARIN-prop-133 No Volunteer Services on Behalf of Unaffiliated Address
> Blocks
>
>  ARIN-prop-134 Identification of Legitimate Address Holders
>
>  ARIN-prop-135 Clarification of draft policy 2009-3
>
>  ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks
>
> The AC voted to abandon ARIN-prop-132 for the following reasons:
>  - Aggregation is one of the goals of addressing stewardship, this
> policy  encourages deaggregation, and accelerates routing table growth.
>  - Creates a situation where the ISP providing the address space is
> not in a position to remediate security and abuse issues which may have
> significant impact on the larger internet community.
>  - The AC believes that a discussion about how staff currently handles
> this situation is worth having, and suggests the author or a member of
> the community submit it as an Open Policy hour topic at the upcoming
> ARIN meeting.

I was initially sympathetic to this proposal and wanted to make sure
the community had a chance to discuss the pros and cons of LIRs that
are not ISPs.  However, it seems that we have an example of non-ISP
LIRs in the RIPE region, and what I've heard from several folks is
that such arrangements cause a lot of problems, and probably would not
be worth doing here.  If anyone takes a different lesson from that,
I'd love to hear your experiences as well.

> ARIN-prop-133 was abandoned by the AC because there was not significant
> support for it on PPML and because the proposal as written is not
> something that could be implemented under the existing circumstances
> (ICANN MOU, ARIN structure, and the fact that there is no provision for
> "alternate" registries in any existing documents, RFCs, or other
> approved structures).
>
> The AC has chosen to abandon ARIN-prop-134. Aside from the author, there
> were no statements of support on the mailing list, and the majority of
> opinion questioned the problem to be solved. While wording can often be
> refined during the policy development process, the problem statement
> itself needs further clarification. The abandonment of this proposal is
> not to dismiss the discussion. It would just be clearer to refine the
> problem statement first and submit a proposal if more clarity and
> support can be reached on the mailing list.

I believe there is actually a substantive problem here that is worth
discussing.  At this point I'm not sure if it should be addressed
through a new policy proposal, or if it would end up being an ACSP
suggestion, though...

I have heard from a number of people the concern that some legacy
holders are reluctant to sign an LRSA because they perceive it to
require giving up rights to use the address space as they see fit.
While I largely thing such concerns are exaggerated, they nonetheless
could represent a barrier if a legacy holder is attempting to make
space available for 8.3 transfer.  The current method for ARIN to
validate that a legacy holder is indeed the legitimate party
responsible for a block is for them to apply for an LRSA, for ARIN to
validate all their documentation, and then to sign the LRSA.  For
parties reluctant to do so, they have the option of waiting to sign
the LRSA until the transfer transaction closes.  But if an
organization looking to receive addresses under 8.3 wants to validate
(before they engage their lawyers in contract negotiations) that they
are dealing with the legitimate holder of the address block, there is
currently no way to do that short of that holder signing an LRSA.

So I think the question is whether the community thinks it would be
worthwhile for ARIN to develop a process to validate an address
holder's legitimacy, the same way they do for the LRSA today, but then
simply provide some sort of pre-qualification document to the holder
while he goes out looking for a party to transfer the block to.
Ideally, IMO, this pre-qualification could be upgraded to a full LRSA
with just a couple signatures (i.e. when the 8.3 transfer transaction
is otherwise approved).

Thoughts?

-Scott

> The AC abandoned ARIN-prop-135 because: a. The original author wished to
> withdraw it, and  b. The proposal was an attempt to clarify policy. If
> policy is to be changed, the policy itself needs to be rewritten, not
> clarified.
>
> The AC voted to abandon ARIN-prop-136 for the following reasons:
> - Overwhelming lack of support within the ARIN community, as evidenced
> by discussion on the PPML.
> - ARIN staff has indicated that they do not believe that it is
> possible to implement this policy due to existing agreements, namely
> they can not not-serve our community.
> -   Today folks have the option of opting out of swip by using RWHOIS
> and providing ARIN information about the location of the RHWOIS service
> to publish in the SWIP record.  This hasn't always gone so well, not all
> RWHOIS services are kept up to date and publicly available.  Providing
> another mechanism for folks to opt out of having records published
> publicly in a centralized location, is not in the best interest of the
> community, as it would complicate abuse, security and law enforcement
> investigations.
>  The AC encourages further discussion of this topic and would be happy
> to work with anyone who believes policy changes in this area are
> needed.
>
> The Advisory Council appreciates the involvement of all community
> members who provide input toward a complete discussion of policy
> proposals. The AC especially wishes to thank those authors of policy
> proposals for their efforts in helping the community address possible
> improvements.
>
> The PDP states, “Any member of the community, including a proposal
> originator, may initiate a Discussion Petition if they are dissatisfied
> with the action taken by the Advisory Council regarding any specific
> policy proposal.” Proposals 132, 133, 134, 135, and 136 were abandoned
> and as such may be petitioned (Discussion Petition) to try to change
> them into draft policies for adoption discussion on the Public Policy
> Mailing List and at the ARIN XXVIII (October 2011) Public Policy Meeting
> (March 7 was the deadline for petitions for the upcoming meeting in San
> Juan). The deadline to begin a petition will be five business days after
> the AC's draft meeting minutes are published.
>
> For more information on starting and participating in petitions, see PDP
> Petitions at: https://www.arin.net/policy/pdp_petitions.html
>
> Draft Policy and Policy Proposal texts are available at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
>
>
>
>
> _______________________________________________
> 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.