+1

On 7/21/2017 12:34 PM, Scott Leibrand wrote:
This looks good: I support.

For clarity, so we don't all have to do it, and to help make sure we're not missing anything, here's what the resulting 6.5.5 looks like after modification:

6.5.5. Registration

ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use.

6.5.5.1. Reassignment information

Each static IPv6 assignment containing a /47 or more addresses, or sub-delegation of any size that will be individually announced, 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.

6.5.5.3. Residential Subscribers

6.5.5.3.1. Residential Customer Privacy

To maintain the privacy of their residential customers, an organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block.

-Scott

On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer <lsaw...@gci.com <mailto:lsaw...@gci.com>> wrote:

    Happy Friday, everybody.

    As promised, here is the latest rewrite of the draft policy below,
     and it will soon be updated at:

    https://www.arin.net/policy/proposals/2017_5.html
    <https://www.arin.net/policy/proposals/2017_5.html>

    There are two changes noted in the policy statement: the first of
    which reflects what seems to be the current

    consensus of the PPML regarding netblock sizing; the second is to
    strike language that may be read as either restrictive

    or non-operational.

    ----

    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 "/64 or more addresses" and change to "/47 or more
    addresses, or sub-delegation of any size that will be individually
    announced,"

    and

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

    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.

    ---

    Leif Sawyer

    Advisory Council


    _______________________________________________
    PPML
    You are receiving this message because you are subscribed to
    the ARIN Public Policy Mailing List (ARIN-PPML@arin.net
    <mailto:ARIN-PPML@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 i...@arin.net <mailto:i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Reply via email to