> On Aug 14, 2018, at 06:43 , David Farmer <[email protected]> wrote:
>
> Because of recent changes, editorial if I remember correctly, section 2.5 now
> reads as;
>
> 2.5. Allocation, Assignment, Reallocation, Reassignment
>
> Allocation - Address space delegated to an organization directly by ARIN for
> the purpose of subsequent distribution by the recipient organization to other
> parties.
>
> Assignment - Address space delegated to an organization directly by ARIN for
> the exclusive use of the recipient organization.
>
> Reallocation - Address space sub-delegated to an organization by an upstream
> provider for the purpose of subsequent distribution by the recipient
> organization to other parties.
>
> Reassignment - Address space sub-delegated to an organization by an upstream
> provider for the exclusive use of the recipient organization.
>
> This proposal essentially adds the following sentence to "Assignment" above.
>
> A temporary assignment of address space provided to third parties shall not
> be considered a reassignment or a violation of the exclusive use criterion.
>
> However, I propose the following minor change to that;
>
> A temporary reassignment of address space provided to third parties shall not
> be considered a reassignment or a violation of the exclusive use criterion.
Here’s the problem…. You’re now saying “A temporary reassignment isn’t a
reassignment”.
I realize that makes the language more consistent with our definitions, but it
really doesn’t parse well.
I propose instead, that we say what we mean and avoid this problem altogether:
Temporary use of address space by third parties with the permission of
the registrant shall not be considered a reassignment
or a violation of the exclusive use criterion.
>
> Further, the sentence should also apply to "Reassignment". So, does the
> sentence also need to be added to "Reassignment"? Or maybe add the following
> sentence to "Reassignment";
>
> Excluding temporary reassignments, as discussed in the definition Assignment
> above.
I’m not sure why we would need such a thing for reassignments from allocations.
Since those are allowed, there’s really no benefit to failing to report them if
reporting requirements would apply. If not, it’s just a no-op that adds
confusion rather than removing it, IMHO.
Owen
>
> Thanks
>
> On Mon, Aug 13, 2018 at 12:39 PM, ARIN <[email protected] <mailto:[email protected]>>
> wrote:
>
> The following has been revised and retitled:
>
> * Draft Policy ARIN-2018-4: Clarification on Temporary Sub-Assignments
>
> Formerly:
>
> * Draft Policy ARIN-2018-4: Clarification on IPv6 Sub-Assignments
>
> Revised text 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 Temporary Sub-Assignments
>
> Problem Statement:
>
> When the policy was drafted, the concept of assignments/sub-assignments did
> not 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.
>
> Additionally, the IETF has recently approved the use of a unique IPv6 /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
> additional language added to the definition of an Assignment.
>
> Note that the proposal text also incorporates changes made under an Editorial
> Change currently awaiting Board of Trustees review, available here:
> https://www.arin.net/policy/proposals/2017_11.html
> <https://www.arin.net/policy/proposals/2017_11.html>
>
> Policy Statement:
>
> Actual Text, Section 2.5:
>
> • 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:
>
> • Assignment - Address space delegated to an organization directly by ARIN
> for the exclusive use of the recipient organization. A temporary assignment
> of address space provided to third parties shall not be considered an
> assignment or a violation of the exclusive use criterion.
>
> Comments
>
> Timetable for implementation:
>
> Immediate
>
> 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.
> _______________________________________________
> 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.
>
>
>
> --
> ===============================================
> 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
> ===============================================
> _______________________________________________
> 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.
