[arin-ppml] Revised - Draft Policy 2023-4: Modernization of Registration Requirements

[Owen DeLong]

This should be fairly trivial…

Since section 3.2 already contains the necessary specifications, it should be pretty easy.

With that in place, it should be fairly trivial to update the policy by changing 4.3.7.1 to “…registered via an acceptable directory service which meets…”

Same for 6.5.5.1.

Owen


> On Jan 18, 2024, at 11:53, Randy Carpenter <rcarpen at network1.net> wrote:
> 
> 
> I agree.
> 
> Would it be feasible to generic-ize as much as possible (even across the entire PPML?) and then have a single section that defines the current best practice examples of the generic terms?
> 
> e.g. replace "WHOIS and SWIP" with "Directory Services" but then elsewhere note that WHOIS and SWIP are current examples of "Directory Services" so there is still some reference for those that are used to those terms.
> 
> When a new specific protocol or technology comes about, just that one section could be updated to "WHOIS, SWIP, and SuperNewThing"
> 
> ,
> -Randy
> 
> 
> 
> ----- On Jan 18, 2024, at 1:49 PM, Andrew Dul <andrew.dul at quark.net <mailto:andrew.dul at quark.net>> wrote:
> If we are "modernizing" the language of this section that should include removing old and outdated terminology.  While the terms "WHOIS" and "SWIP" are popular in the community, they are protocols and methods which are being replaced by new modern protocols and methods.  The language should be updated to reflect those new terms or use generic terms such as directory services or registration records.
> 
> Thanks,
> 
> Andrew
> 
> On 1/17/24 1:16 PM, ARIN wrote:
> 
>  
>  
> Problem Statement:
>  
> Registration is central to the value provided by ARIN to the
> community. Registry quality depends greatly upon the timely
> registration of reassignments from ISPs to end users. The motivation
> for registration has waned since the depletion of the free pool. At
> the same time, privacy laws have been introduced in many jurisdictions
> across ARIN’s service region which constrain registration in certain
> cases. This combination of forces has generally discouraged many ISPs
> from registering reassignments. Registration remains vital to a number
> of stakeholders, including law enforcement and network operators.
>  
> This proposal aims to modernize the registration-related policies in
> Section 4 by introducing language that is meant to make registration
> requirements more adaptable to changing privacy laws, while reminding
> ISPs of the importance of registration when feasible for the benefit
> of the community.
>  
> Policy Statement:
>  
> In section 4.2.3.7.1,
> Replace
> "Each IPv4 reassignment or reallocation containing a /29 or more
> addresses shall be registered via SWIP or a directory services system
> which meets the standards set forth in section 3.2."
> With
> "Each IPv4 reassignment or reallocation containing a /29 or more
> addresses shall be registered in the WHOIS directory via SWIP, or a
> directory services system which meets the standards set forth in
> section 3.2, within 14 days."
>  
> Retire section 4.2.3.7.2 Reassignments and Reallocations Visible
> Within Seven Days
>  
> Rename 6.5.5.1
> From
> "Reassignment Information"
> To
> "Reassignment and Reallocation Information"
>  
> In section 6.5.5.1,
> Replace
> "Each static IPv6 reassignment or reallocation containing a /47 or
> more addresses, or subdelegation 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 and reallocation registrations shall include each
> client’s organizational information, except where specifically
> exempted by this policy."
> With
> "Each static IPv6 reassignment or reallocation containing a /47 or
> more addresses, or subdelegation 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, within 14 days. Reassignment and reallocation registrations shall
> include each client’s organizational information, except where
> specifically exempted by this policy."
>  
> Retire section 6.5.5.2 Reassignments and Reallocations Visible Within Seven Days
>  
> Timetable for Implementation: 90 days.
>  
> 
> 
> _______________________________________________
> ARIN-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:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
> 
> _______________________________________________
> ARIN-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:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> ARIN-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:
> https://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/20240118/9030ced6/attachment.htm>