From jschiller at google.com  Tue Oct  3 12:30:30 2017
From: jschiller at google.com (Jason Schiller)
Date: Tue, 3 Oct 2017 12:30:30 -0400
Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the
 Definition of Community Network
In-Reply-To: <7E7773B523E82C478734E793E58F69E7A52B32C1@SBS2011.thewireinc.local>
References: <d3d50d3e-3c58-607e-e0a6-0ad5358d80dd@arin.net>
 <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net>
 <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local>
 <80cd0ba1-91d6-1ca1-fdd0-f008d3c5c087@quark.net>
 <7E7773B523E82C478734E793E58F69E7A52B32C1@SBS2011.thewireinc.local>
Message-ID: <CAC4yj2X9qO0Dbu-h_jS-6JKOitwf2E3JQ0BCz3mX9MezG9B7Cg@mail.gmail.com>

Id like to come at "Information Technology services" from the opposite
direction.

I propose the following thought experiment:
1. remove "other Information Technology services" text
2. assume "providing free or low-cost connectivity" means:
   A. provide transit to eyeballs to persons or entities within their
community
   B. provide transit to servers providing CDN to/from persons or entities
within their community

3. what service is not covered?


also this definition is tied to 6.5.9.

Is 6.5.9 needed? useful?

Is the purpose of 6.5.9 to give community networks
the flexibility to choose to be an IPv6 end-user when they
normally wouldn't?

And if they take such option they SHALL be considered
an IPv6 end-user for all ARIN matters, but will be considered
an IPv4/ASN ISP/end-user as per those policies normally?

So does this mean a Community network who provides transit
to residents via wi-fi, could choose to be an IPv6-only service,
and get an end-user /48 and pay annually $100 / year as
an end-user?


If that same community network was donated an IPv4 /24,
and wanted to add IPv4 transit would they then hold an
IPv6 assignment and an IPv4 allocation?  Does this mean their
annual fees are
$100 for the IPv6 end-user /48 + $250 for the IPv4 ISP 3X-Small

OR

just $250 for the IPv4 ISP 3X-Small (which over rides the end-user fees)

OR

are they billed as an end-user
$100 for the IPv6 end-user /48 + $100 for the IPv4 /24


Could we eliminate 6.5.9 if \
1. the 3X-small category was $100?

2.A. we change 6.5.2.1.b to read as follows:
" In no case shall an LIR receive smaller than a /32 unless they
specifically request a /36, /40, /44, or /48.
In no case shall an ISP receive more than a /16 initial allocation."

I'd support a raising of my fees if that was necessary to fix this.


___Jason



On Fri, Sep 22, 2017 at 1:40 AM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> Andrew,
>
>
>
> I don?t have a solution for the Information Technology text, other than to
> remove it. It creates a loophole that anything could be considered a
> Community Network.
>
>
>
> Replying to your answers.
>
>
>
> 2) Is charitable organization a synonym or fall under the umbrella of
> non-profit?
>
> AD: My understanding is that this was intended as a synonym, a list of
> descriptors that could be used to define a community network.
>
>                KB: It would make sense to remove Charitable organization
> if it is only a synonym.
>
>
>
> 3) Why is the scope limited to post-secondary institution when many
> smaller communities would not have that? Could accredited educational
> institution be used instead?
>
> AD: The text has been updated to "educational institution"
>
> KB: My apologies on reading the wrong text from the website. Thanks for
> the clarification.
>
>
>
> 4) I agree with Chris W. that "play a large role" is very ambigous.
>
> AD: Do you have a suggestion of text that might be more descriptive?  For
> example would a percentage of revenue / wages ratio be applicable?   That
> was an idea, but I'm not sure one could easily come up with a ratio that
> works.
> KB: The word large could be 15%, depending on who you ask. In TCP/IP 1
> percent loss is large. A non-specific term will more than likely default to
> the lowest possible. I would suggest that majority or 50% are more
> appropriate.
>
>
>
> 5) The last sentence should be reworded completely. Critical functions may
> be handled by paid staff, implies that volunteers shouldn't handle Critical
> functions or that paid staff shouldn't handle menial work?
>
> AD: Should we substitute "Critical" with "Some"?
>
> KB: Changing Critical to Some would be fine.
>
>
>
>
>
> Thanks,
>
>
>
> Kevin Blumberg
>
>
>
>
>
>
>
> *From:* Andrew Dul [mailto:andrew.dul at quark.net]
> *Sent:* Wednesday, September 20, 2017 5:45 PM
> *To:* Kevin Blumberg <kevinb at thewire.ca>; arin-ppml at arin.net
>
> *Subject:* Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the
> Definition of Community Network
>
>
>
> On 9/20/2017 11:01 AM, Kevin Blumberg wrote:
> >
> >
> > I am opposed to the policy if it includes ?or other Information
> Technology services?. That would basically be any defined organization that
> has a website.
>
> Do you have a suggestion of what might be more appropriate wording?  We
> were trying to suggest that a community network might provide more than
> basic connectivity.
>
> On 9/20/2017 10:21 AM, Kevin Blumberg wrote:
>
> Andrew,
>
>
>
> Is this the current text of the policy?
>
>
>
> The text on 2017-8 on the website does not match. The text below includes " or other Information Technology services" which does not appear on the website (https://www.arin.net/policy/proposals/2017_8.html)
>
>
>
> Can you please confirm which is the correct version, I have written my repsonses based on the website.
>
>
>
> 1) Can a "Volunteer Group" sign the RSA?
>
> I'll let ARIN staff answer this part.
>
> 2) Is charitable organization a synonym or fall under the umbrella of non-profit?
>
> My understanding is that this was intended as a synonym, a list of
> descriptors that could be used to define a community network.
>
> 3) Why is the scope limited to post-secondary institution when many smaller communities would not have that? Could accredited educational institution be used instead?
>
> The text has been updated to "educational institution"
>
>
>
> 4) I agree with Chris W. that "play a large role" is very ambigous.
>
>
> Do you have a suggestion of text that might be more descriptive?  For
> example would a percentage of revenue / wages ratio be applicable?   That
> was an idea, but I'm not sure one could easily come up with a ratio that
> works.
>
>
>
>
> 5) The last sentence should be reworded completely. Critical functions may be handled by paid staff, implies that volunteers shouldn't handle Critical functions or that paid staff shouldn't handle menial work?
>
>
> Should we substitute "Critical" with "Some"?
>
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
>
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>] On Behalf Of Andrew Dul
>
> Sent: Tuesday, September 19, 2017 11:21 AM
>
> To: arin-ppml at arin.net
>
> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network
>
>
>
> Hello all,
>
>
>
> We will be discussing this draft proposal at the upcoming ARIN meeting in San Jose.  If you have comments on the updated draft posted below, we'd certainly like to hear from you so we can help shape the conversation in person.
>
>
>
> We have seen some support for this updated draft, but not a lot.
>
> Furthermore, have we addressed all of your concerns which you might have noted earlier on the 1st version of the policy text.
>
>
>
> Thanks,
>
> Andrew
>
>
>
> On 8/24/2017 8:22 AM, ARIN wrote:
>
>
>
>
>
> Draft Policy ARIN-2017-8: Amend the Definition of Community Network
>
>
>
> Problem Statement:
>
>
>
> The Community Networks section of the NRPM has not been used 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.
>
>
>
> Policy statement:
>
>
>
> CURRENT NRPM TEXT:
>
>
>
> ?2.11. Community Network
>
>
>
> A community network is any network organized and operated by a
>
> volunteer group operating as or under the fiscal support of a
>
> nonprofit organization or university for the purpose of providing free
>
> or low-cost connectivity to the residents of their local service area.
>
> To be treated as a community network under ARIN policy, the applicant
>
> must certify to ARIN that the community network staff is 100%
>
> volunteers.?
>
>
>
> NEW NRPM TEXT:
>
>
>
> ?2.11 Community Network
>
>
>
> A community network is a network organized and operated by a volunteer
>
> group, not-for-profit, non-profit, charitable organization, or
>
> educational institution for the purpose of providing free or low-cost
>
> connectivity, or other Information Technology services to persons or
>
> entities within their community. Critical functions may be handled by
>
> paid staff, but volunteers play a large role in offering services
>
> available through community networks.?
>
>
>
> Comments:
>
>
>
> Timetable for implementation: Immediate _
>
>
>
> _______________________________________________
>
> 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.
>
>
>
> _______________________________________________
> 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/20171003/c54c0b0f/attachment.htm>

From mwinters at edwardrose.com  Tue Oct  3 14:59:10 2017
From: mwinters at edwardrose.com (Michael Winters)
Date: Tue, 3 Oct 2017 18:59:10 +0000
Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the
 Definition of Community Network
In-Reply-To: <CAC4yj2X9qO0Dbu-h_jS-6JKOitwf2E3JQ0BCz3mX9MezG9B7Cg@mail.gmail.com>
References: <d3d50d3e-3c58-607e-e0a6-0ad5358d80dd@arin.net>
 <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net>
 <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local>
 <80cd0ba1-91d6-1ca1-fdd0-f008d3c5c087@quark.net>
 <7E7773B523E82C478734E793E58F69E7A52B32C1@SBS2011.thewireinc.local>
 <CAC4yj2X9qO0Dbu-h_jS-6JKOitwf2E3JQ0BCz3mX9MezG9B7Cg@mail.gmail.com>
Message-ID: <df16a419cb844592858ec98b2a0ce3db@kz-mail01.manifold.edwardrosekzoo.com>

I am also concerned that ?educational organization? is too broad.
Are we really saying that Harvard, USC, Ohio State, etc. are so cash strapped that they could not afford to pay the same as any other business?
Yes, I know the current text covers them, I also think that is wrong.

Mike

From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jason Schiller
Sent: Tuesday, October 3, 2017 12:31 PM
To: Kevin Blumberg <kevinb at thewire.ca>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network

Id like to come at "Information Technology services" from the opposite direction.

I propose the following thought experiment:
1. remove "other Information Technology services" text
2. assume "providing free or low-cost connectivity" means:
   A. provide transit to eyeballs to persons or entities within their community
   B. provide transit to servers providing CDN to/from persons or entities within their community

3. what service is not covered?


also this definition is tied to 6.5.9.

Is 6.5.9 needed? useful?

Is the purpose of 6.5.9 to give community networks
the flexibility to choose to be an IPv6 end-user when they
normally wouldn't?

And if they take such option they SHALL be considered
an IPv6 end-user for all ARIN matters, but will be considered
an IPv4/ASN ISP/end-user as per those policies normally?

So does this mean a Community network who provides transit
to residents via wi-fi, could choose to be an IPv6-only service,
and get an end-user /48 and pay annually $100 / year as
an end-user?


If that same community network was donated an IPv4 /24,
and wanted to add IPv4 transit would they then hold an
IPv6 assignment and an IPv4 allocation?  Does this mean their
annual fees are
$100 for the IPv6 end-user /48 + $250 for the IPv4 ISP 3X-Small

OR

just $250 for the IPv4 ISP 3X-Small (which over rides the end-user fees)

OR

are they billed as an end-user
$100 for the IPv6 end-user /48 + $100 for the IPv4 /24


Could we eliminate 6.5.9 if \
1. the 3X-small category was $100?

2.A. we change 6.5.2.1.b to read as follows:
" In no case shall an LIR receive smaller than a /32 unless they
specifically request a /36, /40, /44, or /48.
In no case shall an ISP receive more than a /16 initial allocation."

I'd support a raising of my fees if that was necessary to fix this.


___Jason



On Fri, Sep 22, 2017 at 1:40 AM, Kevin Blumberg <kevinb at thewire.ca<mailto:kevinb at thewire.ca>> wrote:
Andrew,

I don?t have a solution for the Information Technology text, other than to remove it. It creates a loophole that anything could be considered a Community Network.

Replying to your answers.

2) Is charitable organization a synonym or fall under the umbrella of non-profit?
AD: My understanding is that this was intended as a synonym, a list of descriptors that could be used to define a community network.
               KB: It would make sense to remove Charitable organization if it is only a synonym.

3) Why is the scope limited to post-secondary institution when many smaller communities would not have that? Could accredited educational institution be used instead?
AD: The text has been updated to "educational institution"
KB: My apologies on reading the wrong text from the website. Thanks for the clarification.

4) I agree with Chris W. that "play a large role" is very ambigous.
AD: Do you have a suggestion of text that might be more descriptive?  For example would a percentage of revenue / wages ratio be applicable?   That was an idea, but I'm not sure one could easily come up with a ratio that works.
KB: The word large could be 15%, depending on who you ask. In TCP/IP 1 percent loss is large. A non-specific term will more than likely default to the lowest possible. I would suggest that majority or 50% are more appropriate.

5) The last sentence should be reworded completely. Critical functions may be handled by paid staff, implies that volunteers shouldn't handle Critical functions or that paid staff shouldn't handle menial work?
AD: Should we substitute "Critical" with "Some"?
KB: Changing Critical to Some would be fine.


Thanks,

Kevin Blumberg



From: Andrew Dul [mailto:andrew.dul at quark.net<mailto:andrew.dul at quark.net>]
Sent: Wednesday, September 20, 2017 5:45 PM
To: Kevin Blumberg <kevinb at thewire.ca<mailto:kevinb at thewire.ca>>; arin-ppml at arin.net<mailto:arin-ppml at arin.net>

Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network

On 9/20/2017 11:01 AM, Kevin Blumberg wrote:
>
>
> I am opposed to the policy if it includes ?or other Information Technology services?. That would basically be any defined organization that has a website.

Do you have a suggestion of what might be more appropriate wording?  We were trying to suggest that a community network might provide more than basic connectivity.

On 9/20/2017 10:21 AM, Kevin Blumberg wrote:

Andrew,



Is this the current text of the policy?



The text on 2017-8 on the website does not match. The text below includes " or other Information Technology services" which does not appear on the website (https://www.arin.net/policy/proposals/2017_8.html)



Can you please confirm which is the correct version, I have written my repsonses based on the website.



1) Can a "Volunteer Group" sign the RSA?
I'll let ARIN staff answer this part.

2) Is charitable organization a synonym or fall under the umbrella of non-profit?
My understanding is that this was intended as a synonym, a list of descriptors that could be used to define a community network.

3) Why is the scope limited to post-secondary institution when many smaller communities would not have that? Could accredited educational institution be used instead?
The text has been updated to "educational institution"



4) I agree with Chris W. that "play a large role" is very ambigous.

Do you have a suggestion of text that might be more descriptive?  For example would a percentage of revenue / wages ratio be applicable?   That was an idea, but I'm not sure one could easily come up with a ratio that works.




5) The last sentence should be reworded completely. Critical functions may be handled by paid staff, implies that volunteers shouldn't handle Critical functions or that paid staff shouldn't handle menial work?

Should we substitute "Critical" with "Some"?












-----Original Message-----

From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Dul

Sent: Tuesday, September 19, 2017 11:21 AM

To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>

Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network



Hello all,



We will be discussing this draft proposal at the upcoming ARIN meeting in San Jose.  If you have comments on the updated draft posted below, we'd certainly like to hear from you so we can help shape the conversation in person.



We have seen some support for this updated draft, but not a lot.

Furthermore, have we addressed all of your concerns which you might have noted earlier on the 1st version of the policy text.



Thanks,

Andrew



On 8/24/2017 8:22 AM, ARIN wrote:





Draft Policy ARIN-2017-8: Amend the Definition of Community Network



Problem Statement:



The Community Networks section of the NRPM has not been used 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.



Policy statement:



CURRENT NRPM TEXT:



?2.11. Community Network



A community network is any network organized and operated by a

volunteer group operating as or under the fiscal support of a

nonprofit organization or university for the purpose of providing free

or low-cost connectivity to the residents of their local service area.

To be treated as a community network under ARIN policy, the applicant

must certify to ARIN that the community network staff is 100%

volunteers.?



NEW NRPM TEXT:



?2.11 Community Network



A community network is a network organized and operated by a volunteer

group, not-for-profit, non-profit, charitable organization, or

educational institution for the purpose of providing free or low-cost

connectivity, or other Information Technology services to persons or

entities within their community. Critical functions may be handled by

paid staff, but volunteers play a large role in offering services

available through community networks.?



Comments:



Timetable for implementation: Immediate _



_______________________________________________

PPML

You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.



_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.



--
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com<mailto:jschiller at google.com>|571-266-0006


________________________________

________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171003/6778154c/attachment.htm>

From rjletts at uw.edu  Tue Oct  3 15:52:28 2017
From: rjletts at uw.edu (Richard J Letts)
Date: Tue, 3 Oct 2017 19:52:28 +0000
Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the
 Definition of Community Network
In-Reply-To: <df16a419cb844592858ec98b2a0ce3db@kz-mail01.manifold.edwardrosekzoo.com>
References: <d3d50d3e-3c58-607e-e0a6-0ad5358d80dd@arin.net>
 <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net>
 <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local>
 <80cd0ba1-91d6-1ca1-fdd0-f008d3c5c087@quark.net>
 <7E7773B523E82C478734E793E58F69E7A52B32C1@SBS2011.thewireinc.local>
 <CAC4yj2X9qO0Dbu-h_jS-6JKOitwf2E3JQ0BCz3mX9MezG9B7Cg@mail.gmail.com>
 <df16a419cb844592858ec98b2a0ce3db@kz-mail01.manifold.edwardrosekzoo.com>
Message-ID: <DM5PR08MB340409E5C326421569E96308C0720@DM5PR08MB3404.namprd08.prod.outlook.com>


My point of view

a)       I am not sure why educational institutions are not able to pay the fees for other categories of usage, or why they need an exception.

ARIN staff would need to decide if the application satisfies this: ?a volunteer group, not-for-profit, non-profit, or charitable organization?



I?ve been involved with enough community groups to know that two of these have weak governance structures that fail when there are conflicts (a volunteer group and being a non-core aspect of a charitable organization), inevitably leading to the collapse of the organization. I?m not going to prejudge that debate here, but consider striking them. If the community organization doesn?t have 501(c)3 status in the US they are leaving out the opportunity to save money and get grants.



Without a legal entity ?owning? the space how would ARIN know they were dealing with, who is legally allowed to dispose of the space, etc.



b)      Who cares if they provide ?other Information Technology services? to their community; we?re talking about internet access here



c)       ?Persons or entities? seems redundant (It is like saying ?people or not people?); who/what are the not a person and not an entity that are excluded?



d)      I am not sure what is considered critical? Digging ditches? Pulling fiber? Responding to ARIN requests? Filing forms with the IRS?

As an example I?m on the board of a non-profit. We decide on the aims, manage the membership, etc. but we pay [independent 1099] contractors for services (editing and printing the newsletter, performing at concerts, concert sound, etc.). Some of these are non-critical (the newsletter), some are critical (the performers), volunteers some critical things (IRS tax returns, state registrations) and some non-critical things (run the website)

So I think I end up with something with fewer words.

?A community network is a network organized and operated by a volunteer group, not-for-profit, non-profit, or charitable organization

 for the purpose of providing free or low-cost connectivity within their community. Volunteers play a large role in directing the activity of the organization, but some functions may be handled by paid staff.?


/RjL




?2.11 Community Network



A community network is a network organized and operated by a volunteer

group, not-for-profit, non-profit, charitable organization, or

educational institution for the purpose of providing free or low-cost

connectivity, or other Information Technology services to persons or

entities within their community. Critical functions may be handled by

paid staff, but volunteers play a large role in offering services

available through community networks.?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171003/e5f4b7cd/attachment.htm>

From farmer at umn.edu  Tue Oct  3 17:48:50 2017
From: farmer at umn.edu (David Farmer)
Date: Tue, 3 Oct 2017 16:48:50 -0500
Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the
 Definition of Community Network
In-Reply-To: <df16a419cb844592858ec98b2a0ce3db@kz-mail01.manifold.edwardrosekzoo.com>
References: <d3d50d3e-3c58-607e-e0a6-0ad5358d80dd@arin.net>
 <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net>
 <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local>
 <80cd0ba1-91d6-1ca1-fdd0-f008d3c5c087@quark.net>
 <7E7773B523E82C478734E793E58F69E7A52B32C1@SBS2011.thewireinc.local>
 <CAC4yj2X9qO0Dbu-h_jS-6JKOitwf2E3JQ0BCz3mX9MezG9B7Cg@mail.gmail.com>
 <df16a419cb844592858ec98b2a0ce3db@kz-mail01.manifold.edwardrosekzoo.com>
Message-ID: <CAN-Dau3WazwrXy5zM=LtyKC9ZmPkKt3UaVujoKLjNhX5u6=O1A@mail.gmail.com>

I don't think the intent isn't for an educational institution to use this
definition to obtain resources for their own internal use.  However, many
educational institution, libraries, and even local governments are
sponsoring or operating community networks to proving access to service
their communities. Especially important is servicing disadvantaged
students, so they can to do homework, even if they don't have access at
home, or just support their leaning outside school hours, weekend, summer
or after school, etc..  It doesn't seem completely crazy for a school
district, library, or local government to have a IPv6 block for it's
enterprise use and then a separate community network block.

Here is an article that talking about an example of the kind of thing I'm
referring to;

https://www.wired.com/story/schools-secret-spectrum-free-
internet-digital-divide/

By have a separate block for the community network's use, this
operationally facilitates he community network possibly later becoming it's
own separate organization or it could more easily be outsourced to a local
carrier in the future.

Thanks.

On Tue, Oct 3, 2017 at 1:59 PM, Michael Winters <mwinters at edwardrose.com>
wrote:

> I am also concerned that ?educational organization? is too broad.
>
> Are we really saying that Harvard, USC, Ohio State, etc. are so cash
> strapped that they could not afford to pay the same as any other business?
>
> Yes, I know the current text covers them, I also think that is wrong.
>
>
>
> Mike
>
>
>
> *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *Jason
> Schiller
> *Sent:* Tuesday, October 3, 2017 12:31 PM
> *To:* Kevin Blumberg <kevinb at thewire.ca>
> *Cc:* arin-ppml at arin.net
> *Subject:* Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the
> Definition of Community Network
>
>
>
> Id like to come at "Information Technology services" from the opposite
> direction.
>
>
>
> I propose the following thought experiment:
>
> 1. remove "other Information Technology services" text
>
> 2. assume "providing free or low-cost connectivity" means:
>
>    A. provide transit to eyeballs to persons or entities within their
> community
>
>    B. provide transit to servers providing CDN to/from persons or entities
> within their community
>
>
>
> 3. what service is not covered?
>
>
>
>
>
> also this definition is tied to 6.5.9.
>
>
>
> Is 6.5.9 needed? useful?
>
>
>
> Is the purpose of 6.5.9 to give community networks
>
> the flexibility to choose to be an IPv6 end-user when they
>
> normally wouldn't?
>
>
>
> And if they take such option they SHALL be considered
>
> an IPv6 end-user for all ARIN matters, but will be considered
>
> an IPv4/ASN ISP/end-user as per those policies normally?
>
>
>
> So does this mean a Community network who provides transit
>
> to residents via wi-fi, could choose to be an IPv6-only service,
>
> and get an end-user /48 and pay annually $100 / year as
>
> an end-user?
>
>
>
>
>
> If that same community network was donated an IPv4 /24,
>
> and wanted to add IPv4 transit would they then hold an
>
> IPv6 assignment and an IPv4 allocation?  Does this mean their
>
> annual fees are
>
> $100 for the IPv6 end-user /48 + $250 for the IPv4 ISP 3X-Small
>
>
>
> OR
>
>
>
> just $250 for the IPv4 ISP 3X-Small (which over rides the end-user fees)
>
>
>
> OR
>
>
>
> are they billed as an end-user
>
> $100 for the IPv6 end-user /48 + $100 for the IPv4 /24
>
>
>
>
>
> Could we eliminate 6.5.9 if \
>
> 1. the 3X-small category was $100?
>
>
>
> 2.A. we change 6.5.2.1.b to read as follows:
>
> " In no case shall an LIR receive smaller than a /32 unless they
>
> specifically request a /36, /40, /44, or /48.
>
> In no case shall an ISP receive more than a /16 initial allocation."
>
>
>
> I'd support a raising of my fees if that was necessary to fix this.
>
>
>
>
>
> ___Jason
>
>
>
>
>
>
>
> On Fri, Sep 22, 2017 at 1:40 AM, Kevin Blumberg <kevinb at thewire.ca> wrote:
>
> Andrew,
>
>
>
> I don?t have a solution for the Information Technology text, other than to
> remove it. It creates a loophole that anything could be considered a
> Community Network.
>
>
>
> Replying to your answers.
>
>
>
> 2) Is charitable organization a synonym or fall under the umbrella of
> non-profit?
>
> AD: My understanding is that this was intended as a synonym, a list of
> descriptors that could be used to define a community network.
>
>                KB: It would make sense to remove Charitable organization
> if it is only a synonym.
>
>
>
> 3) Why is the scope limited to post-secondary institution when many
> smaller communities would not have that? Could accredited educational
> institution be used instead?
>
> AD: The text has been updated to "educational institution"
>
> KB: My apologies on reading the wrong text from the website. Thanks for
> the clarification.
>
>
>
> 4) I agree with Chris W. that "play a large role" is very ambigous.
>
> AD: Do you have a suggestion of text that might be more descriptive?  For
> example would a percentage of revenue / wages ratio be applicable?   That
> was an idea, but I'm not sure one could easily come up with a ratio that
> works.
> KB: The word large could be 15%, depending on who you ask. In TCP/IP 1
> percent loss is large. A non-specific term will more than likely default to
> the lowest possible. I would suggest that majority or 50% are more
> appropriate.
>
>
>
> 5) The last sentence should be reworded completely. Critical functions may
> be handled by paid staff, implies that volunteers shouldn't handle Critical
> functions or that paid staff shouldn't handle menial work?
>
> AD: Should we substitute "Critical" with "Some"?
>
> KB: Changing Critical to Some would be fine.
>
>
>
>
>
> Thanks,
>
>
>
> Kevin Blumberg
>
>
>
>
>
>
>
> *From:* Andrew Dul [mailto:andrew.dul at quark.net]
> *Sent:* Wednesday, September 20, 2017 5:45 PM
> *To:* Kevin Blumberg <kevinb at thewire.ca>; arin-ppml at arin.net
>
>
> *Subject:* Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the
> Definition of Community Network
>
>
>
> On 9/20/2017 11:01 AM, Kevin Blumberg wrote:
> >
> >
> > I am opposed to the policy if it includes ?or other Information
> Technology services?. That would basically be any defined organization that
> has a website.
>
> Do you have a suggestion of what might be more appropriate wording?  We
> were trying to suggest that a community network might provide more than
> basic connectivity.
>
> On 9/20/2017 10:21 AM, Kevin Blumberg wrote:
>
> Andrew,
>
>
>
> Is this the current text of the policy?
>
>
>
> The text on 2017-8 on the website does not match. The text below includes " or other Information Technology services" which does not appear on the website (https://www.arin.net/policy/proposals/2017_8.html)
>
>
>
> Can you please confirm which is the correct version, I have written my repsonses based on the website.
>
>
>
> 1) Can a "Volunteer Group" sign the RSA?
>
> I'll let ARIN staff answer this part.
>
> 2) Is charitable organization a synonym or fall under the umbrella of non-profit?
>
> My understanding is that this was intended as a synonym, a list of
> descriptors that could be used to define a community network.
>
> 3) Why is the scope limited to post-secondary institution when many smaller communities would not have that? Could accredited educational institution be used instead?
>
> The text has been updated to "educational institution"
>
>
>
> 4) I agree with Chris W. that "play a large role" is very ambigous.
>
>
> Do you have a suggestion of text that might be more descriptive?  For
> example would a percentage of revenue / wages ratio be applicable?   That
> was an idea, but I'm not sure one could easily come up with a ratio that
> works.
>
>
>
> 5) The last sentence should be reworded completely. Critical functions may be handled by paid staff, implies that volunteers shouldn't handle Critical functions or that paid staff shouldn't handle menial work?
>
>
> Should we substitute "Critical" with "Some"?
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
>
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>] On Behalf Of Andrew Dul
>
> Sent: Tuesday, September 19, 2017 11:21 AM
>
> To: arin-ppml at arin.net
>
> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network
>
>
>
> Hello all,
>
>
>
> We will be discussing this draft proposal at the upcoming ARIN meeting in San Jose.  If you have comments on the updated draft posted below, we'd certainly like to hear from you so we can help shape the conversation in person.
>
>
>
> We have seen some support for this updated draft, but not a lot.
>
> Furthermore, have we addressed all of your concerns which you might have noted earlier on the 1st version of the policy text.
>
>
>
> Thanks,
>
> Andrew
>
>
>
> On 8/24/2017 8:22 AM, ARIN wrote:
>
>
>
>
>
> Draft Policy ARIN-2017-8: Amend the Definition of Community Network
>
>
>
> Problem Statement:
>
>
>
> The Community Networks section of the NRPM has not been used 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.
>
>
>
> Policy statement:
>
>
>
> CURRENT NRPM TEXT:
>
>
>
> ?2.11. Community Network
>
>
>
> A community network is any network organized and operated by a
>
> volunteer group operating as or under the fiscal support of a
>
> nonprofit organization or university for the purpose of providing free
>
> or low-cost connectivity to the residents of their local service area.
>
> To be treated as a community network under ARIN policy, the applicant
>
> must certify to ARIN that the community network staff is 100%
>
> volunteers.?
>
>
>
> NEW NRPM TEXT:
>
>
>
> ?2.11 Community Network
>
>
>
> A community network is a network organized and operated by a volunteer
>
> group, not-for-profit, non-profit, charitable organization, or
>
> educational institution for the purpose of providing free or low-cost
>
> connectivity, or other Information Technology services to persons or
>
> entities within their community. Critical functions may be handled by
>
> paid staff, but volunteers play a large role in offering services
>
> available through community networks.?
>
>
>
> Comments:
>
>
>
> Timetable for implementation: Immediate _
>
>
>
> _______________________________________________
>
> 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.
>
>
>
>
> _______________________________________________
> 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 <(571)%20266-0006>
>
>
>
>
> ------------------------------
>
> ------------------------------
>
> _______________________________________________
> 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.
>



-- 
===============================================
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
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171003/d60c69cc/attachment.htm>

From daveid at panix.com  Tue Oct  3 19:32:27 2017
From: daveid at panix.com (David Huberman)
Date: Tue, 3 Oct 2017 19:32:27 -0400
Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the
 Definition of Community Network
In-Reply-To: <DM5PR08MB340409E5C326421569E96308C0720@DM5PR08MB3404.namprd08.prod.outlook.com>
References: <d3d50d3e-3c58-607e-e0a6-0ad5358d80dd@arin.net>
 <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net>
 <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local>
 <80cd0ba1-91d6-1ca1-fdd0-f008d3c5c087@quark.net>
 <7E7773B523E82C478734E793E58F69E7A52B32C1@SBS2011.thewireinc.local>
 <CAC4yj2X9qO0Dbu-h_jS-6JKOitwf2E3JQ0BCz3mX9MezG9B7Cg@mail.gmail.com>
 <df16a419cb844592858ec98b2a0ce3db@kz-mail01.manifold.edwardrosekzoo.com>
 <DM5PR08MB340409E5C326421569E96308C0720@DM5PR08MB3404.namprd08.prod.outlook.com>
Message-ID: <765A1483-6CC2-4A09-9187-8F84DD6ABD18@panix.com>

I like this language a lot, and the strong reasoning behind it. 


> On Oct 3, 2017, at 3:52 PM, Richard J Letts <rjletts at uw.edu> wrote:
> 
>  
> My point of view
> a)       I am not sure why educational institutions are not able to pay the fees for other categories of usage, or why they need an exception.
> ARIN staff would need to decide if the application satisfies this: ?a volunteer group, not-for-profit, non-profit, or charitable organization?
>  
> I?ve been involved with enough community groups to know that two of these have weak governance structures that fail when there are conflicts (a volunteer group and being a non-core aspect of a charitable organization), inevitably leading to the collapse of the organization. I?m not going to prejudge that debate here, but consider striking them. If the community organization doesn?t have 501(c)3 status in the US they are leaving out the opportunity to save money and get grants.
>  
> Without a legal entity ?owning? the space how would ARIN know they were dealing with, who is legally allowed to dispose of the space, etc.
>  
> b)      Who cares if they provide ?other Information Technology services? to their community; we?re talking about internet access here
>  
> c)       ?Persons or entities? seems redundant (It is like saying ?people or not people?); who/what are the not a person and not an entity that are excluded?
>  
> d)      I am not sure what is considered critical? Digging ditches? Pulling fiber? Responding to ARIN requests? Filing forms with the IRS?
> As an example I?m on the board of a non-profit. We decide on the aims, manage the membership, etc. but we pay [independent 1099] contractors for services (editing and printing the newsletter, performing at concerts, concert sound, etc.). Some of these are non-critical (the newsletter), some are critical (the performers), volunteers some critical things (IRS tax returns, state registrations) and some non-critical things (run the website)
>  
> So I think I end up with something with fewer words.
> ?A community network is a network organized and operated by a volunteer group, not-for-profit, non-profit, or charitable organization
>  for the purpose of providing free or low-cost connectivity within their community. Volunteers play a large role in directing the activity of the organization, but some functions may be handled by paid staff.?
>  
>  
> /RjL
>  
>  
> ?2.11 Community Network
>  
> A community network is a network organized and operated by a volunteer 
> group, not-for-profit, non-profit, charitable organization, or 
> educational institution for the purpose of providing free or low-cost 
> connectivity, or other Information Technology services to persons or 
> entities within their community. Critical functions may be handled by 
> paid staff, but volunteers play a large role in offering services 
> available through community networks.?
>  
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171003/49f2ff4a/attachment.htm>

From farmer at umn.edu  Tue Oct  3 20:34:33 2017
From: farmer at umn.edu (David Farmer)
Date: Tue, 3 Oct 2017 19:34:33 -0500
Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the
 Definition of Community Network
In-Reply-To: <DM5PR08MB340409E5C326421569E96308C0720@DM5PR08MB3404.namprd08.prod.outlook.com>
References: <d3d50d3e-3c58-607e-e0a6-0ad5358d80dd@arin.net>
 <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net>
 <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local>
 <80cd0ba1-91d6-1ca1-fdd0-f008d3c5c087@quark.net>
 <7E7773B523E82C478734E793E58F69E7A52B32C1@SBS2011.thewireinc.local>
 <CAC4yj2X9qO0Dbu-h_jS-6JKOitwf2E3JQ0BCz3mX9MezG9B7Cg@mail.gmail.com>
 <df16a419cb844592858ec98b2a0ce3db@kz-mail01.manifold.edwardrosekzoo.com>
 <DM5PR08MB340409E5C326421569E96308C0720@DM5PR08MB3404.namprd08.prod.outlook.com>
Message-ID: <CAN-Dau193J0C+=nO14Jkbmn2GVXSPPUZ2Qb6LGVbe3cLNPtU6Q@mail.gmail.com>

On Tue, Oct 3, 2017 at 2:52 PM, Richard J Letts <rjletts at uw.edu> wrote:

>
>
> My point of view
>
> a)       I am not sure why educational institutions are not able to pay
> the fees for other categories of usage, or why they need an exception.
>
> ARIN staff would need to decide if the application satisfies this: ?a
> volunteer group, not-for-profit, non-profit, or charitable organization?
>
>  I?ve been involved with enough community groups to know that two of
> these have weak governance structures that fail when there are conflicts (a
> volunteer group and being a non-core aspect of a charitable organization),
> inevitably leading to the collapse of the organization. I?m not going to
> prejudge that debate here, but consider striking them. If the community
> organization doesn?t have 501(c)3 status in the US they are leaving out the
> opportunity to save money and get grants.
>
> Without a legal entity ?owning? the space how would ARIN know they were
> dealing with, who is legally allowed to dispose of the space, etc.
>
Does it matter if they are non-profit?  I believe that was originally
included with the hopes that the board to offer a discount.  The board has
hasn't provided a discount, I doubt they ever will.  The board did provided
the 3X-small fee category, which by policy is not available to ISPs. What
if community networks are allowed to be a 3X-small ISPs, the basic idea
behind ARIN-2016-7. Having community networks be 3X-Small ISPs seems to be
more aligned with what they are doing, it allows them to SWIP, where if
they are an end-user they can not.

So, again, does it matter if they are non-profit?  How a bout we focus on
what they are and what do, rather than how they are incorporated or
registered.

ISOC says;

"Community networks, communications infrastructure deployed and operated by
citizens to meet their own communication needs, are being increasingly
proposed as a solution to connect the unconnected."

https://www.internetsociety.org/issues/community-networks/

Citizen isn't the right word for here, but how about users?  So how about
something like this.

"A community network is a network deployed, operated and governed by it's
users, with a purpose of providing free or low-cost connectivity within to
its user's and the community in which they reside?"

By going to 3X-small ISP, if a community network is or gets big they pay
the same as any other ISP of their size, if they are truly small they have
access to the 3X-small ISP fee category.  And, ARIN staff doesn't have to
poke its nose into the financial status of an organization, for-profit or
non-profit.

> b)      Who cares if they provide ?other Information Technology services?
> to their community; we?re talking about internet access here
>
 If in addition to "connectivity" they also provide email or web hosting is
that OK?

Thanks.

-- 
===============================================
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
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171003/cdc2be88/attachment.htm>

From rudi.daniel at gmail.com  Wed Oct  4 11:47:30 2017
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Wed, 4 Oct 2017 11:47:30 -0400
Subject: [arin-ppml] 2017-8 community networks
In-Reply-To: <CA+uaoiUbcE0Oueu0zo4=6b5T2Epdv3+rOdJn=FQ9j82xJfnk7w@mail.gmail.com>
References: <CA+uaoiWnA1rQVeq4pGG5Qq5RQqgm5yVuXnK_hRgubKuTLD_uOw@mail.gmail.com>
 <CA+uaoiUbcE0Oueu0zo4=6b5T2Epdv3+rOdJn=FQ9j82xJfnk7w@mail.gmail.com>
Message-ID: <CA+uaoiWsVLF_tmLY3LpDM9SpgOtRvq-YtnL5ZcjvXUdb=de4Mw@mail.gmail.com>

A community network is a network organized and operated by a volunteer
group, not-for-profit, non-profit, or charitable organization
>  for the purpose of providing free or low-cost connectivity within their
community. Volunteers play a large role in directing the activity of the
organization, but some functions may be handled by paid staff.?

The above suggested definition seems a good deal more tidy that others I
have read.
rd

On Oct 3, 2017 5:35 PM, <arin-ppml-request at arin.net> wrote:

Send ARIN-PPML mailing list submissions to
        arin-ppml at arin.net

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
        arin-ppml-request at arin.net

You can reach the person managing the list at
        arin-ppml-owner at arin.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."


Today's Topics:

   1. Re: Revised: Draft Policy ARIN-2017-8: Amend the Definition
      of Community Network (David Huberman)
   2. Re: Revised: Draft Policy ARIN-2017-8: Amend the Definition
      of Community Network (David Farmer)


----------------------------------------------------------------------

Message: 1
Date: Tue, 3 Oct 2017 19:32:27 -0400
From: David Huberman <daveid at panix.com>
To: Richard J Letts <rjletts at uw.edu>
Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the
        Definition of Community Network
Message-ID: <765A1483-6CC2-4A09-9187-8F84DD6ABD18 at panix.com>
Content-Type: text/plain; charset="utf-8"

I like this language a lot, and the strong reasoning behind it.


> On Oct 3, 2017, at 3:52 PM, Richard J Letts <rjletts at uw.edu> wrote:
>
>
> My point of view
> a)       I am not sure why educational institutions are not able to pay
the fees for other categories of usage, or why they need an exception.
> ARIN staff would need to decide if the application satisfies this: ?a
volunteer group, not-for-profit, non-profit, or charitable organization?
>
> I?ve been involved with enough community groups to know that two of these
have weak governance structures that fail when there are conflicts (a
volunteer group and being a non-core aspect of a charitable organization),
inevitably leading to the collapse of the organization. I?m not going to
prejudge that debate here, but consider striking them. If the community
organization doesn?t have 501(c)3 status in the US they are leaving out the
opportunity to save money and get grants.
>
> Without a legal entity ?owning? the space how would ARIN know they were
dealing with, who is legally allowed to dispose of the space, etc.
>
> b)      Who cares if they provide ?other Information Technology services?
to their community; we?re talking about internet access here
>
> c)       ?Persons or entities? seems redundant (It is like saying ?people
or not people?); who/what are the not a person and not an entity that are
excluded?
>
> d)      I am not sure what is considered critical? Digging ditches?
Pulling fiber? Responding to ARIN requests? Filing forms with the IRS?
> As an example I?m on the board of a non-profit. We decide on the aims,
manage the membership, etc. but we pay [independent 1099] contractors for
services (editing and printing the newsletter, performing at concerts,
concert sound, etc.). Some of these are non-critical (the newsletter), some
are critical (the performers), volunteers some critical things (IRS tax
returns, state registrations) and some non-critical things (run the website)
>
> So I think I end up with something with fewer words.
> ?A community network is a network organized and operated by a volunteer
group, not-for-profit, non-profit, or charitable organization
>  for the purpose of providing free or low-cost connectivity within their
community. Volunteers play a large role in directing the activity of the
organization, but some functions may be handled by paid staff.?
>
>
> /RjL
>
>
> ?2.11 Community Network
>
> A community network is a network organized and operated by a volunteer
> group, not-for-profit, non-profit, charitable organization, or
> educational institution for the purpose of providing free or low-cost
> connectivity, or other Information Technology services to persons or
> entities within their community. Critical functions may be handled by
> paid staff, but volunteers play a large role in offering services
> available through community networks.?
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/
attachments/20171003/49f2ff4a/attachment-0001.html>

------------------------------

Message: 2
Date: Tue, 3 Oct 2017 19:34:33 -0500
From: David Farmer <farmer at umn.edu>
To: Richard J Letts <rjletts at uw.edu>
Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the
        Definition of Community Network
Message-ID:
        <CAN-Dau193J0C+=nO14Jkbmn2GVXSPPUZ2Qb6LGVbe3cLNPtU6Q at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Tue, Oct 3, 2017 at 2:52 PM, Richard J Letts <rjletts at uw.edu> wrote:

>
>
> My point of view
>
> a)       I am not sure why educational institutions are not able to pay
> the fees for other categories of usage, or why they need an exception.
>
> ARIN staff would need to decide if the application satisfies this: ?a
> volunteer group, not-for-profit, non-profit, or charitable organization?
>
>  I?ve been involved with enough community groups to know that two of
> these have weak governance structures that fail when there are conflicts
(a
> volunteer group and being a non-core aspect of a charitable organization),
> inevitably leading to the collapse of the organization. I?m not going to
> prejudge that debate here, but consider striking them. If the community
> organization doesn?t have 501(c)3 status in the US they are leaving out
the
> opportunity to save money and get grants.
>
> Without a legal entity ?owning? the space how would ARIN know they were
> dealing with, who is legally allowed to dispose of the space, etc.
>
Does it matter if they are non-profit?  I believe that was originally
included with the hopes that the board to offer a discount.  The board has
hasn't provided a discount, I doubt they ever will.  The board did provided
the 3X-small fee category, which by policy is not available to ISPs. What
if community networks are allowed to be a 3X-small ISPs, the basic idea
behind ARIN-2016-7. Having community networks be 3X-Small ISPs seems to be
more aligned with what they are doing, it allows them to SWIP, where if
they are an end-user they can not.

So, again, does it matter if they are non-profit?  How a bout we focus on
what they are and what do, rather than how they are incorporated or
registered.

ISOC says;

"Community networks, communications infrastructure deployed and operated by
citizens to meet their own communication needs, are being increasingly
proposed as a solution to connect the unconnected."

https://www.internetsociety.org/issues/community-networks/

Citizen isn't the right word for here, but how about users?  So how about
something like this.

"A community network is a network deployed, operated and governed by it's
users, with a purpose of providing free or low-cost connectivity within to
its user's and the community in which they reside?"

By going to 3X-small ISP, if a community network is or gets big they pay
the same as any other ISP of their size, if they are truly small they have
access to the 3X-small ISP fee category.  And, ARIN staff doesn't have to
poke its nose into the financial status of an organization, for-profit or
non-profit.

> b)      Who cares if they provide ?other Information Technology services?
> to their community; we?re talking about internet access here
>
 If in addition to "connectivity" they also provide email or web hosting is
that OK?

Thanks.

--
===============================================
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
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/
attachments/20171003/cdc2be88/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
ARIN-PPML mailing list
ARIN-PPML at arin.net
http://lists.arin.net/mailman/listinfo/arin-ppml

------------------------------

End of ARIN-PPML Digest, Vol 148, Issue 5
*****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171004/a06ce803/attachment.htm>

From narten at us.ibm.com  Fri Oct  6 00:53:27 2017
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 06 Oct 2017 00:53:27 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201710060453.v964rS8b013068@rotala.raleigh.ibm.com>

Total of 23 messages in the last 7 days.
 
script run at: Fri Oct  6 00:53:22 EDT 2017
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 13.04% |    3 | 21.90% |   174383 | mwinters at edwardrose.com
 13.04% |    3 | 15.80% |   125871 | rudi.daniel at gmail.com
 13.04% |    3 | 11.35% |    90388 | farmer at umn.edu
  8.70% |    2 |  9.75% |    77673 | jschiller at google.com
  4.35% |    1 |  9.75% |    77689 | lsawyer at gci.com
  8.70% |    2 |  5.01% |    39938 | john at egh.com
  8.70% |    2 |  3.19% |    25384 | jcurran at arin.net
  4.35% |    1 |  7.21% |    57408 | owen at delong.com
  4.35% |    1 |  4.54% |    36142 | rjletts at uw.edu
  4.35% |    1 |  3.30% |    26316 | matthew.wilder at telus.com
  4.35% |    1 |  3.24% |    25782 | daveid at panix.com
  4.35% |    1 |  2.57% |    20480 | michael at linuxmagic.com
  4.35% |    1 |  1.20% |     9518 | hostmaster at uneedus.com
  4.35% |    1 |  1.18% |     9432 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |   23 |100.00% |   796404 | Total



From hostmaster at uneedus.com  Sat Oct  7 19:17:38 2017
From: hostmaster at uneedus.com (hostmaster at uneedus.com)
Date: Sat, 7 Oct 2017 19:17:38 -0400 (EDT)
Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6
 Registration Requirements
In-Reply-To: <d5c806287af449239ed35124b3d1237b@BTWP000229.corp.ads>
References: <c3ef71a6-fbef-5b1f-ed4b-792f6083ab6e@arin.net>
 <CAC4yj2VaU6EF=VgM7ZJjTwBYe9_Y=DMhP21b3s8qH8dvkdn7gA@mail.gmail.com>
 <CAC4yj2VcQnkGQYaMr3hkhkDHZhN7GP4jt9hQbnd4K+wJpzcfHg@mail.gmail.com>
 <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net>
 <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local>
 <CAN-Dau1t9NWnPmi0LbjHUM9_mmuVCH+s9TEjpowFu=NLJTLvTA@mail.gmail.com>
 <CAC4yj2UOTLNkGCLm8GMRJUNOFwWhw0ZxZdMsTSRB6RBzUM0D+A@mail.gmail.com>
 <53f61942-1409-a7e1-0ffb-bd129d879827@linuxmagic.com>
 <625212a0-e72e-2b80-ce0f-c70b50dca7fb@egh.com>
 <d5c806287af449239ed35124b3d1237b@BTWP000229.corp.ads>
Message-ID: <Pine.LNX.4.64.1710071911240.20122@localhost.localdomain>

I noticed at ARIN40, that "shall" had more votes, and zero "no" votes, 
as compared to "should".

Just wondering, what happens/will happen next?

Albert Erdmann
Network Administrator
Paradise On Line Inc.



From dewole at forum.org.ng  Sun Oct  8 09:18:33 2017
From: dewole at forum.org.ng (Dewole Ajao)
Date: Sun, 8 Oct 2017 06:18:33 -0700
Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6
 Registration Requirements
In-Reply-To: <Pine.LNX.4.64.1710071911240.20122@localhost.localdomain>
References: <c3ef71a6-fbef-5b1f-ed4b-792f6083ab6e@arin.net>
 <CAC4yj2VaU6EF=VgM7ZJjTwBYe9_Y=DMhP21b3s8qH8dvkdn7gA@mail.gmail.com>
 <CAC4yj2VcQnkGQYaMr3hkhkDHZhN7GP4jt9hQbnd4K+wJpzcfHg@mail.gmail.com>
 <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net>
 <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local>
 <CAN-Dau1t9NWnPmi0LbjHUM9_mmuVCH+s9TEjpowFu=NLJTLvTA@mail.gmail.com>
 <CAC4yj2UOTLNkGCLm8GMRJUNOFwWhw0ZxZdMsTSRB6RBzUM0D+A@mail.gmail.com>
 <53f61942-1409-a7e1-0ffb-bd129d879827@linuxmagic.com>
 <625212a0-e72e-2b80-ce0f-c70b50dca7fb@egh.com>
 <d5c806287af449239ed35124b3d1237b@BTWP000229.corp.ads>
 <Pine.LNX.4.64.1710071911240.20122@localhost.localdomain>
Message-ID: <73708E8E-C140-43FC-8069-1D714BC8A213@forum.org.ng>

Hi Albert,

You would also have noticed that almost everyone seemed fine with "should" as a fallback position if the use of "shall" would pose a delay to general acceptance. 

If I were to guess, "should" would go through and a discussion would be started regarding how to enforce a "shall" in a reasonable manner. 

My thoughts anyway. 

Dewole. 

Sent from a mobile device. Please excuse typos and autocorrect strangeness. 

> On 7 Oct 2017, at 4:17 PM, hostmaster at uneedus.com wrote:
> 
> I noticed at ARIN40, that "shall" had more votes, and zero "no" votes, as compared to "should".
> 
> Just wondering, what happens/will happen next?
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> _______________________________________________
> 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.



From chris at semihuman.com  Sun Oct  8 12:09:10 2017
From: chris at semihuman.com (Chris Woodfield)
Date: Sun, 8 Oct 2017 09:09:10 -0700
Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6
 Registration Requirements
In-Reply-To: <73708E8E-C140-43FC-8069-1D714BC8A213@forum.org.ng>
References: <c3ef71a6-fbef-5b1f-ed4b-792f6083ab6e@arin.net>
 <CAC4yj2VaU6EF=VgM7ZJjTwBYe9_Y=DMhP21b3s8qH8dvkdn7gA@mail.gmail.com>
 <CAC4yj2VcQnkGQYaMr3hkhkDHZhN7GP4jt9hQbnd4K+wJpzcfHg@mail.gmail.com>
 <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net>
 <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local>
 <CAN-Dau1t9NWnPmi0LbjHUM9_mmuVCH+s9TEjpowFu=NLJTLvTA@mail.gmail.com>
 <CAC4yj2UOTLNkGCLm8GMRJUNOFwWhw0ZxZdMsTSRB6RBzUM0D+A@mail.gmail.com>
 <53f61942-1409-a7e1-0ffb-bd129d879827@linuxmagic.com>
 <625212a0-e72e-2b80-ce0f-c70b50dca7fb@egh.com>
 <d5c806287af449239ed35124b3d1237b@BTWP000229.corp.ads>
 <Pine.LNX.4.64.1710071911240.20122@localhost.localdomain>
 <73708E8E-C140-43FC-8069-1D714BC8A213@forum.org.ng>
Message-ID: <7B0B66A2-5F48-46B1-BA76-85158F390538@semihuman.com>

There was discussion on this topic during the meeting (and prior to the meeting, from ARIN staff here on list), with the guidance being that the ?shall? being proposed here would be enforced similarly to every other occurrence of ?shall? as it appears in the NRPM; it becomes part of the RSA like any other adopted proposal that makes it through the PDP.

Don?t forget that in general, this proposal is a *relaxing* of current terms, which currently requires registering *all* static assignments up to /64; the keyword in 6.5.5.1 is *already* ?shall?.

-C

> On Oct 8, 2017, at 6:18 AM, Dewole Ajao <dewole at forum.org.ng> wrote:
> 
> 
> 
> If I were to guess, "should" would go through and a discussion would be started regarding how to enforce a "shall" in a reasonable manner. 
> 
> My thoughts anyway. 
> 
> Dewole. 
> 
> 
> 



From jcurran at arin.net  Sun Oct  8 16:32:25 2017
From: jcurran at arin.net (John Curran)
Date: Sun, 8 Oct 2017 20:32:25 +0000
Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6
 Registration Requirements
In-Reply-To: <Pine.LNX.4.64.1710071911240.20122@localhost.localdomain>
References: <c3ef71a6-fbef-5b1f-ed4b-792f6083ab6e@arin.net>
 <CAC4yj2VaU6EF=VgM7ZJjTwBYe9_Y=DMhP21b3s8qH8dvkdn7gA@mail.gmail.com>
 <CAC4yj2VcQnkGQYaMr3hkhkDHZhN7GP4jt9hQbnd4K+wJpzcfHg@mail.gmail.com>
 <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net>
 <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local>
 <CAN-Dau1t9NWnPmi0LbjHUM9_mmuVCH+s9TEjpowFu=NLJTLvTA@mail.gmail.com>
 <CAC4yj2UOTLNkGCLm8GMRJUNOFwWhw0ZxZdMsTSRB6RBzUM0D+A@mail.gmail.com>
 <53f61942-1409-a7e1-0ffb-bd129d879827@linuxmagic.com>
 <625212a0-e72e-2b80-ce0f-c70b50dca7fb@egh.com>
 <d5c806287af449239ed35124b3d1237b@BTWP000229.corp.ads>
 <Pine.LNX.4.64.1710071911240.20122@localhost.localdomain>
Message-ID: <FDA63CA3-6513-4CE9-AD10-B58C091BA973@arin.net>

On 7 Oct 2017, at 4:17 PM, hostmaster at uneedus.com<mailto:hostmaster at uneedus.com> wrote:

I noticed at ARIN40, that "shall" had more votes, and zero "no" votes, as compared to "should".

Just wondering, what happens/will happen next?

Per <https://www.arin.net/policy/pdp.html> ?

6. Confirming Community Support for Recommended Draft Policies

The Advisory Council confirms community support for Recommended Draft Policies, and this is done by polling community support for the policy change during a Public Policy Consultation.

The AC should carefully weigh the community support shown for a Recommended Draft Policy.  Absence of clear community support is a strong indication that policy abandonment should be considered. A low level of overall support without opposition for a Recommended Draft Policy suggests further discussion of the merits of the policy change or abandonment. A clear split in the community support suggests that the AC should revise the Recommended Draft Policy to accommodate the concerns raised or further explain its consideration of the matter.

A Recommended Draft Policy that has demonstrated clear support (and only relatively low opposition for well-understood reasons) may be advanced to Last Call by the AC within 60 days of its Public Policy Consultation.
?
If the AC sends a Recommended Draft Policy different than the Recommended Draft Policy presented during the Public Policy Consultation, then the Advisory Council will provide a detailed explanation for all changes to the text and these specific changes must have been discussed during the community consultation.

So, the ARIN AC meets and reviews the discussion (including the polls for community support)
and considers whether to send either version of the policy to last call, explaining any/all changes
made to the final text based on the discussion that occurred during the ARIN40 public policy
consultation.

This generally occurs promptly after the ARIN meeting, so you can expect shortly several
announcements about their consideration of each draft policy and the policy status changes
that occur as a result.

Thanks!
/John

John Curran
President and CEO
ARIN

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171008/e714b4f0/attachment.htm>

From info at arin.net  Wed Oct 11 15:09:39 2017
From: info at arin.net (ARIN)
Date: Wed, 11 Oct 2017 15:09:39 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2017
Message-ID: <d5e87ce9-de55-7ecc-ca63-6cd2f2dd44fe@arin.net>

In accordance with the Policy Development Process (PDP), the Advisory 
Council (AC) met on 6 October 2017.



The AC has abandoned the following:

* Draft Policy ARIN-2017-6: Improve Reciprocity Requirement for 
Inter-RIR Transfers

The AC provided the following statement:

"The ARIN Advisory Council has chosen to abandon Policy Proposal 2017-6, 
  ?Improve Reciprocity Requirement for Inter-RIR Transfers?.  This 
proposal did not gain sufficient community support to justify continuing 
to move this policy forward, and as such, the policy has been abandoned."

Anyone dissatisfied with this decision may initiate a petition. The 
deadline to begin a petition will be five business days after the AC's 
draft meeting minutes are published.



The AC has advanced the following to a Last Call period ending 10 
November 2017 (will be posted separately for discussion):

* Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration 
Requirements

The AC provided the following statement regarding policy text revision 
prior to Last Call:

"Based on strong community support - on both the Public Policy Mailing 
List and in person at ARIN 40 during the policy consultation - for 
replacing the "should" qualifier in section 6.5.5.4 with "shall", the 
Advisory Council, after careful review and discussion, has made the 
requested change to the text."



The AC is continuing to work on:

* Draft Policy ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation
* Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR 
Transfers
* Draft Policy ARIN-2017-8: Amend the Definition of Community Network



The PDP can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)


From info at arin.net  Wed Oct 11 15:16:34 2017
From: info at arin.net (ARIN)
Date: Wed, 11 Oct 2017 15:16:34 -0400
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
Message-ID: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>

The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send 
the following to Last Call:

Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration 
Requirements

The AC provided the following statement to the community:

"Based on strong community support - on both the Public Policy Mailing 
List and in person at ARIN 40 during the policy consultation - for
replacing the "should" qualifier in section 6.5.5.4 with "shall", the 
Advisory Council, after careful review and discussion, has made the 
requested change to the text."

Feedback is encouraged during the Last Call period. All comments should 
be provided to the Public Policy Mailing List. This Last Call period 
will expire on 10 November 2017. After Last Call, the AC will conduct 
their Last Call review.

The full text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)



AC's Statement of Conformance with ARIN's Principles of Internet Number 
Resource Policy:

This proposal is technically sound and enables fair and impartial number 
policy for easier IPv6 Registrations. The staff and legal review noted a 
single clarification issue which has been addressed. There is ample 
support for the proposal on PPML and no concerns have been raised by the 
community regarding the proposal.

Problem Statement:

Current ARIN policy has different WHOIS directory registration 
requirements for IPv4 vs IPv6 address assignments. IPv4 registration is 
triggered for an assignment of any address block equal to or greater 
than a /29 (i.e., eight IPv4 addresses). In the case of IPv6, 
registration occurs for an assignment of any block equal to or greater 
than a /64, which constitutes one entire IPv6 subnet and is the minimum 
block size for an allocation. Accordingly, there is a significant 
disparity between IPv4 and IPv6 WHOIS registration thresholds in the 
case of assignments, resulting in more work in the case of IPv6 than is 
the case for IPv4. There is no technical or policy rationale for the 
disparity, which could serve as a deterrent to more rapid IPv6 adoption. 
The purpose of this proposal is to eliminate the disparity and 
corresponding adverse consequences.

Policy statement:

1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to 
strike "assignment containing a /64 or more addresses" and change to 
"re-allocation, reassignment containing a /47 or more addresses, or 
subdelegation of any size that will be individually announced,?

and

2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the 
NRPM to strike the text "4.2.3.7.1" and change to ?6.5.5.1"

and

3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM 
by deleting the phrase "holding /64 and larger blocks"

and

4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the 
NRPM, to read: "If the downstream recipient of a static assignment of 
/64 or more addresses requests publishing of that assignment in ARIN's 
registration database, the ISP shall register that assignment as 
described in section 6.5.5.1."

Comments:

a.    Timetable for implementation: Policy should be adopted as soon as 
possible.

b.    Anything else:

Author Comments:

IPv6 should not be more burdensome than the equivalent IPv4 network 
size. Currently, assignments of /29 or more of IPv4 space (8 addresses) 
require registration. The greatest majority of ISP customers who have 
assignments of IPv4 space are of a single IPv4 address which do not 
trigger any ARIN registration requirement when using IPv4. This is NOT 
true when these same exact customers use IPv6, as assignments of /64 or 
more of IPv6 space require registration. Beginning with RFC 3177, it has 
been standard practice to assign a minimum assignment of /64 to every 
customer end user site, and less is never used. This means that ALL IPv6 
assignments, including those customers that only use a single IPv4 
address must be registered with ARIN if they are given the minimum 
assignment of /64 of IPv6 space. This additional effort may prevent 
ISP's from giving IPv6 addresses because of the additional expense of 
registering those addresses with ARIN, which is not required for IPv4. 
The administrative burden of 100% customer registration of IPv6 
customers is unreasonable, when such is not required for those customers 
receiving only IPv4 connections.


From scottleibrand at gmail.com  Wed Oct 11 15:27:37 2017
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 11 Oct 2017 12:27:37 -0700
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
In-Reply-To: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
References: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
Message-ID: <CAGkMwz7-WoAz_NiFGWab0NEvCV0QvmPAd0-0rzn_p9W0DvQu8Q@mail.gmail.com>

+1 - Support as written.

I know +1's aren't strictly needed in Last Call, but I want to explicitly
state that I agree with the AC that sufficient consideration and discussion
was given to the "should" vs. "shall" question before and during the PPM,
and therefore I agree it is appropriate to send the policy to Last Call
(and on to the board, if no un-considered objections are raised) without
another public policy meeting/consultation.

-Scott

On Wed, Oct 11, 2017 at 12:16 PM, ARIN <info at arin.net> wrote:

> The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send
> the following to Last Call:
>
> Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration
> Requirements
>
> The AC provided the following statement to the community:
>
> "Based on strong community support - on both the Public Policy Mailing
> List and in person at ARIN 40 during the policy consultation - for
> replacing the "should" qualifier in section 6.5.5.4 with "shall", the
> Advisory Council, after careful review and discussion, has made the
> requested change to the text."
>
> Feedback is encouraged during the Last Call period. All comments should be
> provided to the Public Policy Mailing List. This Last Call period will
> expire on 10 November 2017. After Last Call, the AC will conduct their Last
> Call review.
>
> The full text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> AC's Statement of Conformance with ARIN's Principles of Internet Number
> Resource Policy:
>
> This proposal is technically sound and enables fair and impartial number
> policy for easier IPv6 Registrations. The staff and legal review noted a
> single clarification issue which has been addressed. There is ample support
> for the proposal on PPML and no concerns have been raised by the community
> regarding the proposal.
>
> Problem Statement:
>
> Current ARIN policy has different WHOIS directory registration
> requirements for IPv4 vs IPv6 address assignments. IPv4 registration is
> triggered for an assignment of any address block equal to or greater than a
> /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs
> for an assignment of any block equal to or greater than a /64, which
> constitutes one entire IPv6 subnet and is the minimum block size for an
> allocation. Accordingly, there is a significant disparity between IPv4 and
> IPv6 WHOIS registration thresholds in the case of assignments, resulting in
> more work in the case of IPv6 than is the case for IPv4. There is no
> technical or policy rationale for the disparity, which could serve as a
> deterrent to more rapid IPv6 adoption. The purpose of this proposal is to
> eliminate the disparity and corresponding adverse consequences.
>
> Policy statement:
>
> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike
> "assignment containing a /64 or more addresses" and change to
> "re-allocation, reassignment containing a /47 or more addresses, or
> subdelegation of any size that will be individually announced,?
>
> and
>
> 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM
> to strike the text "4.2.3.7.1" and change to ?6.5.5.1"
>
> and
>
> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by
> deleting the phrase "holding /64 and larger blocks"
>
> and
>
> 4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the
> NRPM, to read: "If the downstream recipient of a static assignment of /64
> or more addresses requests publishing of that assignment in ARIN's
> registration database, the ISP shall register that assignment as described
> in section 6.5.5.1."
>
> Comments:
>
> a.    Timetable for implementation: Policy should be adopted as soon as
> possible.
>
> b.    Anything else:
>
> Author Comments:
>
> IPv6 should not be more burdensome than the equivalent IPv4 network size.
> Currently, assignments of /29 or more of IPv4 space (8 addresses) require
> registration. The greatest majority of ISP customers who have assignments
> of IPv4 space are of a single IPv4 address which do not trigger any ARIN
> registration requirement when using IPv4. This is NOT true when these same
> exact customers use IPv6, as assignments of /64 or more of IPv6 space
> require registration. Beginning with RFC 3177, it has been standard
> practice to assign a minimum assignment of /64 to every customer end user
> site, and less is never used. This means that ALL IPv6 assignments,
> including those customers that only use a single IPv4 address must be
> registered with ARIN if they are given the minimum assignment of /64 of
> IPv6 space. This additional effort may prevent ISP's from giving IPv6
> addresses because of the additional expense of registering those addresses
> with ARIN, which is not required for IPv4. The administrative burden of
> 100% customer registration of IPv6 customers is unreasonable, when such is
> not required for those customers receiving only IPv4 connections.
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171011/18e764af/attachment.htm>

From gary.buhrmaster at gmail.com  Wed Oct 11 15:30:29 2017
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Wed, 11 Oct 2017 19:30:29 +0000
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
In-Reply-To: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
References: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
Message-ID: <CAMfXtQyFhBn6j3JiRsr-XXcPr2SDb7--uM9iaRF91a0=Mg7pqw@mail.gmail.com>

On Wed, Oct 11, 2017 at 7:16 PM, ARIN <info at arin.net> wrote:
> The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send the
> following to Last Call:
>
> Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration
> Requirements
>
> Feedback is encouraged during the Last Call period.

Support as written.


From cblecker at gmail.com  Wed Oct 11 15:35:41 2017
From: cblecker at gmail.com (Christoph Blecker)
Date: Wed, 11 Oct 2017 12:35:41 -0700
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
In-Reply-To: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
References: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
Message-ID: <CADx2oGGPS6xHzJ6gXGYF==HWAPnx6f3QAndiH7Gaa8e5kZFBUQ@mail.gmail.com>

Strongly support as written.

Cheers,
Christoph

On 11 October 2017 at 12:16, ARIN <info at arin.net> wrote:

> The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send
> the following to Last Call:
>
> Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration
> Requirements
>
> The AC provided the following statement to the community:
>
> "Based on strong community support - on both the Public Policy Mailing
> List and in person at ARIN 40 during the policy consultation - for
> replacing the "should" qualifier in section 6.5.5.4 with "shall", the
> Advisory Council, after careful review and discussion, has made the
> requested change to the text."
>
> Feedback is encouraged during the Last Call period. All comments should be
> provided to the Public Policy Mailing List. This Last Call period will
> expire on 10 November 2017. After Last Call, the AC will conduct their Last
> Call review.
>
> The full text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> AC's Statement of Conformance with ARIN's Principles of Internet Number
> Resource Policy:
>
> This proposal is technically sound and enables fair and impartial number
> policy for easier IPv6 Registrations. The staff and legal review noted a
> single clarification issue which has been addressed. There is ample support
> for the proposal on PPML and no concerns have been raised by the community
> regarding the proposal.
>
> Problem Statement:
>
> Current ARIN policy has different WHOIS directory registration
> requirements for IPv4 vs IPv6 address assignments. IPv4 registration is
> triggered for an assignment of any address block equal to or greater than a
> /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs
> for an assignment of any block equal to or greater than a /64, which
> constitutes one entire IPv6 subnet and is the minimum block size for an
> allocation. Accordingly, there is a significant disparity between IPv4 and
> IPv6 WHOIS registration thresholds in the case of assignments, resulting in
> more work in the case of IPv6 than is the case for IPv4. There is no
> technical or policy rationale for the disparity, which could serve as a
> deterrent to more rapid IPv6 adoption. The purpose of this proposal is to
> eliminate the disparity and corresponding adverse consequences.
>
> Policy statement:
>
> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike
> "assignment containing a /64 or more addresses" and change to
> "re-allocation, reassignment containing a /47 or more addresses, or
> subdelegation of any size that will be individually announced,?
>
> and
>
> 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM
> to strike the text "4.2.3.7.1" and change to ?6.5.5.1"
>
> and
>
> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by
> deleting the phrase "holding /64 and larger blocks"
>
> and
>
> 4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the
> NRPM, to read: "If the downstream recipient of a static assignment of /64
> or more addresses requests publishing of that assignment in ARIN's
> registration database, the ISP shall register that assignment as described
> in section 6.5.5.1."
>
> Comments:
>
> a.    Timetable for implementation: Policy should be adopted as soon as
> possible.
>
> b.    Anything else:
>
> Author Comments:
>
> IPv6 should not be more burdensome than the equivalent IPv4 network size.
> Currently, assignments of /29 or more of IPv4 space (8 addresses) require
> registration. The greatest majority of ISP customers who have assignments
> of IPv4 space are of a single IPv4 address which do not trigger any ARIN
> registration requirement when using IPv4. This is NOT true when these same
> exact customers use IPv6, as assignments of /64 or more of IPv6 space
> require registration. Beginning with RFC 3177, it has been standard
> practice to assign a minimum assignment of /64 to every customer end user
> site, and less is never used. This means that ALL IPv6 assignments,
> including those customers that only use a single IPv4 address must be
> registered with ARIN if they are given the minimum assignment of /64 of
> IPv6 space. This additional effort may prevent ISP's from giving IPv6
> addresses because of the additional expense of registering those addresses
> with ARIN, which is not required for IPv4. The administrative burden of
> 100% customer registration of IPv6 customers is unreasonable, when such is
> not required for those customers receiving only IPv4 connections.
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171011/c6d3a7c0/attachment.htm>

From hvgeekwtrvl at gmail.com  Wed Oct 11 16:28:03 2017
From: hvgeekwtrvl at gmail.com (james machado)
Date: Wed, 11 Oct 2017 13:28:03 -0700
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
In-Reply-To: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
References: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
Message-ID: <CADVasu69OxWt9qhg1MU9Rc40vipnucvDZ-cRdReeGozCyfEe7Q@mail.gmail.com>

Support as written.

James

On Wed, Oct 11, 2017 at 12:16 PM, ARIN <info at arin.net> wrote:

> The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send
> the following to Last Call:
>
> Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration
> Requirements
>
> The AC provided the following statement to the community:
>
> "Based on strong community support - on both the Public Policy Mailing
> List and in person at ARIN 40 during the policy consultation - for
> replacing the "should" qualifier in section 6.5.5.4 with "shall", the
> Advisory Council, after careful review and discussion, has made the
> requested change to the text."
>
> Feedback is encouraged during the Last Call period. All comments should be
> provided to the Public Policy Mailing List. This Last Call period will
> expire on 10 November 2017. After Last Call, the AC will conduct their Last
> Call review.
>
> The full text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> AC's Statement of Conformance with ARIN's Principles of Internet Number
> Resource Policy:
>
> This proposal is technically sound and enables fair and impartial number
> policy for easier IPv6 Registrations. The staff and legal review noted a
> single clarification issue which has been addressed. There is ample support
> for the proposal on PPML and no concerns have been raised by the community
> regarding the proposal.
>
> Problem Statement:
>
> Current ARIN policy has different WHOIS directory registration
> requirements for IPv4 vs IPv6 address assignments. IPv4 registration is
> triggered for an assignment of any address block equal to or greater than a
> /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs
> for an assignment of any block equal to or greater than a /64, which
> constitutes one entire IPv6 subnet and is the minimum block size for an
> allocation. Accordingly, there is a significant disparity between IPv4 and
> IPv6 WHOIS registration thresholds in the case of assignments, resulting in
> more work in the case of IPv6 than is the case for IPv4. There is no
> technical or policy rationale for the disparity, which could serve as a
> deterrent to more rapid IPv6 adoption. The purpose of this proposal is to
> eliminate the disparity and corresponding adverse consequences.
>
> Policy statement:
>
> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike
> "assignment containing a /64 or more addresses" and change to
> "re-allocation, reassignment containing a /47 or more addresses, or
> subdelegation of any size that will be individually announced,?
>
> and
>
> 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM
> to strike the text "4.2.3.7.1" and change to ?6.5.5.1"
>
> and
>
> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by
> deleting the phrase "holding /64 and larger blocks"
>
> and
>
> 4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the
> NRPM, to read: "If the downstream recipient of a static assignment of /64
> or more addresses requests publishing of that assignment in ARIN's
> registration database, the ISP shall register that assignment as described
> in section 6.5.5.1."
>
> Comments:
>
> a.    Timetable for implementation: Policy should be adopted as soon as
> possible.
>
> b.    Anything else:
>
> Author Comments:
>
> IPv6 should not be more burdensome than the equivalent IPv4 network size.
> Currently, assignments of /29 or more of IPv4 space (8 addresses) require
> registration. The greatest majority of ISP customers who have assignments
> of IPv4 space are of a single IPv4 address which do not trigger any ARIN
> registration requirement when using IPv4. This is NOT true when these same
> exact customers use IPv6, as assignments of /64 or more of IPv6 space
> require registration. Beginning with RFC 3177, it has been standard
> practice to assign a minimum assignment of /64 to every customer end user
> site, and less is never used. This means that ALL IPv6 assignments,
> including those customers that only use a single IPv4 address must be
> registered with ARIN if they are given the minimum assignment of /64 of
> IPv6 space. This additional effort may prevent ISP's from giving IPv6
> addresses because of the additional expense of registering those addresses
> with ARIN, which is not required for IPv4. The administrative burden of
> 100% customer registration of IPv6 customers is unreasonable, when such is
> not required for those customers receiving only IPv4 connections.
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171011/9bdb217a/attachment.htm>

From rudi.daniel at gmail.com  Wed Oct 11 17:15:31 2017
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Wed, 11 Oct 2017 17:15:31 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 148, Issue 8
In-Reply-To: <mailman.42876.1507750565.16601.arin-ppml@arin.net>
References: <mailman.42876.1507750565.16601.arin-ppml@arin.net>
Message-ID: <CA+uaoiWTrUTbc2BWyoKn6PsdPUybs7rwCUCeKmj=BONuK5FVNw@mail.gmail.com>

+1 - Support as written.

I know +1's aren't strictly needed in Last Call, but I want to explicitly
state that I agree with the AC that sufficient consideration and discussion
was given to the "should" vs. "shall" question before and during the PPM,
and therefore I agree it is appropriate to send the policy to Last Call
(and on to the board, if no un-considered objections are raised) without
another public policy meeting/consultation.

-Scott

As Scott above.
rd

On Oct 11, 2017 3:36 PM, <arin-ppml-request at arin.net> wrote:

> Send ARIN-PPML mailing list submissions to
>         arin-ppml at arin.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
>         arin-ppml-request at arin.net
>
> You can reach the person managing the list at
>         arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
>    1. Re: LAST CALL - Recommended Draft Policy ARIN-2017-5:
>       Improved IPv6 Registration Requirements (Scott Leibrand)
>    2. Re: LAST CALL - Recommended Draft Policy ARIN-2017-5:
>       Improved IPv6 Registration Requirements (Gary Buhrmaster)
>    3. Re: LAST CALL - Recommended Draft Policy ARIN-2017-5:
>       Improved IPv6 Registration Requirements (Christoph Blecker)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 11 Oct 2017 12:27:37 -0700
> From: Scott Leibrand <scottleibrand at gmail.com>
> To: ARIN-PPML List <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] LAST CALL - Recommended Draft Policy
>         ARIN-2017-5: Improved IPv6 Registration Requirements
> Message-ID:
>         <CAGkMwz7-WoAz_NiFGWab0NEvCV0QvmPAd0-0rzn_
> p9W0DvQu8Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> +1 - Support as written.
>
> I know +1's aren't strictly needed in Last Call, but I want to explicitly
> state that I agree with the AC that sufficient consideration and discussion
> was given to the "should" vs. "shall" question before and during the PPM,
> and therefore I agree it is appropriate to send the policy to Last Call
> (and on to the board, if no un-considered objections are raised) without
> another public policy meeting/consultation.
>
> -Scott
>
> On Wed, Oct 11, 2017 at 12:16 PM, ARIN <info at arin.net> wrote:
>
> > The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send
> > the following to Last Call:
> >
> > Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration
> > Requirements
> >
> > The AC provided the following statement to the community:
> >
> > "Based on strong community support - on both the Public Policy Mailing
> > List and in person at ARIN 40 during the policy consultation - for
> > replacing the "should" qualifier in section 6.5.5.4 with "shall", the
> > Advisory Council, after careful review and discussion, has made the
> > requested change to the text."
> >
> > Feedback is encouraged during the Last Call period. All comments should
> be
> > provided to the Public Policy Mailing List. This Last Call period will
> > expire on 10 November 2017. After Last Call, the AC will conduct their
> Last
> > Call review.
> >
> > The full text is below and available at:
> > https://www.arin.net/policy/proposals/
> >
> > The ARIN Policy Development Process is available at:
> > https://www.arin.net/policy/pdp.html
> >
> > Regards,
> >
> > Sean Hopkins
> > Policy Analyst
> > American Registry for Internet Numbers (ARIN)
> >
> >
> >
> > AC's Statement of Conformance with ARIN's Principles of Internet Number
> > Resource Policy:
> >
> > This proposal is technically sound and enables fair and impartial number
> > policy for easier IPv6 Registrations. The staff and legal review noted a
> > single clarification issue which has been addressed. There is ample
> support
> > for the proposal on PPML and no concerns have been raised by the
> community
> > regarding the proposal.
> >
> > Problem Statement:
> >
> > Current ARIN policy has different WHOIS directory registration
> > requirements for IPv4 vs IPv6 address assignments. IPv4 registration is
> > triggered for an assignment of any address block equal to or greater
> than a
> > /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration
> occurs
> > for an assignment of any block equal to or greater than a /64, which
> > constitutes one entire IPv6 subnet and is the minimum block size for an
> > allocation. Accordingly, there is a significant disparity between IPv4
> and
> > IPv6 WHOIS registration thresholds in the case of assignments, resulting
> in
> > more work in the case of IPv6 than is the case for IPv4. There is no
> > technical or policy rationale for the disparity, which could serve as a
> > deterrent to more rapid IPv6 adoption. The purpose of this proposal is to
> > eliminate the disparity and corresponding adverse consequences.
> >
> > Policy statement:
> >
> > 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike
> > "assignment containing a /64 or more addresses" and change to
> > "re-allocation, reassignment containing a /47 or more addresses, or
> > subdelegation of any size that will be individually announced,?
> >
> > and
> >
> > 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM
> > to strike the text "4.2.3.7.1" and change to ?6.5.5.1"
> >
> > and
> >
> > 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by
> > deleting the phrase "holding /64 and larger blocks"
> >
> > and
> >
> > 4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the
> > NRPM, to read: "If the downstream recipient of a static assignment of /64
> > or more addresses requests publishing of that assignment in ARIN's
> > registration database, the ISP shall register that assignment as
> described
> > in section 6.5.5.1."
> >
> > Comments:
> >
> > a.    Timetable for implementation: Policy should be adopted as soon as
> > possible.
> >
> > b.    Anything else:
> >
> > Author Comments:
> >
> > IPv6 should not be more burdensome than the equivalent IPv4 network size.
> > Currently, assignments of /29 or more of IPv4 space (8 addresses) require
> > registration. The greatest majority of ISP customers who have assignments
> > of IPv4 space are of a single IPv4 address which do not trigger any ARIN
> > registration requirement when using IPv4. This is NOT true when these
> same
> > exact customers use IPv6, as assignments of /64 or more of IPv6 space
> > require registration. Beginning with RFC 3177, it has been standard
> > practice to assign a minimum assignment of /64 to every customer end user
> > site, and less is never used. This means that ALL IPv6 assignments,
> > including those customers that only use a single IPv4 address must be
> > registered with ARIN if they are given the minimum assignment of /64 of
> > IPv6 space. This additional effort may prevent ISP's from giving IPv6
> > addresses because of the additional expense of registering those
> addresses
> > with ARIN, which is not required for IPv4. The administrative burden of
> > 100% customer registration of IPv6 customers is unreasonable, when such
> is
> > not required for those customers receiving only IPv4 connections.
> > _______________________________________________
> > 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.arin.net/pipermail/arin-ppml/
> attachments/20171011/18e764af/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 11 Oct 2017 19:30:29 +0000
> From: Gary Buhrmaster <gary.buhrmaster at gmail.com>
> To: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] LAST CALL - Recommended Draft Policy
>         ARIN-2017-5: Improved IPv6 Registration Requirements
> Message-ID:
>         <CAMfXtQyFhBn6j3JiRsr-XXcPr2SDb7--uM9iaRF91a0=Mg7pqw
> @mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, Oct 11, 2017 at 7:16 PM, ARIN <info at arin.net> wrote:
> > The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send
> the
> > following to Last Call:
> >
> > Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration
> > Requirements
> >
> > Feedback is encouraged during the Last Call period.
>
> Support as written.
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 11 Oct 2017 12:35:41 -0700
> From: Christoph Blecker <cblecker at gmail.com>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] LAST CALL - Recommended Draft Policy
>         ARIN-2017-5: Improved IPv6 Registration Requirements
> Message-ID:
>         <CADx2oGGPS6xHzJ6gXGYF==HWAPnx6f3QAndiH7Gaa8e5kZFBUQ at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Strongly support as written.
>
> Cheers,
> Christoph
>
> On 11 October 2017 at 12:16, ARIN <info at arin.net> wrote:
>
> > The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send
> > the following to Last Call:
> >
> > Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration
> > Requirements
> >
> > The AC provided the following statement to the community:
> >
> > "Based on strong community support - on both the Public Policy Mailing
> > List and in person at ARIN 40 during the policy consultation - for
> > replacing the "should" qualifier in section 6.5.5.4 with "shall", the
> > Advisory Council, after careful review and discussion, has made the
> > requested change to the text."
> >
> > Feedback is encouraged during the Last Call period. All comments should
> be
> > provided to the Public Policy Mailing List. This Last Call period will
> > expire on 10 November 2017. After Last Call, the AC will conduct their
> Last
> > Call review.
> >
> > The full text is below and available at:
> > https://www.arin.net/policy/proposals/
> >
> > The ARIN Policy Development Process is available at:
> > https://www.arin.net/policy/pdp.html
> >
> > Regards,
> >
> > Sean Hopkins
> > Policy Analyst
> > American Registry for Internet Numbers (ARIN)
> >
> >
> >
> > AC's Statement of Conformance with ARIN's Principles of Internet Number
> > Resource Policy:
> >
> > This proposal is technically sound and enables fair and impartial number
> > policy for easier IPv6 Registrations. The staff and legal review noted a
> > single clarification issue which has been addressed. There is ample
> support
> > for the proposal on PPML and no concerns have been raised by the
> community
> > regarding the proposal.
> >
> > Problem Statement:
> >
> > Current ARIN policy has different WHOIS directory registration
> > requirements for IPv4 vs IPv6 address assignments. IPv4 registration is
> > triggered for an assignment of any address block equal to or greater
> than a
> > /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration
> occurs
> > for an assignment of any block equal to or greater than a /64, which
> > constitutes one entire IPv6 subnet and is the minimum block size for an
> > allocation. Accordingly, there is a significant disparity between IPv4
> and
> > IPv6 WHOIS registration thresholds in the case of assignments, resulting
> in
> > more work in the case of IPv6 than is the case for IPv4. There is no
> > technical or policy rationale for the disparity, which could serve as a
> > deterrent to more rapid IPv6 adoption. The purpose of this proposal is to
> > eliminate the disparity and corresponding adverse consequences.
> >
> > Policy statement:
> >
> > 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike
> > "assignment containing a /64 or more addresses" and change to
> > "re-allocation, reassignment containing a /47 or more addresses, or
> > subdelegation of any size that will be individually announced,?
> >
> > and
> >
> > 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM
> > to strike the text "4.2.3.7.1" and change to ?6.5.5.1"
> >
> > and
> >
> > 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by
> > deleting the phrase "holding /64 and larger blocks"
> >
> > and
> >
> > 4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the
> > NRPM, to read: "If the downstream recipient of a static assignment of /64
> > or more addresses requests publishing of that assignment in ARIN's
> > registration database, the ISP shall register that assignment as
> described
> > in section 6.5.5.1."
> >
> > Comments:
> >
> > a.    Timetable for implementation: Policy should be adopted as soon as
> > possible.
> >
> > b.    Anything else:
> >
> > Author Comments:
> >
> > IPv6 should not be more burdensome than the equivalent IPv4 network size.
> > Currently, assignments of /29 or more of IPv4 space (8 addresses) require
> > registration. The greatest majority of ISP customers who have assignments
> > of IPv4 space are of a single IPv4 address which do not trigger any ARIN
> > registration requirement when using IPv4. This is NOT true when these
> same
> > exact customers use IPv6, as assignments of /64 or more of IPv6 space
> > require registration. Beginning with RFC 3177, it has been standard
> > practice to assign a minimum assignment of /64 to every customer end user
> > site, and less is never used. This means that ALL IPv6 assignments,
> > including those customers that only use a single IPv4 address must be
> > registered with ARIN if they are given the minimum assignment of /64 of
> > IPv6 space. This additional effort may prevent ISP's from giving IPv6
> > addresses because of the additional expense of registering those
> addresses
> > with ARIN, which is not required for IPv4. The administrative burden of
> > 100% customer registration of IPv6 customers is unreasonable, when such
> is
> > not required for those customers receiving only IPv4 connections.
> > _______________________________________________
> > 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.arin.net/pipermail/arin-ppml/
> attachments/20171011/c6d3a7c0/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> ------------------------------
>
> End of ARIN-PPML Digest, Vol 148, Issue 8
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171011/778ec07c/attachment.htm>

From carlton.samuels at gmail.com  Wed Oct 11 19:25:20 2017
From: carlton.samuels at gmail.com (Carlton Samuels)
Date: Wed, 11 Oct 2017 18:25:20 -0500
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
In-Reply-To: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
References: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
Message-ID: <CAOZQb9QbNqoDRMT7KM7Wuo8NZqT-MD+70Q8ZHHeeF1XpSg2gQg@mail.gmail.com>

Support as written.

-CAS


==============================
*Carlton A Samuels*

*Mobile: 876-818-1799Strategy, Planning, Governance, Assessment &
Turnaround*
=============================

On Wed, Oct 11, 2017 at 2:16 PM, ARIN <info at arin.net> wrote:

> The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send
> the following to Last Call:
>
> Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration
> Requirements
>
> The AC provided the following statement to the community:
>
> "Based on strong community support - on both the Public Policy Mailing
> List and in person at ARIN 40 during the policy consultation - for
> replacing the "should" qualifier in section 6.5.5.4 with "shall", the
> Advisory Council, after careful review and discussion, has made the
> requested change to the text."
>
> Feedback is encouraged during the Last Call period. All comments should be
> provided to the Public Policy Mailing List. This Last Call period will
> expire on 10 November 2017. After Last Call, the AC will conduct their Last
> Call review.
>
> The full text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> AC's Statement of Conformance with ARIN's Principles of Internet Number
> Resource Policy:
>
> This proposal is technically sound and enables fair and impartial number
> policy for easier IPv6 Registrations. The staff and legal review noted a
> single clarification issue which has been addressed. There is ample support
> for the proposal on PPML and no concerns have been raised by the community
> regarding the proposal.
>
> Problem Statement:
>
> Current ARIN policy has different WHOIS directory registration
> requirements for IPv4 vs IPv6 address assignments. IPv4 registration is
> triggered for an assignment of any address block equal to or greater than a
> /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs
> for an assignment of any block equal to or greater than a /64, which
> constitutes one entire IPv6 subnet and is the minimum block size for an
> allocation. Accordingly, there is a significant disparity between IPv4 and
> IPv6 WHOIS registration thresholds in the case of assignments, resulting in
> more work in the case of IPv6 than is the case for IPv4. There is no
> technical or policy rationale for the disparity, which could serve as a
> deterrent to more rapid IPv6 adoption. The purpose of this proposal is to
> eliminate the disparity and corresponding adverse consequences.
>
> Policy statement:
>
> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike
> "assignment containing a /64 or more addresses" and change to
> "re-allocation, reassignment containing a /47 or more addresses, or
> subdelegation of any size that will be individually announced,?
>
> and
>
> 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM
> to strike the text "4.2.3.7.1" and change to ?6.5.5.1"
>
> and
>
> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by
> deleting the phrase "holding /64 and larger blocks"
>
> and
>
> 4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the
> NRPM, to read: "If the downstream recipient of a static assignment of /64
> or more addresses requests publishing of that assignment in ARIN's
> registration database, the ISP shall register that assignment as described
> in section 6.5.5.1."
>
> Comments:
>
> a.    Timetable for implementation: Policy should be adopted as soon as
> possible.
>
> b.    Anything else:
>
> Author Comments:
>
> IPv6 should not be more burdensome than the equivalent IPv4 network size.
> Currently, assignments of /29 or more of IPv4 space (8 addresses) require
> registration. The greatest majority of ISP customers who have assignments
> of IPv4 space are of a single IPv4 address which do not trigger any ARIN
> registration requirement when using IPv4. This is NOT true when these same
> exact customers use IPv6, as assignments of /64 or more of IPv6 space
> require registration. Beginning with RFC 3177, it has been standard
> practice to assign a minimum assignment of /64 to every customer end user
> site, and less is never used. This means that ALL IPv6 assignments,
> including those customers that only use a single IPv4 address must be
> registered with ARIN if they are given the minimum assignment of /64 of
> IPv6 space. This additional effort may prevent ISP's from giving IPv6
> addresses because of the additional expense of registering those addresses
> with ARIN, which is not required for IPv4. The administrative burden of
> 100% customer registration of IPv6 customers is unreasonable, when such is
> not required for those customers receiving only IPv4 connections.
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171011/9141a72e/attachment.htm>

From owen at delong.com  Wed Oct 11 19:29:53 2017
From: owen at delong.com (Owen DeLong)
Date: Wed, 11 Oct 2017 16:29:53 -0700
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
In-Reply-To: <CAOZQb9QbNqoDRMT7KM7Wuo8NZqT-MD+70Q8ZHHeeF1XpSg2gQg@mail.gmail.com>
References: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
 <CAOZQb9QbNqoDRMT7KM7Wuo8NZqT-MD+70Q8ZHHeeF1XpSg2gQg@mail.gmail.com>
Message-ID: <01C82F8F-3DD9-46A9-8293-CDEC65699FEF@delong.com>

I?d like to request that if anyone objects to the change made in sending the recommended draft to last call (should->shall), they make that clear.

I believe we it is likely ?Support as written? will actually be interpreted as ?Support as amended and sent to last call?.

Sorry for being pedantic, but as an AC member, I?d like to make sure that we have the clearest possible understanding of community intent as we move forward.

Thanks,

Owen

> On Oct 11, 2017, at 4:25 PM, Carlton Samuels <carlton.samuels at gmail.com> wrote:
> 
> Support as written.
> 
> -CAS
> 
> 
> ==============================
> Carlton A Samuels
> Mobile: 876-818-1799
> Strategy, Planning, Governance, Assessment & Turnaround
> =============================
> 
> On Wed, Oct 11, 2017 at 2:16 PM, ARIN <info at arin.net <mailto:info at arin.net>> wrote:
> The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send the following to Last Call:
> 
> Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements
> 
> The AC provided the following statement to the community:
> 
> "Based on strong community support - on both the Public Policy Mailing List and in person at ARIN 40 during the policy consultation - for
> replacing the "should" qualifier in section 6.5.5.4 with "shall", the Advisory Council, after careful review and discussion, has made the requested change to the text."
> 
> Feedback is encouraged during the Last Call period. All comments should be provided to the Public Policy Mailing List. This Last Call period will expire on 10 November 2017. After Last Call, the AC will conduct their Last Call review.
> 
> The full text is below and available at:
> https://www.arin.net/policy/proposals/ <https://www.arin.net/policy/proposals/>
> 
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html <https://www.arin.net/policy/pdp.html>
> 
> Regards,
> 
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> 
> 
> AC's Statement of Conformance with ARIN's Principles of Internet Number Resource Policy:
> 
> This proposal is technically sound and enables fair and impartial number policy for easier IPv6 Registrations. The staff and legal review noted a single clarification issue which has been addressed. There is ample support for the proposal on PPML and no concerns have been raised by the community regarding the proposal.
> 
> Problem Statement:
> 
> Current ARIN policy has different WHOIS directory registration requirements for IPv4 vs IPv6 address assignments. IPv4 registration is triggered for an assignment of any address block equal to or greater than a /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs for an assignment of any block equal to or greater than a /64, which constitutes one entire IPv6 subnet and is the minimum block size for an allocation. Accordingly, there is a significant disparity between IPv4 and IPv6 WHOIS registration thresholds in the case of assignments, resulting in more work in the case of IPv6 than is the case for IPv4. There is no technical or policy rationale for the disparity, which could serve as a deterrent to more rapid IPv6 adoption. The purpose of this proposal is to eliminate the disparity and corresponding adverse consequences.
> 
> Policy statement:
> 
> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike "assignment containing a /64 or more addresses" and change to "re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any size that will be individually announced,?
> 
> and
> 
> 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM to strike the text "4.2.3.7.1" and change to ?6.5.5.1"
> 
> and
> 
> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by deleting the phrase "holding /64 and larger blocks"
> 
> and
> 
> 4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP shall register that assignment as described in section 6.5.5.1."
> 
> Comments:
> 
> a.    Timetable for implementation: Policy should be adopted as soon as possible.
> 
> b.    Anything else:
> 
> Author Comments:
> 
> IPv6 should not be more burdensome than the equivalent IPv4 network size. Currently, assignments of /29 or more of IPv4 space (8 addresses) require registration. The greatest majority of ISP customers who have assignments of IPv4 space are of a single IPv4 address which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6, as assignments of /64 or more of IPv6 space require registration. Beginning with RFC 3177, it has been standard practice to assign a minimum assignment of /64 to every customer end user site, and less is never used. This means that ALL IPv6 assignments, including those customers that only use a single IPv4 address must be registered with ARIN if they are given the minimum assignment of /64 of IPv6 space. This additional effort may prevent ISP's from giving IPv6 addresses because of the additional expense of registering those addresses with ARIN, which is not required for IPv4. The administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
> 
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171011/dc14f3c0/attachment.htm>

From jschiller at google.com  Thu Oct 12 09:39:26 2017
From: jschiller at google.com (Jason Schiller)
Date: Thu, 12 Oct 2017 09:39:26 -0400
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
In-Reply-To: <01C82F8F-3DD9-46A9-8293-CDEC65699FEF@delong.com>
References: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
 <CAOZQb9QbNqoDRMT7KM7Wuo8NZqT-MD+70Q8ZHHeeF1XpSg2gQg@mail.gmail.com>
 <01C82F8F-3DD9-46A9-8293-CDEC65699FEF@delong.com>
Message-ID: <CAC4yj2Vst2vGs1ntV86OFV_vMyiXC+JaM7mFraxxVe3e_u92mA@mail.gmail.com>

Support as written (amended with Shall).

As a follow up to Owen, clarity is important.
I urge those who do not support it as written (amended with Shall)
to also note if they would support it without the shall amendment.


Also as a separate question to supporting the proposal
is if the process is supported.

Can the PPM chair call separate questions?
Yes.

Can the Shepherd / AC make (minor) text changes after the 30 day freeze?
Yes.

Was there adequate discussion of the change on list and at the meeting?
Yes.

___Jason





On Wed, Oct 11, 2017 at 7:29 PM, Owen DeLong <owen at delong.com> wrote:

> I?d like to request that if anyone objects to the change made in sending
> the recommended draft to last call (should->shall), they make that clear.
>
> I believe we it is likely ?Support as written? will actually be
> interpreted as ?Support as amended and sent to last call?.
>
> Sorry for being pedantic, but as an AC member, I?d like to make sure that
> we have the clearest possible understanding of community intent as we move
> forward.
>
> Thanks,
>
> Owen
>
> On Oct 11, 2017, at 4:25 PM, Carlton Samuels <carlton.samuels at gmail.com>
> wrote:
>
> Support as written.
>
> -CAS
>
>
> ==============================
> *Carlton A Samuels*
>
> *Mobile: 876-818-1799 <(876)%20818-1799>Strategy, Planning, Governance,
> Assessment & Turnaround*
> =============================
>
> On Wed, Oct 11, 2017 at 2:16 PM, ARIN <info at arin.net> wrote:
>
>> The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send
>> the following to Last Call:
>>
>> Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration
>> Requirements
>>
>> The AC provided the following statement to the community:
>>
>> "Based on strong community support - on both the Public Policy Mailing
>> List and in person at ARIN 40 during the policy consultation - for
>> replacing the "should" qualifier in section 6.5.5.4 with "shall", the
>> Advisory Council, after careful review and discussion, has made the
>> requested change to the text."
>>
>> Feedback is encouraged during the Last Call period. All comments should
>> be provided to the Public Policy Mailing List. This Last Call period will
>> expire on 10 November 2017. After Last Call, the AC will conduct their Last
>> Call review.
>>
>> The full text is below and available at:
>> https://www.arin.net/policy/proposals/
>>
>> The ARIN Policy Development Process is available at:
>> https://www.arin.net/policy/pdp.html
>>
>> Regards,
>>
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>> AC's Statement of Conformance with ARIN's Principles of Internet Number
>> Resource Policy:
>>
>> This proposal is technically sound and enables fair and impartial number
>> policy for easier IPv6 Registrations. The staff and legal review noted a
>> single clarification issue which has been addressed. There is ample support
>> for the proposal on PPML and no concerns have been raised by the community
>> regarding the proposal.
>>
>> Problem Statement:
>>
>> Current ARIN policy has different WHOIS directory registration
>> requirements for IPv4 vs IPv6 address assignments. IPv4 registration is
>> triggered for an assignment of any address block equal to or greater than a
>> /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs
>> for an assignment of any block equal to or greater than a /64, which
>> constitutes one entire IPv6 subnet and is the minimum block size for an
>> allocation. Accordingly, there is a significant disparity between IPv4 and
>> IPv6 WHOIS registration thresholds in the case of assignments, resulting in
>> more work in the case of IPv6 than is the case for IPv4. There is no
>> technical or policy rationale for the disparity, which could serve as a
>> deterrent to more rapid IPv6 adoption. The purpose of this proposal is to
>> eliminate the disparity and corresponding adverse consequences.
>>
>> Policy statement:
>>
>> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike
>> "assignment containing a /64 or more addresses" and change to
>> "re-allocation, reassignment containing a /47 or more addresses, or
>> subdelegation of any size that will be individually announced,?
>>
>> and
>>
>> 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM
>> to strike the text "4.2.3.7.1" and change to ?6.5.5.1"
>>
>> and
>>
>> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by
>> deleting the phrase "holding /64 and larger blocks"
>>
>> and
>>
>> 4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the
>> NRPM, to read: "If the downstream recipient of a static assignment of /64
>> or more addresses requests publishing of that assignment in ARIN's
>> registration database, the ISP shall register that assignment as described
>> in section 6.5.5.1."
>>
>> Comments:
>>
>> a.    Timetable for implementation: Policy should be adopted as soon as
>> possible.
>>
>> b.    Anything else:
>>
>> Author Comments:
>>
>> IPv6 should not be more burdensome than the equivalent IPv4 network size.
>> Currently, assignments of /29 or more of IPv4 space (8 addresses) require
>> registration. The greatest majority of ISP customers who have assignments
>> of IPv4 space are of a single IPv4 address which do not trigger any ARIN
>> registration requirement when using IPv4. This is NOT true when these same
>> exact customers use IPv6, as assignments of /64 or more of IPv6 space
>> require registration. Beginning with RFC 3177, it has been standard
>> practice to assign a minimum assignment of /64 to every customer end user
>> site, and less is never used. This means that ALL IPv6 assignments,
>> including those customers that only use a single IPv4 address must be
>> registered with ARIN if they are given the minimum assignment of /64 of
>> IPv6 space. This additional effort may prevent ISP's from giving IPv6
>> addresses because of the additional expense of registering those addresses
>> with ARIN, which is not required for IPv4. The administrative burden of
>> 100% customer registration of IPv6 customers is unreasonable, when such is
>> not required for those customers receiving only IPv4 connections.
>> _______________________________________________
>> 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.
>
>
> _______________________________________________
> 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.
>
>
>
> _______________________________________________
> 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/20171012/ec6250bf/attachment.htm>

From mwinters at edwardrose.com  Thu Oct 12 10:33:21 2017
From: mwinters at edwardrose.com (Michael Winters)
Date: Thu, 12 Oct 2017 14:33:21 +0000
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
In-Reply-To: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
References: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
Message-ID: <d82a1558ab474476afff303a58671e1d@kz-mail01.manifold.edwardrosekzoo.com>

Opposed as written (amended).

As written, (IMHO) it is an incomplete and unenforceable policy (shall part anyway).
If you are saying shall, what is the policy for ARIN to follow if there is noncompliance.
In attempting to fix a potential problem that does not yet exist, due to the word shall, this policy creates a problem.

Should have stuck with should.

Thanks,
Mike

-----Original Message-----
From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
Sent: Wednesday, October 11, 2017 3:17 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send the following to Last Call:

Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

The AC provided the following statement to the community:

"Based on strong community support - on both the Public Policy Mailing List and in person at ARIN 40 during the policy consultation - for replacing the "should" qualifier in section 6.5.5.4 with "shall", the Advisory Council, after careful review and discussion, has made the requested change to the text."

Feedback is encouraged during the Last Call period. All comments should be provided to the Public Policy Mailing List. This Last Call period will expire on 10 November 2017. After Last Call, the AC will conduct their Last Call review.

The full text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)



AC's Statement of Conformance with ARIN's Principles of Internet Number Resource Policy:

This proposal is technically sound and enables fair and impartial number policy for easier IPv6 Registrations. The staff and legal review noted a single clarification issue which has been addressed. There is ample support for the proposal on PPML and no concerns have been raised by the community regarding the proposal.

Problem Statement:

Current ARIN policy has different WHOIS directory registration requirements for IPv4 vs IPv6 address assignments. IPv4 registration is triggered for an assignment of any address block equal to or greater than a /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs for an assignment of any block equal to or greater than a /64, which constitutes one entire IPv6 subnet and is the minimum block size for an allocation. Accordingly, there is a significant disparity between IPv4 and IPv6 WHOIS registration thresholds in the case of assignments, resulting in more work in the case of IPv6 than is the case for IPv4. There is no technical or policy rationale for the disparity, which could serve as a deterrent to more rapid IPv6 adoption.
The purpose of this proposal is to eliminate the disparity and corresponding adverse consequences.

Policy statement:

1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike "assignment containing a /64 or more addresses" and change to "re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any size that will be individually announced,?

and

2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM to strike the text "4.2.3.7.1" and change to ?6.5.5.1"

and

3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by deleting the phrase "holding /64 and larger blocks"

and

4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of
/64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP shall register that assignment as described in section 6.5.5.1."

Comments:

a.    Timetable for implementation: Policy should be adopted as soon as
possible.

b.    Anything else:

Author Comments:

IPv6 should not be more burdensome than the equivalent IPv4 network size. Currently, assignments of /29 or more of IPv4 space (8 addresses) require registration. The greatest majority of ISP customers who have assignments of IPv4 space are of a single IPv4 address which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6, as assignments of /64 or more of IPv6 space require registration. Beginning with RFC 3177, it has been standard practice to assign a minimum assignment of /64 to every customer end user site, and less is never used. This means that ALL IPv6 assignments, including those customers that only use a single IPv4 address must be registered with ARIN if they are given the minimum assignment of /64 of IPv6 space. This additional effort may prevent ISP's from giving IPv6 addresses because of the additional expense of registering those addresses with ARIN, which is not required for IPv4.
The administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections.
_______________________________________________
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.
________________________


________________________


From mike at iptrading.com  Thu Oct 12 10:39:03 2017
From: mike at iptrading.com (Mike Burns)
Date: Thu, 12 Oct 2017 10:39:03 -0400
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
In-Reply-To: <d82a1558ab474476afff303a58671e1d@kz-mail01.manifold.edwardrosekzoo.com>
References: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
 <d82a1558ab474476afff303a58671e1d@kz-mail01.manifold.edwardrosekzoo.com>
Message-ID: <00f701d34367$d9fe23c0$8dfa6b40$@iptrading.com>

+1 to "Should have stuck with should."

I also oppose as written (amended) for the same reasons described below.

Regards,
Mike Burns



-----Original Message-----
From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Winters
Sent: Thursday, October 12, 2017 10:33 AM
To: ARIN <info at arin.net>; arin-ppml at arin.net
Subject: Re: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

Opposed as written (amended).

As written, (IMHO) it is an incomplete and unenforceable policy (shall part anyway).
If you are saying shall, what is the policy for ARIN to follow if there is noncompliance.
In attempting to fix a potential problem that does not yet exist, due to the word shall, this policy creates a problem.

Should have stuck with should.

Thanks,
Mike

-----Original Message-----
From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
Sent: Wednesday, October 11, 2017 3:17 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send the following to Last Call:

Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

The AC provided the following statement to the community:

"Based on strong community support - on both the Public Policy Mailing List and in person at ARIN 40 during the policy consultation - for replacing the "should" qualifier in section 6.5.5.4 with "shall", the Advisory Council, after careful review and discussion, has made the requested change to the text."

Feedback is encouraged during the Last Call period. All comments should be provided to the Public Policy Mailing List. This Last Call period will expire on 10 November 2017. After Last Call, the AC will conduct their Last Call review.

The full text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)



AC's Statement of Conformance with ARIN's Principles of Internet Number Resource Policy:

This proposal is technically sound and enables fair and impartial number policy for easier IPv6 Registrations. The staff and legal review noted a single clarification issue which has been addressed. There is ample support for the proposal on PPML and no concerns have been raised by the community regarding the proposal.

Problem Statement:

Current ARIN policy has different WHOIS directory registration requirements for IPv4 vs IPv6 address assignments. IPv4 registration is triggered for an assignment of any address block equal to or greater than a /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs for an assignment of any block equal to or greater than a /64, which constitutes one entire IPv6 subnet and is the minimum block size for an allocation. Accordingly, there is a significant disparity between IPv4 and IPv6 WHOIS registration thresholds in the case of assignments, resulting in more work in the case of IPv6 than is the case for IPv4. There is no technical or policy rationale for the disparity, which could serve as a deterrent to more rapid IPv6 adoption.
The purpose of this proposal is to eliminate the disparity and corresponding adverse consequences.

Policy statement:

1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike "assignment containing a /64 or more addresses" and change to "re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any size that will be individually announced,?

and

2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM to strike the text "4.2.3.7.1" and change to ?6.5.5.1"

and

3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by deleting the phrase "holding /64 and larger blocks"

and

4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of
/64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP shall register that assignment as described in section 6.5.5.1."

Comments:

a.    Timetable for implementation: Policy should be adopted as soon as
possible.

b.    Anything else:

Author Comments:

IPv6 should not be more burdensome than the equivalent IPv4 network size. Currently, assignments of /29 or more of IPv4 space (8 addresses) require registration. The greatest majority of ISP customers who have assignments of IPv4 space are of a single IPv4 address which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6, as assignments of /64 or more of IPv6 space require registration. Beginning with RFC 3177, it has been standard practice to assign a minimum assignment of /64 to every customer end user site, and less is never used. This means that ALL IPv6 assignments, including those customers that only use a single IPv4 address must be registered with ARIN if they are given the minimum assignment of /64 of IPv6 space. This additional effort may prevent ISP's from giving IPv6 addresses because of the additional expense of registering those addresses with ARIN, which is not required for IPv4.
The administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections.
_______________________________________________
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.
________________________


________________________

_______________________________________________
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.



From chris at semihuman.com  Thu Oct 12 10:54:19 2017
From: chris at semihuman.com (Chris Woodfield)
Date: Thu, 12 Oct 2017 07:54:19 -0700
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
In-Reply-To: <d82a1558ab474476afff303a58671e1d@kz-mail01.manifold.edwardrosekzoo.com>
References: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
 <d82a1558ab474476afff303a58671e1d@kz-mail01.manifold.edwardrosekzoo.com>
Message-ID: <ED4F9973-7AA2-4199-8924-747557BE8FAD@semihuman.com>

I?ll note the existing section text, emphasis mine:

"6.5.5.1. Reassignment information
Each static IPv6 assignment containing a /64 or more addresses *shall* be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations *shall* include each client's organizational information, except where specifically exempted by this policy.
6.5.5.2. Assignments visible within 7 days
All assignments *shall* be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment.?

Guidance from staff on this matter has been discussed before on PPML. For example, John Curran?s comment from 9/30/2017:

"  all parties agree to compliance with resource policies in NRPM 
   per provisions in RSA, with revocation being a potential consequence of chronic
   non-compliance. ?

Are you suggesting that this policy, if implemented, should have specific stated penalties for non-compliance that are separate from the general case of a party violating any other clause of the NRPM?

-C


> On Oct 12, 2017, at 7:33 AM, Michael Winters <mwinters at edwardrose.com> wrote:
> 
> Opposed as written (amended).
> 
> As written, (IMHO) it is an incomplete and unenforceable policy (shall part anyway).
> If you are saying shall, what is the policy for ARIN to follow if there is noncompliance.
> In attempting to fix a potential problem that does not yet exist, due to the word shall, this policy creates a problem.
> 
> Should have stuck with should.
> 
> Thanks,
> Mike
> 
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
> Sent: Wednesday, October 11, 2017 3:17 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements
> 
> The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send the following to Last Call:
> 
> Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements
> 
> The AC provided the following statement to the community:
> 
> "Based on strong community support - on both the Public Policy Mailing List and in person at ARIN 40 during the policy consultation - for replacing the "should" qualifier in section 6.5.5.4 with "shall", the Advisory Council, after careful review and discussion, has made the requested change to the text."
> 
> Feedback is encouraged during the Last Call period. All comments should be provided to the Public Policy Mailing List. This Last Call period will expire on 10 November 2017. After Last Call, the AC will conduct their Last Call review.
> 
> The full text is below and available at:
> https://www.arin.net/policy/proposals/
> 
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
> 
> Regards,
> 
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> 
> 
> AC's Statement of Conformance with ARIN's Principles of Internet Number Resource Policy:
> 
> This proposal is technically sound and enables fair and impartial number policy for easier IPv6 Registrations. The staff and legal review noted a single clarification issue which has been addressed. There is ample support for the proposal on PPML and no concerns have been raised by the community regarding the proposal.
> 
> Problem Statement:
> 
> Current ARIN policy has different WHOIS directory registration requirements for IPv4 vs IPv6 address assignments. IPv4 registration is triggered for an assignment of any address block equal to or greater than a /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs for an assignment of any block equal to or greater than a /64, which constitutes one entire IPv6 subnet and is the minimum block size for an allocation. Accordingly, there is a significant disparity between IPv4 and IPv6 WHOIS registration thresholds in the case of assignments, resulting in more work in the case of IPv6 than is the case for IPv4. There is no technical or policy rationale for the disparity, which could serve as a deterrent to more rapid IPv6 adoption.
> The purpose of this proposal is to eliminate the disparity and corresponding adverse consequences.
> 
> Policy statement:
> 
> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike "assignment containing a /64 or more addresses" and change to "re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any size that will be individually announced,?
> 
> and
> 
> 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM to strike the text "4.2.3.7.1" and change to ?6.5.5.1"
> 
> and
> 
> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by deleting the phrase "holding /64 and larger blocks"
> 
> and
> 
> 4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of
> /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP shall register that assignment as described in section 6.5.5.1."
> 
> Comments:
> 
> a.    Timetable for implementation: Policy should be adopted as soon as
> possible.
> 
> b.    Anything else:
> 
> Author Comments:
> 
> IPv6 should not be more burdensome than the equivalent IPv4 network size. Currently, assignments of /29 or more of IPv4 space (8 addresses) require registration. The greatest majority of ISP customers who have assignments of IPv4 space are of a single IPv4 address which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6, as assignments of /64 or more of IPv6 space require registration. Beginning with RFC 3177, it has been standard practice to assign a minimum assignment of /64 to every customer end user site, and less is never used. This means that ALL IPv6 assignments, including those customers that only use a single IPv4 address must be registered with ARIN if they are given the minimum assignment of /64 of IPv6 space. This additional effort may prevent ISP's from giving IPv6 addresses because of the additional expense of registering those addresses with ARIN, which is not required for IPv4.
> The administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections.
> _______________________________________________
> 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.
> ________________________
> 
> 
> ________________________
> 
> _______________________________________________
> 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.



From john at egh.com  Thu Oct 12 11:03:11 2017
From: john at egh.com (John Santos)
Date: Thu, 12 Oct 2017 11:03:11 -0400
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
In-Reply-To: <CAC4yj2Vst2vGs1ntV86OFV_vMyiXC+JaM7mFraxxVe3e_u92mA@mail.gmail.com>
References: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
 <CAOZQb9QbNqoDRMT7KM7Wuo8NZqT-MD+70Q8ZHHeeF1XpSg2gQg@mail.gmail.com>
 <01C82F8F-3DD9-46A9-8293-CDEC65699FEF@delong.com>
 <CAC4yj2Vst2vGs1ntV86OFV_vMyiXC+JaM7mFraxxVe3e_u92mA@mail.gmail.com>
Message-ID: <d80026d1-cbe0-39b1-83fe-7802fa877562@egh.com>

+1 Also support "shall" rather than "should"

Remember that this is a relaxation of requirements, not an increase.? 
Current requirements require ALL /64 and larger be registered in WHOIS.? 
This policy requires registration for /48 to /64 assignments only if the 
recipient requests it.


On 10/12/2017 9:39 AM, Jason Schiller wrote:
> Support as written (amended with Shall).
>
> As a follow up to Owen, clarity is important.
> I urge those who do not support it as written (amended with Shall)
> to also note if they would support it without the shall amendment.
>
>
> Also as a separate question to supporting the proposal
> is if the process is supported.
>
> Can the PPM chair call separate questions?
> Yes.
>
> Can the Shepherd / AC make (minor) text changes after the 30 day freeze?
> Yes.
>
> Was there adequate discussion of the change on list and at the meeting?
> Yes.
>
> ___Jason
>
>
>
>
>
> On Wed, Oct 11, 2017 at 7:29 PM, Owen DeLong <owen at delong.com 
> <mailto:owen at delong.com>> wrote:
>
>     I?d like to request that if anyone objects to the change made in
>     sending the recommended draft to last call?(should->shall), they
>     make that clear.
>
>     I believe we it is likely ?Support as written? will actually be
>     interpreted as ?Support as amended and sent to last call?.
>
>     Sorry for being pedantic, but as an AC member, I?d like to make
>     sure that we have the clearest possible understanding of community
>     intent as we move forward.
>
>     Thanks,
>
>     Owen
>
>>     On Oct 11, 2017, at 4:25 PM, Carlton Samuels
>>     <carlton.samuels at gmail.com <mailto:carlton.samuels at gmail.com>> wrote:
>>
>>     Support as written.
>>
>>     -CAS
>>
>>
>>     ==============================
>>     /Carlton A Samuels/
>>     /Mobile: 876-818-1799 <tel:%28876%29%20818-1799>
>>     Strategy, Planning, Governance, Assessment & Turnaround/
>>     =============================
>>
>>     On Wed, Oct 11, 2017 at 2:16 PM, ARIN <info at arin.net
>>     <mailto:info at arin.net>> wrote:
>>
>>         The ARIN Advisory Council (AC) met on 6 October 2017 and
>>         decided to send the following to Last Call:
>>
>>         Recommended Draft Policy ARIN-2017-5: Improved IPv6
>>         Registration Requirements
>>
>>         The AC provided the following statement to the community:
>>
>>         "Based on strong community support - on both the Public
>>         Policy Mailing List and in person at ARIN 40 during the
>>         policy consultation - for
>>         replacing the "should" qualifier in section 6.5.5.4 with
>>         "shall", the Advisory Council, after careful review and
>>         discussion, has made the requested change to the text."
>>
>>         Feedback is encouraged during the Last Call period. All
>>         comments should be provided to the Public Policy Mailing
>>         List. This Last Call period will expire on 10 November 2017.
>>         After Last Call, the AC will conduct their Last Call review.
>>
>>         The full text is below and available at:
>>         https://www.arin.net/policy/proposals/
>>         <https://www.arin.net/policy/proposals/>
>>
>>         The ARIN Policy Development Process is available at:
>>         https://www.arin.net/policy/pdp.html
>>         <https://www.arin.net/policy/pdp.html>
>>
>>         Regards,
>>
>>         Sean Hopkins
>>         Policy Analyst
>>         American Registry for Internet Numbers (ARIN)
>>
>>
>>
>>         AC's Statement of Conformance with ARIN's Principles of
>>         Internet Number Resource Policy:
>>
>>         This proposal is technically sound and enables fair and
>>         impartial number policy for easier IPv6 Registrations. The
>>         staff and legal review noted a single clarification issue
>>         which has been addressed. There is ample support for the
>>         proposal on PPML and no concerns have been raised by the
>>         community regarding the proposal.
>>
>>         Problem Statement:
>>
>>         Current ARIN policy has different WHOIS directory
>>         registration requirements for IPv4 vs IPv6 address
>>         assignments. IPv4 registration is triggered for an assignment
>>         of any address block equal to or greater than a /29 (i.e.,
>>         eight IPv4 addresses). In the case of IPv6, registration
>>         occurs for an assignment of any block equal to or greater
>>         than a /64, which constitutes one entire IPv6 subnet and is
>>         the minimum block size for an allocation. Accordingly, there
>>         is a significant disparity between IPv4 and IPv6 WHOIS
>>         registration thresholds in the case of assignments, resulting
>>         in more work in the case of IPv6 than is the case for IPv4.
>>         There is no technical or policy rationale for the disparity,
>>         which could serve as a deterrent to more rapid IPv6 adoption.
>>         The purpose of this proposal is to eliminate the disparity
>>         and corresponding adverse consequences.
>>
>>         Policy statement:
>>
>>         1) Alter section 6.5.5.1 "Reassignment information" of the
>>         NRPM to strike "assignment containing a /64 or more
>>         addresses" and change to "re-allocation, reassignment
>>         containing a /47 or more addresses, or subdelegation of any
>>         size that will be individually announced,?
>>
>>         and
>>
>>         2) Alter section 6.5.5.2. "Assignments visible within 7 days"
>>         of the NRPM to strike the text "4.2.3.7.1" and change to
>>         ?6.5.5.1"
>>
>>         and
>>
>>         3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of
>>         the NRPM by deleting the phrase "holding /64 and larger blocks"
>>
>>         and
>>
>>         4) Add new section 6.5.5.4 "Registration Requested by
>>         Recipient" of the NRPM, to read: "If the downstream recipient
>>         of a static assignment of /64 or more addresses requests
>>         publishing of that assignment in ARIN's registration
>>         database, the ISP shall register that assignment as described
>>         in section 6.5.5.1."
>>
>>         Comments:
>>
>>         a.? ? Timetable for implementation: Policy should be adopted
>>         as soon as possible.
>>
>>         b.? ? Anything else:
>>
>>         Author Comments:
>>
>>         IPv6 should not be more burdensome than the equivalent IPv4
>>         network size. Currently, assignments of /29 or more of IPv4
>>         space (8 addresses) require registration. The greatest
>>         majority of ISP customers who have assignments of IPv4 space
>>         are of a single IPv4 address which do not trigger any ARIN
>>         registration requirement when using IPv4. This is NOT true
>>         when these same exact customers use IPv6, as assignments of
>>         /64 or more of IPv6 space require registration. Beginning
>>         with RFC 3177, it has been standard practice to assign a
>>         minimum assignment of /64 to every customer end user site,
>>         and less is never used. This means that ALL IPv6 assignments,
>>         including those customers that only use a single IPv4 address
>>         must be registered with ARIN if they are given the minimum
>>         assignment of /64 of IPv6 space. This additional effort may
>>         prevent ISP's from giving IPv6 addresses because of the
>>         additional expense of registering those addresses with ARIN,
>>         which is not required for IPv4. The administrative burden of
>>         100% customer registration of IPv6 customers is unreasonable,
>>         when such is not required for those customers receiving only
>>         IPv4 connections.
>>         _______________________________________________
>>         PPML
>>         You are receiving this message because you are subscribed to
>>         the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>>         <mailto:ARIN-PPML at arin.net>).
>>         Unsubscribe or manage your mailing list subscription at:
>>         http://lists.arin.net/mailman/listinfo/arin-ppml
>>         <http://lists.arin.net/mailman/listinfo/arin-ppml>
>>         Please contact info at arin.net <mailto:info at arin.net> if you
>>         experience any issues.
>>
>>
>>     _______________________________________________
>>     PPML
>>     You are receiving this message because you are subscribed to
>>     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>>     <mailto:ARIN-PPML at arin.net>).
>>     Unsubscribe or manage your mailing list subscription at:
>>     http://lists.arin.net/mailman/listinfo/arin-ppml
>>     <http://lists.arin.net/mailman/listinfo/arin-ppml>
>>     Please contact info at arin.net <mailto:info at arin.net> if you
>>     experience any issues.
>
>
>     _______________________________________________
>     PPML
>     You are receiving this message because you are subscribed to
>     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>     <mailto:ARIN-PPML at arin.net>).
>     Unsubscribe or manage your mailing list subscription at:
>     http://lists.arin.net/mailman/listinfo/arin-ppml
>     <http://lists.arin.net/mailman/listinfo/arin-ppml>
>     Please contact info at arin.net <mailto:info at arin.net> if you
>     experience any issues.
>
>
>
>
> -- 
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com 
> <mailto:jschiller at google.com>|571-266-0006
>
>
>
> _______________________________________________
> 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.

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171012/93232da3/attachment.htm>

From paul at arin.net  Thu Oct 12 11:31:22 2017
From: paul at arin.net (Paul Andersen)
Date: Thu, 12 Oct 2017 11:31:22 -0400
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
In-Reply-To: <CAC4yj2Vst2vGs1ntV86OFV_vMyiXC+JaM7mFraxxVe3e_u92mA@mail.gmail.com>
References: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
 <CAOZQb9QbNqoDRMT7KM7Wuo8NZqT-MD+70Q8ZHHeeF1XpSg2gQg@mail.gmail.com>
 <01C82F8F-3DD9-46A9-8293-CDEC65699FEF@delong.com>
 <CAC4yj2Vst2vGs1ntV86OFV_vMyiXC+JaM7mFraxxVe3e_u92mA@mail.gmail.com>
Message-ID: <1942AF11-CE8F-450A-8915-D053EFE4CA75@arin.net>

Jason,

As the current PPM chair I am at liberty to ask any question of the room I feel appropriate to the discussion. In general we ask a standing question for support of a policy as written for Recommended Draft Policies. Questions that we ask other then this are generally on the request of the AC Chairs who in turn solicit that from the AC *prior* to the policy being discussed at the meeting. 

Most importantly I will generally not ask a question that there has not been reasonable opportunity for the body assembled (in person and remotely) to speak to prior to the actual question being called. In the case of 2017-5 the shall/should discussion had ample discussion.

Paul


> On Oct 12, 2017, at 9:39 AM, Jason Schiller <jschiller at google.com> wrote:
> 
> Can the PPM chair call separate questions? 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171012/57f0ed26/attachment.htm>

From kevinb at thewire.ca  Thu Oct 12 11:44:07 2017
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Thu, 12 Oct 2017 15:44:07 +0000
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
In-Reply-To: <01C82F8F-3DD9-46A9-8293-CDEC65699FEF@delong.com>
References: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
 <CAOZQb9QbNqoDRMT7KM7Wuo8NZqT-MD+70Q8ZHHeeF1XpSg2gQg@mail.gmail.com>
 <01C82F8F-3DD9-46A9-8293-CDEC65699FEF@delong.com>
Message-ID: <7E7773B523E82C478734E793E58F69E7A52F1525@SBS2011.thewireinc.local>

I support the policy as amended. My primary concern was addressed by staff during discussion on the floor.

While I prefer should, the improvement this policy makes is significant enough that I support it moving forward with shall.

There is a cost to automation and there is a cost to manually SWIP?ing.

Based on the response from the floor (please correct me if I understood it incorrectly). I can charge a nominal fee where appropriate, as my business practice. If a client refuses the fee, that does not put me out of compliance with the policy.

Thanks,

Kevin Blumberg


From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Wednesday, October 11, 2017 7:30 PM
To: Carlton Samuels <carlton.samuels at gmail.com>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

I?d like to request that if anyone objects to the change made in sending the recommended draft to last call (should->shall), they make that clear.

I believe we it is likely ?Support as written? will actually be interpreted as ?Support as amended and sent to last call?.

Sorry for being pedantic, but as an AC member, I?d like to make sure that we have the clearest possible understanding of community intent as we move forward.

Thanks,

Owen

On Oct 11, 2017, at 4:25 PM, Carlton Samuels <carlton.samuels at gmail.com<mailto:carlton.samuels at gmail.com>> wrote:

Support as written.

-CAS


==============================
Carlton A Samuels
Mobile: 876-818-1799
Strategy, Planning, Governance, Assessment & Turnaround
=============================

On Wed, Oct 11, 2017 at 2:16 PM, ARIN <info at arin.net<mailto:info at arin.net>> wrote:
The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send the following to Last Call:

Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

The AC provided the following statement to the community:

"Based on strong community support - on both the Public Policy Mailing List and in person at ARIN 40 during the policy consultation - for
replacing the "should" qualifier in section 6.5.5.4 with "shall", the Advisory Council, after careful review and discussion, has made the requested change to the text."

Feedback is encouraged during the Last Call period. All comments should be provided to the Public Policy Mailing List. This Last Call period will expire on 10 November 2017. After Last Call, the AC will conduct their Last Call review.

The full text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)



AC's Statement of Conformance with ARIN's Principles of Internet Number Resource Policy:

This proposal is technically sound and enables fair and impartial number policy for easier IPv6 Registrations. The staff and legal review noted a single clarification issue which has been addressed. There is ample support for the proposal on PPML and no concerns have been raised by the community regarding the proposal.

Problem Statement:

Current ARIN policy has different WHOIS directory registration requirements for IPv4 vs IPv6 address assignments. IPv4 registration is triggered for an assignment of any address block equal to or greater than a /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs for an assignment of any block equal to or greater than a /64, which constitutes one entire IPv6 subnet and is the minimum block size for an allocation. Accordingly, there is a significant disparity between IPv4 and IPv6 WHOIS registration thresholds in the case of assignments, resulting in more work in the case of IPv6 than is the case for IPv4. There is no technical or policy rationale for the disparity, which could serve as a deterrent to more rapid IPv6 adoption. The purpose of this proposal is to eliminate the disparity and corresponding adverse consequences.

Policy statement:

1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike "assignment containing a /64 or more addresses" and change to "re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any size that will be individually announced,?

and

2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM to strike the text "4.2.3.7.1" and change to ?6.5.5.1"

and

3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by deleting the phrase "holding /64 and larger blocks"

and

4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP shall register that assignment as described in section 6.5.5.1."

Comments:

a.    Timetable for implementation: Policy should be adopted as soon as possible.

b.    Anything else:

Author Comments:

IPv6 should not be more burdensome than the equivalent IPv4 network size. Currently, assignments of /29 or more of IPv4 space (8 addresses) require registration. The greatest majority of ISP customers who have assignments of IPv4 space are of a single IPv4 address which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6, as assignments of /64 or more of IPv6 space require registration. Beginning with RFC 3177, it has been standard practice to assign a minimum assignment of /64 to every customer end user site, and less is never used. This means that ALL IPv6 assignments, including those customers that only use a single IPv4 address must be registered with ARIN if they are given the minimum assignment of /64 of IPv6 space. This additional effort may prevent ISP's from giving IPv6 addresses because of the additional expense of registering those addresses with ARIN, which is not required for IPv4. The administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20171012/4355eb5e/attachment.htm>

From hostmaster at uneedus.com  Thu Oct 12 12:52:09 2017
From: hostmaster at uneedus.com (hostmaster at uneedus.com)
Date: Thu, 12 Oct 2017 12:52:09 -0400 (EDT)
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
In-Reply-To: <00f701d34367$d9fe23c0$8dfa6b40$@iptrading.com>
References: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
 <d82a1558ab474476afff303a58671e1d@kz-mail01.manifold.edwardrosekzoo.com>
 <00f701d34367$d9fe23c0$8dfa6b40$@iptrading.com>
Message-ID: <Pine.LNX.4.64.1710121041570.11444@localhost.localdomain>

I support the policy as written, with "shall".  I also support with 
"should", but would rather have shall.

As for discussion of what ARIN will do if an ISP decides not to follow the 
policy, I guess we can ask what ARIN is doing NOW.

Under CURRENT policy (6.5.5.1), a /64 or more of static IPv6 space "shall" 
be registered in SWIP, which is basically EVERY IPv6 static assignment, 
governed by the "shall" rule.  "Shall" is the status quo at this time. 
There is no choice regarding registration of static /64's or more, they 
"shall" be registered.

Under the Draft Policy, this "shall" requirement of "shall" of 
registration is greatly reduced.  As an ISP, I can now provide up to a /48 
of space to each site of each customer without triggering any registration 
requirement, as long as it is not independently routed, with one specific 
exception.  That exception is that the customer has actually ASKED me to
register their static assigment of /64 or more.

Since we started with a current policy that gave no choice and ALWAYS 
required registration, and we are moving toward a policy that only 
requires registration of that /64 or more upon request ONLY, I see this as 
a reduction of burden.

As to what ARIN will do if the "shall" requirement is not followed, I did 
ask early in the discussion if ARIN had ever pulled resources (its most 
extreme sanction) because of failure to register in SWIP those /64's that 
current policy say "shall" be registered.  I was told "no" to that 
question.

I have been working with IPv6 since 2006 or so, and went thru the days of 
the Federal Government requirement to have IPv6 in 2008 or so, my bread 
and butter.  In the last few years since the current registration policy 
was lowered from a /48 to a /64, I have looked up many of my customer's 
static IPv6 assignments, and with only the exception of a certain major 
tunnel broker (still kinda the last resort for v6 if native is not 
available), I have never found my static customer IPv6 assignments to 
ever been registered in SWIP.

Therefore, I have reached the conclusion that the /64 current requirement 
is totally ignored, and unenforced.  It is also unreasonable versus v4, 
thus why I proposed this draft.

I doubt that even with "shall", that ARIN will do anything other than talk 
to the customer regarding following number policy required by the RSA, and 
I have extreme doubts that any number resources will be ever pulled, 
regardless of the use either word "should" or "shall".

Albert Erdmann
Network Administrator
Paradise On Line Inc.



On Thu, 12 Oct 2017, Mike Burns wrote:

> +1 to "Should have stuck with should."
>
> I also oppose as written (amended) for the same reasons described below.
>
> Regards,
> Mike Burns
>
>
>
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Winters
> Sent: Thursday, October 12, 2017 10:33 AM
> To: ARIN <info at arin.net>; arin-ppml at arin.net
> Subject: Re: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements
>
> Opposed as written (amended).
>
> As written, (IMHO) it is an incomplete and unenforceable policy (shall part anyway).
> If you are saying shall, what is the policy for ARIN to follow if there is noncompliance.
> In attempting to fix a potential problem that does not yet exist, due to the word shall, this policy creates a problem.
>
> Should have stuck with should.
>
> Thanks,
> Mike
>
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
> Sent: Wednesday, October 11, 2017 3:17 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements
>
> The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send the following to Last Call:
>
> Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements
>
> The AC provided the following statement to the community:
>
> "Based on strong community support - on both the Public Policy Mailing List and in person at ARIN 40 during the policy consultation - for replacing the "should" qualifier in section 6.5.5.4 with "shall", the Advisory Council, after careful review and discussion, has made the requested change to the text."
>
> Feedback is encouraged during the Last Call period. All comments should be provided to the Public Policy Mailing List. This Last Call period will expire on 10 November 2017. After Last Call, the AC will conduct their Last Call review.
>
> The full text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> AC's Statement of Conformance with ARIN's Principles of Internet Number Resource Policy:
>
> This proposal is technically sound and enables fair and impartial number policy for easier IPv6 Registrations. The staff and legal review noted a single clarification issue which has been addressed. There is ample support for the proposal on PPML and no concerns have been raised by the community regarding the proposal.
>
> Problem Statement:
>
> Current ARIN policy has different WHOIS directory registration requirements for IPv4 vs IPv6 address assignments. IPv4 registration is triggered for an assignment of any address block equal to or greater than a /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs for an assignment of any block equal to or greater than a /64, which constitutes one entire IPv6 subnet and is the minimum block size for an allocation. Accordingly, there is a significant disparity between IPv4 and IPv6 WHOIS registration thresholds in the case of assignments, resulting in more work in the case of IPv6 than is the case for IPv4. There is no technical or policy rationale for the disparity, which could serve as a deterrent to more rapid IPv6 adoption.
> The purpose of this proposal is to eliminate the disparity and corresponding adverse consequences.
>
> Policy statement:
>
> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike "assignment containing a /64 or more addresses" and change to "re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any size that will be individually announced,???
>
> and
>
> 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM to strike the text "4.2.3.7.1" and change to ???6.5.5.1"
>
> and
>
> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by deleting the phrase "holding /64 and larger blocks"
>
> and
>
> 4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of
> /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP shall register that assignment as described in section 6.5.5.1."
>
> Comments:
>
> a.    Timetable for implementation: Policy should be adopted as soon as
> possible.
>
> b.    Anything else:
>
> Author Comments:
>
> IPv6 should not be more burdensome than the equivalent IPv4 network size. Currently, assignments of /29 or more of IPv4 space (8 addresses) require registration. The greatest majority of ISP customers who have assignments of IPv4 space are of a single IPv4 address which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6, as assignments of /64 or more of IPv6 space require registration. Beginning with RFC 3177, it has been standard practice to assign a minimum assignment of /64 to every customer end user site, and less is never used. This means that ALL IPv6 assignments, including those customers that only use a single IPv4 address must be registered with ARIN if they are given the minimum assignment of /64 of IPv6 space. This additional effort may prevent ISP's from giving IPv6 addresses because of the additional expense of registering those addresses with ARIN, which is not required for IPv4.
> The administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections.
> _______________________________________________
> 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.
> ________________________
>
>
> ________________________
>
> _______________________________________________
> 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.
>
> _______________________________________________
> 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.
>

From jschiller at google.com  Thu Oct 12 13:36:33 2017
From: jschiller at google.com (Jason Schiller)
Date: Thu, 12 Oct 2017 13:36:33 -0400
Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
 Improved IPv6 Registration Requirements
In-Reply-To: <Pine.LNX.4.64.1710121041570.11444@localhost.localdomain>
References: <bdc6fdcc-a2a1-5d25-ef9d-9349b0460bef@arin.net>
 <d82a1558ab474476afff303a58671e1d@kz-mail01.manifold.edwardrosekzoo.com>
 <00f701d34367$d9fe23c0$8dfa6b40$@iptrading.com>
 <Pine.LNX.4.64.1710121041570.11444@localhost.localdomain>
Message-ID: <CAC4yj2Xs8qqyFbYDi2tXHcSPXBkC2Vye22deLpCBuXvZFvmErQ@mail.gmail.com>

On Thu, Oct 12, 2017 at 12:52 PM, <hostmaster at uneedus.com> wrote:
>
> I doubt that even with "shall", that ARIN will do anything other than
talk to the customer regarding
> following number policy required by the RSA, and I have extreme doubts
that any number
> resources will be ever pulled, regardless of the use either word "should"
or "shall".

Even if ARIN does not pull resources, it is important to be clear if SWIP
is optional.

Can an organization, acting in good faith, committed to do the minimum
required
by ARIN policy, ignore SWIP and believe they are not out of compliance?

___Jason


On Thu, Oct 12, 2017 at 12:52 PM, <hostmaster at uneedus.com> wrote:

> I support the policy as written, with "shall".  I also support with
> "should", but would rather have shall.
>
> As for discussion of what ARIN will do if an ISP decides not to follow the
> policy, I guess we can ask what ARIN is doing NOW.
>
> Under CURRENT policy (6.5.5.1), a /64 or more of static IPv6 space "shall"
> be registered in SWIP, which is basically EVERY IPv6 static assignment,
> governed by the "shall" rule.  "Shall" is the status quo at this time.
> There is no choice regarding registration of static /64's or more, they
> "shall" be registered.
>
> Under the Draft Policy, this "shall" requirement of "shall" of
> registration is greatly reduced.  As an ISP, I can now provide up to a /48
> of space to each site of each customer without triggering any registration
> requirement, as long as it is not independently routed, with one specific
> exception.  That exception is that the customer has actually ASKED me to
> register their static assigment of /64 or more.
>
> Since we started with a current policy that gave no choice and ALWAYS
> required registration, and we are moving toward a policy that only requires
> registration of that /64 or more upon request ONLY, I see this as a
> reduction of burden.
>
> As to what ARIN will do if the "shall" requirement is not followed, I did
> ask early in the discussion if ARIN had ever pulled resources (its most
> extreme sanction) because of failure to register in SWIP those /64's that
> current policy say "shall" be registered.  I was told "no" to that question.
>
> I have been working with IPv6 since 2006 or so, and went thru the days of
> the Federal Government requirement to have IPv6 in 2008 or so, my bread and
> butter.  In the last few years since the current registration policy was
> lowered from a /48 to a /64, I have looked up many of my customer's static
> IPv6 assignments, and with only the exception of a certain major tunnel
> broker (still kinda the last resort for v6 if native is not available), I
> have never found my static customer IPv6 assignments to ever been
> registered in SWIP.
>
> Therefore, I have reached the conclusion that the /64 current requirement
> is totally ignored, and unenforced.  It is also unreasonable versus v4,
> thus why I proposed this draft.
>
> I doubt that even with "shall", that ARIN will do anything other than talk
> to the customer regarding following number policy required by the RSA, and
> I have extreme doubts that any number resources will be ever pulled,
> regardless of the use either word "should" or "shall".
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
>
>
>
> On Thu, 12 Oct 2017, Mike Burns wrote:
>
> +1 to "Should have stuck with should."
>>
>> I also oppose as written (amended) for the same reasons described below.
>>
>> Regards,
>> Mike Burns
>>
>>
>>
>> -----Original Message-----
>> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael
>> Winters
>> Sent: Thursday, October 12, 2017 10:33 AM
>> To: ARIN <info at arin.net>; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] LAST CALL - Recommended Draft Policy
>> ARIN-2017-5: Improved IPv6 Registration Requirements
>>
>> Opposed as written (amended).
>>
>> As written, (IMHO) it is an incomplete and unenforceable policy (shall
>> part anyway).
>> If you are saying shall, what is the policy for ARIN to follow if there
>> is noncompliance.
>> In attempting to fix a potential problem that does not yet exist, due to
>> the word shall, this policy creates a problem.
>>
>> Should have stuck with should.
>>
>> Thanks,
>> Mike
>>
>> -----Original Message-----
>> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
>> Sent: Wednesday, October 11, 2017 3:17 PM
>> To: arin-ppml at arin.net
>> Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5:
>> Improved IPv6 Registration Requirements
>>
>> The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send
>> the following to Last Call:
>>
>> Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration
>> Requirements
>>
>> The AC provided the following statement to the community:
>>
>> "Based on strong community support - on both the Public Policy Mailing
>> List and in person at ARIN 40 during the policy consultation - for
>> replacing the "should" qualifier in section 6.5.5.4 with "shall", the
>> Advisory Council, after careful review and discussion, has made the
>> requested change to the text."
>>
>> Feedback is encouraged during the Last Call period. All comments should
>> be provided to the Public Policy Mailing List. This Last Call period will
>> expire on 10 November 2017. After Last Call, the AC will conduct their Last
>> Call review.
>>
>> The full text is below and available at:
>> https://www.arin.net/policy/proposals/
>>
>> The ARIN Policy Development Process is available at:
>> https://www.arin.net/policy/pdp.html
>>
>> Regards,
>>
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>> AC's Statement of Conformance with ARIN's Principles of Internet Number
>> Resource Policy:
>>
>> This proposal is technically sound and enables fair and impartial number
>> policy for easier IPv6 Registrations. The staff and legal review noted a
>> single clarification issue which has been addressed. There is ample support
>> for the proposal on PPML and no concerns have been raised by the community
>> regarding the proposal.
>>
>> Problem Statement:
>>
>> Current ARIN policy has different WHOIS directory registration
>> requirements for IPv4 vs IPv6 address assignments. IPv4 registration is
>> triggered for an assignment of any address block equal to or greater than a
>> /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs
>> for an assignment of any block equal to or greater than a /64, which
>> constitutes one entire IPv6 subnet and is the minimum block size for an
>> allocation. Accordingly, there is a significant disparity between IPv4 and
>> IPv6 WHOIS registration thresholds in the case of assignments, resulting in
>> more work in the case of IPv6 than is the case for IPv4. There is no
>> technical or policy rationale for the disparity, which could serve as a
>> deterrent to more rapid IPv6 adoption.
>> The purpose of this proposal is to eliminate the disparity and
>> corresponding adverse consequences.
>>
>> Policy statement:
>>
>> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike
>> "assignment containing a /64 or more addresses" and change to
>> "re-allocation, reassignment containing a /47 or more addresses, or
>> subdelegation of any size that will be individually announced,?
>>
>> and
>>
>> 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM
>> to strike the text "4.2.3.7.1" and change to ?6.5.5.1"
>>
>> and
>>
>> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by
>> deleting the phrase "holding /64 and larger blocks"
>>
>> and
>>
>> 4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the
>> NRPM, to read: "If the downstream recipient of a static assignment of
>> /64 or more addresses requests publishing of that assignment in ARIN's
>> registration database, the ISP shall register that assignment as described
>> in section 6.5.5.1."
>>
>> Comments:
>>
>> a.    Timetable for implementation: Policy should be adopted as soon as
>> possible.
>>
>> b.    Anything else:
>>
>> Author Comments:
>>
>> IPv6 should not be more burdensome than the equivalent IPv4 network size.
>> Currently, assignments of /29 or more of IPv4 space (8 addresses) require
>> registration. The greatest majority of ISP customers who have assignments
>> of IPv4 space are of a single IPv4 address which do not trigger any ARIN
>> registration requirement when using IPv4. This is NOT true when these same
>> exact customers use IPv6, as assignments of /64 or more of IPv6 space
>> require registration. Beginning with RFC 3177, it has been standard
>> practice to assign a minimum assignment of /64 to every customer end user
>> site, and less is never used. This means that ALL IPv6 assignments,
>> including those customers that only use a single IPv4 address must be
>> registered with ARIN if they are given the minimum assignment of /64 of
>> IPv6 space. This additional effort may prevent ISP's from giving IPv6
>> addresses because of the additional expense of registering those addresses
>> with ARIN, which is not required for IPv4.
>> The administrative burden of 100% customer registration of IPv6 customers
>> is unreasonable, when such is not required for those customers receiving
>> only IPv4 connections.
>> _______________________________________________
>> 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.
>> ________________________
>>
>>
>> ________________________
>>
>> _______________________________________________
>> 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.
>>
>> _______________________________________________
>> 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.
>>
>
> _______________________________________________
> 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/20171012/3fa3bf5e/attachment.htm>

From narten at us.ibm.com  Fri Oct 13 00:53:24 2017
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 13 Oct 2017 00:53:24 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201710130453.v9D4rONk025147@rotala.raleigh.ibm.com>

Total of 23 messages in the last 7 days.
 
script run at: Fri Oct 13 00:53:18 EDT 2017
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
  8.70% |    2 | 15.01% |    66225 | jschiller at google.com
  4.35% |    1 | 10.88% |    48019 | rudi.daniel at gmail.com
  8.70% |    2 |  5.52% |    24338 | hostmaster at uneedus.com
  4.35% |    1 |  9.61% |    42410 | john at egh.com
  8.70% |    2 |  4.94% |    21802 | chris at semihuman.com
  8.70% |    2 |  4.19% |    18493 | info at arin.net
  4.35% |    1 |  7.14% |    31491 | kevinb at thewire.ca
  4.35% |    1 |  5.88% |    25928 | owen at delong.com
  4.35% |    1 |  4.97% |    21938 | carlton.samuels at gmail.com
  4.35% |    1 |  4.92% |    21722 | scottleibrand at gmail.com
  4.35% |    1 |  4.72% |    20841 | cblecker at gmail.com
  4.35% |    1 |  4.72% |    20833 | hvgeekwtrvl at gmail.com
  4.35% |    1 |  3.32% |    14659 | jcurran at arin.net
  4.35% |    1 |  3.03% |    13365 | mike at iptrading.com
  4.35% |    1 |  2.95% |    13031 | mwinters at edwardrose.com
  4.35% |    1 |  2.24% |     9897 | paul at arin.net
  4.35% |    1 |  2.10% |     9254 | dewole at forum.org.ng
  4.35% |    1 |  2.08% |     9173 | narten at us.ibm.com
  4.35% |    1 |  1.78% |     7850 | gary.buhrmaster at gmail.com
--------+------+--------+----------+------------------------
100.00% |   23 |100.00% |   441269 | Total



From narten at us.ibm.com  Fri Oct 20 00:53:02 2017
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 20 Oct 2017 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201710200453.v9K4r3nK014526@rotala.raleigh.ibm.com>

Total of 1 messages in the last 7 days.
 
script run at: Fri Oct 20 00:53:02 EDT 2017
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
100.00% |    1 |100.00% |     9508 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    1 |100.00% |     9508 | Total



From info at arin.net  Tue Oct 24 17:00:24 2017
From: info at arin.net (ARIN)
Date: Tue, 24 Oct 2017 17:00:24 -0400
Subject: [arin-ppml] Fwd: Advisory Council Meeting Results - October 2017
In-Reply-To: <d5e87ce9-de55-7ecc-ca63-6cd2f2dd44fe@arin.net>
References: <d5e87ce9-de55-7ecc-ca63-6cd2f2dd44fe@arin.net>
Message-ID: <aa8eb89f-56a8-ca5f-f115-185c48e7258f@arin.net>

On 10/11/17 3:09 PM, ARIN wrote:

> The AC has abandoned the following:
>
> * Draft Policy ARIN-2017-6: Improve Reciprocity Requirement for
> Inter-RIR Transfers
>
> The AC provided the following statement:
>
> "The ARIN Advisory Council has chosen to abandon Policy Proposal 2017-6,
>  ?Improve Reciprocity Requirement for Inter-RIR Transfers?.  This
> proposal did not gain sufficient community support to justify continuing
> to move this policy forward, and as such, the policy has been abandoned."
>
> Anyone dissatisfied with this decision may initiate a petition. The
> deadline to begin a petition will be five business days after the AC's
> draft meeting minutes are published.

The draft minutes from the ARIN Advisory Council's 6 October 2017 
meeting have been published:

https://www.arin.net/about_us/ac/ac2017_1006.html

The petition deadline for both Draft Policy ARIN-2017-6 is 29 October 
2017 (in five calendar days).

For more information on starting and participating in petitions, see PDP 
Petitions at: https://www.arin.net/policy/pdp_petitions.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)



From narten at us.ibm.com  Fri Oct 27 00:53:03 2017
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 27 Oct 2017 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201710270453.v9R4r3Sd003870@rotala.raleigh.ibm.com>

Total of 2 messages in the last 7 days.
 
script run at: Fri Oct 27 00:53:03 EDT 2017
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 50.00% |    1 | 51.64% |     8525 | narten at us.ibm.com
 50.00% |    1 | 48.36% |     7982 | info at arin.net
--------+------+--------+----------+------------------------
100.00% |    2 |100.00% |    16507 | Total