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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 ([email protected]). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected] if you experience any issues. > > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. > > > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|[email protected]|571-266-0006
_______________________________________________ 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
