[arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks

[Jason Schiller]

I support the proposal with the exclusion of section 6.5.9.3.
I support the proposal with the inclusion of section 6.5.9.3.
I ask what is the purpose of section 6.5.9.3?
Is section 6.5.9.3 needed?
Is section 6.5.9.3 restricting the right thing?

Without section 6.5.9.3 the policy clearly defines a community network,
and allows what would otherwise be an LIR  getting a /32 (or /36 upon
request)
get instead a /40.

This would reduce there fees from X-small $1,000 annunally
(or upon request 2X-small $500 annually)
to 3X-small $250 annually.

Sounds well and good.


Section 6.5.9.3 adds a further restriction of there shall be no no
re-allocations,
suggesting they cannot have a user of their space which in turn has its own
users.

(for the record I think you can drop the text "to other organizations."
and just have "However, they shall not reallocate resources.")


What behavior are you intending to prevent?

Doesn't the definition already have the required limits on behavior in the
form of:

"A community network is deployed, operated, and governed by its users,
for the purpose of providing free or low-cost connectivity to the community
it services."

It appears what you are preventing are the cases below.  I ask is this what
you
intend to prevent?  and if so why?

Should the Colorado IPv6 cooperative be prevented from providing transit to
the
Rocky Mountain Spotted IPv6 community network because they in turn assign
IPv6 addresses to community members?


What if this is all within one community network?  What if the Rocky
Mountain
Spotted IPv6 community network has a part of the network that is managed by
a group in Ball Mountain community and another part is managed by a group in
Mount Lincoln.  Wouldn't it make sense to re-allocate some of the Rocky
Mountain
Spotted IPv6 community network's /40 to Ball Mountain community and let
them
handle the assignments to users in their locale?


___Jason





On Sat, Jan 13, 2018 at 2:14 PM, David Farmer <farmer at umn.edu> wrote:

> After taking into account the discussion of ARIN-2017-8 preceding and
> during ARIN 40, here are the proposed revisions for the Problem and Policy
> Statements for ARIN-2017-8: Amend Community Networks.
>
> Note the name of the policy is being changed to account for the expansion
> of the scope of policy changes beyond just the definition of a Community
> Network.
>
> Following any initial comments or suggestion I will move this forward as
> an official update to the Draft Policy in a week or so.
>
> Thanks.
>
> -----
>
> Problem Statement:
>
> The Community Networks section of the NRPM has only been used once since
> implementation in January 2010. Proposal ARIN-2016-7, to increase the
> number of use cases, was abandoned by the Advisory Council due to lack of
> feedback. Proposal ARIN 2017-2, to remove all mention of community networks
> from NRPM was met with opposition by the community. Many responded that the
> definition of "community network" was too narrow, which could be the reason
> for lack of uptake.
>
> In the discussion at ARIN 40, it was clear that more than just the
> definition of a community network needs to be revised and that community
> networks need to have allocations and not assignments made to them.
>
> Policy statement:
>
> Replace section 2.11 with the following;
>
> 2.11 Community Network
>
> *A community network is deployed, operated, and governed by its users, for
> the purpose of providing free or low-cost connectivity to the community it
> services. Users of the network or other volunteers must play a primary role
> in governance of the organization, other functions may be handled by either
> paid staff or volunteers.*
>
> Rename section 6.5.9 and revise the last sentence as follows;
>
> 6.5.9. Community Network *Allocations*
>
> While community networks would normally be considered to be ISP type
> organizations under existing ARIN criteria, they tend to operate on much
> tighter budgets and often depend on volunteer labor. As a result, they tend
> to be much smaller and more communal in their organization rather than
> provider/customer relationships of commercial ISPs. This section seeks to
> provide policy that is more friendly to those environments by allowing *community
> network to receive a smaller allocation than other LIRs or commercial ISPs.*
>
> Replace section 6.5.9.2 and 6.5.9.3 with the following;
>
> *6.5.9.2. Allocation Size*
>
> *Community Networks are eligible only to receive an allocation of /40 of
> IPv6 resources under this section. Community Networks that wish to receive
> a larger initial allocation or any subsequent allocations must qualify as a
> regular LIR, see sections 6.5.2 or 6.5.3 respectively. *
>
> *6.5.9.3. Reassignments by Community Networks*
>
> *Similar to other LIRs, Community Networks shall make reassignments to
> end-users in accordance with applicable policies, in particular but not
> limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate
> resources to other organizations.*
>
> Comments:
>
> Timetable for implementation: Immediate
>
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
> ===============================================
>
> _______________________________________________
> 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/20180116/2aeab8fb/attachment.htm>