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

[Scott Leibrand]

On Thu, Mar 24, 2011 at 5:16 PM, Benson Schliesser
<bensons at queuefull.net> wrote:
> Hi, Scott.
>
> On Mar 23, 2011, at 7:40 PM, Scott Leibrand wrote:
>
>> 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.
>
> Thank you for your feedback, Scott.  I appreciate your contribution to the conversation.
>
>>  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.
>
> Do you know when the AC meeting minutes will be posted?  The only 2011 meeting minutes currently posted at https://www.arin.net/about_us/ac/index.html are from the January meeting (under the outdated heading "2010").  Does it typically take a month(+) to publish these?

Per https://www.arin.net/about_us/acguidelines.html#approval the
process is that the minutes are first reviewed by the AC chair, and
then sent out to the full AC for review.  After that 10 business day
review, they are posted as "draft" to the website until they are
formally approved by the AC at their next meeting.

In this case, the February minutes were posted to the AC for review on
March 8, and formally approved on the 17th, so I believe they should
be posted already.  I'll check with ARIN staff on the status of that.

In the case of the March 17 meeting, the minutes were sent to the AC
for review on March 21, so they should be considered approved on the
4th of April (or possibly the 11th, if a second round of review is
needed), and can be posted shortly after that.

>>> 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.
>
> I'm confused by your choice of words, and I think it would be useful to clarify.  The current NRPM language allows ISPs to assign addresses to their customers, but doesn't define what "customer" means.  The text of proposal 132 does not explicitly create "non-ISP LIRs", but explicitly allows an ISP to act as a LIR for customers that might not be receiving "traditional connectivity" services from that ISP.  Granted, this is a nuance - but it's worth noting, for operational purposes, that the proposal wouldn't necessarily allow non-ISPs to become LIRs.
>
> Having said that, I'm frankly not sure this matters.  As I mentioned above, the current policy doesn't define "customer" and I posit that an ISP is already free to engage in this behavior.  Proposal 132 was intended to clarify existing policy.  The AC "reasons" given for abandoning this proposal seem to suggest a preference for the opposite of 132; should we expect such a proposal in the near future?

I agree with you that the NRPM is ambiguous on the question of whether
ISPs can act as LIRs for organizations that don't buy IP connectivity
services from them.   The relevant NRPM section is:

2.4. Local Internet Registry (LIR)

A Local Internet Registry (LIR) is an IR that primarily assigns
address space to the users of the network services that it provides.
LIRs are generally Internet Service Providers (ISPs), whose customers
are primarily end users and possibly other ISPs.

However, during the evaluation of ARIN-prop-132, ARIN staff stated
that "If a network assigns address space without a corresponding
network service (i.e. connectivity), it's no longer an LIR, thus no
longer an ISP, thus ineligible for consideration under ISP policy."

In order to change that, we'd need a policy proposal to modify NRPM
2.4.  Given what I've learned about the impacts of a more liberal
definition of LIR in the RIPE region, I don't think I'd support
relaxing the "network services" requirement in 2.4.

>>> 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 don't have much to say about this, except that I think the standard should be documented in an open and transparent way.

At the moment, the standards are documented at
https://www.arin.net/resources/transfer_listing/index.html and
https://www.arin.net/resources/request/transfers.html
If you think any particular aspect of those documents should be
clarified, or would like to suggest a change to any of the procedures,
the ARIN Consultation and Suggestion Process (ACSP) is the way to do
it: https://www.arin.net/participate/acsp/index.html or
https://www.arin.net/app/suggestion/

> If you think there is an alteration that would make prop 134 more interesting to the "ARIN community", please feel free to submit a new version.  I have no objections to my proposal text being used and/or adapted by anybody here.

Thanks.  I intend to continue discussing the general topic of whether
the transfer market is working effectively, so any input there is
welcome.  And if you're going to be at the San Juan meeting, we should
definitely discuss it there.  At the moment I don't see any clear need
for policy changes, but when we do identify something, I'll be happy
to work with anyone who's interested to submit a proposal to make
them.

-Scott