Maybe a better way to approach this question would be, are the use cases at 
issue here (guest wifi hotspots, etc) a business activity that one would 
consider a primary line of business for the organization?

I’m wondering if a better way to approach this would be to ask the question as 
to whether or not the assignment of resources to third-party end users is an 
action that’s considered a product that the organization/company provides, or 
an ancillary service. In most cases, wifi hotspots clearly are ancillary, and 
as such, I would not see any issue with considering those allocations direct 
assignments. If wifi connectivity is a substantial revenue-generating service 
for the organization, however, then I agree that an allocation is a better fit.

-C

> On May 8, 2018, at 9:40 AM, Austin Murkland <[email protected]> 
> wrote:
> 
> +1
> 
> On Fri, May 4, 2018 at 9:40 PM Andrew Dul <[email protected] 
> <mailto:[email protected]>> wrote:
> I'd like to suggest that the proposed policy text be shorted and clarified.  
> I don't believe all the examples are necessary in the definition section.
> 
> Add to the end of NRPM Section 2.5 - 
> https://www.arin.net/policy/nrpm.html#two5 
> <https://www.arin.net/policy/nrpm.html#two5>
> 
> Current draft text: 
> 
> The fact that a unique address or even a unique /64 prefix is non-permanently 
> provided to third parties, on a link operated by the original receiver of the 
> assignment, shall not be considered a sub-assignment. This includes, for 
> example, guests or employees (devices or servers), hotspots, and 
> point-to-point links or VPNs. The provision of addressing for permanent 
> connectivity or broadband services is still considered a sub-assignment. Only 
> the addressing of the point-to-point link itself can be permanent and that 
> addressing can't be used (neither directly or indirectly) for the actual 
> communication. 
> 
> My suggested rewrite:
> 
> A unique address or a unique /64 prefix that is non-permanently provided to 
> third parties, shall not be considered an assignment. 
> 
>  
> 
> On 4/24/2018 11:57 AM, David Farmer wrote:
>> I note that the text in question is the subject of an editorial change that 
>> the AC has recently forwarded to Board for review, at a minimum the policy 
>> text need to be updated to account for this editorial change. Further, I do 
>> not support the text as written.
>> 
>> I support a change to section 2 that is not quite so IPv6 specific and 
>> focused more on the idea that providing hotspot, guest access, or other such 
>> temporary access does not necessitate the making of re-assignments from a 
>> policy perspective.  Furthermore, such uses are not in conflict with the 
>> conditions of an assignment (made by ARIN) or re-assignment (made by an ISP 
>> or LIR). Also, If the details of RFC8273 need to be mentioned at all, they 
>> should be someplace in section 6, not in section 2, the definitions of 
>> assign, allocate, re-assign and re-allocate should remain agnostic about IP 
>> version.
>> 
>> Thanks.    
>> 
>> On Mon, Apr 23, 2018 at 2:22 PM, ARIN <[email protected] <mailto:[email protected]>> 
>> wrote:
>> On 18 April 2018 the ARIN Advisory Council (AC) accepted "ARIN-prop-254: 
>> Clarification on IPv6 Sub-Assignments" as a Draft Policy.
>> 
>> Draft Policy ARIN-2018-4 is below and can be found at:
>> https://www.arin.net/policy/proposals/2018_4.html 
>> <https://www.arin.net/policy/proposals/2018_4.html>
>> 
>> You are encouraged to discuss all Draft Policies on PPML. The AC will 
>> evaluate the discussion in order to assess the conformance of this draft 
>> policy with ARIN's Principles of Internet number resource policy as stated 
>> in the Policy Development Process (PDP). Specifically, these principles are:
>> 
>>  * Enabling Fair and Impartial Number Resource Administration
>>  * Technically Sound
>>  * Supported by the Community
>> 
>> The PDP can be found at:
>> https://www.arin.net/policy/pdp.html <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 
>> <https://www.arin.net/policy/proposals/index.html>
>> 
>> Regards,
>> 
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>> 
>> 
>> 
>> Draft Policy ARIN-2018-4: Clarification on IPv6 Sub-Assignments
>> 
>> Problem Statement:
>> 
>> When the policy was drafted, the concept of assignments/sub-assignments did 
>> not consider a practice very common in IPv4 which is replicated and even 
>> amplified in IPv6: the use of IP addresses for point-to-point links or VPNs.
>> 
>> In the case of IPv6, instead of unique addresses, the use of unique prefixes 
>> (/64) is increasingly common.
>> 
>> Likewise, the policy failed to consider the use of IP addresses in hotspots, 
>> or the use of IP addresses by guests or employees in Bring Your Own Device 
>> (BYOD) and many other similar cases.
>> 
>> Finally, the IETF has recently approved the use of a unique /64 prefix per 
>> interface/host (RFC8273) instead of a unique address. This, for example, 
>> allows users to connect to a hotspot, receive a /64 such that they are 
>> “isolated” from other users (for reasons of security, regulatory 
>> requirements, etc.) and they can also use multiple virtual machines on their 
>> devices with a unique address for each one (within the same /64).
>> 
>> Section 2.5 (Definitions/Allocate and Assign), explicitly prohibits such 
>> assignments, stating that “Assignments... are not to be sub-assigned to 
>> other parties”.
>> 
>> This proposal clarifies this situation in this regard and better define the 
>> concept, particularly considering new uses of IPv6 (RFC8273), by means of a 
>> new paragraph.
>> 
>> 5.    Policy Statement
>> 
>> Actual Text
>> 
>> •    Assign - To assign means to delegate address space to an ISP or 
>> end-user, for specific use within the Internet infrastructure they operate. 
>> Assignments must only be made for specific purposes documented by specific 
>> organizations and are not to be sub-assigned to other parties.
>> 
>> New Text
>> 
>> •    Assign - To assign means to delegate address space to an ISP or 
>> end-user, for specific use within the Internet infrastructure they operate. 
>> Assignments must only be made for specific purposes documented by specific 
>> organizations and are not to be sub-assigned to other parties.
>> 
>> The fact that a unique address or even a unique /64 prefix is 
>> non-permanently provided to third parties, on a link operated by the 
>> original receiver of the assignment, shall not be considered a 
>> sub-assignment. This includes, for example, guests or employees (devices or 
>> servers), hotspots, and point-to-point links or VPNs. The provision of 
>> addressing for permanent connectivity or broadband services is still 
>> considered a sub-assignment. Only the addressing of the point-to-point link 
>> itself can be permanent and that addressing can't be used (neither directly 
>> or indirectly) for the actual communication.
>> 
>> 
>> 
>> 6.    Comments
>> 
>> a.    Timetable for implementation:
>> 
>> Immediate
>> 
>> b.    Anything else:
>> 
>> Situation in other regions: This situation, has already been corrected in 
>> RIPE, and the policy was updated in a similar way, even if right now there 
>> is a small discrepancy between the policy text that reached consensus and 
>> the RIPE NCC Impact Analysis. A new policy proposal has been submitted to 
>> amend that, and the text is the same as presented by this proposal at ARIN. 
>> Same text has also been submitted to AfriNIC, LACNIC and APNIC.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List ([email protected] 
>> <mailto:[email protected]>).
>> 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 [email protected] <mailto:[email protected]> if you experience any 
>> issues.
>> 
>> 
>> 
>> -- 
>> ===============================================
>> David Farmer               Email:[email protected] 
>> <mailto:email%[email protected]>
>> 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
>> ===============================================
>> 
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List ([email protected] 
>> <mailto:[email protected]>).
>> 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 [email protected] <mailto:[email protected]> if you experience any 
>> issues.
> 
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected] 
> <mailto:[email protected]>).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml 
> <https://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact [email protected] <mailto:[email protected]> if you experience any 
> issues.
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

Reply via email to