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

[Owen DeLong]

On Mar 24, 2011, at 5:16 PM, Benson Schliesser 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?
> 
The meeting minutes are approved by motion at the next meeting which is
pretty typical of such bodies in general.

As such, they cannot be published until that time. The AC meets monthly, so,
by definition, that would mean a one-month cycle.

>>> 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.
> 
It really doesn't matter whether you have to be an ISP or not. You can fabricate an ISP out of thin
air by claiming you are a schedule C business selling service to your individual self.

So, your nuance is really irrelevant.

> 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 that the current policy has unfortunate ambiguity, but, ARIN has, to date,
interpreted the policy to imply connectivity services. However, I would support
a policy proposal to amend the policy and codify this interpretation (that connectivity
services are required for the address utilization to be considered legitimate).

>>> 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.
> 
> 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.
> 
I'm probably short on time to develop one at the moment, but, I will
support a proposal to codify a requirement for connectivity services into the
existing policy if someone wants to draft such a proposal.

Owen