From narten at us.ibm.com Fri Aug 4 00:53:27 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 04 Aug 2017 00:53:27 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201708040453.v744rRSW031355@rotala.raleigh.ibm.com> Total of 2 messages in the last 7 days. script run at: Fri Aug 4 00:53:22 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 74.15% | 26419 | jschiller at google.com 50.00% | 1 | 25.85% | 9212 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 35631 | Total From info at arin.net Tue Aug 8 11:08:52 2017 From: info at arin.net (ARIN) Date: Tue, 8 Aug 2017 11:08:52 -0400 Subject: [arin-ppml] NRPM 2017.4: New Policies Implemented Message-ID: <5989D404.7000408@arin.net> On 22 June 2017, the Board of Trustees adopted the following Recommended Draft Policies: Recommended Draft Policy ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers These policies are now in effect. A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. NRPM version 2017.4 is effective 8 August 2017 and supersedes the previous version. The NRPM is available at: https://www.arin.net/policy/nrpm.html Board minutes are available at: https://www.arin.net/about_us/bot/index.html Draft policies and proposals are available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process (PDP) is available at: https://www.arin.net/policy/pdp.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) From narten at us.ibm.com Fri Aug 11 00:53:23 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 11 Aug 2017 00:53:23 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201708110453.v7B4rN95010362@rotala.raleigh.ibm.com> Total of 2 messages in the last 7 days. script run at: Fri Aug 11 00:53:18 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 57.15% | 8155 | narten at us.ibm.com 50.00% | 1 | 42.85% | 6114 | info at arin.net --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 14269 | Total From info at arin.net Tue Aug 15 13:06:58 2017 From: info at arin.net (ARIN) Date: Tue, 15 Aug 2017 13:06:58 -0400 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Message-ID: <59932A32.8010708@arin.net> The following has been revised: * Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_5.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 Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) 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 subdelegation 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" and 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM that reads "If the downstream recipient of a netblock ( a /64 or more addresses) requests publishing in ARIN's registration database, the ISP must register the netblock, regardless of size." 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. From daveid at panix.com Tue Aug 15 14:03:55 2017 From: daveid at panix.com (David Huberman) Date: Tue, 15 Aug 2017 14:03:55 -0400 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <59932A32.8010708@arin.net> References: <59932A32.8010708@arin.net> Message-ID: <4A6F1E24-9D75-4D72-9F0E-D795C5CF03FD@panix.com> Very well done, everyone! Strongly support this draft. Kudos to Albert Erdmann and the AC shepherds for their leadership on this proposal. > On Aug 15, 2017, at 1:06 PM, ARIN wrote: > > The following has been revised: > > * Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_5.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 > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > > 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 subdelegation 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" > > and > > 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM that reads "If the downstream recipient of a netblock ( a /64 or more addresses) requests publishing in ARIN's registration database, the ISP must register the netblock, regardless of size." > > 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 (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From chris at semihuman.com Tue Aug 15 14:08:10 2017 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 15 Aug 2017 11:08:10 -0700 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <4A6F1E24-9D75-4D72-9F0E-D795C5CF03FD@panix.com> References: <59932A32.8010708@arin.net> <4A6F1E24-9D75-4D72-9F0E-D795C5CF03FD@panix.com> Message-ID: <1C167E2A-B184-49BD-B309-2F6A322DA125@semihuman.com> Agreed. While there are a wide range of opinions on where this line belongs, The /47 line appears to have the most consensus, and has my support. -Chris > On Aug 15, 2017, at 11:03 AM, David Huberman wrote: > > Very well done, everyone! Strongly support this draft. > > Kudos to Albert Erdmann and the AC shepherds for their leadership on this proposal. > > >> On Aug 15, 2017, at 1:06 PM, ARIN wrote: >> >> The following has been revised: >> >> * Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_5.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 >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> >> 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 subdelegation 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" >> >> and >> >> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM that reads "If the downstream recipient of a netblock ( a /64 or more addresses) requests publishing in ARIN's registration database, the ISP must register the netblock, regardless of size." >> >> 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 adm > inistrative 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 (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From austin.murkland at qscend.com Tue Aug 15 14:09:18 2017 From: austin.murkland at qscend.com (Austin Murkland) Date: Tue, 15 Aug 2017 14:09:18 -0400 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <1C167E2A-B184-49BD-B309-2F6A322DA125@semihuman.com> References: <59932A32.8010708@arin.net> <4A6F1E24-9D75-4D72-9F0E-D795C5CF03FD@panix.com> <1C167E2A-B184-49BD-B309-2F6A322DA125@semihuman.com> Message-ID: Concur with the above, Support the draft as written. On Tue, Aug 15, 2017 at 2:08 PM, Chris Woodfield wrote: > Agreed. While there are a wide range of opinions on where this line > belongs, The /47 line appears to have the most consensus, and has my > support. > > -Chris > > > On Aug 15, 2017, at 11:03 AM, David Huberman wrote: > > > > Very well done, everyone! Strongly support this draft. > > > > Kudos to Albert Erdmann and the AC shepherds for their leadership on > this proposal. > > > > > >> On Aug 15, 2017, at 1:06 PM, ARIN wrote: > >> > >> The following has been revised: > >> > >> * Draft Policy ARIN-2017-5: Equalization of Assignment Registration > requirements between IPv4 and IPv6 > >> > >> Revised text is below and can be found at: > >> https://www.arin.net/policy/proposals/2017_5.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 > >> > >> Draft Policies and Proposals under discussion can be found at: > >> https://www.arin.net/policy/proposals/index.html > >> > >> Regards, > >> > >> Sean Hopkins > >> Policy Analyst > >> American Registry for Internet Numbers (ARIN) > >> > >> > >> > >> > >> 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 > subdelegation 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" > >> > >> and > >> > >> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the > NRPM that reads "If the downstream recipient of a netblock ( a /64 or more > addresses) requests publishing in ARIN's registration database, the ISP > must register the netblock, regardless of size." > >> > >> 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 ad > m > > inistrative 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 (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at 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 at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Tue Aug 15 15:05:25 2017 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Tue, 15 Aug 2017 12:05:25 -0700 Subject: [arin-ppml] ARIN-PPML Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements Message-ID: In general support of 2017-5 draft as written. rd On Aug 15, 2017 2:10 PM, wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. NRPM 2017.4: New Policies Implemented (ARIN) > 2. Weekly posting summary for ppml at arin.net (narten at us.ibm.com) > 3. Revised: Draft Policy ARIN-2017-5: Equalization of Assignment > Registration requirements between IPv4 and IPv6 (ARIN) > 4. Re: Revised: Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > (David Huberman) > 5. Re: Revised: Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > (Chris Woodfield) > 6. Re: Revised: Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > (Austin Murkland) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 8 Aug 2017 11:08:52 -0400 > From: ARIN > To: arin-ppml at arin.net > Subject: [arin-ppml] NRPM 2017.4: New Policies Implemented > Message-ID: <5989D404.7000408 at arin.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 22 June 2017, the Board of Trustees adopted the following Recommended > Draft Policies: > > Recommended Draft Policy ARIN-2016-3: Alternative simplified criteria > for justifying small IPv4 transfers > > Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition > Transfers > > These policies are now in effect. A new version of the ARIN Number > Resource Policy Manual (NRPM) has been published to the ARIN website. > > NRPM version 2017.4 is effective 8 August 2017 and supersedes the > previous version. > > The NRPM is available at: > > https://www.arin.net/policy/nrpm.html > > Board minutes are available at: > > https://www.arin.net/about_us/bot/index.html > > Draft policies and proposals are available at: > > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process (PDP) is available at: > > https://www.arin.net/policy/pdp.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > ------------------------------ > > Message: 2 > Date: Fri, 11 Aug 2017 00:53:23 -0400 > From: narten at us.ibm.com > To: arin-ppml at arin.net > Subject: [arin-ppml] Weekly posting summary for ppml at arin.net > Message-ID: <201708110453.v7B4rN95010362 at rotala.raleigh.ibm.com> > Content-Type: text/plain; charset=us-ascii > > Total of 2 messages in the last 7 days. > > script run at: Fri Aug 11 00:53:18 EDT 2017 > > Messages | Bytes | Who > --------+------+--------+----------+------------------------ > 50.00% | 1 | 57.15% | 8155 | narten at us.ibm.com > 50.00% | 1 | 42.85% | 6114 | info at arin.net > --------+------+--------+----------+------------------------ > 100.00% | 2 |100.00% | 14269 | Total > > > > ------------------------------ > > Message: 3 > Date: Tue, 15 Aug 2017 13:06:58 -0400 > From: ARIN > To: arin-ppml at arin.net > Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization > of Assignment Registration requirements between IPv4 and IPv6 > Message-ID: <59932A32.8010708 at arin.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > The following has been revised: > > * Draft Policy ARIN-2017-5: Equalization of Assignment Registration > requirements between IPv4 and IPv6 > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_5.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 > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > > 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 > subdelegation 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" > > and > > 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the > NRPM that reads "If the downstream recipient of a netblock ( a /64 or > more addresses) requests publishing in ARIN's registration database, the > ISP must register the netblock, regardless of size." > > 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. > > > ------------------------------ > > Message: 4 > Date: Tue, 15 Aug 2017 14:03:55 -0400 > From: David Huberman > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 > and > IPv6 > Message-ID: <4A6F1E24-9D75-4D72-9F0E-D795C5CF03FD at panix.com> > Content-Type: text/plain; charset=us-ascii > > Very well done, everyone! Strongly support this draft. > > Kudos to Albert Erdmann and the AC shepherds for their leadership on this > proposal. > > > > On Aug 15, 2017, at 1:06 PM, ARIN wrote: > > > > The following has been revised: > > > > * Draft Policy ARIN-2017-5: Equalization of Assignment Registration > requirements between IPv4 and IPv6 > > > > Revised text is below and can be found at: > > https://www.arin.net/policy/proposals/2017_5.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 > > > > Draft Policies and Proposals under discussion can be found at: > > https://www.arin.net/policy/proposals/index.html > > > > Regards, > > > > Sean Hopkins > > Policy Analyst > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > 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 > subdelegation 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" > > > > and > > > > 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the > NRPM that reads "If the downstream recipient of a netblock ( a /64 or more > addresses) requests publishing in ARIN's registration database, the ISP > must register the netblock, regardless of size." > > > > 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 adm > inistrative 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 (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > > > ------------------------------ > > Message: 5 > Date: Tue, 15 Aug 2017 11:08:10 -0700 > From: Chris Woodfield > To: David Huberman , arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 > and > IPv6 > Message-ID: <1C167E2A-B184-49BD-B309-2F6A322DA125 at semihuman.com> > Content-Type: text/plain; charset=us-ascii > > Agreed. While there are a wide range of opinions on where this line > belongs, The /47 line appears to have the most consensus, and has my > support. > > -Chris > > > On Aug 15, 2017, at 11:03 AM, David Huberman wrote: > > > > Very well done, everyone! Strongly support this draft. > > > > Kudos to Albert Erdmann and the AC shepherds for their leadership on > this proposal. > > > > > >> On Aug 15, 2017, at 1:06 PM, ARIN wrote: > >> > >> The following has been revised: > >> > >> * Draft Policy ARIN-2017-5: Equalization of Assignment Registration > requirements between IPv4 and IPv6 > >> > >> Revised text is below and can be found at: > >> https://www.arin.net/policy/proposals/2017_5.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 > >> > >> Draft Policies and Proposals under discussion can be found at: > >> https://www.arin.net/policy/proposals/index.html > >> > >> Regards, > >> > >> Sean Hopkins > >> Policy Analyst > >> American Registry for Internet Numbers (ARIN) > >> > >> > >> > >> > >> 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 > subdelegation 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" > >> > >> and > >> > >> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the > NRPM that reads "If the downstream recipient of a netblock ( a /64 or more > addresses) requests publishing in ARIN's registration database, the ISP > must register the netblock, regardless of size." > >> > >> 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 ad > m > > inistrative 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 (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at 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 at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > > > ------------------------------ > > Message: 6 > Date: Tue, 15 Aug 2017 14:09:18 -0400 > From: Austin Murkland > To: Chris Woodfield > Cc: David Huberman , arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 > and > IPv6 > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > Concur with the above, Support the draft as written. > > On Tue, Aug 15, 2017 at 2:08 PM, Chris Woodfield > wrote: > > > Agreed. While there are a wide range of opinions on where this line > > belongs, The /47 line appears to have the most consensus, and has my > > support. > > > > -Chris > > > > > On Aug 15, 2017, at 11:03 AM, David Huberman wrote: > > > > > > Very well done, everyone! Strongly support this draft. > > > > > > Kudos to Albert Erdmann and the AC shepherds for their leadership on > > this proposal. > > > > > > > > >> On Aug 15, 2017, at 1:06 PM, ARIN wrote: > > >> > > >> The following has been revised: > > >> > > >> * Draft Policy ARIN-2017-5: Equalization of Assignment Registration > > requirements between IPv4 and IPv6 > > >> > > >> Revised text is below and can be found at: > > >> https://www.arin.net/policy/proposals/2017_5.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 > > >> > > >> Draft Policies and Proposals under discussion can be found at: > > >> https://www.arin.net/policy/proposals/index.html > > >> > > >> Regards, > > >> > > >> Sean Hopkins > > >> Policy Analyst > > >> American Registry for Internet Numbers (ARIN) > > >> > > >> > > >> > > >> > > >> 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 > > subdelegation 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" > > >> > > >> and > > >> > > >> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the > > NRPM that reads "If the downstream recipient of a netblock ( a /64 or > more > > addresses) requests publishing in ARIN's registration database, the ISP > > must register the netblock, regardless of size." > > >> > > >> 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 ad > > m > > > inistrative 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 (ARIN-PPML at arin.net). > > >> Unsubscribe or manage your mailing list subscription at: > > >> http://lists.arin.net/mailman/listinfo/arin-ppml > > >> Please contact info at 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 at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at 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 at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20170815/0b5af2a5/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > ------------------------------ > > End of ARIN-PPML Digest, Vol 146, Issue 2 > ***************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue Aug 15 15:59:58 2017 From: farmer at umn.edu (David Farmer) Date: Tue, 15 Aug 2017 14:59:58 -0500 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <59932A32.8010708@arin.net> References: <59932A32.8010708@arin.net> Message-ID: I support what I think is the intent, but I have language/editorial nits; 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of size" that requires registration? I think logically we need one or the other, or some qualification on "regardless of size" statement. I think it is a good idea to not require registration of less than a /64. But the current language seems contradictory, and therefore confusing, my recommendation is delete "regardless of size", from the sentence and leaving "a /64 or more addresses". I pretty sure we don't want people having an expectation that they can request the registration of "their" /128 address. 2. Also in 3) below; It would seem to require even dynamic assignments be registered if requested, I don't think that is our intent either, section 6.5.5.1 starts with "Each static IPv6 assignment containing", this needs a similar qualification. Also, I'm fine with the deltas in the policy statement but it would be helpful to see the final resulting policy block, maybe in a separate email so we can all see how the result reads. Thanks, I think we are getting close, maybe one or two more turns of the crank. On Tue, Aug 15, 2017 at 12:06 PM, ARIN wrote: > The following has been revised: > > * Draft Policy ARIN-2017-5: Equalization of Assignment Registration > requirements between IPv4 and IPv6 > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_5.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 > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > > 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 > subdelegation 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" > > and > > 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM > that reads "If the downstream recipient of a netblock ( a /64 or more > addresses) requests publishing in ARIN's registration database, the ISP > must register the netblock, regardless of size." > > 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 (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- =============================================== David Farmer Email:farmer at umn.edu 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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at egh.com Tue Aug 15 16:14:40 2017 From: john at egh.com (John Santos) Date: Tue, 15 Aug 2017 16:14:40 -0400 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59932A32.8010708@arin.net> Message-ID: <4f8974ce-8c1a-b73e-e069-38fb2939774e@egh.com> I think that the "/64 or more addresses" and the "regardless of size" are meant to convey that any netblock between a /64 and a /48 can and should be registered if the recipient requests it, even if the block is smaller than the /47 which would make it mandatory. Perhaps there is better wording that would make this clearer. Three ranges: 1. smaller than /64: shouldn't be issued, can't be registered. 2. /64 through /48: register at recipient's request 3. /47 or larger: must be registered I agree on dynamic assignments Otherwise, I think this is a much clearer and better update to the proposed policy, and can't find any other reason not to support it. (I.E. this is a tentative vote FOR, if there is such a thing.) On 8/15/2017 3:59 PM, David Farmer wrote: > I support what I think is the intent, but I have language/editorial nits; > > 1. In 3) below; Which is it "a /64 or more addresses" or "regardless > of size" that requires registration? I think logically we need one or > the other, or some qualification on "regardless of size" statement. I > think it is a good idea to not require registration of less than a > /64. But the current language seems contradictory, and therefore > confusing, my recommendation is delete "regardless of size", from the > sentence and leaving "a /64 or more addresses". I pretty sure we > don't want people having an expectation that they can request the > registration of "their" /128 address. > > 2. Also in 3) below; It would seem to require even dynamic assignments > be registered if requested, I don't think that is our intent either, > section 6.5.5.1 starts with "Each static IPv6 assignment containing", > this needs a similar qualification. > > Also, I'm fine with the deltas in the policy statement but it would be > helpful to see the final resulting policy block, maybe in a separate > email so we can all see how the result reads. > > Thanks, I think we are getting close, maybe one or two more turns of > the crank. > > On Tue, Aug 15, 2017 at 12:06 PM, ARIN > wrote: > > The following has been revised: > > * Draft Policy ARIN-2017-5: Equalization of Assignment > Registration requirements between IPv4 and IPv6 > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_5.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 > > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > > 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 subdelegation 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" > > and > > 3) Add new section 6.5.5.4 "Downstream Registration Requests" to > the NRPM that reads "If the downstream recipient of a netblock ( a > /64 or more addresses) requests publishing in ARIN's registration > database, the ISP must register the netblock, regardless of size." > > 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. > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinb at thewire.ca Tue Aug 15 22:04:58 2017 From: kevinb at thewire.ca (Kevin Blumberg) Date: Wed, 16 Aug 2017 02:04:58 +0000 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59932A32.8010708@arin.net> Message-ID: <7E7773B523E82C478734E793E58F69E78EC95958@SBS2011.thewireinc.local> David, I agree with both of your edits. I don?t believe either fundamentally change the current proposal, and I support the 2017-5 which a strong recommendation for those edits. I would also add that the word netblock is not in the NRPM today and should be either ?static IPv6 assignment? or possibly ?reassigned IPv6 address blocks?. Thanks, Kevin Blumberg From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer Sent: Tuesday, August 15, 2017 4:00 PM To: ARIN Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 I support what I think is the intent, but I have language/editorial nits; 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of size" that requires registration? I think logically we need one or the other, or some qualification on "regardless of size" statement. I think it is a good idea to not require registration of less than a /64. But the current language seems contradictory, and therefore confusing, my recommendation is delete "regardless of size", from the sentence and leaving "a /64 or more addresses". I pretty sure we don't want people having an expectation that they can request the registration of "their" /128 address. 2. Also in 3) below; It would seem to require even dynamic assignments be registered if requested, I don't think that is our intent either, section 6.5.5.1 starts with "Each static IPv6 assignment containing", this needs a similar qualification. Also, I'm fine with the deltas in the policy statement but it would be helpful to see the final resulting policy block, maybe in a separate email so we can all see how the result reads. Thanks, I think we are getting close, maybe one or two more turns of the crank. On Tue, Aug 15, 2017 at 12:06 PM, ARIN > wrote: The following has been revised: * Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_5.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 Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) 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 subdelegation 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" and 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM that reads "If the downstream recipient of a netblock ( a /64 or more addresses) requests publishing in ARIN's registration database, the ISP must register the netblock, regardless of size." 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 (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu 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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Wed Aug 16 07:10:30 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 16 Aug 2017 07:10:30 -0400 (EDT) Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <4f8974ce-8c1a-b73e-e069-38fb2939774e@egh.com> References: <59932A32.8010708@arin.net> <4f8974ce-8c1a-b73e-e069-38fb2939774e@egh.com> Message-ID: I am in favor of the draft, with or without the changes to make it clearer. I suggest the following language for clarity: 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM that reads "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that static assignment in ARIN's registration database, the ISP must register that static assignment." Since "static assignment" is the term in this section, not netblock, I suggest using this term instead of "netblock". "Of any size" is not needed, as the language would require the ISP to register in total whatever size the ISP has assigned to the downstream in the ARIN database if requested by the downstream recipient, as long as it was /64 or more. This language would also prevent requests to register only part of an assignment. I think this language works in making the intent of the new section more clear. Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 15 Aug 2017, John Santos wrote: > I think that the "/64 or more addresses" and the "regardless of size" are > meant to convey that any netblock between a /64 and a /48 can and should be > registered if the recipient requests it, even if the block is smaller than > the /47 which would make it mandatory. Perhaps there is better wording that > would make this clearer. > > Three ranges: > > 1. smaller than /64: shouldn't be issued, can't be registered. > 2. /64 through /48: register at recipient's request > 3. /47 or larger: must be registered > > I agree on dynamic assignments > > Otherwise, I think this is a much clearer and better update to the proposed > policy, and can't find any other reason not to support it. (I.E. this is a > tentative vote FOR, if there is such a thing.) > > > > On 8/15/2017 3:59 PM, David Farmer wrote: >> I support what I think is the intent, but I have language/editorial nits; >> >> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of >> size" that requires registration? I think logically we need one or the >> other, or some qualification on "regardless of size" statement. I think it >> is a good idea to not require registration of less than a /64. But the >> current language seems contradictory, and therefore confusing, my >> recommendation is delete "regardless of size", from the sentence and >> leaving "a /64 or more addresses". I pretty sure we don't want people >> having an expectation that they can request the registration of "their" >> /128 address. >> >> 2. Also in 3) below; It would seem to require even dynamic assignments be >> registered if requested, I don't think that is our intent either, section >> 6.5.5.1 starts with "Each static IPv6 assignment containing", this needs a >> similar qualification. >> >> Also, I'm fine with the deltas in the policy statement but it would be >> helpful to see the final resulting policy block, maybe in a separate email >> so we can all see how the result reads. >> >> Thanks, I think we are getting close, maybe one or two more turns of the >> crank. >> >> On Tue, Aug 15, 2017 at 12:06 PM, ARIN > > wrote: >> >> The following has been revised: >> >> * Draft Policy ARIN-2017-5: Equalization of Assignment >> Registration requirements between IPv4 and IPv6 >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_5.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 >> >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> >> 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 subdelegation 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" >> >> and >> >> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to >> the NRPM that reads "If the downstream recipient of a netblock ( a >> /64 or more addresses) requests publishing in ARIN's registration >> database, the ISP must register the netblock, regardless of size." >> >> 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. >> > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > > From bjones at vt.edu Wed Aug 16 14:50:24 2017 From: bjones at vt.edu (Brian Jones) Date: Wed, 16 Aug 2017 14:50:24 -0400 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59932A32.8010708@arin.net> <4f8974ce-8c1a-b73e-e069-38fb2939774e@egh.com> Message-ID: I'm in favor of this draft and +1 Albert's suggested language for wording changes. -- Brian ? E Jones ? On Wed, Aug 16, 2017 at 7:10 AM, wrote: > I am in favor of the draft, with or without the changes to make it clearer. > > I suggest the following language for clarity: > > 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM > that reads "If the downstream recipient of a static assignment of /64 or > more addresses requests publishing of that static assignment in ARIN's > registration database, the ISP must register that static assignment." > > Since "static assignment" is the term in this section, not netblock, I > suggest using this term instead of "netblock". "Of any size" is not > needed, as the language would require the ISP to register in total whatever > size the ISP has assigned to the downstream in the ARIN database if > requested by the downstream recipient, as long as it was /64 or more. > > This language would also prevent requests to register only part of an > assignment. I think this language works in making the intent of the new > section more clear. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > > On Tue, 15 Aug 2017, John Santos wrote: > > I think that the "/64 or more addresses" and the "regardless of size" are >> meant to convey that any netblock between a /64 and a /48 can and should be >> registered if the recipient requests it, even if the block is smaller than >> the /47 which would make it mandatory. Perhaps there is better wording >> that would make this clearer. >> >> Three ranges: >> >> 1. smaller than /64: shouldn't be issued, can't be registered. >> 2. /64 through /48: register at recipient's request >> 3. /47 or larger: must be registered >> >> I agree on dynamic assignments >> >> Otherwise, I think this is a much clearer and better update to the >> proposed policy, and can't find any other reason not to support it. (I.E. >> this is a tentative vote FOR, if there is such a thing.) >> >> >> >> On 8/15/2017 3:59 PM, David Farmer wrote: >> >>> I support what I think is the intent, but I have language/editorial nits; >>> >>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of >>> size" that requires registration? I think logically we need one or the >>> other, or some qualification on "regardless of size" statement. I think it >>> is a good idea to not require registration of less than a /64. But the >>> current language seems contradictory, and therefore confusing, my >>> recommendation is delete "regardless of size", from the sentence and >>> leaving "a /64 or more addresses". I pretty sure we don't want people >>> having an expectation that they can request the registration of "their" >>> /128 address. >>> >>> 2. Also in 3) below; It would seem to require even dynamic assignments >>> be registered if requested, I don't think that is our intent either, >>> section 6.5.5.1 starts with "Each static IPv6 assignment containing", this >>> needs a similar qualification. >>> >>> Also, I'm fine with the deltas in the policy statement but it would be >>> helpful to see the final resulting policy block, maybe in a separate email >>> so we can all see how the result reads. >>> >>> Thanks, I think we are getting close, maybe one or two more turns of the >>> crank. >>> >>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN >> info at arin.net>> wrote: >>> >>> The following has been revised: >>> >>> * Draft Policy ARIN-2017-5: Equalization of Assignment >>> Registration requirements between IPv4 and IPv6 >>> >>> Revised text is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_5.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 >>> >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> >>> Regards, >>> >>> Sean Hopkins >>> Policy Analyst >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> >>> >>> 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 subdelegation 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" >>> >>> and >>> >>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to >>> the NRPM that reads "If the downstream recipient of a netblock ( a >>> /64 or more addresses) requests publishing in ARIN's registration >>> database, the ISP must register the netblock, regardless of size." >>> >>> 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. >>> >>> -- >> John Santos >> Evans Griffiths & Hart, Inc. >> 781-861-0670 ext 539 >> >> >> _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at egh.com Wed Aug 16 22:38:38 2017 From: john at egh.com (John Santos) Date: Wed, 16 Aug 2017 22:38:38 -0400 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59932A32.8010708@arin.net> <4f8974ce-8c1a-b73e-e069-38fb2939774e@egh.com> Message-ID: Your wording is simpler and better. Just saying "static" and "/64 or more" clarifies all the ambiguous situations. Unless someone has a good argument why a recipient would only want part of their assignment registered, that seems to be a non-issue. In any case, in such an event, the ISP could always issue two assignments, and only register one of them to the recipient, retaining the other one as registered to the ISP, like any other small assignment would be by default. (They would probably charge more for this service, but that's not ARIN's department :-) ) I support. On 8/16/2017 7:10 AM, hostmaster at uneedus.com wrote: > I am in favor of the draft, with or without the changes to make it > clearer. > > I suggest the following language for clarity: > > 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the > NRPM that reads "If the downstream recipient of a static assignment of > /64 or more addresses requests publishing of that static assignment in > ARIN's registration database, the ISP must register that static > assignment." > > Since "static assignment" is the term in this section, not netblock, I > suggest using this term instead of "netblock". "Of any size" is not > needed, as the language would require the ISP to register in total > whatever size the ISP has assigned to the downstream in the ARIN > database if requested by the downstream recipient, as long as it was > /64 or more. > > This language would also prevent requests to register only part of an > assignment. I think this language works in making the intent of the > new section more clear. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > > On Tue, 15 Aug 2017, John Santos wrote: > >> I think that the "/64 or more addresses" and the "regardless of size" >> are meant to convey that any netblock between a /64 and a /48 can and >> should be registered if the recipient requests it, even if the block >> is smaller than the /47 which would make it mandatory. Perhaps there >> is better wording that would make this clearer. >> >> Three ranges: >> >> 1. smaller than /64: shouldn't be issued, can't be registered. >> 2. /64 through /48: register at recipient's request >> 3. /47 or larger: must be registered >> >> I agree on dynamic assignments >> >> Otherwise, I think this is a much clearer and better update to the >> proposed policy, and can't find any other reason not to support it. >> (I.E. this is a tentative vote FOR, if there is such a thing.) >> >> >> >> On 8/15/2017 3:59 PM, David Farmer wrote: >>> I support what I think is the intent, but I have language/editorial >>> nits; >>> >>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless >>> of size" that requires registration? I think logically we need one >>> or the other, or some qualification on "regardless of size" >>> statement. I think it is a good idea to not require registration of >>> less than a /64. But the current language seems contradictory, and >>> therefore confusing, my recommendation is delete "regardless of >>> size", from the sentence and leaving "a /64 or more addresses". I >>> pretty sure we don't want people having an expectation that they can >>> request the registration of "their" /128 address. >>> >>> 2. Also in 3) below; It would seem to require even dynamic >>> assignments be registered if requested, I don't think that is our >>> intent either, section 6.5.5.1 starts with "Each static IPv6 >>> assignment containing", this needs a similar qualification. >>> >>> Also, I'm fine with the deltas in the policy statement but it would >>> be helpful to see the final resulting policy block, maybe in a >>> separate email so we can all see how the result reads. >>> >>> Thanks, I think we are getting close, maybe one or two more turns of >>> the crank. >>> >>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN >> > wrote: >>> >>> The following has been revised: >>> >>> * Draft Policy ARIN-2017-5: Equalization of Assignment >>> Registration requirements between IPv4 and IPv6 >>> >>> Revised text is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_5.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 >>> >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> >>> Regards, >>> >>> Sean Hopkins >>> Policy Analyst >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> >>> >>> 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 subdelegation 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" >>> >>> and >>> >>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to >>> the NRPM that reads "If the downstream recipient of a netblock ( a >>> /64 or more addresses) requests publishing in ARIN's registration >>> database, the ISP must register the netblock, regardless of size." >>> >>> 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. >>> >> -- >> John Santos >> Evans Griffiths & Hart, Inc. >> 781-861-0670 ext 539 >> >> > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From farmer at umn.edu Thu Aug 17 12:53:23 2017 From: farmer at umn.edu (David Farmer) Date: Thu, 17 Aug 2017 11:53:23 -0500 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59932A32.8010708@arin.net> <4f8974ce-8c1a-b73e-e069-38fb2939774e@egh.com> Message-ID: Here is a slightly different formulation to consider. I refactored the title a little, and based the phrasing on other parts of section 6.5.5 6.5.5.4 Registration Requested by Recipient If requested by the downstream recipient of a block, each static IPv6 assignment containing a /64 or more addresses, shall be registered, as described in section 6.5.5.1. I'd like us to think about adding an additional section, based on previous discussions. 6.5.5.5 Re-allocation to ISPs Each IPv6 re-allocation to a downstream ISP, regardless of size, intended for further assignment by the downstream ISP's to it's customers, shall be registered, as described in section 6.5.5.1 Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. I think this is a cut and past error, I think the reference should be to 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with sections 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. Thanks. On Wed, Aug 16, 2017 at 6:10 AM, wrote: > I am in favor of the draft, with or without the changes to make it clearer. > > I suggest the following language for clarity: > > 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM > that reads "If the downstream recipient of a static assignment of /64 or > more addresses requests publishing of that static assignment in ARIN's > registration database, the ISP must register that static assignment." > > Since "static assignment" is the term in this section, not netblock, I > suggest using this term instead of "netblock". "Of any size" is not > needed, as the language would require the ISP to register in total whatever > size the ISP has assigned to the downstream in the ARIN database if > requested by the downstream recipient, as long as it was /64 or more. > > This language would also prevent requests to register only part of an > assignment. I think this language works in making the intent of the new > section more clear. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > > On Tue, 15 Aug 2017, John Santos wrote: > > I think that the "/64 or more addresses" and the "regardless of size" are >> meant to convey that any netblock between a /64 and a /48 can and should be >> registered if the recipient requests it, even if the block is smaller than >> the /47 which would make it mandatory. Perhaps there is better wording >> that would make this clearer. >> >> Three ranges: >> >> 1. smaller than /64: shouldn't be issued, can't be registered. >> 2. /64 through /48: register at recipient's request >> 3. /47 or larger: must be registered >> >> I agree on dynamic assignments >> >> Otherwise, I think this is a much clearer and better update to the >> proposed policy, and can't find any other reason not to support it. (I.E. >> this is a tentative vote FOR, if there is such a thing.) >> >> >> >> On 8/15/2017 3:59 PM, David Farmer wrote: >> >>> I support what I think is the intent, but I have language/editorial nits; >>> >>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of >>> size" that requires registration? I think logically we need one or the >>> other, or some qualification on "regardless of size" statement. I think it >>> is a good idea to not require registration of less than a /64. But the >>> current language seems contradictory, and therefore confusing, my >>> recommendation is delete "regardless of size", from the sentence and >>> leaving "a /64 or more addresses". I pretty sure we don't want people >>> having an expectation that they can request the registration of "their" >>> /128 address. >>> >>> 2. Also in 3) below; It would seem to require even dynamic assignments >>> be registered if requested, I don't think that is our intent either, >>> section 6.5.5.1 starts with "Each static IPv6 assignment containing", this >>> needs a similar qualification. >>> >>> Also, I'm fine with the deltas in the policy statement but it would be >>> helpful to see the final resulting policy block, maybe in a separate email >>> so we can all see how the result reads. >>> >>> Thanks, I think we are getting close, maybe one or two more turns of the >>> crank. >>> >>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN >> info at arin.net>> wrote: >>> >>> The following has been revised: >>> >>> * Draft Policy ARIN-2017-5: Equalization of Assignment >>> Registration requirements between IPv4 and IPv6 >>> >>> Revised text is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_5.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 >>> >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> >>> Regards, >>> >>> Sean Hopkins >>> Policy Analyst >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> >>> >>> 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 subdelegation 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" >>> >>> and >>> >>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to >>> the NRPM that reads "If the downstream recipient of a netblock ( a >>> /64 or more addresses) requests publishing in ARIN's registration >>> database, the ISP must register the netblock, regardless of size." >>> >>> 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. >>> >>> -- >> John Santos >> Evans Griffiths & Hart, Inc. >> 781-861-0670 ext 539 >> >> >> _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- =============================================== David Farmer Email:farmer at umn.edu 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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsawyer at gci.com Thu Aug 17 13:29:31 2017 From: lsawyer at gci.com (Leif Sawyer) Date: Thu, 17 Aug 2017 17:29:31 +0000 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59932A32.8010708@arin.net> <4f8974ce-8c1a-b73e-e069-38fb2939774e@egh.com> , Message-ID: Thanks for the feedback, David. I've added the fix for 6.5.5.2, since we're already in the section. I've also modified the text for 6.5.5.4 as well, because I think your suggesting is a little cleaner. I'm not sure what the point of 6.5.5.5 is - you're just reiterating 6.5.5.1. That said, we could potentially clean up 6.5.5.1 by extending "static IPv6 assignment" to "static IPv6 assignment, or allocation," - or something similar. Which also brings to mind the question: LIR or ISP? Both are in use in 6.5.... ________________________________ From: ARIN-PPML [arin-ppml-bounces at arin.net] on behalf of David Farmer [farmer at umn.edu] Sent: Thursday, August 17, 2017 8:53 AM To: hostmaster at uneedus.com Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 [External Email] Here is a slightly different formulation to consider. I refactored the title a little, and based the phrasing on other parts of section 6.5.5 6.5.5.4 Registration Requested by Recipient If requested by the downstream recipient of a block, each static IPv6 assignment containing a /64 or more addresses, shall be registered, as described in section 6.5.5.1. I'd like us to think about adding an additional section, based on previous discussions. 6.5.5.5 Re-allocation to ISPs Each IPv6 re-allocation to a downstream ISP, regardless of size, intended for further assignment by the downstream ISP's to it's customers, shall be registered, as described in section 6.5.5.1 Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. I think this is a cut and past error, I think the reference should be to 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with sections 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. Thanks. On Wed, Aug 16, 2017 at 6:10 AM, > wrote: I am in favor of the draft, with or without the changes to make it clearer. I suggest the following language for clarity: 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM that reads "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that static assignment in ARIN's registration database, the ISP must register that static assignment." Since "static assignment" is the term in this section, not netblock, I suggest using this term instead of "netblock". "Of any size" is not needed, as the language would require the ISP to register in total whatever size the ISP has assigned to the downstream in the ARIN database if requested by the downstream recipient, as long as it was /64 or more. This language would also prevent requests to register only part of an assignment. I think this language works in making the intent of the new section more clear. Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 15 Aug 2017, John Santos wrote: I think that the "/64 or more addresses" and the "regardless of size" are meant to convey that any netblock between a /64 and a /48 can and should be registered if the recipient requests it, even if the block is smaller than the /47 which would make it mandatory. Perhaps there is better wording that would make this clearer. Three ranges: 1. smaller than /64: shouldn't be issued, can't be registered. 2. /64 through /48: register at recipient's request 3. /47 or larger: must be registered I agree on dynamic assignments Otherwise, I think this is a much clearer and better update to the proposed policy, and can't find any other reason not to support it. (I.E. this is a tentative vote FOR, if there is such a thing.) On 8/15/2017 3:59 PM, David Farmer wrote: I support what I think is the intent, but I have language/editorial nits; 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of size" that requires registration? I think logically we need one or the other, or some qualification on "regardless of size" statement. I think it is a good idea to not require registration of less than a /64. But the current language seems contradictory, and therefore confusing, my recommendation is delete "regardless of size", from the sentence and leaving "a /64 or more addresses". I pretty sure we don't want people having an expectation that they can request the registration of "their" /128 address. 2. Also in 3) below; It would seem to require even dynamic assignments be registered if requested, I don't think that is our intent either, section 6.5.5.1 starts with "Each static IPv6 assignment containing", this needs a similar qualification. Also, I'm fine with the deltas in the policy statement but it would be helpful to see the final resulting policy block, maybe in a separate email so we can all see how the result reads. Thanks, I think we are getting close, maybe one or two more turns of the crank. On Tue, Aug 15, 2017 at 12:06 PM, ARIN >> wrote: The following has been revised: * Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_5.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 > Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html > Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) 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 subdelegation 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" and 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM that reads "If the downstream recipient of a netblock ( a /64 or more addresses) requests publishing in ARIN's registration database, the ISP must register the netblock, regardless of size." 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. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 _______________________________________________ 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu 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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Thu Aug 17 13:50:22 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 17 Aug 2017 13:50:22 -0400 (EDT) Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59932A32.8010708@arin.net> <4f8974ce-8c1a-b73e-e069-38fb2939774e@egh.com> , Message-ID: I note that any ISP size reassignment, with the recommended /48 for each end user site, will be /47 or larger, which must always be registered. Thus, I think 6.5.5.5 language is unneeded, since any LIR/ISP reassignment will be large enough to already trigger registration. Under the current policy, LIR's and ISP's are equal, so usually both terms are stated in any policy that mentions them. May I also suggest that if we are going to require registration upon downstream request for IPv6, that we consider placing the same language and requirements for IPv4 customers as well? And if we do, where do we draw the minimum line? Maybe a /32.... Also, good catch on the cut and paste error..... Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 17 Aug 2017, Leif Sawyer wrote: > Thanks for the feedback, David. > > I've added the fix for 6.5.5.2, since we're already in the section. > > I've also modified the text for 6.5.5.4 as well, because I think your suggesting is a little cleaner. > > I'm not sure what the point of 6.5.5.5 is - you're just reiterating 6.5.5.1. > That said, we could potentially clean up 6.5.5.1 by extending "static IPv6 assignment" > to "static IPv6 assignment, or allocation," - or something similar. > > > Which also brings to mind the question: LIR or ISP? Both are in use in 6.5.... > > ________________________________ > From: ARIN-PPML [arin-ppml-bounces at arin.net] on behalf of David Farmer [farmer at umn.edu] > Sent: Thursday, August 17, 2017 8:53 AM > To: hostmaster at uneedus.com > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 > > [External Email] > > Here is a slightly different formulation to consider. I refactored the title a little, and based the phrasing on other parts of section 6.5.5 > > 6.5.5.4 Registration Requested by Recipient > > If requested by the downstream recipient of a block, each static IPv6 assignment containing a /64 or more addresses, shall be registered, as described in section 6.5.5.1. > > I'd like us to think about adding an additional section, based on previous discussions. > > 6.5.5.5 Re-allocation to ISPs > > Each IPv6 re-allocation to a downstream ISP, regardless of size, intended for further assignment by the downstream ISP's to it's customers, shall be registered, as described in section 6.5.5.1 > > Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. I think this is a cut and past error, I think the reference should be to 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with sections 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. > > Thanks. > > On Wed, Aug 16, 2017 at 6:10 AM, > wrote: > I am in favor of the draft, with or without the changes to make it clearer. > > I suggest the following language for clarity: > > 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM that reads "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that static assignment in ARIN's registration database, the ISP must register that static assignment." > > Since "static assignment" is the term in this section, not netblock, I suggest using this term instead of "netblock". "Of any size" is not needed, as the language would require the ISP to register in total whatever size the ISP has assigned to the downstream in the ARIN database if requested by the downstream recipient, as long as it was /64 or more. > > This language would also prevent requests to register only part of an assignment. I think this language works in making the intent of the new section more clear. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > > On Tue, 15 Aug 2017, John Santos wrote: > > I think that the "/64 or more addresses" and the "regardless of size" are meant to convey that any netblock between a /64 and a /48 can and should be registered if the recipient requests it, even if the block is smaller than the /47 which would make it mandatory. Perhaps there is better wording that would make this clearer. > > Three ranges: > > 1. smaller than /64: shouldn't be issued, can't be registered. > 2. /64 through /48: register at recipient's request > 3. /47 or larger: must be registered > > I agree on dynamic assignments > > Otherwise, I think this is a much clearer and better update to the proposed policy, and can't find any other reason not to support it. (I.E. this is a tentative vote FOR, if there is such a thing.) > > > > On 8/15/2017 3:59 PM, David Farmer wrote: > I support what I think is the intent, but I have language/editorial nits; > > 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of size" that requires registration? I think logically we need one or the other, or some qualification on "regardless of size" statement. I think it is a good idea to not require registration of less than a /64. But the current language seems contradictory, and therefore confusing, my recommendation is delete "regardless of size", from the sentence and leaving "a /64 or more addresses". I pretty sure we don't want people having an expectation that they can request the registration of "their" /128 address. > > 2. Also in 3) below; It would seem to require even dynamic assignments be registered if requested, I don't think that is our intent either, section 6.5.5.1 starts with "Each static IPv6 assignment containing", this needs a similar qualification. > > Also, I'm fine with the deltas in the policy statement but it would be helpful to see the final resulting policy block, maybe in a separate email so we can all see how the result reads. > > Thanks, I think we are getting close, maybe one or two more turns of the crank. > > On Tue, Aug 15, 2017 at 12:06 PM, ARIN >> wrote: > > The following has been revised: > > * Draft Policy ARIN-2017-5: Equalization of Assignment > Registration requirements between IPv4 and IPv6 > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_5.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 > > > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > > 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 subdelegation 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" > > and > > 3) Add new section 6.5.5.4 "Downstream Registration Requests" to > the NRPM that reads "If the downstream recipient of a netblock ( a > /64 or more addresses) requests publishing in ARIN's registration > database, the ISP must register the netblock, regardless of size." > > 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. > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > 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 > =============================================== > From pmcnary at cameron.net Thu Aug 17 14:26:44 2017 From: pmcnary at cameron.net (Paul McNary) Date: Thu, 17 Aug 2017 13:26:44 -0500 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59932A32.8010708@arin.net> <4f8974ce-8c1a-b73e-e069-38fb2939774e@egh.com> Message-ID: <77aa9cb4-8162-dbed-f950-cae808914c09@cameron.net> A /47 is smaller than a /48 and would not be required to be registered? On 8/17/2017 12:50 PM, hostmaster at uneedus.com wrote: > I note that any ISP size reassignment, with the recommended /48 for > each end user site, will be /47 or larger, which must always be > registered. > > Thus, I think 6.5.5.5 language is unneeded, since any LIR/ISP > reassignment will be large enough to already trigger registration. > > Under the current policy, LIR's and ISP's are equal, so usually both > terms are stated in any policy that mentions them. > > May I also suggest that if we are going to require registration upon > downstream request for IPv6, that we consider placing the same > language and requirements for IPv4 customers as well? And if we do, > where do we draw the minimum line? Maybe a /32.... > > Also, good catch on the cut and paste error..... > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > On Thu, 17 Aug 2017, Leif Sawyer wrote: > >> Thanks for the feedback, David. >> >> I've added the fix for 6.5.5.2, since we're already in the section. >> >> I've also modified the text for 6.5.5.4 as well, because I think your >> suggesting is a little cleaner. >> >> I'm not sure what the point of 6.5.5.5 is - you're just reiterating >> 6.5.5.1. >> That said, we could potentially clean up 6.5.5.1 by extending "static >> IPv6 assignment" >> to "static IPv6 assignment, or allocation," - or something similar. >> >> >> Which also brings to mind the question: LIR or ISP? Both are in >> use in 6.5.... >> >> ________________________________ >> From: ARIN-PPML [arin-ppml-bounces at arin.net] on behalf of David >> Farmer [farmer at umn.edu] >> Sent: Thursday, August 17, 2017 8:53 AM >> To: hostmaster at uneedus.com >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: >> Equalization of Assignment Registration requirements between IPv4 and >> IPv6 >> >> [External Email] >> >> Here is a slightly different formulation to consider. I refactored >> the title a little, and based the phrasing on other parts of section >> 6.5.5 >> >> 6.5.5.4 Registration Requested by Recipient >> >> If requested by the downstream recipient of a block, each static IPv6 >> assignment containing a /64 or more addresses, shall be registered, >> as described in section 6.5.5.1. >> >> I'd like us to think about adding an additional section, based on >> previous discussions. >> >> 6.5.5.5 Re-allocation to ISPs >> >> Each IPv6 re-allocation to a downstream ISP, regardless of size, >> intended for further assignment by the downstream ISP's to it's >> customers, shall be registered, as described in section 6.5.5.1 >> >> Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. I >> think this is a cut and past error, I think the reference should be >> to 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with >> sections 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. >> >> Thanks. >> >> On Wed, Aug 16, 2017 at 6:10 AM, >> > wrote: >> I am in favor of the draft, with or without the changes to make it >> clearer. >> >> I suggest the following language for clarity: >> >> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the >> NRPM that reads "If the downstream recipient of a static assignment >> of /64 or more addresses requests publishing of that static >> assignment in ARIN's registration database, the ISP must register >> that static assignment." >> >> Since "static assignment" is the term in this section, not netblock, >> I suggest using this term instead of "netblock". "Of any size" is >> not needed, as the language would require the ISP to register in >> total whatever size the ISP has assigned to the downstream in the >> ARIN database if requested by the downstream recipient, as long as it >> was /64 or more. >> >> This language would also prevent requests to register only part of an >> assignment. I think this language works in making the intent of the >> new section more clear. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> >> On Tue, 15 Aug 2017, John Santos wrote: >> >> I think that the "/64 or more addresses" and the "regardless of size" >> are meant to convey that any netblock between a /64 and a /48 can and >> should be registered if the recipient requests it, even if the block >> is smaller than the /47 which would make it mandatory. Perhaps there >> is better wording that would make this clearer. >> >> Three ranges: >> >> 1. smaller than /64: shouldn't be issued, can't be registered. >> 2. /64 through /48: register at recipient's request >> 3. /47 or larger: must be registered >> >> I agree on dynamic assignments >> >> Otherwise, I think this is a much clearer and better update to the >> proposed policy, and can't find any other reason not to support it. >> (I.E. this is a tentative vote FOR, if there is such a thing.) >> >> >> >> On 8/15/2017 3:59 PM, David Farmer wrote: >> I support what I think is the intent, but I have language/editorial >> nits; >> >> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless >> of size" that requires registration? I think logically we need one >> or the other, or some qualification on "regardless of size" >> statement. I think it is a good idea to not require registration of >> less than a /64. But the current language seems contradictory, and >> therefore confusing, my recommendation is delete "regardless of >> size", from the sentence and leaving "a /64 or more addresses". I >> pretty sure we don't want people having an expectation that they can >> request the registration of "their" /128 address. >> >> 2. Also in 3) below; It would seem to require even dynamic >> assignments be registered if requested, I don't think that is our >> intent either, section 6.5.5.1 starts with "Each static IPv6 >> assignment containing", this needs a similar qualification. >> >> Also, I'm fine with the deltas in the policy statement but it would >> be helpful to see the final resulting policy block, maybe in a >> separate email so we can all see how the result reads. >> >> Thanks, I think we are getting close, maybe one or two more turns of >> the crank. >> >> On Tue, Aug 15, 2017 at 12:06 PM, ARIN >> >> >> wrote: >> >> The following has been revised: >> >> * Draft Policy ARIN-2017-5: Equalization of Assignment >> Registration requirements between IPv4 and IPv6 >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_5.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 >> > >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> > >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> >> 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 subdelegation 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" >> >> and >> >> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to >> the NRPM that reads "If the downstream recipient of a netblock ( a >> /64 or more addresses) requests publishing in ARIN's registration >> database, the ISP must register the netblock, regardless of size." >> >> 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. >> >> -- >> John Santos >> Evans Griffiths & Hart, Inc. >> 781-861-0670 ext 539 >> >> >> _______________________________________________ >> 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: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> >> Please contact info at arin.net if you experience >> any issues. >> >> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> 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 (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > From farmer at umn.edu Thu Aug 17 14:43:28 2017 From: farmer at umn.edu (David Farmer) Date: Thu, 17 Aug 2017 13:43:28 -0500 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59932A32.8010708@arin.net> <4f8974ce-8c1a-b73e-e069-38fb2939774e@egh.com> Message-ID: Inline. On Thu, Aug 17, 2017 at 12:29 PM, Leif Sawyer wrote: > Thanks for the feedback, David. > > I've added the fix for 6.5.5.2, since we're already in the section. > > I've also modified the text for 6.5.5.4 as well, because I think your > suggesting is a little cleaner. > > I'm not sure what the point of 6.5.5.5 is - you're just reiterating > 6.5.5.1. > That said, we could potentially clean up 6.5.5.1 by extending "static IPv6 > assignment" > to "static IPv6 assignment, or allocation," - or something similar. > ISP re-allocations need to be registered regardless of size or if it is being advertised or not. For example, if for some stupid reason a /56 was re-allocated to downsterm ISP so they could assign /64s to customers that has to be registered, by 6.5.5.1 that wouldn't have to be registered. Should you re-allocate a /56, @!@#$ NO!!! But if you did, it has to be registered. This is so LEA and other legal requests get directly to the correct ISP the first time. I think this is important enough issue that it should have it's own section, and not get blended in to 6.5.5.1. Now should that be part of this policy maybe not, maybe this belongs in ARIN-2017-3 or whole new separate policy proposal instead. Suggestions? > Which also brings to mind the question: LIR or ISP? Both are in use in > 6.5.... > In my mind you could be called an LIR or ISP if you get addresses from ARIN (an RIR) and assign them to others, If you get addresses from an LIR or another ISP and assign them you are just an downstream ISP, I wouldn't call you an LIR. But that's just me, I'm not sure there is an official answer. Thanks ------------------------------ > *From:* ARIN-PPML [arin-ppml-bounces at arin.net] on behalf of David Farmer [ > farmer at umn.edu] > *Sent:* Thursday, August 17, 2017 8:53 AM > *To:* hostmaster at uneedus.com > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 and IPv6 > > [External Email] > > Here is a slightly different formulation to consider. I refactored the > title a little, and based the phrasing on other parts of section 6.5.5 > > 6.5.5.4 Registration Requested by Recipient > > If requested by the downstream recipient of a block, each static IPv6 > assignment containing a /64 or more addresses, shall be registered, as > described in section 6.5.5.1. > > > I'd like us to think about adding an additional section, based on previous > discussions. > > 6.5.5.5 Re-allocation to ISPs > > Each IPv6 re-allocation to a downstream ISP, regardless of size, intended > for further assignment by the downstream ISP's to it's customers, shall be > registered, as described in section 6.5.5.1 > > > Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. I > think this is a cut and past error, I think the reference should be to > 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with sections > 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. > > Thanks. > > On Wed, Aug 16, 2017 at 6:10 AM, wrote: > >> I am in favor of the draft, with or without the changes to make it >> clearer. >> >> I suggest the following language for clarity: >> >> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM >> that reads "If the downstream recipient of a static assignment of /64 or >> more addresses requests publishing of that static assignment in ARIN's >> registration database, the ISP must register that static assignment." >> >> Since "static assignment" is the term in this section, not netblock, I >> suggest using this term instead of "netblock". "Of any size" is not >> needed, as the language would require the ISP to register in total whatever >> size the ISP has assigned to the downstream in the ARIN database if >> requested by the downstream recipient, as long as it was /64 or more. >> >> This language would also prevent requests to register only part of an >> assignment. I think this language works in making the intent of the new >> section more clear. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> >> On Tue, 15 Aug 2017, John Santos wrote: >> >> I think that the "/64 or more addresses" and the "regardless of size" are >>> meant to convey that any netblock between a /64 and a /48 can and should be >>> registered if the recipient requests it, even if the block is smaller than >>> the /47 which would make it mandatory. Perhaps there is better wording >>> that would make this clearer. >>> >>> Three ranges: >>> >>> 1. smaller than /64: shouldn't be issued, can't be registered. >>> 2. /64 through /48: register at recipient's request >>> 3. /47 or larger: must be registered >>> >>> I agree on dynamic assignments >>> >>> Otherwise, I think this is a much clearer and better update to the >>> proposed policy, and can't find any other reason not to support it. (I.E. >>> this is a tentative vote FOR, if there is such a thing.) >>> >>> >>> >>> On 8/15/2017 3:59 PM, David Farmer wrote: >>> >>>> I support what I think is the intent, but I have language/editorial >>>> nits; >>>> >>>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of >>>> size" that requires registration? I think logically we need one or the >>>> other, or some qualification on "regardless of size" statement. I think it >>>> is a good idea to not require registration of less than a /64. But the >>>> current language seems contradictory, and therefore confusing, my >>>> recommendation is delete "regardless of size", from the sentence and >>>> leaving "a /64 or more addresses". I pretty sure we don't want people >>>> having an expectation that they can request the registration of "their" >>>> /128 address. >>>> >>>> 2. Also in 3) below; It would seem to require even dynamic assignments >>>> be registered if requested, I don't think that is our intent either, >>>> section 6.5.5.1 starts with "Each static IPv6 assignment containing", this >>>> needs a similar qualification. >>>> >>>> Also, I'm fine with the deltas in the policy statement but it would be >>>> helpful to see the final resulting policy block, maybe in a separate email >>>> so we can all see how the result reads. >>>> >>>> Thanks, I think we are getting close, maybe one or two more turns of >>>> the crank. >>>> >>>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN >>> info at arin.net>> wrote: >>>> >>>> The following has been revised: >>>> >>>> * Draft Policy ARIN-2017-5: Equalization of Assignment >>>> Registration requirements between IPv4 and IPv6 >>>> >>>> Revised text is below and can be found at: >>>> https://www.arin.net/policy/proposals/2017_5.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 >>>> >>>> >>>> Draft Policies and Proposals under discussion can be found at: >>>> https://www.arin.net/policy/proposals/index.html >>>> >>>> >>>> Regards, >>>> >>>> Sean Hopkins >>>> Policy Analyst >>>> American Registry for Internet Numbers (ARIN) >>>> >>>> >>>> >>>> >>>> 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 subdelegation 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" >>>> >>>> and >>>> >>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to >>>> the NRPM that reads "If the downstream recipient of a netblock ( a >>>> /64 or more addresses) requests publishing in ARIN's registration >>>> database, the ISP must register the netblock, regardless of size." >>>> >>>> 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. >>>> >>>> -- >>> John Santos >>> Evans Griffiths & Hart, Inc. >>> 781-861-0670 ext 539 >>> >>> >>> _______________________________________________ >> 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: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Thu Aug 17 14:57:35 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 17 Aug 2017 14:57:35 -0400 (EDT) Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <77aa9cb4-8162-dbed-f950-cae808914c09@cameron.net> References: <59932A32.8010708@arin.net> <4f8974ce-8c1a-b73e-e069-38fb2939774e@egh.com> <77aa9cb4-8162-dbed-f950-cae808914c09@cameron.net> Message-ID: A /47 is larger than a /48, and under the draft must always be registered. /48's are only registered upon request, or if it is independently routed. /49 - /64 are only registered upon request. If future routing policy changes allows these sizes to be independently routed and in fact are so routed, they must also be registered. Currently, most networks will not accept an advertisement smaller than a /48. Smaller than /64 should never be assigned, and are never registered. Arin policy 2.15 recommends each end site be given a /48. The main difference from previous drafts is the part allowing the downstream to require registration of their assignment. Currently this is not required. LIR's include the term ISP. See 2.4. Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 17 Aug 2017, Paul McNary wrote: > A /47 is smaller than a /48 and would not be required to be registered? > > > On 8/17/2017 12:50 PM, hostmaster at uneedus.com wrote: >> I note that any ISP size reassignment, with the recommended /48 for each >> end user site, will be /47 or larger, which must always be registered. >> >> Thus, I think 6.5.5.5 language is unneeded, since any LIR/ISP reassignment >> will be large enough to already trigger registration. >> >> Under the current policy, LIR's and ISP's are equal, so usually both terms >> are stated in any policy that mentions them. >> >> May I also suggest that if we are going to require registration upon >> downstream request for IPv6, that we consider placing the same language and >> requirements for IPv4 customers as well? And if we do, where do we draw >> the minimum line? Maybe a /32.... >> >> Also, good catch on the cut and paste error..... >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> On Thu, 17 Aug 2017, Leif Sawyer wrote: >> >>> Thanks for the feedback, David. >>> >>> I've added the fix for 6.5.5.2, since we're already in the section. >>> >>> I've also modified the text for 6.5.5.4 as well, because I think your >>> suggesting is a little cleaner. >>> >>> I'm not sure what the point of 6.5.5.5 is - you're just reiterating >>> 6.5.5.1. >>> That said, we could potentially clean up 6.5.5.1 by extending "static IPv6 >>> assignment" >>> to "static IPv6 assignment, or allocation," - or something similar. >>> >>> >>> Which also brings to mind the question: LIR or ISP? Both are in use in >>> 6.5.... >>> >>> ________________________________ >>> From: ARIN-PPML [arin-ppml-bounces at arin.net] on behalf of David Farmer >>> [farmer at umn.edu] >>> Sent: Thursday, August 17, 2017 8:53 AM >>> To: hostmaster at uneedus.com >>> Cc: arin-ppml at arin.net >>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization >>> of Assignment Registration requirements between IPv4 and IPv6 >>> >>> [External Email] >>> >>> Here is a slightly different formulation to consider. I refactored the >>> title a little, and based the phrasing on other parts of section 6.5.5 >>> >>> 6.5.5.4 Registration Requested by Recipient >>> >>> If requested by the downstream recipient of a block, each static IPv6 >>> assignment containing a /64 or more addresses, shall be registered, as >>> described in section 6.5.5.1. >>> >>> I'd like us to think about adding an additional section, based on previous >>> discussions. >>> >>> 6.5.5.5 Re-allocation to ISPs >>> >>> Each IPv6 re-allocation to a downstream ISP, regardless of size, intended >>> for further assignment by the downstream ISP's to it's customers, shall be >>> registered, as described in section 6.5.5.1 >>> >>> Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. I >>> think this is a cut and past error, I think the reference should be to >>> 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with sections >>> 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. >>> >>> Thanks. >>> >>> On Wed, Aug 16, 2017 at 6:10 AM, >>> > wrote: >>> I am in favor of the draft, with or without the changes to make it >>> clearer. >>> >>> I suggest the following language for clarity: >>> >>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM >>> that reads "If the downstream recipient of a static assignment of /64 or >>> more addresses requests publishing of that static assignment in ARIN's >>> registration database, the ISP must register that static assignment." >>> >>> Since "static assignment" is the term in this section, not netblock, I >>> suggest using this term instead of "netblock". "Of any size" is not >>> needed, as the language would require the ISP to register in total >>> whatever size the ISP has assigned to the downstream in the ARIN database >>> if requested by the downstream recipient, as long as it was /64 or more. >>> >>> This language would also prevent requests to register only part of an >>> assignment. I think this language works in making the intent of the new >>> section more clear. >>> >>> Albert Erdmann >>> Network Administrator >>> Paradise On Line Inc. >>> >>> >>> >>> On Tue, 15 Aug 2017, John Santos wrote: >>> >>> I think that the "/64 or more addresses" and the "regardless of size" are >>> meant to convey that any netblock between a /64 and a /48 can and should >>> be registered if the recipient requests it, even if the block is smaller >>> than the /47 which would make it mandatory. Perhaps there is better >>> wording that would make this clearer. >>> >>> Three ranges: >>> >>> 1. smaller than /64: shouldn't be issued, can't be registered. >>> 2. /64 through /48: register at recipient's request >>> 3. /47 or larger: must be registered >>> >>> I agree on dynamic assignments >>> >>> Otherwise, I think this is a much clearer and better update to the >>> proposed policy, and can't find any other reason not to support it. (I.E. >>> this is a tentative vote FOR, if there is such a thing.) >>> >>> >>> >>> On 8/15/2017 3:59 PM, David Farmer wrote: >>> I support what I think is the intent, but I have language/editorial nits; >>> >>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of >>> size" that requires registration? I think logically we need one or the >>> other, or some qualification on "regardless of size" statement. I think >>> it is a good idea to not require registration of less than a /64. But the >>> current language seems contradictory, and therefore confusing, my >>> recommendation is delete "regardless of size", from the sentence and >>> leaving "a /64 or more addresses". I pretty sure we don't want people >>> having an expectation that they can request the registration of "their" >>> /128 address. >>> >>> 2. Also in 3) below; It would seem to require even dynamic assignments be >>> registered if requested, I don't think that is our intent either, section >>> 6.5.5.1 starts with "Each static IPv6 assignment containing", this needs a >>> similar qualification. >>> >>> Also, I'm fine with the deltas in the policy statement but it would be >>> helpful to see the final resulting policy block, maybe in a separate email >>> so we can all see how the result reads. >>> >>> Thanks, I think we are getting close, maybe one or two more turns of the >>> crank. >>> >>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN >>> >>> >> wrote: >>> >>> The following has been revised: >>> >>> * Draft Policy ARIN-2017-5: Equalization of Assignment >>> Registration requirements between IPv4 and IPv6 >>> >>> Revised text is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_5.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 >>> > >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> > >>> >>> Regards, >>> >>> Sean Hopkins >>> Policy Analyst >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> >>> >>> 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 subdelegation 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" >>> >>> and >>> >>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to >>> the NRPM that reads "If the downstream recipient of a netblock ( a >>> /64 or more addresses) requests publishing in ARIN's registration >>> database, the ISP must register the netblock, regardless of size." >>> >>> 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. >>> >>> -- >>> John Santos >>> Evans Griffiths & Hart, Inc. >>> 781-861-0670 ext 539 >>> >>> >>> _______________________________________________ >>> 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: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any >>> issues. >>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:farmer at umn.edu >>> 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 (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From owen at delong.com Thu Aug 17 15:16:14 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Aug 2017 12:16:14 -0700 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59932A32.8010708@arin.net> Message-ID: > On Aug 15, 2017, at 12:59 , David Farmer wrote: > > I support what I think is the intent, but I have language/editorial nits; > > 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of size" that requires registration? I think logically we need one or the other, or some qualification on "regardless of size" statement. I think it is a good idea to not require registration of less than a /64. But the current language seems contradictory, and therefore confusing, my recommendation is delete "regardless of size", from the sentence and leaving "a /64 or more addresses". I pretty sure we don't want people having an expectation that they can request the registration of "their" /128 address. While I support the edit to delete unnecessary and non-active verbiage, I think it is overly pedantic and do not find the current wording at all misleading or confusing. > 2. Also in 3) below; It would seem to require even dynamic assignments be registered if requested, I don't think that is our intent either, section 6.5.5.1 starts with "Each static IPv6 assignment containing", this needs a similar qualification. I would support adding the word static to 6.5.5.4 as ??recipient of a static netblock?? > Also, I'm fine with the deltas in the policy statement but it would be helpful to see the final resulting policy block, maybe in a separate email so we can all see how the result reads. > > Thanks, I think we are getting close, maybe one or two more turns of the crank. While we?re turning the crank, can we please fix the title since IPv4 is no longer relevant to the proposal and there?s really no equalization happening? Perhaps ?Improved Registration Requirements for IPv6? Owen > > On Tue, Aug 15, 2017 at 12:06 PM, ARIN > wrote: > The following has been revised: > > * Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_5.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 > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > > 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 subdelegation 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" > > and > > 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM that reads "If the downstream recipient of a netblock ( a /64 or more addresses) requests publishing in ARIN's registration database, the ISP must register the netblock, regardless of size." > > 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 (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > 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 (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmcnary at cameron.net Thu Aug 17 16:49:47 2017 From: pmcnary at cameron.net (Paul McNary) Date: Thu, 17 Aug 2017 15:49:47 -0500 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59932A32.8010708@arin.net> <4f8974ce-8c1a-b73e-e069-38fb2939774e@egh.com> <77aa9cb4-8162-dbed-f950-cae808914c09@cameron.net> Message-ID: <7460ee99-c116-7c0a-b726-2267de135596@cameron.net> Sorry I typed the numbers backwards, yes, that is what I meant. :-) A /48 is smaller than a /47 and would not be required to be registered? A /47 would need to be On 8/17/2017 1:30 PM, Chris Woodfield wrote: > The opposite - a /47 is 2 /48s aggregated. > > -C > >> On Aug 17, 2017, at 11:26 AM, Paul McNary wrote: >> >> A /47 is smaller than a /48 and would not be required to be registered? >> >> >> On 8/17/2017 12:50 PM, hostmaster at uneedus.com wrote: >>> I note that any ISP size reassignment, with the recommended /48 for each end user site, will be /47 or larger, which must always be registered. >>> >>> Thus, I think 6.5.5.5 language is unneeded, since any LIR/ISP reassignment will be large enough to already trigger registration. >>> >>> Under the current policy, LIR's and ISP's are equal, so usually both terms are stated in any policy that mentions them. >>> >>> May I also suggest that if we are going to require registration upon downstream request for IPv6, that we consider placing the same language and requirements for IPv4 customers as well? And if we do, where do we draw the minimum line? Maybe a /32.... >>> >>> Also, good catch on the cut and paste error..... >>> >>> Albert Erdmann >>> Network Administrator >>> Paradise On Line Inc. >>> >>> >>> On Thu, 17 Aug 2017, Leif Sawyer wrote: >>> >>>> Thanks for the feedback, David. >>>> >>>> I've added the fix for 6.5.5.2, since we're already in the section. >>>> >>>> I've also modified the text for 6.5.5.4 as well, because I think your suggesting is a little cleaner. >>>> >>>> I'm not sure what the point of 6.5.5.5 is - you're just reiterating 6.5.5.1. >>>> That said, we could potentially clean up 6.5.5.1 by extending "static IPv6 assignment" >>>> to "static IPv6 assignment, or allocation," - or something similar. >>>> >>>> >>>> Which also brings to mind the question: LIR or ISP? Both are in use in 6.5.... >>>> >>>> ________________________________ >>>> From: ARIN-PPML [arin-ppml-bounces at arin.net] on behalf of David Farmer [farmer at umn.edu] >>>> Sent: Thursday, August 17, 2017 8:53 AM >>>> To: hostmaster at uneedus.com >>>> Cc: arin-ppml at arin.net >>>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 >>>> >>>> [External Email] >>>> >>>> Here is a slightly different formulation to consider. I refactored the title a little, and based the phrasing on other parts of section 6.5.5 >>>> >>>> 6.5.5.4 Registration Requested by Recipient >>>> >>>> If requested by the downstream recipient of a block, each static IPv6 assignment containing a /64 or more addresses, shall be registered, as described in section 6.5.5.1. >>>> >>>> I'd like us to think about adding an additional section, based on previous discussions. >>>> >>>> 6.5.5.5 Re-allocation to ISPs >>>> >>>> Each IPv6 re-allocation to a downstream ISP, regardless of size, intended for further assignment by the downstream ISP's to it's customers, shall be registered, as described in section 6.5.5.1 >>>> >>>> Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. I think this is a cut and past error, I think the reference should be to 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with sections 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. >>>> >>>> Thanks. >>>> >>>> On Wed, Aug 16, 2017 at 6:10 AM, > wrote: >>>> I am in favor of the draft, with or without the changes to make it clearer. >>>> >>>> I suggest the following language for clarity: >>>> >>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM that reads "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that static assignment in ARIN's registration database, the ISP must register that static assignment." >>>> >>>> Since "static assignment" is the term in this section, not netblock, I suggest using this term instead of "netblock". "Of any size" is not needed, as the language would require the ISP to register in total whatever size the ISP has assigned to the downstream in the ARIN database if requested by the downstream recipient, as long as it was /64 or more. >>>> >>>> This language would also prevent requests to register only part of an assignment. I think this language works in making the intent of the new section more clear. >>>> >>>> Albert Erdmann >>>> Network Administrator >>>> Paradise On Line Inc. >>>> >>>> >>>> >>>> On Tue, 15 Aug 2017, John Santos wrote: >>>> >>>> I think that the "/64 or more addresses" and the "regardless of size" are meant to convey that any netblock between a /64 and a /48 can and should be registered if the recipient requests it, even if the block is smaller than the /47 which would make it mandatory. Perhaps there is better wording that would make this clearer. >>>> >>>> Three ranges: >>>> >>>> 1. smaller than /64: shouldn't be issued, can't be registered. >>>> 2. /64 through /48: register at recipient's request >>>> 3. /47 or larger: must be registered >>>> >>>> I agree on dynamic assignments >>>> >>>> Otherwise, I think this is a much clearer and better update to the proposed policy, and can't find any other reason not to support it. (I.E. this is a tentative vote FOR, if there is such a thing.) >>>> >>>> >>>> >>>> On 8/15/2017 3:59 PM, David Farmer wrote: >>>> I support what I think is the intent, but I have language/editorial nits; >>>> >>>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of size" that requires registration? I think logically we need one or the other, or some qualification on "regardless of size" statement. I think it is a good idea to not require registration of less than a /64. But the current language seems contradictory, and therefore confusing, my recommendation is delete "regardless of size", from the sentence and leaving "a /64 or more addresses". I pretty sure we don't want people having an expectation that they can request the registration of "their" /128 address. >>>> >>>> 2. Also in 3) below; It would seem to require even dynamic assignments be registered if requested, I don't think that is our intent either, section 6.5.5.1 starts with "Each static IPv6 assignment containing", this needs a similar qualification. >>>> >>>> Also, I'm fine with the deltas in the policy statement but it would be helpful to see the final resulting policy block, maybe in a separate email so we can all see how the result reads. >>>> >>>> Thanks, I think we are getting close, maybe one or two more turns of the crank. >>>> >>>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN >> wrote: >>>> >>>> The following has been revised: >>>> >>>> * Draft Policy ARIN-2017-5: Equalization of Assignment >>>> Registration requirements between IPv4 and IPv6 >>>> >>>> Revised text is below and can be found at: >>>> https://www.arin.net/policy/proposals/2017_5.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 >>>> > >>>> >>>> Draft Policies and Proposals under discussion can be found at: >>>> https://www.arin.net/policy/proposals/index.html >>>> > >>>> >>>> Regards, >>>> >>>> Sean Hopkins >>>> Policy Analyst >>>> American Registry for Internet Numbers (ARIN) >>>> >>>> >>>> >>>> >>>> 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 subdelegation 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" >>>> >>>> and >>>> >>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to >>>> the NRPM that reads "If the downstream recipient of a netblock ( a >>>> /64 or more addresses) requests publishing in ARIN's registration >>>> database, the ISP must register the netblock, regardless of size." >>>> >>>> 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. >>>> >>>> -- >>>> John Santos >>>> Evans Griffiths & Hart, Inc. >>>> 781-861-0670 ext 539 >>>> >>>> >>>> _______________________________________________ >>>> 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: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>>> >>>> >>>> >>>> -- >>>> =============================================== >>>> David Farmer Email:farmer at umn.edu >>>> 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 (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at 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 at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > From Alison.WOOD at oregon.gov Thu Aug 17 16:54:23 2017 From: Alison.WOOD at oregon.gov (WOOD Alison * DAS) Date: Thu, 17 Aug 2017 20:54:23 +0000 Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers Message-ID: Thank you for the feedback on this draft policy to date. I would appreciate any other thoughts or comments on this draft policy. For review, Draft Policy 2017-6 is intended to add the following conditions on Inter RIR transfers to section 8.4: Recipient RIR policy must not permit transfers to other RIRs or NIRs whose policies do not support bi-directional transfers. And the problem statement on this draft policy is: Currently ARIN's requirement that inter-RIR transfer policies be reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a two-hop RIR transfer process can be used to circumvent the intent of the requirement. Rather than eliminate the requirement, a better approach would be to close the loophole. All feedback is appreciated. Thank you -Alison Wood -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Thu Aug 17 18:00:05 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 17 Aug 2017 18:00:05 -0400 (EDT) Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59932A32.8010708@arin.net> Message-ID: While the most recent drafts have not dealt with IPv4, in the last round there was a proposal to require registration upon request of the downstream customer of their IPv6 assignment. If we intend to provide that power to require registration for IPv6 customer assignments upon request, in fairness we should also use the same language in a new 4.2.3.7.4 to allow static IPv4 customers that same power. I suggest /32 as the limit, as /29 or more already has required registration. The same problems identfied in not being able to register assignments with ARIN for v6 are also true for v4 assignments between those limits. Since both protocols are still being addressed and attempts are being made by the draft to make v6 equal or better than v4, the title should remain. The only thing we have done is not shift the v4 limit of /29. Albert Erdmann Network Administrator Paradise On Line Inc. > While we???re turning the crank, can we please fix the title since IPv4 > is no longer relevant to the proposal and there???s really no > equalization happening? > > Perhaps ???Improved Registration Requirements for IPv6??? > > Owen From farmer at umn.edu Thu Aug 17 18:01:09 2017 From: farmer at umn.edu (David Farmer) Date: Thu, 17 Aug 2017 17:01:09 -0500 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59932A32.8010708@arin.net> <4f8974ce-8c1a-b73e-e069-38fb2939774e@egh.com> Message-ID: On Thu, Aug 17, 2017 at 1:43 PM, David Farmer wrote: > Inline. > > On Thu, Aug 17, 2017 at 12:29 PM, Leif Sawyer wrote: > >> Thanks for the feedback, David. >> > ... > I'm not sure what the point of 6.5.5.5 is - you're just reiterating >> 6.5.5.1. >> That said, we could potentially clean up 6.5.5.1 by extending "static >> IPv6 assignment" >> to "static IPv6 assignment, or allocation," - or something similar. >> > > ISP re-allocations need to be registered regardless of size or if it is > being advertised or not. For example, if for some stupid reason a /56 was > re-allocated to downsterm ISP so they could assign /64s to customers that > has to be registered, by 6.5.5.1 that wouldn't have to be registered. > Should you re-allocate a /56, @!@#$ NO!!! But if you did, it has to be > registered. This is so LEA and other legal requests get directly to the > correct ISP the first time. I think this is important enough issue that it > should have it's own section, and not get blended in to 6.5.5.1. > > Now should that be part of this policy maybe not, maybe this belongs in > ARIN-2017-3 or whole new separate policy proposal instead. > Thinking about this for the last couple hours I'm thinking 6.5.5.5 this should not be part of this policy. As similar text should be added in the IPv4 section, and this should have a somewhat different problem statement as well. -- =============================================== David Farmer Email:farmer at umn.edu 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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Fri Aug 18 06:10:50 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Fri, 18 Aug 2017 06:10:50 -0400 (EDT) Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers In-Reply-To: References: Message-ID: I would not consider an RIR that has NIR units that do not have a bi directional transfer policy to comply with the policy of ARIN to only permit transfers to/from those with a bi directional transfer policy. Thus, I support the statement being added in this draft to make this more clear. Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 17 Aug 2017, WOOD Alison * DAS wrote: > Thank you for the feedback on this draft policy to date. I would > appreciate any other thoughts or comments on this draft policy. > > For review, Draft Policy 2017-6 is intended to add the following > conditions on Inter RIR transfers to section 8.4: > > Recipient RIR policy must not permit transfers to other RIRs or NIRs > whose policies do not support bi-directional transfers. > > And the problem statement on this draft policy is: > > Currently ARIN's requirement that inter-RIR transfer policies be > reciprocal has a glaring hole in it in that RIRs which have NIRs and/or > a two-hop RIR transfer process can be used to circumvent the intent of > the requirement. Rather than eliminate the requirement, a better > approach would be to close the loophole. > > All feedback is appreciated. > > Thank you > > -Alison Wood > From daveid at panix.com Fri Aug 18 08:14:10 2017 From: daveid at panix.com (David Huberman) Date: Fri, 18 Aug 2017 08:14:10 -0400 Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers In-Reply-To: References: Message-ID: <415F505D-1A01-4B43-9386-4F29013D8F4B@panix.com> I am a US-based company and I operate a network on multiple continents. I need to be able to move space from my home RIR of ARIN to other regions as I expand my network overseas. The current policy that has been in effect for many years allows me to operate my network properly -- using ARIN blocks in ARIN, APNIC blocks in APNIC, and RIPE blocks in RIPE. The policy is predictable and I can plan network growth around it. If this proposal passes, it will shut off transfers between ARIN and APNIC. This will hurt my business's finances. We purchased addresses in the ARIN region wth the intention of moving them to APNIC in the future. We did so because the size blocks we needed were not available in the APNIC region. So now we are talking about hurting my business for ... what reason? How do network operations benefit from this proposal? > On Aug 18, 2017, at 6:10 AM, hostmaster at uneedus.com wrote: > > I would not consider an RIR that has NIR units that do not have a bi directional transfer policy to comply with the policy of ARIN to only permit transfers to/from those with a bi directional transfer policy. > > Thus, I support the statement being added in this draft to make this more clear. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > >> On Thu, 17 Aug 2017, WOOD Alison * DAS wrote: >> >> Thank you for the feedback on this draft policy to date. I would appreciate any other thoughts or comments on this draft policy. >> >> For review, Draft Policy 2017-6 is intended to add the following conditions on Inter RIR transfers to section 8.4: >> >> Recipient RIR policy must not permit transfers to other RIRs or NIRs whose policies do not support bi-directional transfers. >> >> And the problem statement on this draft policy is: >> >> Currently ARIN's requirement that inter-RIR transfer policies be reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a two-hop RIR transfer process can be used to circumvent the intent of the requirement. Rather than eliminate the requirement, a better approach would be to close the loophole. >> >> All feedback is appreciated. >> >> Thank you >> >> -Alison Wood >> > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From hostmaster at uneedus.com Fri Aug 18 08:30:22 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Fri, 18 Aug 2017 08:30:22 -0400 (EDT) Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers In-Reply-To: <415F505D-1A01-4B43-9386-4F29013D8F4B@panix.com> References: <415F505D-1A01-4B43-9386-4F29013D8F4B@panix.com> Message-ID: I was always under the impression that companies that operate in more than one region usually obtain their number resources from their home region, and use these worldwide. I once worked with a company who was based in the Netherlands, but has a presence all over the world. I was involved in their networks in the USA, using a portion of a class B legacy space, which was at the time assigned to RIPE. However, we used it in Texas and Florida. We dealt with the geolocation problem by setting up proxy servers with address space from a local ISP for internet access, and to save cross ocean bandwidth for general internet access. Places like Netflix treated this space as Europe, even though the space was SWIP'ed to the USA. It is my understanding that section 9 of the NRPM allows out of region use. Is there a reason you do not simply leave the resources registered with ARIN? Is it because local affiliates, or otherwise? Albert Erdmann Network Administrator Paradise On Line Inc. On Fri, 18 Aug 2017, David Huberman wrote: > I am a US-based company and I operate a network on multiple continents. > > I need to be able to move space from my home RIR of ARIN to other regions as I expand my network overseas. > > The current policy that has been in effect for many years allows me to operate my network properly -- using ARIN blocks in ARIN, APNIC blocks in APNIC, and RIPE blocks in RIPE. The policy is predictable and I can plan network growth around it. > > If this proposal passes, it will shut off transfers between ARIN and APNIC. This will hurt my business's finances. We purchased addresses in the ARIN region wth the intention of moving them to APNIC in the future. We did so because the size blocks we needed were not available in the APNIC region. So now we are talking about hurting my business for ... what reason? How do network operations benefit from this proposal? > > >> On Aug 18, 2017, at 6:10 AM, hostmaster at uneedus.com wrote: >> >> I would not consider an RIR that has NIR units that do not have a bi directional transfer policy to comply with the policy of ARIN to only permit transfers to/from those with a bi directional transfer policy. >> >> Thus, I support the statement being added in this draft to make this more clear. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >>> On Thu, 17 Aug 2017, WOOD Alison * DAS wrote: >>> >>> Thank you for the feedback on this draft policy to date. I would appreciate any other thoughts or comments on this draft policy. >>> >>> For review, Draft Policy 2017-6 is intended to add the following conditions on Inter RIR transfers to section 8.4: >>> >>> Recipient RIR policy must not permit transfers to other RIRs or NIRs whose policies do not support bi-directional transfers. >>> >>> And the problem statement on this draft policy is: >>> >>> Currently ARIN's requirement that inter-RIR transfer policies be reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a two-hop RIR transfer process can be used to circumvent the intent of the requirement. Rather than eliminate the requirement, a better approach would be to close the loophole. >>> >>> All feedback is appreciated. >>> >>> Thank you >>> >>> -Alison Wood >>> >> _______________________________________________ >> 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: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > From farmer at umn.edu Fri Aug 18 08:58:41 2017 From: farmer at umn.edu (David Farmer) Date: Fri, 18 Aug 2017 07:58:41 -0500 Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers In-Reply-To: References: Message-ID: The problem statement of this draft policy identifies a theoretical problem, but provides no evidence that there is an actual problem in practice. Further, the proposed solution penalizes both good and bad actors within a region indiscriminately and probably disproportionally as well. As such without strong evidence of an actual problem and without any understanding of the efficacy of the solution in practice, I cannot support this draft policy as written. Thanks. On Thu, Aug 17, 2017 at 3:54 PM, WOOD Alison * DAS wrote: > Thank you for the feedback on this draft policy to date. I would > appreciate any other thoughts or comments on this draft policy. > > > > For review, Draft Policy 2017-6 is intended to add the following > conditions on Inter RIR transfers to section 8.4: > > > > Recipient RIR policy must not permit transfers to other RIRs or NIRs whose > policies do not support bi-directional transfers. > > > > And the problem statement on this draft policy is: > > > > Currently ARIN's requirement that inter-RIR transfer policies be > reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a > two-hop RIR transfer process can be used to circumvent the intent of the > requirement. Rather than eliminate the requirement, a better approach would > be to close the loophole. > > > > All feedback is appreciated. > > > > Thank you > > > > -Alison Wood > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- =============================================== David Farmer Email:farmer at umn.edu 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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Fri Aug 18 09:28:51 2017 From: farmer at umn.edu (David Farmer) Date: Fri, 18 Aug 2017 08:28:51 -0500 Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers In-Reply-To: References: <415F505D-1A01-4B43-9386-4F29013D8F4B@panix.com> Message-ID: On Fri, Aug 18, 2017 at 7:30 AM, wrote: > I was always under the impression that companies that operate in more than > one region usually obtain their number resources from their home region, > and use these worldwide. > That is one way to do things, and especially if you primarily operate in one region and have some operations in other regions. However, if you view yourself as a global operation it is equally valid to obtain resources from multiple or all RIRs. > I once worked with a company who was based in the Netherlands, but has a > presence all over the world. I was involved in their networks in the USA, > using a portion of a class B legacy space, which was at the time assigned > to RIPE. However, we used it in Texas and Florida. We dealt with the > geolocation problem by setting up proxy servers with address space from a > local ISP for internet access, and to save cross ocean bandwidth for > general internet access. Places like Netflix treated this space as Europe, > even though the space was SWIP'ed to the USA. > > It is my understanding that section 9 of the NRPM allows out of region > use. Is there a reason you do not simply leave the resources registered > with ARIN? Is it because local affiliates, or otherwise? > The out of region use policy, is permissive not proscriptive policy, it allow out of region use, and only requires that need in another region cannot be used as a justification to obtain resources from both ARIN and another RIR at the same time. The choice of where to obtain resources or maintain the registry of resources used in another region remains with the entity using the resources. > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > On Fri, 18 Aug 2017, David Huberman wrote: > > I am a US-based company and I operate a network on multiple continents. >> >> I need to be able to move space from my home RIR of ARIN to other regions >> as I expand my network overseas. >> >> The current policy that has been in effect for many years allows me to >> operate my network properly -- using ARIN blocks in ARIN, APNIC blocks in >> APNIC, and RIPE blocks in RIPE. The policy is predictable and I can plan >> network growth around it. >> >> If this proposal passes, it will shut off transfers between ARIN and >> APNIC. This will hurt my business's finances. We purchased addresses in >> the ARIN region wth the intention of moving them to APNIC in the future. We >> did so because the size blocks we needed were not available in the APNIC >> region. So now we are talking about hurting my business for ... what >> reason? How do network operations benefit from this proposal? >> >> >> On Aug 18, 2017, at 6:10 AM, hostmaster at uneedus.com wrote: >>> >>> I would not consider an RIR that has NIR units that do not have a bi >>> directional transfer policy to comply with the policy of ARIN to only >>> permit transfers to/from those with a bi directional transfer policy. >>> >>> Thus, I support the statement being added in this draft to make this >>> more clear. >>> >>> Albert Erdmann >>> Network Administrator >>> Paradise On Line Inc. >>> >>> >>> On Thu, 17 Aug 2017, WOOD Alison * DAS wrote: >>>> >>>> Thank you for the feedback on this draft policy to date. I would >>>> appreciate any other thoughts or comments on this draft policy. >>>> >>>> For review, Draft Policy 2017-6 is intended to add the following >>>> conditions on Inter RIR transfers to section 8.4: >>>> >>>> Recipient RIR policy must not permit transfers to other RIRs or NIRs >>>> whose policies do not support bi-directional transfers. >>>> >>>> And the problem statement on this draft policy is: >>>> >>>> Currently ARIN's requirement that inter-RIR transfer policies be >>>> reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a >>>> two-hop RIR transfer process can be used to circumvent the intent of the >>>> requirement. Rather than eliminate the requirement, a better approach would >>>> be to close the loophole. >>>> >>>> All feedback is appreciated. >>>> >>>> Thank you >>>> >>>> -Alison Wood >>>> >>>> _______________________________________________ >>> 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: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Fri Aug 18 09:48:59 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Fri, 18 Aug 2017 09:48:59 -0400 (EDT) Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers In-Reply-To: References: <415F505D-1A01-4B43-9386-4F29013D8F4B@panix.com> Message-ID: My gut still tells me that transfers should not take place without a bidirectional policy. Even then, the other RIR's are very likely seeking IPv4 resources from ARIN, as opposed to the reverse, simply because ARIN has under its control more than 1/2 the total space available, because of the greatest amount of early space assigned was assigned to this region. Even then, if the policy were to change, the OP would still be able to use the address space it very likely purchased in the ARIN region in the APNIC region, it just would not be able to transfer control of the space to APNIC. I would like to hear more information regarding actual examples from the original policy proposer regarding the issues that were encountered that caused this draft policy to be written. Was it something like space that could not be transfered back to the origin, and thinking that the policy allows one way transfers, or what? Albert Erdmann Network Administrator Paradise On Line Inc. On Fri, 18 Aug 2017, David Farmer wrote: > On Fri, Aug 18, 2017 at 7:30 AM, wrote: > >> I was always under the impression that companies that operate in more than >> one region usually obtain their number resources from their home region, >> and use these worldwide. >> > > That is one way to do things, and especially if you primarily operate in > one region and have some operations in other regions. However, if you view > yourself as a global operation it is equally valid to obtain resources from > multiple or all RIRs. > > >> I once worked with a company who was based in the Netherlands, but has a >> presence all over the world. I was involved in their networks in the USA, >> using a portion of a class B legacy space, which was at the time assigned >> to RIPE. However, we used it in Texas and Florida. We dealt with the >> geolocation problem by setting up proxy servers with address space from a >> local ISP for internet access, and to save cross ocean bandwidth for >> general internet access. Places like Netflix treated this space as Europe, >> even though the space was SWIP'ed to the USA. >> >> It is my understanding that section 9 of the NRPM allows out of region >> use. Is there a reason you do not simply leave the resources registered >> with ARIN? Is it because local affiliates, or otherwise? >> > > The out of region use policy, is permissive not proscriptive policy, it > allow out of region use, and only requires that need in another region > cannot be used as a justification to obtain resources from both ARIN and > another RIR at the same time. The choice of where to obtain resources or > maintain the registry of resources used in another region remains with the > entity using the resources. > > >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> On Fri, 18 Aug 2017, David Huberman wrote: >> >> I am a US-based company and I operate a network on multiple continents. >>> >>> I need to be able to move space from my home RIR of ARIN to other regions >>> as I expand my network overseas. >>> >>> The current policy that has been in effect for many years allows me to >>> operate my network properly -- using ARIN blocks in ARIN, APNIC blocks in >>> APNIC, and RIPE blocks in RIPE. The policy is predictable and I can plan >>> network growth around it. >>> >>> If this proposal passes, it will shut off transfers between ARIN and >>> APNIC. This will hurt my business's finances. We purchased addresses in >>> the ARIN region wth the intention of moving them to APNIC in the future. We >>> did so because the size blocks we needed were not available in the APNIC >>> region. So now we are talking about hurting my business for ... what >>> reason? How do network operations benefit from this proposal? >>> >>> >>> On Aug 18, 2017, at 6:10 AM, hostmaster at uneedus.com wrote: >>>> >>>> I would not consider an RIR that has NIR units that do not have a bi >>>> directional transfer policy to comply with the policy of ARIN to only >>>> permit transfers to/from those with a bi directional transfer policy. >>>> >>>> Thus, I support the statement being added in this draft to make this >>>> more clear. >>>> >>>> Albert Erdmann >>>> Network Administrator >>>> Paradise On Line Inc. >>>> >>>> >>>> On Thu, 17 Aug 2017, WOOD Alison * DAS wrote: >>>>> >>>>> Thank you for the feedback on this draft policy to date. I would >>>>> appreciate any other thoughts or comments on this draft policy. >>>>> >>>>> For review, Draft Policy 2017-6 is intended to add the following >>>>> conditions on Inter RIR transfers to section 8.4: >>>>> >>>>> Recipient RIR policy must not permit transfers to other RIRs or NIRs >>>>> whose policies do not support bi-directional transfers. >>>>> >>>>> And the problem statement on this draft policy is: >>>>> >>>>> Currently ARIN's requirement that inter-RIR transfer policies be >>>>> reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a >>>>> two-hop RIR transfer process can be used to circumvent the intent of the >>>>> requirement. Rather than eliminate the requirement, a better approach would >>>>> be to close the loophole. >>>>> >>>>> All feedback is appreciated. >>>>> >>>>> Thank you >>>>> >>>>> -Alison Wood >>>>> >>>>> _______________________________________________ >>>> 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: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at 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 at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > From daveid at panix.com Fri Aug 18 09:49:26 2017 From: daveid at panix.com (David Huberman) Date: Fri, 18 Aug 2017 09:49:26 -0400 Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers In-Reply-To: References: <415F505D-1A01-4B43-9386-4F29013D8F4B@panix.com> Message-ID: <535666F0-E182-4BD2-8FB2-233AD6E228BD@panix.com> On Aug 18, 2017, at 8:30 AM, hostmaster at uneedus.com wrote: > > Is there a reason you do not simply leave the resources registered with ARIN? Is it because local affiliates, or otherwise? There are a few reasons to transfer to the network's local RIR, including data sovereignty laws and the routing requirements of some transit providers. Moving addresses from ARIN to another RIR is compulsory in our case to comply with the rules others put on us. It's not optional. From rudi.daniel at gmail.com Fri Aug 18 15:36:56 2017 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Fri, 18 Aug 2017 12:36:56 -0700 Subject: [arin-ppml] ARIN-PPML 2017-6 draft policy Message-ID: " Recipient RIR policy must not permit transfers to other RIRs or NIRs whose policies do not support bi-directional transfers." Whereas I am in support of closing this loophole, I cannot be sure that this is actually achievable... rd On Aug 17, 2017 6:01 PM, wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Revised: Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > (Paul McNary) > 2. Draft Policy 2017-6: Improve Reciprocity Requirements for > Inter RIR Transfers (WOOD Alison * DAS) > 3. Re: Revised: Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > (hostmaster at uneedus.com) > 4. Re: Revised: Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > (David Farmer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 17 Aug 2017 15:49:47 -0500 > From: Paul McNary > To: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 > and > IPv6 > Message-ID: <7460ee99-c116-7c0a-b726-2267de135596 at cameron.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > Sorry I typed the numbers backwards, yes, that is what I meant. :-) > > A /48 is smaller than a /47 and would not be required to be registered? > A /47 would need to be > > > On 8/17/2017 1:30 PM, Chris Woodfield wrote: > > The opposite - a /47 is 2 /48s aggregated. > > > > -C > > > >> On Aug 17, 2017, at 11:26 AM, Paul McNary wrote: > >> > >> A /47 is smaller than a /48 and would not be required to be registered? > >> > >> > >> On 8/17/2017 12:50 PM, hostmaster at uneedus.com wrote: > >>> I note that any ISP size reassignment, with the recommended /48 for > each end user site, will be /47 or larger, which must always be registered. > >>> > >>> Thus, I think 6.5.5.5 language is unneeded, since any LIR/ISP > reassignment will be large enough to already trigger registration. > >>> > >>> Under the current policy, LIR's and ISP's are equal, so usually both > terms are stated in any policy that mentions them. > >>> > >>> May I also suggest that if we are going to require registration upon > downstream request for IPv6, that we consider placing the same language and > requirements for IPv4 customers as well? And if we do, where do we draw > the minimum line? Maybe a /32.... > >>> > >>> Also, good catch on the cut and paste error..... > >>> > >>> Albert Erdmann > >>> Network Administrator > >>> Paradise On Line Inc. > >>> > >>> > >>> On Thu, 17 Aug 2017, Leif Sawyer wrote: > >>> > >>>> Thanks for the feedback, David. > >>>> > >>>> I've added the fix for 6.5.5.2, since we're already in the section. > >>>> > >>>> I've also modified the text for 6.5.5.4 as well, because I think your > suggesting is a little cleaner. > >>>> > >>>> I'm not sure what the point of 6.5.5.5 is - you're just reiterating > 6.5.5.1. > >>>> That said, we could potentially clean up 6.5.5.1 by extending "static > IPv6 assignment" > >>>> to "static IPv6 assignment, or allocation," - or something similar. > >>>> > >>>> > >>>> Which also brings to mind the question: LIR or ISP? Both are in > use in 6.5.... > >>>> > >>>> ________________________________ > >>>> From: ARIN-PPML [arin-ppml-bounces at arin.net] on behalf of David > Farmer [farmer at umn.edu] > >>>> Sent: Thursday, August 17, 2017 8:53 AM > >>>> To: hostmaster at uneedus.com > >>>> Cc: arin-ppml at arin.net > >>>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 and IPv6 > >>>> > >>>> [External Email] > >>>> > >>>> Here is a slightly different formulation to consider. I refactored > the title a little, and based the phrasing on other parts of section 6.5.5 > >>>> > >>>> 6.5.5.4 Registration Requested by Recipient > >>>> > >>>> If requested by the downstream recipient of a block, each static IPv6 > assignment containing a /64 or more addresses, shall be registered, as > described in section 6.5.5.1. > >>>> > >>>> I'd like us to think about adding an additional section, based on > previous discussions. > >>>> > >>>> 6.5.5.5 Re-allocation to ISPs > >>>> > >>>> Each IPv6 re-allocation to a downstream ISP, regardless of size, > intended for further assignment by the downstream ISP's to it's customers, > shall be registered, as described in section 6.5.5.1 > >>>> > >>>> Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. I > think this is a cut and past error, I think the reference should be to > 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with sections > 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. > >>>> > >>>> Thanks. > >>>> > >>>> On Wed, Aug 16, 2017 at 6:10 AM, hostmaster at uneedus.com>> wrote: > >>>> I am in favor of the draft, with or without the changes to make it > clearer. > >>>> > >>>> I suggest the following language for clarity: > >>>> > >>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the > NRPM that reads "If the downstream recipient of a static assignment of /64 > or more addresses requests publishing of that static assignment in ARIN's > registration database, the ISP must register that static assignment." > >>>> > >>>> Since "static assignment" is the term in this section, not netblock, > I suggest using this term instead of "netblock". "Of any size" is not > needed, as the language would require the ISP to register in total whatever > size the ISP has assigned to the downstream in the ARIN database if > requested by the downstream recipient, as long as it was /64 or more. > >>>> > >>>> This language would also prevent requests to register only part of an > assignment. I think this language works in making the intent of the new > section more clear. > >>>> > >>>> Albert Erdmann > >>>> Network Administrator > >>>> Paradise On Line Inc. > >>>> > >>>> > >>>> > >>>> On Tue, 15 Aug 2017, John Santos wrote: > >>>> > >>>> I think that the "/64 or more addresses" and the "regardless of size" > are meant to convey that any netblock between a /64 and a /48 can and > should be registered if the recipient requests it, even if the block is > smaller than the /47 which would make it mandatory. Perhaps there is > better wording that would make this clearer. > >>>> > >>>> Three ranges: > >>>> > >>>> 1. smaller than /64: shouldn't be issued, can't be registered. > >>>> 2. /64 through /48: register at recipient's request > >>>> 3. /47 or larger: must be registered > >>>> > >>>> I agree on dynamic assignments > >>>> > >>>> Otherwise, I think this is a much clearer and better update to the > proposed policy, and can't find any other reason not to support it. (I.E. > this is a tentative vote FOR, if there is such a thing.) > >>>> > >>>> > >>>> > >>>> On 8/15/2017 3:59 PM, David Farmer wrote: > >>>> I support what I think is the intent, but I have language/editorial > nits; > >>>> > >>>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless > of size" that requires registration? I think logically we need one or the > other, or some qualification on "regardless of size" statement. I think it > is a good idea to not require registration of less than a /64. But the > current language seems contradictory, and therefore confusing, my > recommendation is delete "regardless of size", from the sentence and > leaving "a /64 or more addresses". I pretty sure we don't want people > having an expectation that they can request the registration of "their" > /128 address. > >>>> > >>>> 2. Also in 3) below; It would seem to require even dynamic > assignments be registered if requested, I don't think that is our intent > either, section 6.5.5.1 starts with "Each static IPv6 assignment > containing", this needs a similar qualification. > >>>> > >>>> Also, I'm fine with the deltas in the policy statement but it would > be helpful to see the final resulting policy block, maybe in a separate > email so we can all see how the result reads. > >>>> > >>>> Thanks, I think we are getting close, maybe one or two more turns of > the crank. > >>>> > >>>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN arin.net> >> wrote: > >>>> > >>>> The following has been revised: > >>>> > >>>> * Draft Policy ARIN-2017-5: Equalization of Assignment > >>>> Registration requirements between IPv4 and IPv6 > >>>> > >>>> Revised text is below and can be found at: > >>>> https://www.arin.net/policy/proposals/2017_5.html www.arin.net/policy/proposals/2017_5.html> > >>>> www.arin.net/policy/proposals/2017_5.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 policy/pdp.html> > >>>> policy/pdp.html>> > >>>> > >>>> Draft Policies and Proposals under discussion can be found at: > >>>> https://www.arin.net/policy/proposals/index.html www.arin.net/policy/proposals/index.html> > >>>> www.arin.net/policy/proposals/index.html>> > >>>> > >>>> Regards, > >>>> > >>>> Sean Hopkins > >>>> Policy Analyst > >>>> American Registry for Internet Numbers (ARIN) > >>>> > >>>> > >>>> > >>>> > >>>> 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 subdelegation 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" > >>>> > >>>> and > >>>> > >>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to > >>>> the NRPM that reads "If the downstream recipient of a netblock ( a > >>>> /64 or more addresses) requests publishing in ARIN's registration > >>>> database, the ISP must register the netblock, regardless of size." > >>>> > >>>> 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. > >>>> > >>>> -- > >>>> John Santos > >>>> Evans Griffiths & Hart, Inc. > >>>> 781-861-0670 ext 539 > >>>> > >>>> > >>>> _______________________________________________ > >>>> PPML > >>>> You are receiving this message because you are subscribed to > >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net N-PPML at arin.net>). > >>>> Unsubscribe or manage your mailing list subscription at: > >>>> http://lists.arin.net/mailman/listinfo/arin-ppml lists.arin.net/mailman/listinfo/arin-ppml> > >>>> Please contact info at arin.net if you experience > any issues. > >>>> > >>>> > >>>> > >>>> -- > >>>> =============================================== > >>>> David Farmer Email:farmer at umn.edu > >>>> 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 (ARIN-PPML at arin.net). > >>> Unsubscribe or manage your mailing list subscription at: > >>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>> Please contact info at 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 at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > >> > > > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 17 Aug 2017 20:54:23 +0000 > From: WOOD Alison * DAS > To: "arin-ppml at arin.net" > Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity > Requirements for Inter RIR Transfers > Message-ID: > ENTSS.OR.GOV> > Content-Type: text/plain; charset="us-ascii" > > Thank you for the feedback on this draft policy to date. I would > appreciate any other thoughts or comments on this draft policy. > > For review, Draft Policy 2017-6 is intended to add the following > conditions on Inter RIR transfers to section 8.4: > > Recipient RIR policy must not permit transfers to other RIRs or NIRs whose > policies do not support bi-directional transfers. > > And the problem statement on this draft policy is: > > Currently ARIN's requirement that inter-RIR transfer policies be > reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a > two-hop RIR transfer process can be used to circumvent the intent of the > requirement. Rather than eliminate the requirement, a better approach would > be to close the loophole. > > All feedback is appreciated. > > Thank you > > -Alison Wood > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20170817/22d7858b/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Thu, 17 Aug 2017 18:00:05 -0400 (EDT) > From: hostmaster at uneedus.com > To: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 > and > IPv6 > Message-ID: > Content-Type: text/plain; charset="x-unknown"; Format="flowed" > > While the most recent drafts have not dealt with IPv4, in the last round > there was a proposal to require registration upon request of the > downstream customer of their IPv6 assignment. > > If we intend to provide that power to require registration for IPv6 > customer assignments upon request, in fairness we should also use the same > language in a new 4.2.3.7.4 to allow static IPv4 customers that same > power. I suggest /32 as the limit, as /29 or more already has required > registration. The same problems identfied in not being able to register > assignments with ARIN for v6 are also true for v4 assignments between > those limits. > > Since both protocols are still being addressed and attempts are being > made by the draft to make v6 equal or better than v4, the title should > remain. The only thing we have done is not shift the v4 limit of /29. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > > While we???re turning the crank, can we please fix the title since IPv4 > > is no longer relevant to the proposal and there???s really no > > equalization happening? > > > > Perhaps ???Improved Registration Requirements for IPv6??? > > > > Owen > > ------------------------------ > > Message: 4 > Date: Thu, 17 Aug 2017 17:01:09 -0500 > From: David Farmer > To: Leif Sawyer > Cc: "hostmaster at uneedus.com" , > "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 > and > IPv6 > Message-ID: > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Thu, Aug 17, 2017 at 1:43 PM, David Farmer wrote: > > > Inline. > > > > On Thu, Aug 17, 2017 at 12:29 PM, Leif Sawyer wrote: > > > >> Thanks for the feedback, David. > >> > > ... > > > I'm not sure what the point of 6.5.5.5 is - you're just reiterating > >> 6.5.5.1. > >> That said, we could potentially clean up 6.5.5.1 by extending "static > >> IPv6 assignment" > >> to "static IPv6 assignment, or allocation," - or something similar. > >> > > > > ISP re-allocations need to be registered regardless of size or if it is > > being advertised or not. For example, if for some stupid reason a /56 was > > re-allocated to downsterm ISP so they could assign /64s to customers that > > has to be registered, by 6.5.5.1 that wouldn't have to be registered. > > Should you re-allocate a /56, @!@#$ NO!!! But if you did, it has to be > > registered. This is so LEA and other legal requests get directly to the > > correct ISP the first time. I think this is important enough issue that > it > > should have it's own section, and not get blended in to 6.5.5.1. > > > > Now should that be part of this policy maybe not, maybe this belongs in > > ARIN-2017-3 or whole new separate policy proposal instead. > > > > Thinking about this for the last couple hours I'm thinking 6.5.5.5 this > should not be part of this policy. As similar text should be added in the > IPv4 section, and this should have a somewhat different problem statement > as well. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > 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 > =============================================== > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20170817/7e7a2fcd/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > ------------------------------ > > End of ARIN-PPML Digest, Vol 146, Issue 10 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Tue Aug 22 12:38:08 2017 From: info at arin.net (ARIN) Date: Tue, 22 Aug 2017 12:38:08 -0400 Subject: [arin-ppml] Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements Message-ID: The following has been revised: * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_5.html Note that the Draft Policy title has changed from "Equalization of Assignment Registration requirements between IPv4 and IPv6" 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 Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements 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 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 must 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. From info at arin.net Tue Aug 22 12:38:43 2017 From: info at arin.net (ARIN) Date: Tue, 22 Aug 2017 12:38:43 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - August 2017 Message-ID: <1c42fbd2-d4b4-1041-1fc5-c95def85d78e@arin.net> In accordance with the Policy Development Process (PDP), the Advisory Council (AC) met on 17 August 2017. The AC has abandoned the following Draft Policy: ARIN-2017-2: Removal of Community Networks The AC provided the following statement: "The ARIN Advisory Council has chosen to abandon Policy Proposal 2017-2, "Removal of Community Networks," due to lack of community support and the introduction of an alternative policy proposal to amend the definition of "community network." Anyone dissatisfied with this decision may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. The AC has abandoned the following Draft Policy: ARIN-2017-7: Retire Obsolete Section 4 from the NRPM The AC provided the following statement: "The ARIN Advisory Council has chosen to abandon Policy Proposal 2017-7, ?Retire Obsolete Section 4 from the NRPM?. This proposal did not gain sufficient community support to justify continuing to move this policy forward, and as such, we have requested that the policy be abandoned." Anyone dissatisfied with this decision may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. The AC has advanced the following Proposal to Draft Policy status (will be posted separately for discussion): ARIN-prop-243: Amend the Definition of Community Network The AC advances Proposals to Draft Policy status once they are found to be within the scope of the PDP, and contain a clear problem statement and suggested changes to Internet number resource policy text. The AC is continuing to work on: * ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation * ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers * ARIN-2017-5: Improved IPv6 Registration Requirements * ARIN-2017-6: Improve Reciprocity Requirement for Inter-RIR Transfers The PDP can be found at: 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 Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) From info at arin.net Tue Aug 22 12:39:53 2017 From: info at arin.net (ARIN) Date: Tue, 22 Aug 2017 12:39:53 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of Community Network Message-ID: <28d7e4fc-532c-209f-039a-57c1d88cea20@arin.net> On 17 August 2017 the ARIN Advisory Council (AC) advanced "ARIN-prop-243: Amend the Definition of Community Network" to Draft Policy status. Draft Policy ARIN-2017-8 is below and can be found at: https://www.arin.net/policy/proposals/2017_8.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 Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-8: Amend the Definition of Community Network Problem Statement: The Community Networks section of the NRPM has not been used since implementation in January 2010. Proposal ARIN-2016-7, to increase the number of use cases, was abandoned by the Advisory Council due to lack of feedback. Proposal ARIN 2017-2, to remove all mention of community networks from NRPM was met with opposition by the community. Many responded that the definition of ?community network? was too narrow, which could be the reason for lack of uptake. Policy statement: CURRENT NRPM TEXT: ?2.11. Community Network A community network is any network organized and operated by a volunteer group operating as or under the fiscal support of a nonprofit organization or university for the purpose of providing free or low-cost connectivity to the residents of their local service area. To be treated as a community network under ARIN policy, the applicant must certify to ARIN that the community network staff is 100% volunteers.? NEW NRPM TEXT: ?2.11 Community Network A community network is a network organized and operated by a volunteer group, not-for-profit, non-profit, charitable organization, or post-secondary institution for the purpose of providing free or low-cost connectivity to residents in their service area. Critical functions may be handled by paid staff, but volunteers play a large role in offering services available through community networks.? Comments: Timetable for implementation: Immediate From owen at delong.com Tue Aug 22 17:05:40 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Aug 2017 14:05:40 -0700 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <7460ee99-c116-7c0a-b726-2267de135596@cameron.net> References: <59932A32.8010708@arin.net> <4f8974ce-8c1a-b73e-e069-38fb2939774e@egh.com> <77aa9cb4-8162-dbed-f950-cae808914c09@cameron.net> <7460ee99-c116-7c0a-b726-2267de135596@cameron.net> Message-ID: <9629D8FC-8536-49CA-8A4D-A62CB05AC0AF@delong.com> > On Aug 17, 2017, at 13:49 , Paul McNary wrote: > > Sorry I typed the numbers backwards, yes, that is what I meant. :-) > > A /48 is smaller than a /47 and would not be required to be registered? > A /47 would need to be > That is correct as the current state of the proposal stands. Owen > > On 8/17/2017 1:30 PM, Chris Woodfield wrote: >> The opposite - a /47 is 2 /48s aggregated. >> >> -C >> >>> On Aug 17, 2017, at 11:26 AM, Paul McNary wrote: >>> >>> A /47 is smaller than a /48 and would not be required to be registered? >>> >>> >>> On 8/17/2017 12:50 PM, hostmaster at uneedus.com wrote: >>>> I note that any ISP size reassignment, with the recommended /48 for each end user site, will be /47 or larger, which must always be registered. >>>> >>>> Thus, I think 6.5.5.5 language is unneeded, since any LIR/ISP reassignment will be large enough to already trigger registration. >>>> >>>> Under the current policy, LIR's and ISP's are equal, so usually both terms are stated in any policy that mentions them. >>>> >>>> May I also suggest that if we are going to require registration upon downstream request for IPv6, that we consider placing the same language and requirements for IPv4 customers as well? And if we do, where do we draw the minimum line? Maybe a /32.... >>>> >>>> Also, good catch on the cut and paste error..... >>>> >>>> Albert Erdmann >>>> Network Administrator >>>> Paradise On Line Inc. >>>> >>>> >>>> On Thu, 17 Aug 2017, Leif Sawyer wrote: >>>> >>>>> Thanks for the feedback, David. >>>>> >>>>> I've added the fix for 6.5.5.2, since we're already in the section. >>>>> >>>>> I've also modified the text for 6.5.5.4 as well, because I think your suggesting is a little cleaner. >>>>> >>>>> I'm not sure what the point of 6.5.5.5 is - you're just reiterating 6.5.5.1. >>>>> That said, we could potentially clean up 6.5.5.1 by extending "static IPv6 assignment" >>>>> to "static IPv6 assignment, or allocation," - or something similar. >>>>> >>>>> >>>>> Which also brings to mind the question: LIR or ISP? Both are in use in 6.5.... >>>>> >>>>> ________________________________ >>>>> From: ARIN-PPML [arin-ppml-bounces at arin.net] on behalf of David Farmer [farmer at umn.edu] >>>>> Sent: Thursday, August 17, 2017 8:53 AM >>>>> To: hostmaster at uneedus.com >>>>> Cc: arin-ppml at arin.net >>>>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 >>>>> >>>>> [External Email] >>>>> >>>>> Here is a slightly different formulation to consider. I refactored the title a little, and based the phrasing on other parts of section 6.5.5 >>>>> >>>>> 6.5.5.4 Registration Requested by Recipient >>>>> >>>>> If requested by the downstream recipient of a block, each static IPv6 assignment containing a /64 or more addresses, shall be registered, as described in section 6.5.5.1. >>>>> >>>>> I'd like us to think about adding an additional section, based on previous discussions. >>>>> >>>>> 6.5.5.5 Re-allocation to ISPs >>>>> >>>>> Each IPv6 re-allocation to a downstream ISP, regardless of size, intended for further assignment by the downstream ISP's to it's customers, shall be registered, as described in section 6.5.5.1 >>>>> >>>>> Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. I think this is a cut and past error, I think the reference should be to 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with sections 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. >>>>> >>>>> Thanks. >>>>> >>>>> On Wed, Aug 16, 2017 at 6:10 AM, > wrote: >>>>> I am in favor of the draft, with or without the changes to make it clearer. >>>>> >>>>> I suggest the following language for clarity: >>>>> >>>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM that reads "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that static assignment in ARIN's registration database, the ISP must register that static assignment." >>>>> >>>>> Since "static assignment" is the term in this section, not netblock, I suggest using this term instead of "netblock". "Of any size" is not needed, as the language would require the ISP to register in total whatever size the ISP has assigned to the downstream in the ARIN database if requested by the downstream recipient, as long as it was /64 or more. >>>>> >>>>> This language would also prevent requests to register only part of an assignment. I think this language works in making the intent of the new section more clear. >>>>> >>>>> Albert Erdmann >>>>> Network Administrator >>>>> Paradise On Line Inc. >>>>> >>>>> >>>>> >>>>> On Tue, 15 Aug 2017, John Santos wrote: >>>>> >>>>> I think that the "/64 or more addresses" and the "regardless of size" are meant to convey that any netblock between a /64 and a /48 can and should be registered if the recipient requests it, even if the block is smaller than the /47 which would make it mandatory. Perhaps there is better wording that would make this clearer. >>>>> >>>>> Three ranges: >>>>> >>>>> 1. smaller than /64: shouldn't be issued, can't be registered. >>>>> 2. /64 through /48: register at recipient's request >>>>> 3. /47 or larger: must be registered >>>>> >>>>> I agree on dynamic assignments >>>>> >>>>> Otherwise, I think this is a much clearer and better update to the proposed policy, and can't find any other reason not to support it. (I.E. this is a tentative vote FOR, if there is such a thing.) >>>>> >>>>> >>>>> >>>>> On 8/15/2017 3:59 PM, David Farmer wrote: >>>>> I support what I think is the intent, but I have language/editorial nits; >>>>> >>>>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of size" that requires registration? I think logically we need one or the other, or some qualification on "regardless of size" statement. I think it is a good idea to not require registration of less than a /64. But the current language seems contradictory, and therefore confusing, my recommendation is delete "regardless of size", from the sentence and leaving "a /64 or more addresses". I pretty sure we don't want people having an expectation that they can request the registration of "their" /128 address. >>>>> >>>>> 2. Also in 3) below; It would seem to require even dynamic assignments be registered if requested, I don't think that is our intent either, section 6.5.5.1 starts with "Each static IPv6 assignment containing", this needs a similar qualification. >>>>> >>>>> Also, I'm fine with the deltas in the policy statement but it would be helpful to see the final resulting policy block, maybe in a separate email so we can all see how the result reads. >>>>> >>>>> Thanks, I think we are getting close, maybe one or two more turns of the crank. >>>>> >>>>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN >> wrote: >>>>> >>>>> The following has been revised: >>>>> >>>>> * Draft Policy ARIN-2017-5: Equalization of Assignment >>>>> Registration requirements between IPv4 and IPv6 >>>>> >>>>> Revised text is below and can be found at: >>>>> https://www.arin.net/policy/proposals/2017_5.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 >>>>> > >>>>> >>>>> Draft Policies and Proposals under discussion can be found at: >>>>> https://www.arin.net/policy/proposals/index.html >>>>> > >>>>> >>>>> Regards, >>>>> >>>>> Sean Hopkins >>>>> Policy Analyst >>>>> American Registry for Internet Numbers (ARIN) >>>>> >>>>> >>>>> >>>>> >>>>> 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 subdelegation 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" >>>>> >>>>> and >>>>> >>>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to >>>>> the NRPM that reads "If the downstream recipient of a netblock ( a >>>>> /64 or more addresses) requests publishing in ARIN's registration >>>>> database, the ISP must register the netblock, regardless of size." >>>>> >>>>> 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. >>>>> >>>>> -- >>>>> John Santos >>>>> Evans Griffiths & Hart, Inc. >>>>> 781-861-0670 ext 539 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>>>> >>>>> >>>>> >>>>> -- >>>>> =============================================== >>>>> David Farmer Email:farmer at umn.edu >>>>> 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 (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at 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 at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Tue Aug 22 17:10:08 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Aug 2017 14:10:08 -0700 Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers In-Reply-To: <415F505D-1A01-4B43-9386-4F29013D8F4B@panix.com> References: <415F505D-1A01-4B43-9386-4F29013D8F4B@panix.com> Message-ID: <4603E5A4-8DEB-4F14-BA93-941C0A75D00D@delong.com> > On Aug 18, 2017, at 05:14 , David Huberman wrote: > > I am a US-based company and I operate a network on multiple continents. > > I need to be able to move space from my home RIR of ARIN to other regions as I expand my network overseas. > > The current policy that has been in effect for many years allows me to operate my network properly -- using ARIN blocks in ARIN, APNIC blocks in APNIC, and RIPE blocks in RIPE. The policy is predictable and I can plan network growth around it. > > If this proposal passes, it will shut off transfers between ARIN and APNIC. This will hurt my business's finances. We purchased addresses in the ARIN region wth the intention of moving them to APNIC in the future. We did so because the size blocks we needed were not available in the APNIC region. So now we are talking about hurting my business for ... what reason? How do network operations benefit from this proposal? Currently, there are certain registries that are operating like roach motels for IP addresses. KR-NIC, CN-NIC are examples. AfriNIC is discussing a similar proposal and a similar proposal was discussed in LACNIC. It is hoped that by implementing this policy it will put pressure on those registries to be more cooperative with the global community in allowing bi-directional transfers. That is how it helps network operations. Admittedly, it?s a short-term pain for a longer term gain, but that is the intent. Owen > > >> On Aug 18, 2017, at 6:10 AM, hostmaster at uneedus.com wrote: >> >> I would not consider an RIR that has NIR units that do not have a bi directional transfer policy to comply with the policy of ARIN to only permit transfers to/from those with a bi directional transfer policy. >> >> Thus, I support the statement being added in this draft to make this more clear. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >>> On Thu, 17 Aug 2017, WOOD Alison * DAS wrote: >>> >>> Thank you for the feedback on this draft policy to date. I would appreciate any other thoughts or comments on this draft policy. >>> >>> For review, Draft Policy 2017-6 is intended to add the following conditions on Inter RIR transfers to section 8.4: >>> >>> Recipient RIR policy must not permit transfers to other RIRs or NIRs whose policies do not support bi-directional transfers. >>> >>> And the problem statement on this draft policy is: >>> >>> Currently ARIN's requirement that inter-RIR transfer policies be reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a two-hop RIR transfer process can be used to circumvent the intent of the requirement. Rather than eliminate the requirement, a better approach would be to close the loophole. >>> >>> All feedback is appreciated. >>> >>> Thank you >>> >>> -Alison Wood >>> >> _______________________________________________ >> 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: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Tue Aug 22 17:12:45 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Aug 2017 14:12:45 -0700 Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers In-Reply-To: References: <415F505D-1A01-4B43-9386-4F29013D8F4B@panix.com> Message-ID: <9CCE0F27-6914-4CE8-8C9D-F6DA18305524@delong.com> > On Aug 18, 2017, at 05:30 , hostmaster at uneedus.com wrote: > > I was always under the impression that companies that operate in more than one region usually obtain their number resources from their home region, and use these worldwide. That is a perfectly valid mode of operation and many companies do so. Some providers, however, have difficulty with this concept and refuse to accept routes that aren?t from the local RIR or otherwise make operating in this manner difficult. There are also, as you noted, geolocation issues. In some cases, the proxy server solution isn?t as workable as it apparently was in the case you described. Owen > > On Fri, 18 Aug 2017, David Huberman wrote: > >> I am a US-based company and I operate a network on multiple continents. >> >> I need to be able to move space from my home RIR of ARIN to other regions as I expand my network overseas. >> >> The current policy that has been in effect for many years allows me to operate my network properly -- using ARIN blocks in ARIN, APNIC blocks in APNIC, and RIPE blocks in RIPE. The policy is predictable and I can plan network growth around it. >> >> If this proposal passes, it will shut off transfers between ARIN and APNIC. This will hurt my business's finances. We purchased addresses in the ARIN region wth the intention of moving them to APNIC in the future. We did so because the size blocks we needed were not available in the APNIC region. So now we are talking about hurting my business for ... what reason? How do network operations benefit from this proposal? >> >> >>> On Aug 18, 2017, at 6:10 AM, hostmaster at uneedus.com wrote: >>> >>> I would not consider an RIR that has NIR units that do not have a bi directional transfer policy to comply with the policy of ARIN to only permit transfers to/from those with a bi directional transfer policy. >>> >>> Thus, I support the statement being added in this draft to make this more clear. >>> >>> Albert Erdmann >>> Network Administrator >>> Paradise On Line Inc. >>> >>> >>>> On Thu, 17 Aug 2017, WOOD Alison * DAS wrote: >>>> >>>> Thank you for the feedback on this draft policy to date. I would appreciate any other thoughts or comments on this draft policy. >>>> >>>> For review, Draft Policy 2017-6 is intended to add the following conditions on Inter RIR transfers to section 8.4: >>>> >>>> Recipient RIR policy must not permit transfers to other RIRs or NIRs whose policies do not support bi-directional transfers. >>>> >>>> And the problem statement on this draft policy is: >>>> >>>> Currently ARIN's requirement that inter-RIR transfer policies be reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a two-hop RIR transfer process can be used to circumvent the intent of the requirement. Rather than eliminate the requirement, a better approach would be to close the loophole. >>>> >>>> All feedback is appreciated. >>>> >>>> Thank you >>>> >>>> -Alison Wood >>>> >>> _______________________________________________ >>> 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: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Tue Aug 22 17:15:27 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Aug 2017 14:15:27 -0700 Subject: [arin-ppml] ARIN-PPML 2017-6 draft policy In-Reply-To: References: Message-ID: <84C695FE-80CE-44C1-A608-6FC459125827@delong.com> It is achievable because ARIN will evaluate the policy of each RIR in this regard prior to approving the transfer. Owen > On Aug 18, 2017, at 12:36 , Rudolph Daniel wrote: > > " Recipient RIR policy must not permit transfers to other RIRs or NIRs whose policies do not support bi-directional transfers." > > Whereas I am in support of closing this loophole, I cannot be sure that this is actually achievable... > rd > > > On Aug 17, 2017 6:01 PM, > wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Revised: Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > (Paul McNary) > 2. Draft Policy 2017-6: Improve Reciprocity Requirements for > Inter RIR Transfers (WOOD Alison * DAS) > 3. Re: Revised: Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > (hostmaster at uneedus.com ) > 4. Re: Revised: Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > (David Farmer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 17 Aug 2017 15:49:47 -0500 > From: Paul McNary > > To: "arin-ppml at arin.net " > > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 and > IPv6 > Message-ID: <7460ee99-c116-7c0a-b726-2267de135596 at cameron.net > > Content-Type: text/plain; charset=utf-8; format=flowed > > Sorry I typed the numbers backwards, yes, that is what I meant. :-) > > A /48 is smaller than a /47 and would not be required to be registered? > A /47 would need to be > > > On 8/17/2017 1:30 PM, Chris Woodfield wrote: > > The opposite - a /47 is 2 /48s aggregated. > > > > -C > > > >> On Aug 17, 2017, at 11:26 AM, Paul McNary > wrote: > >> > >> A /47 is smaller than a /48 and would not be required to be registered? > >> > >> > >> On 8/17/2017 12:50 PM, hostmaster at uneedus.com wrote: > >>> I note that any ISP size reassignment, with the recommended /48 for each end user site, will be /47 or larger, which must always be registered. > >>> > >>> Thus, I think 6.5.5.5 language is unneeded, since any LIR/ISP reassignment will be large enough to already trigger registration. > >>> > >>> Under the current policy, LIR's and ISP's are equal, so usually both terms are stated in any policy that mentions them. > >>> > >>> May I also suggest that if we are going to require registration upon downstream request for IPv6, that we consider placing the same language and requirements for IPv4 customers as well? And if we do, where do we draw the minimum line? Maybe a /32.... > >>> > >>> Also, good catch on the cut and paste error..... > >>> > >>> Albert Erdmann > >>> Network Administrator > >>> Paradise On Line Inc. > >>> > >>> > >>> On Thu, 17 Aug 2017, Leif Sawyer wrote: > >>> > >>>> Thanks for the feedback, David. > >>>> > >>>> I've added the fix for 6.5.5.2, since we're already in the section. > >>>> > >>>> I've also modified the text for 6.5.5.4 as well, because I think your suggesting is a little cleaner. > >>>> > >>>> I'm not sure what the point of 6.5.5.5 is - you're just reiterating 6.5.5.1. > >>>> That said, we could potentially clean up 6.5.5.1 by extending "static IPv6 assignment" > >>>> to "static IPv6 assignment, or allocation," - or something similar. > >>>> > >>>> > >>>> Which also brings to mind the question: LIR or ISP? Both are in use in 6.5.... > >>>> > >>>> ________________________________ > >>>> From: ARIN-PPML [arin-ppml-bounces at arin.net ] on behalf of David Farmer [farmer at umn.edu ] > >>>> Sent: Thursday, August 17, 2017 8:53 AM > >>>> To: hostmaster at uneedus.com > >>>> Cc: arin-ppml at arin.net > >>>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 > >>>> > >>>> [External Email] > >>>> > >>>> Here is a slightly different formulation to consider. I refactored the title a little, and based the phrasing on other parts of section 6.5.5 > >>>> > >>>> 6.5.5.4 Registration Requested by Recipient > >>>> > >>>> If requested by the downstream recipient of a block, each static IPv6 assignment containing a /64 or more addresses, shall be registered, as described in section 6.5.5.1. > >>>> > >>>> I'd like us to think about adding an additional section, based on previous discussions. > >>>> > >>>> 6.5.5.5 Re-allocation to ISPs > >>>> > >>>> Each IPv6 re-allocation to a downstream ISP, regardless of size, intended for further assignment by the downstream ISP's to it's customers, shall be registered, as described in section 6.5.5.1 > >>>> > >>>> Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. I think this is a cut and past error, I think the reference should be to 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with sections 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. > >>>> > >>>> Thanks. > >>>> > >>>> On Wed, Aug 16, 2017 at 6:10 AM, >> wrote: > >>>> I am in favor of the draft, with or without the changes to make it clearer. > >>>> > >>>> I suggest the following language for clarity: > >>>> > >>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM that reads "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that static assignment in ARIN's registration database, the ISP must register that static assignment." > >>>> > >>>> Since "static assignment" is the term in this section, not netblock, I suggest using this term instead of "netblock". "Of any size" is not needed, as the language would require the ISP to register in total whatever size the ISP has assigned to the downstream in the ARIN database if requested by the downstream recipient, as long as it was /64 or more. > >>>> > >>>> This language would also prevent requests to register only part of an assignment. I think this language works in making the intent of the new section more clear. > >>>> > >>>> Albert Erdmann > >>>> Network Administrator > >>>> Paradise On Line Inc. > >>>> > >>>> > >>>> > >>>> On Tue, 15 Aug 2017, John Santos wrote: > >>>> > >>>> I think that the "/64 or more addresses" and the "regardless of size" are meant to convey that any netblock between a /64 and a /48 can and should be registered if the recipient requests it, even if the block is smaller than the /47 which would make it mandatory. Perhaps there is better wording that would make this clearer. > >>>> > >>>> Three ranges: > >>>> > >>>> 1. smaller than /64: shouldn't be issued, can't be registered. > >>>> 2. /64 through /48: register at recipient's request > >>>> 3. /47 or larger: must be registered > >>>> > >>>> I agree on dynamic assignments > >>>> > >>>> Otherwise, I think this is a much clearer and better update to the proposed policy, and can't find any other reason not to support it. (I.E. this is a tentative vote FOR, if there is such a thing.) > >>>> > >>>> > >>>> > >>>> On 8/15/2017 3:59 PM, David Farmer wrote: > >>>> I support what I think is the intent, but I have language/editorial nits; > >>>> > >>>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of size" that requires registration? I think logically we need one or the other, or some qualification on "regardless of size" statement. I think it is a good idea to not require registration of less than a /64. But the current language seems contradictory, and therefore confusing, my recommendation is delete "regardless of size", from the sentence and leaving "a /64 or more addresses". I pretty sure we don't want people having an expectation that they can request the registration of "their" /128 address. > >>>> > >>>> 2. Also in 3) below; It would seem to require even dynamic assignments be registered if requested, I don't think that is our intent either, section 6.5.5.1 starts with "Each static IPv6 assignment containing", this needs a similar qualification. > >>>> > >>>> Also, I'm fine with the deltas in the policy statement but it would be helpful to see the final resulting policy block, maybe in a separate email so we can all see how the result reads. > >>>> > >>>> Thanks, I think we are getting close, maybe one or two more turns of the crank. > >>>> > >>>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN > >>> wrote: > >>>> > >>>> The following has been revised: > >>>> > >>>> * Draft Policy ARIN-2017-5: Equalization of Assignment > >>>> Registration requirements between IPv4 and IPv6 > >>>> > >>>> Revised text is below and can be found at: > >>>> https://www.arin.net/policy/proposals/2017_5.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 > > >>>> >> > >>>> > >>>> Draft Policies and Proposals under discussion can be found at: > >>>> https://www.arin.net/policy/proposals/index.html > > >>>> >> > >>>> > >>>> Regards, > >>>> > >>>> Sean Hopkins > >>>> Policy Analyst > >>>> American Registry for Internet Numbers (ARIN) > >>>> > >>>> > >>>> > >>>> > >>>> 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 subdelegation 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" > >>>> > >>>> and > >>>> > >>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to > >>>> the NRPM that reads "If the downstream recipient of a netblock ( a > >>>> /64 or more addresses) requests publishing in ARIN's registration > >>>> database, the ISP must register the netblock, regardless of size." > >>>> > >>>> 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. > >>>> > >>>> -- > >>>> John Santos > >>>> Evans Griffiths & Hart, Inc. > >>>> 781-861-0670 ext 539 > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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: > >>>> http://lists.arin.net/mailman/listinfo/arin-ppml > > >>>> Please contact info at arin.net > if you experience any issues. > >>>> > >>>> > >>>> > >>>> -- > >>>> =============================================== > >>>> David Farmer Email:farmer at umn.edu > > >>>> 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 (ARIN-PPML at arin.net ). > >>> Unsubscribe or manage your mailing list subscription at: > >>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>> Please contact info at 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 at arin.net ). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > >> > > > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 17 Aug 2017 20:54:23 +0000 > From: WOOD Alison * DAS > > To: "arin-ppml at arin.net " > > Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity > Requirements for Inter RIR Transfers > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > Thank you for the feedback on this draft policy to date. I would appreciate any other thoughts or comments on this draft policy. > > For review, Draft Policy 2017-6 is intended to add the following conditions on Inter RIR transfers to section 8.4: > > Recipient RIR policy must not permit transfers to other RIRs or NIRs whose policies do not support bi-directional transfers. > > And the problem statement on this draft policy is: > > Currently ARIN's requirement that inter-RIR transfer policies be reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a two-hop RIR transfer process can be used to circumvent the intent of the requirement. Rather than eliminate the requirement, a better approach would be to close the loophole. > > All feedback is appreciated. > > Thank you > > -Alison Wood > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 3 > Date: Thu, 17 Aug 2017 18:00:05 -0400 (EDT) > From: hostmaster at uneedus.com > To: "arin-ppml at arin.net " > > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 and > IPv6 > Message-ID: > Content-Type: text/plain; charset="x-unknown"; Format="flowed" > > While the most recent drafts have not dealt with IPv4, in the last round > there was a proposal to require registration upon request of the > downstream customer of their IPv6 assignment. > > If we intend to provide that power to require registration for IPv6 > customer assignments upon request, in fairness we should also use the same > language in a new 4.2.3.7.4 to allow static IPv4 customers that same > power. I suggest /32 as the limit, as /29 or more already has required > registration. The same problems identfied in not being able to register > assignments with ARIN for v6 are also true for v4 assignments between > those limits. > > Since both protocols are still being addressed and attempts are being > made by the draft to make v6 equal or better than v4, the title should > remain. The only thing we have done is not shift the v4 limit of /29. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > > While we???re turning the crank, can we please fix the title since IPv4 > > is no longer relevant to the proposal and there???s really no > > equalization happening? > > > > Perhaps ???Improved Registration Requirements for IPv6??? > > > > Owen > > ------------------------------ > > Message: 4 > Date: Thu, 17 Aug 2017 17:01:09 -0500 > From: David Farmer > > To: Leif Sawyer > > Cc: "hostmaster at uneedus.com " >, > "arin-ppml at arin.net " > > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 and > IPv6 > Message-ID: > > > Content-Type: text/plain; charset="utf-8" > > On Thu, Aug 17, 2017 at 1:43 PM, David Farmer > wrote: > > > Inline. > > > > On Thu, Aug 17, 2017 at 12:29 PM, Leif Sawyer > wrote: > > > >> Thanks for the feedback, David. > >> > > ... > > > I'm not sure what the point of 6.5.5.5 is - you're just reiterating > >> 6.5.5.1. > >> That said, we could potentially clean up 6.5.5.1 by extending "static > >> IPv6 assignment" > >> to "static IPv6 assignment, or allocation," - or something similar. > >> > > > > ISP re-allocations need to be registered regardless of size or if it is > > being advertised or not. For example, if for some stupid reason a /56 was > > re-allocated to downsterm ISP so they could assign /64s to customers that > > has to be registered, by 6.5.5.1 that wouldn't have to be registered. > > Should you re-allocate a /56, @!@#$ NO!!! But if you did, it has to be > > registered. This is so LEA and other legal requests get directly to the > > correct ISP the first time. I think this is important enough issue that it > > should have it's own section, and not get blended in to 6.5.5.1. > > > > Now should that be part of this policy maybe not, maybe this belongs in > > ARIN-2017-3 or whole new separate policy proposal instead. > > > > Thinking about this for the last couple hours I'm thinking 6.5.5.5 this > should not be part of this policy. As similar text should be added in the > IPv4 section, and this should have a somewhat different problem statement > as well. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > 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 > =============================================== > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > ------------------------------ > > End of ARIN-PPML Digest, Vol 146, Issue 10 > ****************************************** > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Wed Aug 23 09:15:26 2017 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Wed, 23 Aug 2017 10:15:26 -0300 Subject: [arin-ppml] ARIN-PPML 2017-6 draft policy In-Reply-To: <84C695FE-80CE-44C1-A608-6FC459125827@delong.com> References: <84C695FE-80CE-44C1-A608-6FC459125827@delong.com> Message-ID: Thank you Owen, and I remember those exact words when the policy was formulated and I accept that too. Of course, the community did not, at that time see the loop hole we are currently trying to close. So I was being cautious in that whilst we can modify the wording, to achieve a close, is arin staff also confident that it can be implemented. Of course I also appreciate that what ever we as a community do, there is always some out there looking or searching for yet another loop hole. rd Rudi Daniel *danielcharles consulting * On Tue, Aug 22, 2017 at 6:15 PM, Owen DeLong wrote: > It is achievable because ARIN will evaluate the policy of each RIR in this > regard prior to approving the transfer. > > Owen > > On Aug 18, 2017, at 12:36 , Rudolph Daniel wrote: > > " Recipient RIR policy must not permit transfers to other RIRs or NIRs > whose policies do not support bi-directional transfers." > > Whereas I am in support of closing this loophole, I cannot be sure that > this is actually achievable... > rd > > On Aug 17, 2017 6:01 PM, wrote: > >> Send ARIN-PPML mailing list submissions to >> arin-ppml at arin.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.arin.net/mailman/listinfo/arin-ppml >> or, via email, send a message with subject or body 'help' to >> arin-ppml-request at arin.net >> >> You can reach the person managing the list at >> arin-ppml-owner at arin.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of ARIN-PPML digest..." >> >> >> Today's Topics: >> >> 1. Re: Revised: Draft Policy ARIN-2017-5: Equalization of >> Assignment Registration requirements between IPv4 and IPv6 >> (Paul McNary) >> 2. Draft Policy 2017-6: Improve Reciprocity Requirements for >> Inter RIR Transfers (WOOD Alison * DAS) >> 3. Re: Revised: Draft Policy ARIN-2017-5: Equalization of >> Assignment Registration requirements between IPv4 and IPv6 >> (hostmaster at uneedus.com) >> 4. Re: Revised: Draft Policy ARIN-2017-5: Equalization of >> Assignment Registration requirements between IPv4 and IPv6 >> (David Farmer) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 17 Aug 2017 15:49:47 -0500 >> From: Paul McNary >> To: "arin-ppml at arin.net" >> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: >> Equalization of Assignment Registration requirements between IPv4 >> and >> IPv6 >> Message-ID: <7460ee99-c116-7c0a-b726-2267de135596 at cameron.net> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> Sorry I typed the numbers backwards, yes, that is what I meant. :-) >> >> A /48 is smaller than a /47 and would not be required to be registered? >> A /47 would need to be >> >> >> On 8/17/2017 1:30 PM, Chris Woodfield wrote: >> > The opposite - a /47 is 2 /48s aggregated. >> > >> > -C >> > >> >> On Aug 17, 2017, at 11:26 AM, Paul McNary wrote: >> >> >> >> A /47 is smaller than a /48 and would not be required to be registered? >> >> >> >> >> >> On 8/17/2017 12:50 PM, hostmaster at uneedus.com wrote: >> >>> I note that any ISP size reassignment, with the recommended /48 for >> each end user site, will be /47 or larger, which must always be registered. >> >>> >> >>> Thus, I think 6.5.5.5 language is unneeded, since any LIR/ISP >> reassignment will be large enough to already trigger registration. >> >>> >> >>> Under the current policy, LIR's and ISP's are equal, so usually both >> terms are stated in any policy that mentions them. >> >>> >> >>> May I also suggest that if we are going to require registration upon >> downstream request for IPv6, that we consider placing the same language and >> requirements for IPv4 customers as well? And if we do, where do we draw >> the minimum line? Maybe a /32.... >> >>> >> >>> Also, good catch on the cut and paste error..... >> >>> >> >>> Albert Erdmann >> >>> Network Administrator >> >>> Paradise On Line Inc. >> >>> >> >>> >> >>> On Thu, 17 Aug 2017, Leif Sawyer wrote: >> >>> >> >>>> Thanks for the feedback, David. >> >>>> >> >>>> I've added the fix for 6.5.5.2, since we're already in the section. >> >>>> >> >>>> I've also modified the text for 6.5.5.4 as well, because I think >> your suggesting is a little cleaner. >> >>>> >> >>>> I'm not sure what the point of 6.5.5.5 is - you're just reiterating >> 6.5.5.1. >> >>>> That said, we could potentially clean up 6.5.5.1 by extending >> "static IPv6 assignment" >> >>>> to "static IPv6 assignment, or allocation," - or something similar. >> >>>> >> >>>> >> >>>> Which also brings to mind the question: LIR or ISP? Both are in >> use in 6.5.... >> >>>> >> >>>> ________________________________ >> >>>> From: ARIN-PPML [arin-ppml-bounces at arin.net] on behalf of David >> Farmer [farmer at umn.edu] >> >>>> Sent: Thursday, August 17, 2017 8:53 AM >> >>>> To: hostmaster at uneedus.com >> >>>> Cc: arin-ppml at arin.net >> >>>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: >> Equalization of Assignment Registration requirements between IPv4 and IPv6 >> >>>> >> >>>> [External Email] >> >>>> >> >>>> Here is a slightly different formulation to consider. I refactored >> the title a little, and based the phrasing on other parts of section 6.5.5 >> >>>> >> >>>> 6.5.5.4 Registration Requested by Recipient >> >>>> >> >>>> If requested by the downstream recipient of a block, each static >> IPv6 assignment containing a /64 or more addresses, shall be registered, as >> described in section 6.5.5.1. >> >>>> >> >>>> I'd like us to think about adding an additional section, based on >> previous discussions. >> >>>> >> >>>> 6.5.5.5 Re-allocation to ISPs >> >>>> >> >>>> Each IPv6 re-allocation to a downstream ISP, regardless of size, >> intended for further assignment by the downstream ISP's to it's customers, >> shall be registered, as described in section 6.5.5.1 >> >>>> >> >>>> Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. >> I think this is a cut and past error, I think the reference should be to >> 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with sections >> 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. >> >>>> >> >>>> Thanks. >> >>>> >> >>>> On Wed, Aug 16, 2017 at 6:10 AM, > hostmaster at uneedus.com>> wrote: >> >>>> I am in favor of the draft, with or without the changes to make it >> clearer. >> >>>> >> >>>> I suggest the following language for clarity: >> >>>> >> >>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the >> NRPM that reads "If the downstream recipient of a static assignment of /64 >> or more addresses requests publishing of that static assignment in ARIN's >> registration database, the ISP must register that static assignment." >> >>>> >> >>>> Since "static assignment" is the term in this section, not netblock, >> I suggest using this term instead of "netblock". "Of any size" is not >> needed, as the language would require the ISP to register in total whatever >> size the ISP has assigned to the downstream in the ARIN database if >> requested by the downstream recipient, as long as it was /64 or more. >> >>>> >> >>>> This language would also prevent requests to register only part of >> an assignment. I think this language works in making the intent of the new >> section more clear. >> >>>> >> >>>> Albert Erdmann >> >>>> Network Administrator >> >>>> Paradise On Line Inc. >> >>>> >> >>>> >> >>>> >> >>>> On Tue, 15 Aug 2017, John Santos wrote: >> >>>> >> >>>> I think that the "/64 or more addresses" and the "regardless of >> size" are meant to convey that any netblock between a /64 and a /48 can and >> should be registered if the recipient requests it, even if the block is >> smaller than the /47 which would make it mandatory. Perhaps there is >> better wording that would make this clearer. >> >>>> >> >>>> Three ranges: >> >>>> >> >>>> 1. smaller than /64: shouldn't be issued, can't be registered. >> >>>> 2. /64 through /48: register at recipient's request >> >>>> 3. /47 or larger: must be registered >> >>>> >> >>>> I agree on dynamic assignments >> >>>> >> >>>> Otherwise, I think this is a much clearer and better update to the >> proposed policy, and can't find any other reason not to support it. (I.E. >> this is a tentative vote FOR, if there is such a thing.) >> >>>> >> >>>> >> >>>> >> >>>> On 8/15/2017 3:59 PM, David Farmer wrote: >> >>>> I support what I think is the intent, but I have language/editorial >> nits; >> >>>> >> >>>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless >> of size" that requires registration? I think logically we need one or the >> other, or some qualification on "regardless of size" statement. I think it >> is a good idea to not require registration of less than a /64. But the >> current language seems contradictory, and therefore confusing, my >> recommendation is delete "regardless of size", from the sentence and >> leaving "a /64 or more addresses". I pretty sure we don't want people >> having an expectation that they can request the registration of "their" >> /128 address. >> >>>> >> >>>> 2. Also in 3) below; It would seem to require even dynamic >> assignments be registered if requested, I don't think that is our intent >> either, section 6.5.5.1 starts with "Each static IPv6 assignment >> containing", this needs a similar qualification. >> >>>> >> >>>> Also, I'm fine with the deltas in the policy statement but it would >> be helpful to see the final resulting policy block, maybe in a separate >> email so we can all see how the result reads. >> >>>> >> >>>> Thanks, I think we are getting close, maybe one or two more turns of >> the crank. >> >>>> >> >>>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN > info at arin.net> >> wrote: >> >>>> >> >>>> The following has been revised: >> >>>> >> >>>> * Draft Policy ARIN-2017-5: Equalization of Assignment >> >>>> Registration requirements between IPv4 and IPv6 >> >>>> >> >>>> Revised text is below and can be found at: >> >>>> https://www.arin.net/policy/proposals/2017_5.html> w.arin.net/policy/proposals/2017_5.html> >> >>>> > ww.arin.net/policy/proposals/2017_5.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> licy/pdp.html> >> >>>> > olicy/pdp.html>> >> >>>> >> >>>> Draft Policies and Proposals under discussion can be found at: >> >>>> https://www.arin.net/policy/proposals/index.html> .arin.net/policy/proposals/index.html> >> >>>> > w.arin.net/policy/proposals/index.html>> >> >>>> >> >>>> Regards, >> >>>> >> >>>> Sean Hopkins >> >>>> Policy Analyst >> >>>> American Registry for Internet Numbers (ARIN) >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> 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 subdelegation 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" >> >>>> >> >>>> and >> >>>> >> >>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to >> >>>> the NRPM that reads "If the downstream recipient of a netblock ( a >> >>>> /64 or more addresses) requests publishing in ARIN's registration >> >>>> database, the ISP must register the netblock, regardless of size." >> >>>> >> >>>> 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. >> >>>> >> >>>> -- >> >>>> John Santos >> >>>> Evans Griffiths & Hart, Inc. >> >>>> 781-861-0670 ext 539 <(781)%20861-0670>> 39> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> PPML >> >>>> You are receiving this message because you are subscribed to >> >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net> N-PPML at arin.net>). >> >>>> Unsubscribe or manage your mailing list subscription at: >> >>>> http://lists.arin.net/mailman/listinfo/arin-ppml> s.arin.net/mailman/listinfo/arin-ppml> >> >>>> Please contact info at arin.net if you >> experience any issues. >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> =============================================== >> >>>> David Farmer Email:farmer at umn.edu >> >>>> 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 (ARIN-PPML at arin.net). >> >>> Unsubscribe or manage your mailing list subscription at: >> >>> http://lists.arin.net/mailman/listinfo/arin-ppml >> >>> Please contact info at 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 at arin.net). >> >> Unsubscribe or manage your mailing list subscription at: >> >> http://lists.arin.net/mailman/listinfo/arin-ppml >> >> Please contact info at arin.net if you experience any issues. >> >> >> > >> > >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Thu, 17 Aug 2017 20:54:23 +0000 >> From: WOOD Alison * DAS >> To: "arin-ppml at arin.net" >> Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity >> Requirements for Inter RIR Transfers >> Message-ID: >> > S.OR.GOV> >> Content-Type: text/plain; charset="us-ascii" >> >> Thank you for the feedback on this draft policy to date. I would >> appreciate any other thoughts or comments on this draft policy. >> >> For review, Draft Policy 2017-6 is intended to add the following >> conditions on Inter RIR transfers to section 8.4: >> >> Recipient RIR policy must not permit transfers to other RIRs or NIRs >> whose policies do not support bi-directional transfers. >> >> And the problem statement on this draft policy is: >> >> Currently ARIN's requirement that inter-RIR transfer policies be >> reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a >> two-hop RIR transfer process can be used to circumvent the intent of the >> requirement. Rather than eliminate the requirement, a better approach would >> be to close the loophole. >> >> All feedback is appreciated. >> >> Thank you >> >> -Alison Wood >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: > 20170817/22d7858b/attachment-0001.html> >> >> ------------------------------ >> >> Message: 3 >> Date: Thu, 17 Aug 2017 18:00:05 -0400 (EDT) >> From: hostmaster at uneedus.com >> To: "arin-ppml at arin.net" >> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: >> Equalization of Assignment Registration requirements between IPv4 >> and >> IPv6 >> Message-ID: >> Content-Type: text/plain; charset="x-unknown"; Format="flowed" >> >> While the most recent drafts have not dealt with IPv4, in the last round >> there was a proposal to require registration upon request of the >> downstream customer of their IPv6 assignment. >> >> If we intend to provide that power to require registration for IPv6 >> customer assignments upon request, in fairness we should also use the same >> language in a new 4.2.3.7.4 to allow static IPv4 customers that same >> power. I suggest /32 as the limit, as /29 or more already has required >> registration. The same problems identfied in not being able to register >> assignments with ARIN for v6 are also true for v4 assignments between >> those limits. >> >> Since both protocols are still being addressed and attempts are being >> made by the draft to make v6 equal or better than v4, the title should >> remain. The only thing we have done is not shift the v4 limit of /29. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> > While we???re turning the crank, can we please fix the title since IPv4 >> > is no longer relevant to the proposal and there???s really no >> > equalization happening? >> > >> > Perhaps ???Improved Registration Requirements for IPv6??? >> > >> > Owen >> >> ------------------------------ >> >> Message: 4 >> Date: Thu, 17 Aug 2017 17:01:09 -0500 >> From: David Farmer >> To: Leif Sawyer >> Cc: "hostmaster at uneedus.com" , >> "arin-ppml at arin.net" >> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: >> Equalization of Assignment Registration requirements between IPv4 >> and >> IPv6 >> Message-ID: >> > gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> On Thu, Aug 17, 2017 at 1:43 PM, David Farmer wrote: >> >> > Inline. >> > >> > On Thu, Aug 17, 2017 at 12:29 PM, Leif Sawyer wrote: >> > >> >> Thanks for the feedback, David. >> >> >> > ... >> >> > I'm not sure what the point of 6.5.5.5 is - you're just reiterating >> >> 6.5.5.1. >> >> That said, we could potentially clean up 6.5.5.1 by extending "static >> >> IPv6 assignment" >> >> to "static IPv6 assignment, or allocation," - or something similar. >> >> >> > >> > ISP re-allocations need to be registered regardless of size or if it is >> > being advertised or not. For example, if for some stupid reason a /56 >> was >> > re-allocated to downsterm ISP so they could assign /64s to customers >> that >> > has to be registered, by 6.5.5.1 that wouldn't have to be registered. >> > Should you re-allocate a /56, @!@#$ NO!!! But if you did, it has to be >> > registered. This is so LEA and other legal requests get directly to the >> > correct ISP the first time. I think this is important enough issue >> that it >> > should have it's own section, and not get blended in to 6.5.5.1. >> > >> > Now should that be part of this policy maybe not, maybe this belongs in >> > ARIN-2017-3 or whole new separate policy proposal instead. >> > >> >> Thinking about this for the last couple hours I'm thinking 6.5.5.5 this >> should not be part of this policy. As similar text should be added in the >> IPv4 section, and this should have a somewhat different problem statement >> as well. >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> 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 >> =============================================== >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: > 20170817/7e7a2fcd/attachment.html> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> ARIN-PPML mailing list >> ARIN-PPML at arin.net >> http://lists.arin.net/mailman/listinfo/arin-ppml >> >> ------------------------------ >> >> End of ARIN-PPML Digest, Vol 146, Issue 10 >> ****************************************** >> > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Wed Aug 23 10:02:31 2017 From: mike at iptrading.com (Mike Burns) Date: Wed, 23 Aug 2017 10:02:31 -0400 Subject: [arin-ppml] ARIN-PPML 2017-6 draft policy In-Reply-To: References: <84C695FE-80CE-44C1-A608-6FC459125827@delong.com> Message-ID: <000801d31c18$766527d0$632f7770$@iptrading.com> I oppose this policy, although I do understand and agree with the gut feeling expressed in this thread. For many reasons, a free and global market in IPv4 addresses, which mirrors the goal of a free and global delivery of packets, is what I think would be best. And this requires trade in all directions. However, let us not throw out the baby with the bathwater. Let?s unpack that gut feeling. I think the gut could be reacting in two ways. First, there is a ?balance of trade? argument, which rejects one-way trade barriers as something to be fought against. Why let our valuable commodities flow only outwards towards the world? Second, there is the fairness issue. We all have a sense of fairness and on the face of it, this is patently unfair. For the first argument, let me say that we have North American address owners seeking to sell, and this proposal artificially limits their ability to do that. Is it proper, and our role, to punish these North American entities? Is the correct answer to limited trade even more limited trade? And what of that trade imbalance, wouldn?t this proposal exacerbate that imbalance by precluding the sale of North American assets to swaths of the world? For the second argument, fairness, let us regard the fairness of ipv4 distribution around the world. I know the gut feeling of some in Latin America or Asia or Africa regarding this issue of fairness would have a different expression, when they see that every North American citizen got 5 addresses and every one of them got to share a single ipv4 address with 1000 of their neighbors. Yes, for some countries the ratio is 5000:1 in our favor. http://www.nationmaster.com/country-info/stats/Media/Internet/IP-addresses-per-capita RIPE, the registry which I consider most advanced in terms of IPv4 market policies, and the registry which processes the largest number of transfers, has already agreed to send addresses via a one-way policy to other RIRs. LACNIC and AFRINIC have discussed one-way policies, and I think it is easy to understand, from their perspectives, the fear of allowing already scarce addresses to leave those regions. I have heard the fear that this would provide incentive for networks in their region to convert to CGN in order to sell their resources to the wealthy nations who already enjoy many addresses. But the bottom line is that address flow is a result of market forces and not policy. When the supply is in one region and the demand in another, forces act as one would expect to move addresses. But when registry stewards stand athwart that flow and say ?Stop! Our regard for fairness is outraged!? then, like water finds its level, addresses will find their way to those in need. The net result is things like zombie corporations changing hands, leases which are invisible to Whois, artificial pricing imbalances, and overall unpleasantness. Let?s accept one-way transfers as a recognition of the reality of the historical artifact of address allocation, and as a step in the direction of a true global market, albeit a half-step. This proposal, on the other hand, is a step backwards. Those one-way regions are not suppliers of addresses to the market, so requiring outbound transfers from them will have no effect. On the other hand, denying needed addresses to these address-poor regions will affect them direly. Regards, Mike Burns From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Rudolph Daniel Sent: Wednesday, August 23, 2017 9:15 AM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-PPML 2017-6 draft policy Thank you Owen, and I remember those exact words when the policy was formulated and I accept that too. Of course, the community did not, at that time see the loop hole we are currently trying to close. So I was being cautious in that whilst we can modify the wording, to achieve a close, is arin staff also confident that it can be implemented. Of course I also appreciate that what ever we as a community do, there is always some out there looking or searching for yet another loop hole. rd Rudi Daniel danielcharles consulting On Tue, Aug 22, 2017 at 6:15 PM, Owen DeLong > wrote: It is achievable because ARIN will evaluate the policy of each RIR in this regard prior to approving the transfer. Owen On Aug 18, 2017, at 12:36 , Rudolph Daniel > wrote: " Recipient RIR policy must not permit transfers to other RIRs or NIRs whose policies do not support bi-directional transfers." Whereas I am in support of closing this loophole, I cannot be sure that this is actually achievable... rd On Aug 17, 2017 6:01 PM, > wrote: Send ARIN-PPML mailing list submissions to arin-ppml at arin.net To subscribe or unsubscribe via the World Wide Web, visit http://lists.arin.net/mailman/listinfo/arin-ppml or, via email, send a message with subject or body 'help' to arin-ppml-request at arin.net You can reach the person managing the list at arin-ppml-owner at arin.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ARIN-PPML digest..." Today's Topics: 1. Re: Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 (Paul McNary) 2. Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers (WOOD Alison * DAS) 3. Re: Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 (hostmaster at uneedus.com ) 4. Re: Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 (David Farmer) ---------------------------------------------------------------------- Message: 1 Date: Thu, 17 Aug 2017 15:49:47 -0500 From: Paul McNary > To: "arin-ppml at arin.net " > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Message-ID: <7460ee99-c116-7c0a-b726-2267de135596 at cameron.net > Content-Type: text/plain; charset=utf-8; format=flowed Sorry I typed the numbers backwards, yes, that is what I meant. :-) A /48 is smaller than a /47 and would not be required to be registered? A /47 would need to be On 8/17/2017 1:30 PM, Chris Woodfield wrote: > The opposite - a /47 is 2 /48s aggregated. > > -C > >> On Aug 17, 2017, at 11:26 AM, Paul McNary > wrote: >> >> A /47 is smaller than a /48 and would not be required to be registered? >> >> >> On 8/17/2017 12:50 PM, hostmaster at uneedus.com wrote: >>> I note that any ISP size reassignment, with the recommended /48 for each end user site, will be /47 or larger, which must always be registered. >>> >>> Thus, I think 6.5.5.5 language is unneeded, since any LIR/ISP reassignment will be large enough to already trigger registration. >>> >>> Under the current policy, LIR's and ISP's are equal, so usually both terms are stated in any policy that mentions them. >>> >>> May I also suggest that if we are going to require registration upon downstream request for IPv6, that we consider placing the same language and requirements for IPv4 customers as well? And if we do, where do we draw the minimum line? Maybe a /32.... >>> >>> Also, good catch on the cut and paste error..... >>> >>> Albert Erdmann >>> Network Administrator >>> Paradise On Line Inc. >>> >>> >>> On Thu, 17 Aug 2017, Leif Sawyer wrote: >>> >>>> Thanks for the feedback, David. >>>> >>>> I've added the fix for 6.5.5.2, since we're already in the section. >>>> >>>> I've also modified the text for 6.5.5.4 as well, because I think your suggesting is a little cleaner. >>>> >>>> I'm not sure what the point of 6.5.5.5 is - you're just reiterating 6.5.5.1. >>>> That said, we could potentially clean up 6.5.5.1 by extending "static IPv6 assignment" >>>> to "static IPv6 assignment, or allocation," - or something similar. >>>> >>>> >>>> Which also brings to mind the question: LIR or ISP? Both are in use in 6.5.... >>>> >>>> ________________________________ >>>> From: ARIN-PPML [arin-ppml-bounces at arin.net ] on behalf of David Farmer [farmer at umn.edu ] >>>> Sent: Thursday, August 17, 2017 8:53 AM >>>> To: hostmaster at uneedus.com >>>> Cc: arin-ppml at arin.net >>>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 >>>> >>>> [External Email] >>>> >>>> Here is a slightly different formulation to consider. I refactored the title a little, and based the phrasing on other parts of section 6.5.5 >>>> >>>> 6.5.5.4 Registration Requested by Recipient >>>> >>>> If requested by the downstream recipient of a block, each static IPv6 assignment containing a /64 or more addresses, shall be registered, as described in section 6.5.5.1. >>>> >>>> I'd like us to think about adding an additional section, based on previous discussions. >>>> >>>> 6.5.5.5 Re-allocation to ISPs >>>> >>>> Each IPv6 re-allocation to a downstream ISP, regardless of size, intended for further assignment by the downstream ISP's to it's customers, shall be registered, as described in section 6.5.5.1 >>>> >>>> Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. I think this is a cut and past error, I think the reference should be to 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with sections 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. >>>> >>>> Thanks. >>>> >>>> On Wed, Aug 16, 2017 at 6:10 AM, >> wrote: >>>> I am in favor of the draft, with or without the changes to make it clearer. >>>> >>>> I suggest the following language for clarity: >>>> >>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM that reads "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that static assignment in ARIN's registration database, the ISP must register that static assignment." >>>> >>>> Since "static assignment" is the term in this section, not netblock, I suggest using this term instead of "netblock". "Of any size" is not needed, as the language would require the ISP to register in total whatever size the ISP has assigned to the downstream in the ARIN database if requested by the downstream recipient, as long as it was /64 or more. >>>> >>>> This language would also prevent requests to register only part of an assignment. I think this language works in making the intent of the new section more clear. >>>> >>>> Albert Erdmann >>>> Network Administrator >>>> Paradise On Line Inc. >>>> >>>> >>>> >>>> On Tue, 15 Aug 2017, John Santos wrote: >>>> >>>> I think that the "/64 or more addresses" and the "regardless of size" are meant to convey that any netblock between a /64 and a /48 can and should be registered if the recipient requests it, even if the block is smaller than the /47 which would make it mandatory. Perhaps there is better wording that would make this clearer. >>>> >>>> Three ranges: >>>> >>>> 1. smaller than /64: shouldn't be issued, can't be registered. >>>> 2. /64 through /48: register at recipient's request >>>> 3. /47 or larger: must be registered >>>> >>>> I agree on dynamic assignments >>>> >>>> Otherwise, I think this is a much clearer and better update to the proposed policy, and can't find any other reason not to support it. (I.E. this is a tentative vote FOR, if there is such a thing.) >>>> >>>> >>>> >>>> On 8/15/2017 3:59 PM, David Farmer wrote: >>>> I support what I think is the intent, but I have language/editorial nits; >>>> >>>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of size" that requires registration? I think logically we need one or the other, or some qualification on "regardless of size" statement. I think it is a good idea to not require registration of less than a /64. But the current language seems contradictory, and therefore confusing, my recommendation is delete "regardless of size", from the sentence and leaving "a /64 or more addresses". I pretty sure we don't want people having an expectation that they can request the registration of "their" /128 address. >>>> >>>> 2. Also in 3) below; It would seem to require even dynamic assignments be registered if requested, I don't think that is our intent either, section 6.5.5.1 starts with "Each static IPv6 assignment containing", this needs a similar qualification. >>>> >>>> Also, I'm fine with the deltas in the policy statement but it would be helpful to see the final resulting policy block, maybe in a separate email so we can all see how the result reads. >>>> >>>> Thanks, I think we are getting close, maybe one or two more turns of the crank. >>>> >>>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN > >>> wrote: >>>> >>>> The following has been revised: >>>> >>>> * Draft Policy ARIN-2017-5: Equalization of Assignment >>>> Registration requirements between IPv4 and IPv6 >>>> >>>> Revised text is below and can be found at: >>>> https://www.arin.net/policy/proposals/2017_5.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 >>>> > >>>> >>>> Draft Policies and Proposals under discussion can be found at: >>>> https://www.arin.net/policy/proposals/index.html >>>> > >>>> >>>> Regards, >>>> >>>> Sean Hopkins >>>> Policy Analyst >>>> American Registry for Internet Numbers (ARIN) >>>> >>>> >>>> >>>> >>>> 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 subdelegation 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" >>>> >>>> and >>>> >>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to >>>> the NRPM that reads "If the downstream recipient of a netblock ( a >>>> /64 or more addresses) requests publishing in ARIN's registration >>>> database, the ISP must register the netblock, regardless of size." >>>> >>>> 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. >>>> >>>> -- >>>> John Santos >>>> Evans Griffiths & Hart, Inc. >>>> 781-861-0670 ext 539 20539> >>>> >>>> >>>> _______________________________________________ >>>> 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: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net > if you experience any issues. >>>> >>>> >>>> >>>> -- >>>> =============================================== >>>> David Farmer Email:farmer at umn.edu > >>>> 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 (ARIN-PPML at arin.net ). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at 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 at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > ------------------------------ Message: 2 Date: Thu, 17 Aug 2017 20:54:23 +0000 From: WOOD Alison * DAS > To: "arin-ppml at arin.net " > Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers Message-ID: > Content-Type: text/plain; charset="us-ascii" Thank you for the feedback on this draft policy to date. I would appreciate any other thoughts or comments on this draft policy. For review, Draft Policy 2017-6 is intended to add the following conditions on Inter RIR transfers to section 8.4: Recipient RIR policy must not permit transfers to other RIRs or NIRs whose policies do not support bi-directional transfers. And the problem statement on this draft policy is: Currently ARIN's requirement that inter-RIR transfer policies be reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a two-hop RIR transfer process can be used to circumvent the intent of the requirement. Rather than eliminate the requirement, a better approach would be to close the loophole. All feedback is appreciated. Thank you -Alison Wood -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Thu, 17 Aug 2017 18:00:05 -0400 (EDT) From: hostmaster at uneedus.com To: "arin-ppml at arin.net " > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Message-ID: > Content-Type: text/plain; charset="x-unknown"; Format="flowed" While the most recent drafts have not dealt with IPv4, in the last round there was a proposal to require registration upon request of the downstream customer of their IPv6 assignment. If we intend to provide that power to require registration for IPv6 customer assignments upon request, in fairness we should also use the same language in a new 4.2.3.7.4 to allow static IPv4 customers that same power. I suggest /32 as the limit, as /29 or more already has required registration. The same problems identfied in not being able to register assignments with ARIN for v6 are also true for v4 assignments between those limits. Since both protocols are still being addressed and attempts are being made by the draft to make v6 equal or better than v4, the title should remain. The only thing we have done is not shift the v4 limit of /29. Albert Erdmann Network Administrator Paradise On Line Inc. > While we???re turning the crank, can we please fix the title since IPv4 > is no longer relevant to the proposal and there???s really no > equalization happening? > > Perhaps ???Improved Registration Requirements for IPv6??? > > Owen ------------------------------ Message: 4 Date: Thu, 17 Aug 2017 17:01:09 -0500 From: David Farmer > To: Leif Sawyer > Cc: "hostmaster at uneedus.com " >, "arin-ppml at arin.net " > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Message-ID: > Content-Type: text/plain; charset="utf-8" On Thu, Aug 17, 2017 at 1:43 PM, David Farmer > wrote: > Inline. > > On Thu, Aug 17, 2017 at 12:29 PM, Leif Sawyer > wrote: > >> Thanks for the feedback, David. >> > ... > I'm not sure what the point of 6.5.5.5 is - you're just reiterating >> 6.5.5.1. >> That said, we could potentially clean up 6.5.5.1 by extending "static >> IPv6 assignment" >> to "static IPv6 assignment, or allocation," - or something similar. >> > > ISP re-allocations need to be registered regardless of size or if it is > being advertised or not. For example, if for some stupid reason a /56 was > re-allocated to downsterm ISP so they could assign /64s to customers that > has to be registered, by 6.5.5.1 that wouldn't have to be registered. > Should you re-allocate a /56, @!@#$ NO!!! But if you did, it has to be > registered. This is so LEA and other legal requests get directly to the > correct ISP the first time. I think this is important enough issue that it > should have it's own section, and not get blended in to 6.5.5.1. > > Now should that be part of this policy maybe not, maybe this belongs in > ARIN-2017-3 or whole new separate policy proposal instead. > Thinking about this for the last couple hours I'm thinking 6.5.5.5 this should not be part of this policy. As similar text should be added in the IPv4 section, and this should have a somewhat different problem statement as well. -- =============================================== David Farmer Email:farmer at umn.edu 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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml ------------------------------ End of ARIN-PPML Digest, Vol 146, Issue 10 ****************************************** _______________________________________________ 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From calderon.alfredo at gmail.com Wed Aug 23 12:46:51 2017 From: calderon.alfredo at gmail.com (Alfredo Calderon) Date: Wed, 23 Aug 2017 12:46:51 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of Community Network In-Reply-To: <28d7e4fc-532c-209f-039a-57c1d88cea20@arin.net> References: <28d7e4fc-532c-209f-039a-57c1d88cea20@arin.net> Message-ID: I support the New NRPM TEXT proposed for Community Network. [image: photo] *Alfredo Calderon* eLearning Consultant calderon.alfredo at gmail.com | http://aprendizajedistancia.blogspot.com | Skype: Alfredo_1212 <#> | wiseintro.co/alfredocalderon Get your own email signature On Tue, Aug 22, 2017 at 12:39 PM, ARIN wrote: > On 17 August 2017 the ARIN Advisory Council (AC) advanced "ARIN-prop-243: > Amend the Definition of Community Network" to Draft Policy status. > > Draft Policy ARIN-2017-8 is below and can be found at: > https://www.arin.net/policy/proposals/2017_8.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 > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-8: Amend the Definition of Community Network > > Problem Statement: > > The Community Networks section of the NRPM has not been used since > implementation in January 2010. Proposal ARIN-2016-7, to increase the > number of use cases, was abandoned by the Advisory Council due to lack of > feedback. Proposal ARIN 2017-2, to remove all mention of community networks > from NRPM was met with opposition by the community. Many responded that the > definition of ?community network? was too narrow, which could be the reason > for lack of uptake. > > Policy statement: > > CURRENT NRPM TEXT: > > ?2.11. Community Network > > A community network is any network organized and operated by a volunteer > group operating as or under the fiscal support of a nonprofit organization > or university for the purpose of providing free or low-cost connectivity to > the residents of their local service area. To be treated as a community > network under ARIN policy, the applicant must certify to ARIN that the > community network staff is 100% volunteers.? > > NEW NRPM TEXT: > > ?2.11 Community Network > > A community network is a network organized and operated by a volunteer > group, not-for-profit, non-profit, charitable organization, or > post-secondary institution for the purpose of providing free or low-cost > connectivity to residents in their service area. Critical functions may be > handled by paid staff, but volunteers play a large role in offering > services available through community networks.? > > Comments: > > Timetable for implementation: Immediate > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmahoney at dataonenetworks.biz Wed Aug 23 13:23:54 2017 From: dmahoney at dataonenetworks.biz (dmahoney at dataonenetworks.biz) Date: Wed, 23 Aug 2017 13:23:54 -0400 Subject: [arin-ppml] ARIN-PPML 2017-6 draft policy In-Reply-To: <000801d31c18$766527d0$632f7770$@iptrading.com> References: <84C695FE-80CE-44C1-A608-6FC459125827@delong.com> <000801d31c18$766527d0$632f7770$@iptrading.com> Message-ID: I agree with Mike's opposition to this policy as well based on his reasoning. Regards, Don Mahoney On 8/23/17 10:02 AM, Mike Burns wrote: > I oppose this policy, although I do understand and agree with the gut feeling expressed in this thread. For many reasons, a free and global market in IPv4 addresses, which mirrors the goal of a free and global delivery of packets, is what I think would be best. And this requires trade in all directions. > > > > However, let us not throw out the baby with the bathwater. > > Let?s unpack that gut feeling. I think the gut could be reacting in two ways. First, there is a ?balance of trade? argument, which rejects one-way trade barriers as something to be fought against. Why let our valuable commodities flow only outwards towards the world? > > > > Second, there is the fairness issue. We all have a sense of fairness and on the face of it, this is patently unfair. > > > > For the first argument, let me say that we have North American address owners seeking to sell, and this proposal artificially limits their ability to do that. Is it proper, and our role, to punish these North American entities? Is the correct answer to limited trade even more limited trade? And what of that trade imbalance, wouldn?t this proposal exacerbate that imbalance by precluding the sale of North American assets to swaths of the world? > > > > For the second argument, fairness, let us regard the fairness of ipv4 distribution around the world. I know the gut feeling of some in Latin America or Asia or Africa regarding this issue of fairness would have a different expression, when they see that every North American citizen got 5 addresses and every one of them got to share a single ipv4 address with 1000 of their neighbors. Yes, for some countries the ratio is 5000:1 in our favor. > > http://www.nationmaster.com/country-info/stats/Media/Internet/IP-addresses-per-capita > > > > RIPE, the registry which I consider most advanced in terms of IPv4 market policies, and the registry which processes the largest number of transfers, has already agreed to send addresses via a one-way policy to other RIRs. > > > > LACNIC and AFRINIC have discussed one-way policies, and I think it is easy to understand, from their perspectives, the fear of allowing already scarce addresses to leave those regions. I have heard the fear that this would provide incentive for networks in their region to convert to CGN in order to sell their resources to the wealthy nations who already enjoy many addresses. > > > > But the bottom line is that address flow is a result of market forces and not policy. When the supply is in one region and the demand in another, forces act as one would expect to move addresses. But when registry stewards stand athwart that flow and say ?Stop! Our regard for fairness is outraged!? then, like water finds its level, addresses will find their way to those in need. The net result is things like zombie corporations changing hands, leases which are invisible to Whois, artificial pricing imbalances, and overall unpleasantness. > > > > Let?s accept one-way transfers as a recognition of the reality of the historical artifact of address allocation, and as a step in the direction of a true global market, albeit a half-step. This proposal, on the other hand, is a step backwards. Those one-way regions are not suppliers of addresses to the market, so requiring outbound transfers from them will have no effect. On the other hand, denying needed addresses to these address-poor regions will affect them direly. > > > > Regards, > > Mike Burns > > > > > > > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Rudolph Daniel > Sent: Wednesday, August 23, 2017 9:15 AM > To: Owen DeLong > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-PPML 2017-6 draft policy > > > > Thank you Owen, and I remember those exact words when the policy was formulated and I accept that too. Of course, the community did not, at that time see the loop hole we are currently trying to close. So I was being cautious in that whilst we can modify the wording, to achieve a close, is arin staff also confident that it can be implemented. Of course I also appreciate that what ever we as a community do, there is always some out there looking or searching for yet another loop hole. > > rd > > > > > > > Rudi Daniel > > danielcharles consulting > > > > > > > > On Tue, Aug 22, 2017 at 6:15 PM, Owen DeLong > wrote: > > It is achievable because ARIN will evaluate the policy of each RIR in this regard prior to approving the transfer. > > > > Owen > > > > On Aug 18, 2017, at 12:36 , Rudolph Daniel > wrote: > > > > " Recipient RIR policy must not permit transfers to other RIRs or NIRs whose policies do not support bi-directional transfers." > > Whereas I am in support of closing this loophole, I cannot be sure that this is actually achievable... > rd > > > > On Aug 17, 2017 6:01 PM, > wrote: > > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Revised: Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > (Paul McNary) > 2. Draft Policy 2017-6: Improve Reciprocity Requirements for > Inter RIR Transfers (WOOD Alison * DAS) > 3. Re: Revised: Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > (hostmaster at uneedus.com ) > 4. Re: Revised: Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > (David Farmer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 17 Aug 2017 15:49:47 -0500 > From: Paul McNary > > To: "arin-ppml at arin.net " > > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 and > IPv6 > Message-ID: <7460ee99-c116-7c0a-b726-2267de135596 at cameron.net > > Content-Type: text/plain; charset=utf-8; format=flowed > > Sorry I typed the numbers backwards, yes, that is what I meant. :-) > > A /48 is smaller than a /47 and would not be required to be registered? > A /47 would need to be > > > On 8/17/2017 1:30 PM, Chris Woodfield wrote: >> The opposite - a /47 is 2 /48s aggregated. >> >> -C >> >>> On Aug 17, 2017, at 11:26 AM, Paul McNary > wrote: >>> >>> A /47 is smaller than a /48 and would not be required to be registered? >>> >>> >>> On 8/17/2017 12:50 PM, hostmaster at uneedus.com wrote: >>>> I note that any ISP size reassignment, with the recommended /48 for each end user site, will be /47 or larger, which must always be registered. >>>> >>>> Thus, I think 6.5.5.5 language is unneeded, since any LIR/ISP reassignment will be large enough to already trigger registration. >>>> >>>> Under the current policy, LIR's and ISP's are equal, so usually both terms are stated in any policy that mentions them. >>>> >>>> May I also suggest that if we are going to require registration upon downstream request for IPv6, that we consider placing the same language and requirements for IPv4 customers as well? And if we do, where do we draw the minimum line? Maybe a /32.... >>>> >>>> Also, good catch on the cut and paste error..... >>>> >>>> Albert Erdmann >>>> Network Administrator >>>> Paradise On Line Inc. >>>> >>>> >>>> On Thu, 17 Aug 2017, Leif Sawyer wrote: >>>> >>>>> Thanks for the feedback, David. >>>>> >>>>> I've added the fix for 6.5.5.2, since we're already in the section. >>>>> >>>>> I've also modified the text for 6.5.5.4 as well, because I think your suggesting is a little cleaner. >>>>> >>>>> I'm not sure what the point of 6.5.5.5 is - you're just reiterating 6.5.5.1. >>>>> That said, we could potentially clean up 6.5.5.1 by extending "static IPv6 assignment" >>>>> to "static IPv6 assignment, or allocation," - or something similar. >>>>> >>>>> >>>>> Which also brings to mind the question: LIR or ISP? Both are in use in 6.5.... >>>>> >>>>> ________________________________ >>>>> From: ARIN-PPML [arin-ppml-bounces at arin.net ] on behalf of David Farmer [farmer at umn.edu ] >>>>> Sent: Thursday, August 17, 2017 8:53 AM >>>>> To: hostmaster at uneedus.com >>>>> Cc: arin-ppml at arin.net >>>>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 >>>>> >>>>> [External Email] >>>>> >>>>> Here is a slightly different formulation to consider. I refactored the title a little, and based the phrasing on other parts of section 6.5.5 >>>>> >>>>> 6.5.5.4 Registration Requested by Recipient >>>>> >>>>> If requested by the downstream recipient of a block, each static IPv6 assignment containing a /64 or more addresses, shall be registered, as described in section 6.5.5.1. >>>>> >>>>> I'd like us to think about adding an additional section, based on previous discussions. >>>>> >>>>> 6.5.5.5 Re-allocation to ISPs >>>>> >>>>> Each IPv6 re-allocation to a downstream ISP, regardless of size, intended for further assignment by the downstream ISP's to it's customers, shall be registered, as described in section 6.5.5.1 >>>>> >>>>> Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. I think this is a cut and past error, I think the reference should be to 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with sections 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. >>>>> >>>>> Thanks. >>>>> >>>>> On Wed, Aug 16, 2017 at 6:10 AM, >> wrote: >>>>> I am in favor of the draft, with or without the changes to make it clearer. >>>>> >>>>> I suggest the following language for clarity: >>>>> >>>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM that reads "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that static assignment in ARIN's registration database, the ISP must register that static assignment." >>>>> >>>>> Since "static assignment" is the term in this section, not netblock, I suggest using this term instead of "netblock". "Of any size" is not needed, as the language would require the ISP to register in total whatever size the ISP has assigned to the downstream in the ARIN database if requested by the downstream recipient, as long as it was /64 or more. >>>>> >>>>> This language would also prevent requests to register only part of an assignment. I think this language works in making the intent of the new section more clear. >>>>> >>>>> Albert Erdmann >>>>> Network Administrator >>>>> Paradise On Line Inc. >>>>> >>>>> >>>>> >>>>> On Tue, 15 Aug 2017, John Santos wrote: >>>>> >>>>> I think that the "/64 or more addresses" and the "regardless of size" are meant to convey that any netblock between a /64 and a /48 can and should be registered if the recipient requests it, even if the block is smaller than the /47 which would make it mandatory. Perhaps there is better wording that would make this clearer. >>>>> >>>>> Three ranges: >>>>> >>>>> 1. smaller than /64: shouldn't be issued, can't be registered. >>>>> 2. /64 through /48: register at recipient's request >>>>> 3. /47 or larger: must be registered >>>>> >>>>> I agree on dynamic assignments >>>>> >>>>> Otherwise, I think this is a much clearer and better update to the proposed policy, and can't find any other reason not to support it. (I.E. this is a tentative vote FOR, if there is such a thing.) >>>>> >>>>> >>>>> >>>>> On 8/15/2017 3:59 PM, David Farmer wrote: >>>>> I support what I think is the intent, but I have language/editorial nits; >>>>> >>>>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of size" that requires registration? I think logically we need one or the other, or some qualification on "regardless of size" statement. I think it is a good idea to not require registration of less than a /64. But the current language seems contradictory, and therefore confusing, my recommendation is delete "regardless of size", from the sentence and leaving "a /64 or more addresses". I pretty sure we don't want people having an expectation that they can request the registration of "their" /128 address. >>>>> >>>>> 2. Also in 3) below; It would seem to require even dynamic assignments be registered if requested, I don't think that is our intent either, section 6.5.5.1 starts with "Each static IPv6 assignment containing", this needs a similar qualification. >>>>> >>>>> Also, I'm fine with the deltas in the policy statement but it would be helpful to see the final resulting policy block, maybe in a separate email so we can all see how the result reads. >>>>> >>>>> Thanks, I think we are getting close, maybe one or two more turns of the crank. >>>>> >>>>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN > >>> wrote: >>>>> >>>>> The following has been revised: >>>>> >>>>> * Draft Policy ARIN-2017-5: Equalization of Assignment >>>>> Registration requirements between IPv4 and IPv6 >>>>> >>>>> Revised text is below and can be found at: >>>>> https://www.arin.net/policy/proposals/2017_5.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 >>>>> > >>>>> >>>>> Draft Policies and Proposals under discussion can be found at: >>>>> https://www.arin.net/policy/proposals/index.html >>>>> > >>>>> >>>>> Regards, >>>>> >>>>> Sean Hopkins >>>>> Policy Analyst >>>>> American Registry for Internet Numbers (ARIN) >>>>> >>>>> >>>>> >>>>> >>>>> 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 subdelegation 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" >>>>> >>>>> and >>>>> >>>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to >>>>> the NRPM that reads "If the downstream recipient of a netblock ( a >>>>> /64 or more addresses) requests publishing in ARIN's registration >>>>> database, the ISP must register the netblock, regardless of size." >>>>> >>>>> 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. >>>>> >>>>> -- >>>>> John Santos >>>>> Evans Griffiths & Hart, Inc. >>>>> 781-861-0670 ext 539 20539> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net > if you experience any issues. >>>>> >>>>> >>>>> >>>>> -- >>>>> =============================================== >>>>> David Farmer Email:farmer at umn.edu > >>>>> 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 (ARIN-PPML at arin.net ). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at 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 at arin.net ). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >> > > > ------------------------------ > > Message: 2 > Date: Thu, 17 Aug 2017 20:54:23 +0000 > From: WOOD Alison * DAS > > To: "arin-ppml at arin.net " > > Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity > Requirements for Inter RIR Transfers > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > Thank you for the feedback on this draft policy to date. I would appreciate any other thoughts or comments on this draft policy. > > For review, Draft Policy 2017-6 is intended to add the following conditions on Inter RIR transfers to section 8.4: > > Recipient RIR policy must not permit transfers to other RIRs or NIRs whose policies do not support bi-directional transfers. > > And the problem statement on this draft policy is: > > Currently ARIN's requirement that inter-RIR transfer policies be reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a two-hop RIR transfer process can be used to circumvent the intent of the requirement. Rather than eliminate the requirement, a better approach would be to close the loophole. > > All feedback is appreciated. > > Thank you > > -Alison Wood > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 3 > Date: Thu, 17 Aug 2017 18:00:05 -0400 (EDT) > From: hostmaster at uneedus.com > To: "arin-ppml at arin.net " > > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 and > IPv6 > Message-ID: > > Content-Type: text/plain; charset="x-unknown"; Format="flowed" > > While the most recent drafts have not dealt with IPv4, in the last round > there was a proposal to require registration upon request of the > downstream customer of their IPv6 assignment. > > If we intend to provide that power to require registration for IPv6 > customer assignments upon request, in fairness we should also use the same > language in a new 4.2.3.7.4 to allow static IPv4 customers that same > power. I suggest /32 as the limit, as /29 or more already has required > registration. The same problems identfied in not being able to register > assignments with ARIN for v6 are also true for v4 assignments between > those limits. > > Since both protocols are still being addressed and attempts are being > made by the draft to make v6 equal or better than v4, the title should > remain. The only thing we have done is not shift the v4 limit of /29. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > >> While we???re turning the crank, can we please fix the title since IPv4 >> is no longer relevant to the proposal and there???s really no >> equalization happening? >> >> Perhaps ???Improved Registration Requirements for IPv6??? >> >> Owen > ------------------------------ > > Message: 4 > Date: Thu, 17 Aug 2017 17:01:09 -0500 > From: David Farmer > > To: Leif Sawyer > > Cc: "hostmaster at uneedus.com " >, > "arin-ppml at arin.net " > > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 and > IPv6 > Message-ID: > > > Content-Type: text/plain; charset="utf-8" > > On Thu, Aug 17, 2017 at 1:43 PM, David Farmer > wrote: > >> Inline. >> >> On Thu, Aug 17, 2017 at 12:29 PM, Leif Sawyer > wrote: >> >>> Thanks for the feedback, David. >>> >> ... >> I'm not sure what the point of 6.5.5.5 is - you're just reiterating >>> 6.5.5.1. >>> That said, we could potentially clean up 6.5.5.1 by extending "static >>> IPv6 assignment" >>> to "static IPv6 assignment, or allocation," - or something similar. >>> >> ISP re-allocations need to be registered regardless of size or if it is >> being advertised or not. For example, if for some stupid reason a /56 was >> re-allocated to downsterm ISP so they could assign /64s to customers that >> has to be registered, by 6.5.5.1 that wouldn't have to be registered. >> Should you re-allocate a /56, @!@#$ NO!!! But if you did, it has to be >> registered. This is so LEA and other legal requests get directly to the >> correct ISP the first time. I think this is important enough issue that it >> should have it's own section, and not get blended in to 6.5.5.1. >> >> Now should that be part of this policy maybe not, maybe this belongs in >> ARIN-2017-3 or whole new separate policy proposal instead. >> > Thinking about this for the last couple hours I'm thinking 6.5.5.5 this > should not be part of this policy. As similar text should be added in the > IPv4 section, and this should have a somewhat different problem statement > as well. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > 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 > =============================================== > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > ------------------------------ > > End of ARIN-PPML Digest, Vol 146, Issue 10 > ****************************************** > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Wed Aug 23 13:56:44 2017 From: farmer at umn.edu (David Farmer) Date: Wed, 23 Aug 2017 12:56:44 -0500 Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers In-Reply-To: <4603E5A4-8DEB-4F14-BA93-941C0A75D00D@delong.com> References: <415F505D-1A01-4B43-9386-4F29013D8F4B@panix.com> <4603E5A4-8DEB-4F14-BA93-941C0A75D00D@delong.com> Message-ID: On Tue, Aug 22, 2017 at 4:10 PM, Owen DeLong wrote: > > > On Aug 18, 2017, at 05:14 , David Huberman wrote: > > > > I am a US-based company and I operate a network on multiple continents. > > > > I need to be able to move space from my home RIR of ARIN to other > regions as I expand my network overseas. > > > > The current policy that has been in effect for many years allows me to > operate my network properly -- using ARIN blocks in ARIN, APNIC blocks in > APNIC, and RIPE blocks in RIPE. The policy is predictable and I can plan > network growth around it. > > > > If this proposal passes, it will shut off transfers between ARIN and > APNIC. This will hurt my business's finances. We purchased addresses in > the ARIN region wth the intention of moving them to APNIC in the future. We > did so because the size blocks we needed were not available in the APNIC > region. So now we are talking about hurting my business for ... what > reason? How do network operations benefit from this proposal? > > Currently, there are certain registries that are operating like roach > motels for IP addresses. KR-NIC, CN-NIC are examples. > There is no evidence that this presents anything more than a theoretical problem, in fact I went and looked at APNICs transfer logs; https://www.apnic.net/manage-ip/manage-resources/transfer-resources/transfer-logs/ or http://ftp.apnic.net/transfers/apnic/ I found out of 281 transfers from ARIN to APNIC, there were 2 to KR and 15 to CN, and the 2 to KR were /22s and all the transfers to CN appear to be cloud providers from the best I can tell. There were also another 22 transfers from APNIC to ARIN, for a total of 303 transfers between APNIC and ARIN. You want to break 94% of the transfers between APNIC and ARIN because you don't like 6% of them. AfriNIC is discussing a similar proposal and a similar proposal was > discussed in LACNIC. > Help me understand this, we are going to break transfers to APNIC in hopes that ArfNIC and LACNIC won't pass a policy? Please explain how you expect that to work. > It is hoped that by implementing this policy it will put pressure on those > registries to be more cooperative with the global community in allowing > bi-directional transfers. > > That is how it helps network operations. Admittedly, it?s a short-term > pain for a longer term gain, but that is the intent. > In my opinion the cure you propose is fare worse than the disease you seek to remedy. This policy will seriously damage what seems like a mostly well functioning system, primarily to influence a decision that is independent of the result. I cannot support this policy. Thanks. -- =============================================== David Farmer Email:farmer at umn.edu 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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at wsfnet.org Wed Aug 23 14:07:51 2017 From: admin at wsfnet.org (Whitestone IT) Date: Wed, 23 Aug 2017 10:07:51 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of Community Network In-Reply-To: <28d7e4fc-532c-209f-039a-57c1d88cea20@arin.net> References: <28d7e4fc-532c-209f-039a-57c1d88cea20@arin.net> Message-ID: I support the new NRPM text. Improving the NRPM to align with reality is good. I've built and operated community networks since 1998 and prior, and I was and am directly affected by this policy. We have found that a strictly volunteer-only policy is unsustainable. On Tue, Aug 22, 2017 at 8:39 AM, ARIN wrote: > On 17 August 2017 the ARIN Advisory Council (AC) advanced "ARIN-prop-243: > Amend the Definition of Community Network" to Draft Policy status. > > Draft Policy ARIN-2017-8 is below and can be found at: > https://www.arin.net/policy/proposals/2017_8.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 > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-8: Amend the Definition of Community Network > > Problem Statement: > > The Community Networks section of the NRPM has not been used since > implementation in January 2010. Proposal ARIN-2016-7, to increase the > number of use cases, was abandoned by the Advisory Council due to lack of > feedback. Proposal ARIN 2017-2, to remove all mention of community networks > from NRPM was met with opposition by the community. Many responded that the > definition of ?community network? was too narrow, which could be the reason > for lack of uptake. > > Policy statement: > > CURRENT NRPM TEXT: > > ?2.11. Community Network > > A community network is any network organized and operated by a volunteer > group operating as or under the fiscal support of a nonprofit organization > or university for the purpose of providing free or low-cost connectivity to > the residents of their local service area. To be treated as a community > network under ARIN policy, the applicant must certify to ARIN that the > community network staff is 100% volunteers.? > > NEW NRPM TEXT: > > ?2.11 Community Network > > A community network is a network organized and operated by a volunteer > group, not-for-profit, non-profit, charitable organization, or > post-secondary institution for the purpose of providing free or low-cost > connectivity to residents in their service area. Critical functions may be > handled by paid staff, but volunteers play a large role in offering > services available through community networks.? > > Comments: > > Timetable for implementation: Immediate > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- Jeremy Austin IT Administrator Whitestone, Alaska -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Wed Aug 23 14:14:20 2017 From: mike at iptrading.com (Mike Burns) Date: Wed, 23 Aug 2017 14:14:20 -0400 Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers In-Reply-To: References: <415F505D-1A01-4B43-9386-4F29013D8F4B@panix.com> <4603E5A4-8DEB-4F14-BA93-941C0A75D00D@delong.com> Message-ID: <010f01d31c3b$a4365a30$eca30e90$@iptrading.com> Hi David, https://www.apnic.net/manage-ip/manage-resources/transfer-resources/nir-ipv4-transfer/ CNNIC allows outbound transfers now. So of your statistics below, really only the two /22s to KRNIC are valid examples of transfers to one-way recipient NIRs. Frankly I believe both KRNIC and VNNIC would both actually process an outbound transfer if one was ever presented to it. They are technically bound in some way to APNIC policies but I doubt this has ever been challenged. Regards, Mike From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer Sent: Wednesday, August 23, 2017 1:57 PM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers On Tue, Aug 22, 2017 at 4:10 PM, Owen DeLong > wrote: > On Aug 18, 2017, at 05:14 , David Huberman > wrote: > > I am a US-based company and I operate a network on multiple continents. > > I need to be able to move space from my home RIR of ARIN to other regions as I expand my network overseas. > > The current policy that has been in effect for many years allows me to operate my network properly -- using ARIN blocks in ARIN, APNIC blocks in APNIC, and RIPE blocks in RIPE. The policy is predictable and I can plan network growth around it. > > If this proposal passes, it will shut off transfers between ARIN and APNIC. This will hurt my business's finances. We purchased addresses in the ARIN region wth the intention of moving them to APNIC in the future. We did so because the size blocks we needed were not available in the APNIC region. So now we are talking about hurting my business for ... what reason? How do network operations benefit from this proposal? Currently, there are certain registries that are operating like roach motels for IP addresses. KR-NIC, CN-NIC are examples. There is no evidence that this presents anything more than a theoretical problem, in fact I went and looked at APNICs transfer logs; https://www.apnic.net/manage-ip/manage-resources/transfer-resources/transfer-logs/ or http://ftp.apnic.net/transfers/apnic/ I found out of 281 transfers from ARIN to APNIC, there were 2 to KR and 15 to CN, and the 2 to KR were /22s and all the transfers to CN appear to be cloud providers from the best I can tell. There were also another 22 transfers from APNIC to ARIN, for a total of 303 transfers between APNIC and ARIN. You want to break 94% of the transfers between APNIC and ARIN because you don't like 6% of them. AfriNIC is discussing a similar proposal and a similar proposal was discussed in LACNIC. Help me understand this, we are going to break transfers to APNIC in hopes that ArfNIC and LACNIC won't pass a policy? Please explain how you expect that to work. It is hoped that by implementing this policy it will put pressure on those registries to be more cooperative with the global community in allowing bi-directional transfers. That is how it helps network operations. Admittedly, it?s a short-term pain for a longer term gain, but that is the intent. In my opinion the cure you propose is fare worse than the disease you seek to remedy. This policy will seriously damage what seems like a mostly well functioning system, primarily to influence a decision that is independent of the result. I cannot support this policy. Thanks. -- =============================================== David Farmer Email:farmer at umn.edu 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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Wed Aug 23 14:23:05 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Aug 2017 11:23:05 -0700 Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers In-Reply-To: References: <415F505D-1A01-4B43-9386-4F29013D8F4B@panix.com> <4603E5A4-8DEB-4F14-BA93-941C0A75D00D@delong.com> Message-ID: Agreed: this proposal is a very bad idea for many reasons, and I would encourage the AC to abandon it prior to the next public policy meeting. If you're reading this message on PPML, feel like this policy is generally a bad idea, but haven't commented on it yet: please do. The AC needs to hear clearly from the community that a draft policy is a bad idea, either from PPML or from a public policy meeting, before they'll generally feel comfortable abandoning a draft policy for lack of community support. In the absence of such clarity on PPML, this would likely go to the PPM as a draft policy for discussion there, which would be a waste of everyone's time IMO. -Scott On Wed, Aug 23, 2017 at 10:56 AM, David Farmer wrote: > > On Tue, Aug 22, 2017 at 4:10 PM, Owen DeLong wrote: > >> >> > On Aug 18, 2017, at 05:14 , David Huberman wrote: >> > >> > I am a US-based company and I operate a network on multiple continents. >> > >> > I need to be able to move space from my home RIR of ARIN to other >> regions as I expand my network overseas. >> > >> > The current policy that has been in effect for many years allows me to >> operate my network properly -- using ARIN blocks in ARIN, APNIC blocks in >> APNIC, and RIPE blocks in RIPE. The policy is predictable and I can plan >> network growth around it. >> > >> > If this proposal passes, it will shut off transfers between ARIN and >> APNIC. This will hurt my business's finances. We purchased addresses in >> the ARIN region wth the intention of moving them to APNIC in the future. We >> did so because the size blocks we needed were not available in the APNIC >> region. So now we are talking about hurting my business for ... what >> reason? How do network operations benefit from this proposal? >> >> Currently, there are certain registries that are operating like roach >> motels for IP addresses. KR-NIC, CN-NIC are examples. >> > > There is no evidence that this presents anything more than a theoretical > problem, in fact I went and looked at APNICs transfer logs; > > https://www.apnic.net/manage-ip/manage-resources/transfer- > resources/transfer-logs/ > or > http://ftp.apnic.net/transfers/apnic/ > > I found out of 281 transfers from ARIN to APNIC, there were 2 to KR and 15 > to CN, and the 2 to KR were /22s and all the transfers to CN appear to be > cloud providers from the best I can tell. There were also another 22 > transfers from APNIC to ARIN, for a total of 303 transfers between APNIC > and ARIN. > > You want to break 94% of the transfers between APNIC and ARIN because you > don't like 6% of them. > > AfriNIC is discussing a similar proposal and a similar proposal was >> discussed in LACNIC. >> > > Help me understand this, we are going to break transfers to APNIC in hopes > that ArfNIC and LACNIC won't pass a policy? Please explain how you expect > that to work. > > >> It is hoped that by implementing this policy it will put pressure on >> those registries to be more cooperative with the global community in >> allowing bi-directional transfers. >> >> That is how it helps network operations. Admittedly, it?s a short-term >> pain for a longer term gain, but that is the intent. >> > > In my opinion the cure you propose is fare worse than the disease you seek > to remedy. This policy will seriously damage what seems like a mostly well > functioning system, primarily to influence a decision that is independent > of the result. > > I cannot support this policy. > > Thanks. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael+ppml at burnttofu.net Wed Aug 23 14:25:33 2017 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Wed, 23 Aug 2017 11:25:33 -0700 Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers In-Reply-To: References: <415F505D-1A01-4B43-9386-4F29013D8F4B@panix.com> <4603E5A4-8DEB-4F14-BA93-941C0A75D00D@delong.com> Message-ID: On 08/23/17 10:56, David Farmer wrote: > You want to break 94% of the transfers between APNIC and ARIN because > you don't like 6% of them. ? > > AfriNIC is discussing a similar proposal and a similar proposal was > discussed in LACNIC. > > > Help me understand this, we are going to break transfers to APNIC in > hopes that ArfNIC and LACNIC won't pass a policy?? Please explain how > you expect that to work. ?? Without asserting for/against this proposal, I'd like a bit more information. ISTR an incident in the AfriNIC region where there was an abuse of some policy which resulted in the acquisition of resources in that region for the express (or perhaps covert) purpose of transfer to, and sale in, the APNIC region. Did such an incident happen and is this (or possibly AfriNIC's proposed) policy based on that? Any other references that anyone can provide? (Right now, I am interested in cases, not quantitative studies, although I am still sympathetic to quantitative arguments.) thanks, michael From chris at semihuman.com Wed Aug 23 14:43:23 2017 From: chris at semihuman.com (Chris Woodfield) Date: Wed, 23 Aug 2017 14:43:23 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of Community Network In-Reply-To: <28d7e4fc-532c-209f-039a-57c1d88cea20@arin.net> References: <28d7e4fc-532c-209f-039a-57c1d88cea20@arin.net> Message-ID: <1C3B9E1D-9E7C-40AE-876D-2B6345ADA768@semihuman.com> I?m not aware of at what point in time the Community Networks clause was originally added to the NRPM, but I?m betting it was a time where internet access was nowhere near as vital a service as it is today. Given that, it?s obvious that very few, if any, community networks could operate reliably without a certain amount of paid staff. I would note that IMO the phrase ?a large role? could be imprecise; If I were writing this policy, I'd choose a term such as ?a predominant role? instead - still fuzzy, but substantially less so. Alternatively, the policy could require organizations to have an all-volunteer board of directors, but that may result in some organizations we?d otherwise consider clear beneficiaries of the policy being unable to do so (for example, academic networks). Given the above, I support this policy as written. Thanks, -Chris > On Aug 22, 2017, at 12:39 PM, ARIN wrote: > > On 17 August 2017 the ARIN Advisory Council (AC) advanced "ARIN-prop-243: Amend the Definition of Community Network" to Draft Policy status. > > Draft Policy ARIN-2017-8 is below and can be found at: > https://www.arin.net/policy/proposals/2017_8.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 > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-8: Amend the Definition of Community Network > > Problem Statement: > > The Community Networks section of the NRPM has not been used since implementation in January 2010. Proposal ARIN-2016-7, to increase the number of use cases, was abandoned by the Advisory Council due to lack of feedback. Proposal ARIN 2017-2, to remove all mention of community networks from NRPM was met with opposition by the community. Many responded that the definition of ?community network? was too narrow, which could be the reason for lack of uptake. > > Policy statement: > > CURRENT NRPM TEXT: > > ?2.11. Community Network > > A community network is any network organized and operated by a volunteer group operating as or under the fiscal support of a nonprofit organization or university for the purpose of providing free or low-cost connectivity to the residents of their local service area. To be treated as a community network under ARIN policy, the applicant must certify to ARIN that the community network staff is 100% volunteers.? > > NEW NRPM TEXT: > > ?2.11 Community Network > > A community network is a network organized and operated by a volunteer group, not-for-profit, non-profit, charitable organization, or post-secondary institution for the purpose of providing free or low-cost connectivity to residents in their service area. Critical functions may be handled by paid staff, but volunteers play a large role in offering services available through community networks.? > > Comments: > > Timetable for implementation: Immediate > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From kevinb at thewire.ca Wed Aug 23 15:22:02 2017 From: kevinb at thewire.ca (Kevin Blumberg) Date: Wed, 23 Aug 2017 19:22:02 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of Community Network In-Reply-To: <28d7e4fc-532c-209f-039a-57c1d88cea20@arin.net> References: <28d7e4fc-532c-209f-039a-57c1d88cea20@arin.net> Message-ID: <7E7773B523E82C478734E793E58F69E78ECA850B@SBS2011.thewireinc.local> I do not support the policy as written but do support the overall intent. 1) The definition of a community network has gone from overly specific to overly broad. An example in Canada there are over 160,000 non-profit and not-for-profit organizations. 2) A volunteer group, that is not an organization, wouldn't be able to get space from ARIN as it requires a business registration (ARIN Staff please confirm). 3) Why is there a limit to only post-secondary institutions? Many rural locations have K-12 that would not qualify. 4) In Canada, a charity is a non-profit organization, more generic terms should be used that covers the entire ARIN serving region. 5) The current Community Networks policy conflicts with the intent of 2017-5 Improved IPv6 Registration Requirements. By placing all space into End User assignment, Community Networks operating as a ISP collective for residential subscribers would be unable to reassign static assignments. The current Community Networks policy requires an applicant to qualify under standard end-user requirements (Section 6.5.9.2). If there is no difference to the qualification criteria, why would an organization go out of the way to qualify as a Community Network? I wrote a policy in 2016 that tried to address some of these issues, it was abandoned at the time ( https://www.arin.net/policy/proposals/2016_7.html ) Kevin Blumberg -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Tuesday, August 22, 2017 12:40 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of Community Network On 17 August 2017 the ARIN Advisory Council (AC) advanced "ARIN-prop-243: Amend the Definition of Community Network" to Draft Policy status. Draft Policy ARIN-2017-8 is below and can be found at: https://www.arin.net/policy/proposals/2017_8.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 Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-8: Amend the Definition of Community Network Problem Statement: The Community Networks section of the NRPM has not been used since implementation in January 2010. Proposal ARIN-2016-7, to increase the number of use cases, was abandoned by the Advisory Council due to lack of feedback. Proposal ARIN 2017-2, to remove all mention of community networks from NRPM was met with opposition by the community. Many responded that the definition of ?community network? was too narrow, which could be the reason for lack of uptake. Policy statement: CURRENT NRPM TEXT: ?2.11. Community Network A community network is any network organized and operated by a volunteer group operating as or under the fiscal support of a nonprofit organization or university for the purpose of providing free or low-cost connectivity to the residents of their local service area. To be treated as a community network under ARIN policy, the applicant must certify to ARIN that the community network staff is 100% volunteers.? NEW NRPM TEXT: ?2.11 Community Network A community network is a network organized and operated by a volunteer group, not-for-profit, non-profit, charitable organization, or post-secondary institution for the purpose of providing free or low-cost connectivity to residents in their service area. Critical functions may be handled by paid staff, but volunteers play a large role in offering services available through community networks.? Comments: Timetable for implementation: Immediate _______________________________________________ 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From farmer at umn.edu Wed Aug 23 15:59:59 2017 From: farmer at umn.edu (David Farmer) Date: Wed, 23 Aug 2017 14:59:59 -0500 Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers In-Reply-To: <010f01d31c3b$a4365a30$eca30e90$@iptrading.com> References: <415F505D-1A01-4B43-9386-4F29013D8F4B@panix.com> <4603E5A4-8DEB-4F14-BA93-941C0A75D00D@delong.com> <010f01d31c3b$a4365a30$eca30e90$@iptrading.com> Message-ID: Mike, Thanks for the correction on CN and the link. I double checked of KR, TW, and VN, the three NIRs that don't allow outbound transfers, only KR has the two transfers of /22 from 2014 that I originally mentioned. That is then less than 1% of the 303 transfers between APNIC and ARIN, and probably way less than 1% of the address space involved. This only reinforces my conclusion, the cure is worse than disease! Thanks On Wed, Aug 23, 2017 at 1:14 PM, Mike Burns wrote: > Hi David, > > > > https://www.apnic.net/manage-ip/manage-resources/transfer- > resources/nir-ipv4-transfer/ > > > > CNNIC allows outbound transfers now. > > So of your statistics below, really only the two /22s to KRNIC are valid > examples of transfers to one-way recipient NIRs. > > > > Frankly I believe both KRNIC and VNNIC would both actually process an > outbound transfer if one was ever presented to it. They are technically > bound in some way to APNIC policies but I doubt this has ever been > challenged. > > > > Regards, > > Mike > > > > > > *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *David > Farmer > *Sent:* Wednesday, August 23, 2017 1:57 PM > *To:* Owen DeLong > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity > Requirements for Inter RIR Transfers > > > > > > On Tue, Aug 22, 2017 at 4:10 PM, Owen DeLong wrote: > > > > On Aug 18, 2017, at 05:14 , David Huberman wrote: > > > > I am a US-based company and I operate a network on multiple continents. > > > > I need to be able to move space from my home RIR of ARIN to other > regions as I expand my network overseas. > > > > The current policy that has been in effect for many years allows me to > operate my network properly -- using ARIN blocks in ARIN, APNIC blocks in > APNIC, and RIPE blocks in RIPE. The policy is predictable and I can plan > network growth around it. > > > > If this proposal passes, it will shut off transfers between ARIN and > APNIC. This will hurt my business's finances. We purchased addresses in > the ARIN region wth the intention of moving them to APNIC in the future. We > did so because the size blocks we needed were not available in the APNIC > region. So now we are talking about hurting my business for ... what > reason? How do network operations benefit from this proposal? > > Currently, there are certain registries that are operating like roach > motels for IP addresses. KR-NIC, CN-NIC are examples. > > > > There is no evidence that this presents anything more than a theoretical > problem, in fact I went and looked at APNICs transfer logs; > > > > https://www.apnic.net/manage-ip/manage-resources/transfer- > resources/transfer-logs/ > > or > > http://ftp.apnic.net/transfers/apnic/ > > > > I found out of 281 transfers from ARIN to APNIC, there were 2 to KR and 15 > to CN, and the 2 to KR were /22s and all the transfers to CN appear to be > cloud providers from the best I can tell. There were also another 22 > transfers from APNIC to ARIN, for a total of 303 transfers between APNIC > and ARIN. > > > > You want to break 94% of the transfers between APNIC and ARIN because you > don't like 6% of them. > > > > AfriNIC is discussing a similar proposal and a similar proposal was > discussed in LACNIC. > > > > Help me understand this, we are going to break transfers to APNIC in hopes > that ArfNIC and LACNIC won't pass a policy? Please explain how you expect > that to work. > > > > It is hoped that by implementing this policy it will put pressure on those > registries to be more cooperative with the global community in allowing > bi-directional transfers. > > That is how it helps network operations. Admittedly, it?s a short-term > pain for a longer term gain, but that is the intent. > > > > In my opinion the cure you propose is fare worse than the disease you seek > to remedy. This policy will seriously damage what seems like a mostly well > functioning system, primarily to influence a decision that is independent > of the result. > > > > I cannot support this policy. > > > > Thanks. > > > > -- > > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > -- =============================================== David Farmer Email:farmer at umn.edu 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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Thu Aug 24 11:22:11 2017 From: info at arin.net (ARIN) Date: Thu, 24 Aug 2017 11:22:11 -0400 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network Message-ID: The following has been revised: * Draft Policy ARIN-2017-8: Amend the Definition of Community Network Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_8.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 Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-8: Amend the Definition of Community Network Problem Statement: The Community Networks section of the NRPM has not been used since implementation in January 2010. Proposal ARIN-2016-7, to increase the number of use cases, was abandoned by the Advisory Council due to lack of feedback. Proposal ARIN 2017-2, to remove all mention of community networks from NRPM was met with opposition by the community. Many responded that the definition of ?community network? was too narrow, which could be the reason for lack of uptake. Policy statement: CURRENT NRPM TEXT: ?2.11. Community Network A community network is any network organized and operated by a volunteer group operating as or under the fiscal support of a nonprofit organization or university for the purpose of providing free or low-cost connectivity to the residents of their local service area. To be treated as a community network under ARIN policy, the applicant must certify to ARIN that the community network staff is 100% volunteers.? NEW NRPM TEXT: ?2.11 Community Network A community network is a network organized and operated by a volunteer group, not-for-profit, non-profit, charitable organization, or educational institution for the purpose of providing free or low-cost connectivity, or other Information Technology services to persons or entities within their community. Critical functions may be handled by paid staff, but volunteers play a large role in offering services available through community networks.? Comments: Timetable for implementation: Immediate From andrew.dul at quark.net Thu Aug 24 13:41:16 2017 From: andrew.dul at quark.net (Andrew Dul) Date: Thu, 24 Aug 2017 10:41:16 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of Community Network In-Reply-To: <1C3B9E1D-9E7C-40AE-876D-2B6345ADA768@semihuman.com> References: <28d7e4fc-532c-209f-039a-57c1d88cea20@arin.net> <1C3B9E1D-9E7C-40AE-876D-2B6345ADA768@semihuman.com> Message-ID: Chris, I'd agree that the wording around the requirements that the organization have volunteers fulfill a "large" or "predominant" role could be an area of improvement in the draft text. Do others feel that this part of the definition could be improved too? If so what requirements were would you like to see in the policy language. Andrew > On Aug 23, 2017, at 11:43 AM, Chris Woodfield wrote: > > I?m not aware of at what point in time the Community Networks clause was originally added to the NRPM, but I?m betting it was a time where internet access was nowhere near as vital a service as it is today. Given that, it?s obvious that very few, if any, community networks could operate reliably without a certain amount of paid staff. > > I would note that IMO the phrase ?a large role? could be imprecise; If I were writing this policy, I'd choose a term such as ?a predominant role? instead - still fuzzy, but substantially less so. Alternatively, the policy could require organizations to have an all-volunteer board of directors, but that may result in some organizations we?d otherwise consider clear beneficiaries of the policy being unable to do so (for example, academic networks). > > Given the above, I support this policy as written. From gary.buhrmaster at gmail.com Thu Aug 24 14:23:59 2017 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 24 Aug 2017 18:23:59 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of Community Network In-Reply-To: References: <28d7e4fc-532c-209f-039a-57c1d88cea20@arin.net> <1C3B9E1D-9E7C-40AE-876D-2B6345ADA768@semihuman.com> Message-ID: On Thu, Aug 24, 2017 at 5:41 PM, Andrew Dul wrote: > Do others feel that this part of the definition could be improved too? If so what requirements were would you like to see in the policy language. I do not want to see ARIN have to decide (and create a formal definition of) what a non-profit/volunteer/large org is, or how large/small you need to be. I (believe I) have stated this before, that I think ARIN should require the org to be validated by the countries definitions of same (something like 501(3)(c) in the US, I presume something equivalent elsewhere). If an org wants to be considered a non-profit (with whatever benefits that might offer in the future), they would provide ARIN with their national tax registration forms. From farmer at umn.edu Thu Aug 24 15:04:55 2017 From: farmer at umn.edu (David Farmer) Date: Thu, 24 Aug 2017 14:04:55 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of Community Network In-Reply-To: <7E7773B523E82C478734E793E58F69E78ECA850B@SBS2011.thewireinc.local> References: <28d7e4fc-532c-209f-039a-57c1d88cea20@arin.net> <7E7773B523E82C478734E793E58F69E78ECA850B@SBS2011.thewireinc.local> Message-ID: Kevin, There was a little confusion, mostly on my part it seems. Cutting to the chase; An older version of the text got sent out with the announcement of this policy. An updated version of text got sent out earlier today, it addresses some but for sure not all of your points. As for several of the broader points you bring up, I'd like to work on updating the definition for Community Networks first, mostly because that is the scope of the problem statement focuses on. Once we develop some consensus around a new definition for Community Networks, then I think we could build on that and look at some of the broader issues you bring up. Would that plan work for you? Thanks On Wed, Aug 23, 2017 at 2:22 PM, Kevin Blumberg wrote: > I do not support the policy as written but do support the overall intent. > > 1) The definition of a community network has gone from overly specific to > overly broad. An example in Canada there are over 160,000 non-profit and > not-for-profit organizations. > 2) A volunteer group, that is not an organization, wouldn't be able to get > space from ARIN as it requires a business registration (ARIN Staff please > confirm). > 3) Why is there a limit to only post-secondary institutions? Many rural > locations have K-12 that would not qualify. > 4) In Canada, a charity is a non-profit organization, more generic terms > should be used that covers the entire ARIN serving region. > 5) The current Community Networks policy conflicts with the intent of > 2017-5 Improved IPv6 Registration Requirements. By placing all space into > End User assignment, Community Networks operating as a ISP collective for > residential subscribers would be unable to reassign static assignments. > > The current Community Networks policy requires an applicant to qualify > under standard end-user requirements (Section 6.5.9.2). If there is no > difference to the qualification criteria, why would an organization go out > of the way to qualify as a Community Network? > > I wrote a policy in 2016 that tried to address some of these issues, it > was abandoned at the time ( https://www.arin.net/policy/pr > oposals/2016_7.html ) > > Kevin Blumberg > > -----Original Message----- > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN > Sent: Tuesday, August 22, 2017 12:40 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of > Community Network > > On 17 August 2017 the ARIN Advisory Council (AC) advanced > "ARIN-prop-243: Amend the Definition of Community Network" to Draft Policy > status. > > Draft Policy ARIN-2017-8 is below and can be found at: > https://www.arin.net/policy/proposals/2017_8.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 > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-8: Amend the Definition of Community Network > > Problem Statement: > > The Community Networks section of the NRPM has not been used since > implementation in January 2010. Proposal ARIN-2016-7, to increase the > number of use cases, was abandoned by the Advisory Council due to lack of > feedback. Proposal ARIN 2017-2, to remove all mention of community networks > from NRPM was met with opposition by the community. Many responded that the > definition of ?community network? was too narrow, which could be the reason > for lack of uptake. > > Policy statement: > > CURRENT NRPM TEXT: > > ?2.11. Community Network > > A community network is any network organized and operated by a volunteer > group operating as or under the fiscal support of a nonprofit organization > or university for the purpose of providing free or low-cost connectivity to > the residents of their local service area. To be treated as a community > network under ARIN policy, the applicant must certify to ARIN that the > community network staff is 100% volunteers.? > > NEW NRPM TEXT: > > ?2.11 Community Network > > A community network is a network organized and operated by a volunteer > group, not-for-profit, non-profit, charitable organization, or > post-secondary institution for the purpose of providing free or low-cost > connectivity to residents in their service area. Critical functions may be > handled by paid staff, but volunteers play a large role in offering > services available through community networks.? > > Comments: > > Timetable for implementation: Immediate > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinb at thewire.ca Fri Aug 25 00:19:23 2017 From: kevinb at thewire.ca (Kevin Blumberg) Date: Fri, 25 Aug 2017 04:19:23 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of Community Network In-Reply-To: References: <28d7e4fc-532c-209f-039a-57c1d88cea20@arin.net> <7E7773B523E82C478734E793E58F69E78ECA850B@SBS2011.thewireinc.local> Message-ID: <7E7773B523E82C478734E793E58F69E78ECABE3D@SBS2011.thewireinc.local> David, I see that the revised text addresses some of the definition issues. Regarding your question I believe that the definition and section 6.5.9 are intrinsically tied together. Currently the only active part of Community Networks is the state that it will be considered an end-user regarding ?all ARIN purposes?. I have an issue if this is used by Organizations to act as a way of opting-out of SWIP requirements. With a substantially expanded definition the number of Organizations that could use the policy is significant. Another interesting problem comes from the new Registration Services Plan (https://www.arin.net/fees/fee_schedule.html) ?Organizations that choose to convert to the Registration Services Plan will be evaluated as an ISP from a policy perspective when requesting future Internet number resources from ARIN. The applicable annual registration services plan will be invoiced annually based on the organization resources in the ARIN registry.? Kevin Blumberg From: David Farmer [mailto:farmer at umn.edu] Sent: Thursday, August 24, 2017 3:05 PM To: Kevin Blumberg Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of Community Network Kevin, There was a little confusion, mostly on my part it seems. Cutting to the chase; An older version of the text got sent out with the announcement of this policy. An updated version of text got sent out earlier today, it addresses some but for sure not all of your points. As for several of the broader points you bring up, I'd like to work on updating the definition for Community Networks first, mostly because that is the scope of the problem statement focuses on. Once we develop some consensus around a new definition for Community Networks, then I think we could build on that and look at some of the broader issues you bring up. Would that plan work for you? Thanks On Wed, Aug 23, 2017 at 2:22 PM, Kevin Blumberg > wrote: I do not support the policy as written but do support the overall intent. 1) The definition of a community network has gone from overly specific to overly broad. An example in Canada there are over 160,000 non-profit and not-for-profit organizations. 2) A volunteer group, that is not an organization, wouldn't be able to get space from ARIN as it requires a business registration (ARIN Staff please confirm). 3) Why is there a limit to only post-secondary institutions? Many rural locations have K-12 that would not qualify. 4) In Canada, a charity is a non-profit organization, more generic terms should be used that covers the entire ARIN serving region. 5) The current Community Networks policy conflicts with the intent of 2017-5 Improved IPv6 Registration Requirements. By placing all space into End User assignment, Community Networks operating as a ISP collective for residential subscribers would be unable to reassign static assignments. The current Community Networks policy requires an applicant to qualify under standard end-user requirements (Section 6.5.9.2). If there is no difference to the qualification criteria, why would an organization go out of the way to qualify as a Community Network? I wrote a policy in 2016 that tried to address some of these issues, it was abandoned at the time ( https://www.arin.net/policy/proposals/2016_7.html ) Kevin Blumberg -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Tuesday, August 22, 2017 12:40 PM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of Community Network On 17 August 2017 the ARIN Advisory Council (AC) advanced "ARIN-prop-243: Amend the Definition of Community Network" to Draft Policy status. Draft Policy ARIN-2017-8 is below and can be found at: https://www.arin.net/policy/proposals/2017_8.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 Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-8: Amend the Definition of Community Network Problem Statement: The Community Networks section of the NRPM has not been used since implementation in January 2010. Proposal ARIN-2016-7, to increase the number of use cases, was abandoned by the Advisory Council due to lack of feedback. Proposal ARIN 2017-2, to remove all mention of community networks from NRPM was met with opposition by the community. Many responded that the definition of ?community network? was too narrow, which could be the reason for lack of uptake. Policy statement: CURRENT NRPM TEXT: ?2.11. Community Network A community network is any network organized and operated by a volunteer group operating as or under the fiscal support of a nonprofit organization or university for the purpose of providing free or low-cost connectivity to the residents of their local service area. To be treated as a community network under ARIN policy, the applicant must certify to ARIN that the community network staff is 100% volunteers.? NEW NRPM TEXT: ?2.11 Community Network A community network is a network organized and operated by a volunteer group, not-for-profit, non-profit, charitable organization, or post-secondary institution for the purpose of providing free or low-cost connectivity to residents in their service area. Critical functions may be handled by paid staff, but volunteers play a large role in offering services available through community networks.? Comments: Timetable for implementation: Immediate _______________________________________________ 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at 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 at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu 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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Aug 25 00:53:23 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 25 Aug 2017 00:53:23 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201708250453.v7P4rONm020359@rotala.raleigh.ibm.com> Total of 24 messages in the last 7 days. script run at: Fri Aug 25 00:53:18 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 16.67% | 4 | 20.41% | 133521 | owen at delong.com 8.33% | 2 | 17.69% | 115711 | mike at iptrading.com 12.50% | 3 | 10.94% | 71566 | farmer at umn.edu 16.67% | 4 | 5.50% | 35979 | info at arin.net 4.17% | 1 | 13.84% | 90505 | dmahoney at dataonenetworks.biz 4.17% | 1 | 12.34% | 80710 | rudi.daniel at gmail.com 8.33% | 2 | 3.27% | 21365 | chris at semihuman.com 4.17% | 1 | 4.48% | 29324 | calderon.alfredo at gmail.com 4.17% | 1 | 3.23% | 21101 | scottleibrand at gmail.com 4.17% | 1 | 2.70% | 17679 | admin at wsfnet.org 4.17% | 1 | 1.78% | 11661 | kevinb at thewire.ca 4.17% | 1 | 1.40% | 9159 | andrew.dul at quark.net 4.17% | 1 | 1.27% | 8289 | gary.buhrmaster at gmail.com 4.17% | 1 | 1.16% | 7580 | michael+ppml at burnttofu.net --------+------+--------+----------+------------------------ 100.00% | 24 |100.00% | 654150 | Total From farmer at umn.edu Fri Aug 25 09:42:03 2017 From: farmer at umn.edu (David Farmer) Date: Fri, 25 Aug 2017 08:42:03 -0500 Subject: [arin-ppml] Expanding Scope? :Draft Policy ARIN-2017-8: Amend the definition of Community Network Message-ID: Ok, then I need to hear from others in the community on the subject expanding the scope of the problem statement for this Draft Policy beyond the just the Definition of Community Networks at this point; Should we revise the problem statement beyond it's current scope? If yes, then what should the revised problem statement include? Thanks On Thu, Aug 24, 2017 at 11:19 PM, Kevin Blumberg wrote: > David, > > > > I see that the revised text addresses some of the definition issues. > Regarding your question I believe that the definition and section 6.5.9 are > intrinsically tied together. > > > > Currently the only active part of Community Networks is the state that it > will be considered an end-user regarding ?all ARIN purposes?. I have an > issue if this is used by Organizations to act as a way of opting-out of > SWIP requirements. With a substantially expanded definition the number of > Organizations that could use the policy is significant. > > > > Another interesting problem comes from the new Registration Services Plan ( > https://www.arin.net/fees/fee_schedule.html) > > > > ?Organizations that choose to convert to the Registration Services Plan > will be evaluated as an ISP from a policy perspective when requesting > future Internet number resources from ARIN. The applicable annual > registration services plan will be invoiced annually based on the > organization resources in the ARIN registry.? > > > > Kevin Blumberg > > > > *From:* David Farmer [mailto:farmer at umn.edu] > *Sent:* Thursday, August 24, 2017 3:05 PM > *To:* Kevin Blumberg > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition > of Community Network > > > > Kevin, > > > > There was a little confusion, mostly on my part it seems. Cutting to the > chase; An older version of the text got sent out with the announcement of > this policy. An updated version of text got sent out earlier today, it > addresses some but for sure not all of your points. > > > > As for several of the broader points you bring up, I'd like to work on > updating the definition for Community Networks first, mostly because that > is the scope of the problem statement focuses on. Once we develop some > consensus around a new definition for Community Networks, then I think we > could build on that and look at some of the broader issues you bring up. > Would that plan work for you? > > > > Thanks > > > > On Wed, Aug 23, 2017 at 2:22 PM, Kevin Blumberg wrote: > > I do not support the policy as written but do support the overall intent. > > 1) The definition of a community network has gone from overly specific to > overly broad. An example in Canada there are over 160,000 non-profit and > not-for-profit organizations. > 2) A volunteer group, that is not an organization, wouldn't be able to get > space from ARIN as it requires a business registration (ARIN Staff please > confirm). > 3) Why is there a limit to only post-secondary institutions? Many rural > locations have K-12 that would not qualify. > 4) In Canada, a charity is a non-profit organization, more generic terms > should be used that covers the entire ARIN serving region. > 5) The current Community Networks policy conflicts with the intent of > 2017-5 Improved IPv6 Registration Requirements. By placing all space into > End User assignment, Community Networks operating as a ISP collective for > residential subscribers would be unable to reassign static assignments. > > The current Community Networks policy requires an applicant to qualify > under standard end-user requirements (Section 6.5.9.2). If there is no > difference to the qualification criteria, why would an organization go out > of the way to qualify as a Community Network? > > I wrote a policy in 2016 that tried to address some of these issues, it > was abandoned at the time ( https://www.arin.net/policy/ > proposals/2016_7.html ) > > Kevin Blumberg > > -----Original Message----- > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN > Sent: Tuesday, August 22, 2017 12:40 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of > Community Network > > On 17 August 2017 the ARIN Advisory Council (AC) advanced > "ARIN-prop-243: Amend the Definition of Community Network" to Draft Policy > status. > > Draft Policy ARIN-2017-8 is below and can be found at: > https://www.arin.net/policy/proposals/2017_8.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 > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-8: Amend the Definition of Community Network > > Problem Statement: > > The Community Networks section of the NRPM has not been used since > implementation in January 2010. Proposal ARIN-2016-7, to increase the > number of use cases, was abandoned by the Advisory Council due to lack of > feedback. Proposal ARIN 2017-2, to remove all mention of community networks > from NRPM was met with opposition by the community. Many responded that the > definition of ?community network? was too narrow, which could be the reason > for lack of uptake. > > Policy statement: > > CURRENT NRPM TEXT: > > ?2.11. Community Network > > A community network is any network organized and operated by a volunteer > group operating as or under the fiscal support of a nonprofit organization > or university for the purpose of providing free or low-cost connectivity to > the residents of their local service area. To be treated as a community > network under ARIN policy, the applicant must certify to ARIN that the > community network staff is 100% volunteers.? > > NEW NRPM TEXT: > > ?2.11 Community Network > > A community network is a network organized and operated by a volunteer > group, not-for-profit, non-profit, charitable organization, or > post-secondary institution for the purpose of providing free or low-cost > connectivity to residents in their service area. Critical functions may be > handled by paid staff, but volunteers play a large role in offering > services available through community networks.? > > Comments: > > Timetable for implementation: Immediate > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > > > -- > > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > -- =============================================== David Farmer Email:farmer at umn.edu 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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlton.samuels at gmail.com Fri Aug 25 11:00:06 2017 From: carlton.samuels at gmail.com (Carlton Samuels) Date: Fri, 25 Aug 2017 10:00:06 -0500 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network In-Reply-To: References: Message-ID: I support this change to the definition of community networks. -Carlton Samuels Virus-free. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Planning, Governance, Assessment & Turnaround* ============================= On Thu, Aug 24, 2017 at 10:22 AM, ARIN wrote: > The following has been revised: > > * Draft Policy ARIN-2017-8: Amend the Definition of Community Network > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_8.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 > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-8: Amend the Definition of Community Network > > Problem Statement: > > The Community Networks section of the NRPM has not been used since > implementation in January 2010. Proposal ARIN-2016-7, to increase the > number of use cases, was abandoned by the Advisory Council due to lack of > feedback. Proposal ARIN 2017-2, to remove all mention of community networks > from NRPM was met with opposition by the community. Many responded that the > definition of ?community network? was too narrow, which could be the reason > for lack of uptake. > > Policy statement: > > CURRENT NRPM TEXT: > > ?2.11. Community Network > > A community network is any network organized and operated by a volunteer > group operating as or under the fiscal support of a nonprofit organization > or university for the purpose of providing free or low-cost connectivity to > the residents of their local service area. To be treated as a community > network under ARIN policy, the applicant must certify to ARIN that the > community network staff is 100% volunteers.? > > NEW NRPM TEXT: > > ?2.11 Community Network > > A community network is a network organized and operated by a volunteer > group, not-for-profit, non-profit, charitable organization, or educational > institution for the purpose of providing free or low-cost connectivity, or > other Information Technology services to persons or entities within their > community. Critical functions may be handled by paid staff, but volunteers > play a large role in offering services available through community > networks.? > > Comments: > > Timetable for implementation: Immediate > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrdelacruz at acm.org Sun Aug 27 21:45:11 2017 From: jrdelacruz at acm.org (Jose R. de la Cruz III) Date: Sun, 27 Aug 2017 21:45:11 -0400 Subject: [arin-ppml] Expanding Scope? :Draft Policy ARIN-2017-8: Amend the definition of Community Network In-Reply-To: References: Message-ID: David: ISOC proposes that "*Community networks, communications infrastructure deployed and operated by citizens to meet their own communication needs*" ( http://www.internetsociety.org/what-we-do/community-networks). The problem is *if* ARIN should support this connectivity initiative, and *how*. The community network's focus should be providing connectivity rather than achieving a profit. The definition is the problem, as identifying a "proper" community network will allow to work on a real solution. Jos? R. de la Cruz jrdelacruz at acm.org On Fri, Aug 25, 2017 at 9:42 AM, David Farmer wrote: > Ok, then I need to hear from others in the community on the subject > expanding the scope of the problem statement for this Draft Policy beyond > the just the Definition of Community Networks at this point; > > Should we revise the problem statement beyond it's current scope? > > If yes, then what should the revised problem statement include? > > Thanks > > On Thu, Aug 24, 2017 at 11:19 PM, Kevin Blumberg > wrote: > >> David, >> >> >> >> I see that the revised text addresses some of the definition issues. >> Regarding your question I believe that the definition and section 6.5.9 are >> intrinsically tied together. >> >> >> >> Currently the only active part of Community Networks is the state that it >> will be considered an end-user regarding ?all ARIN purposes?. I have an >> issue if this is used by Organizations to act as a way of opting-out of >> SWIP requirements. With a substantially expanded definition the number of >> Organizations that could use the policy is significant. >> >> >> >> Another interesting problem comes from the new Registration Services Plan >> (https://www.arin.net/fees/fee_schedule.html) >> >> >> >> ?Organizations that choose to convert to the Registration Services Plan >> will be evaluated as an ISP from a policy perspective when requesting >> future Internet number resources from ARIN. The applicable annual >> registration services plan will be invoiced annually based on the >> organization resources in the ARIN registry.? >> >> >> >> Kevin Blumberg >> >> >> >> *From:* David Farmer [mailto:farmer at umn.edu] >> *Sent:* Thursday, August 24, 2017 3:05 PM >> *To:* Kevin Blumberg >> *Cc:* arin-ppml at arin.net >> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-8: Amend the >> definition of Community Network >> >> >> >> Kevin, >> >> >> >> There was a little confusion, mostly on my part it seems. Cutting to the >> chase; An older version of the text got sent out with the announcement of >> this policy. An updated version of text got sent out earlier today, it >> addresses some but for sure not all of your points. >> >> >> >> As for several of the broader points you bring up, I'd like to work on >> updating the definition for Community Networks first, mostly because that >> is the scope of the problem statement focuses on. Once we develop some >> consensus around a new definition for Community Networks, then I think we >> could build on that and look at some of the broader issues you bring up. >> Would that plan work for you? >> >> >> >> Thanks >> >> >> >> On Wed, Aug 23, 2017 at 2:22 PM, Kevin Blumberg >> wrote: >> >> I do not support the policy as written but do support the overall intent. >> >> 1) The definition of a community network has gone from overly specific to >> overly broad. An example in Canada there are over 160,000 non-profit and >> not-for-profit organizations. >> 2) A volunteer group, that is not an organization, wouldn't be able to >> get space from ARIN as it requires a business registration (ARIN Staff >> please confirm). >> 3) Why is there a limit to only post-secondary institutions? Many rural >> locations have K-12 that would not qualify. >> 4) In Canada, a charity is a non-profit organization, more generic terms >> should be used that covers the entire ARIN serving region. >> 5) The current Community Networks policy conflicts with the intent of >> 2017-5 Improved IPv6 Registration Requirements. By placing all space into >> End User assignment, Community Networks operating as a ISP collective for >> residential subscribers would be unable to reassign static assignments. >> >> The current Community Networks policy requires an applicant to qualify >> under standard end-user requirements (Section 6.5.9.2). If there is no >> difference to the qualification criteria, why would an organization go out >> of the way to qualify as a Community Network? >> >> I wrote a policy in 2016 that tried to address some of these issues, it >> was abandoned at the time ( https://www.arin.net/policy/pr >> oposals/2016_7.html ) >> >> Kevin Blumberg >> >> -----Original Message----- >> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >> Sent: Tuesday, August 22, 2017 12:40 PM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of >> Community Network >> >> On 17 August 2017 the ARIN Advisory Council (AC) advanced >> "ARIN-prop-243: Amend the Definition of Community Network" to Draft >> Policy status. >> >> Draft Policy ARIN-2017-8 is below and can be found at: >> https://www.arin.net/policy/proposals/2017_8.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 >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> Draft Policy ARIN-2017-8: Amend the Definition of Community Network >> >> Problem Statement: >> >> The Community Networks section of the NRPM has not been used since >> implementation in January 2010. Proposal ARIN-2016-7, to increase the >> number of use cases, was abandoned by the Advisory Council due to lack of >> feedback. Proposal ARIN 2017-2, to remove all mention of community networks >> from NRPM was met with opposition by the community. Many responded that the >> definition of ?community network? was too narrow, which could be the reason >> for lack of uptake. >> >> Policy statement: >> >> CURRENT NRPM TEXT: >> >> ?2.11. Community Network >> >> A community network is any network organized and operated by a volunteer >> group operating as or under the fiscal support of a nonprofit organization >> or university for the purpose of providing free or low-cost connectivity to >> the residents of their local service area. To be treated as a community >> network under ARIN policy, the applicant must certify to ARIN that the >> community network staff is 100% volunteers.? >> >> NEW NRPM TEXT: >> >> ?2.11 Community Network >> >> A community network is a network organized and operated by a volunteer >> group, not-for-profit, non-profit, charitable organization, or >> post-secondary institution for the purpose of providing free or low-cost >> connectivity to residents in their service area. Critical functions may be >> handled by paid staff, but volunteers play a large role in offering >> services available through community networks.? >> >> Comments: >> >> Timetable for implementation: Immediate >> _______________________________________________ >> 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: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at 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 at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> >> >> >> >> -- >> >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> =============================================== >> > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Aug 28 13:32:41 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Aug 2017 10:32:41 -0700 Subject: [arin-ppml] ARIN-PPML 2017-6 draft policy In-Reply-To: <000801d31c18$766527d0$632f7770$@iptrading.com> References: <84C695FE-80CE-44C1-A608-6FC459125827@delong.com> <000801d31c18$766527d0$632f7770$@iptrading.com> Message-ID: <02BBAA1A-8231-4BA4-BC94-4AAF3EC33275@delong.com> > On Aug 23, 2017, at 07:02 , Mike Burns wrote: > > I oppose this policy, although I do understand and agree with the gut feeling expressed in this thread. For many reasons, a free and global market in IPv4 addresses, which mirrors the goal of a free and global delivery of packets, is what I think would be best. And this requires trade in all directions. > > However, let us not throw out the baby with the bathwater. > Let?s unpack that gut feeling. I think the gut could be reacting in two ways. First, there is a ?balance of trade? argument, which rejects one-way trade barriers as something to be fought against. Why let our valuable commodities flow only outwards towards the world? > > Second, there is the fairness issue. We all have a sense of fairness and on the face of it, this is patently unfair. > > For the first argument, let me say that we have North American address owners seeking to sell, and this proposal artificially limits their ability to do that. Is it proper, and our role, to punish these North American entities? Is the correct answer to limited trade even more limited trade? And what of that trade imbalance, wouldn?t this proposal exacerbate that imbalance by precluding the sale of North American assets to swaths of the world? On the surface, I?d agree with you. However, the reality is that as much as North American address owners are seeking to sell, there is an even greater demand for addresses in Asia and as such, I believe this may be the most effective possible way to push for change to these one-way policies and I am confident that any additional limitations imposed by this policy change would likely be short-lived. > For the second argument, fairness, let us regard the fairness of ipv4 distribution around the world. I know the gut feeling of some in Latin America or Asia or Africa regarding this issue of fairness would have a different expression, when they see that every North American citizen got 5 addresses and every one of them got to share a single ipv4 address with 1000 of their neighbors. Yes, for some countries the ratio is 5000:1 in our favor. > http://www.nationmaster.com/country-info/stats/Media/Internet/IP-addresses-per-capita It is not my intent here to prevent the flow of addresses to any of these regions, but, to make sure that if we do permit that flow, we do so on an equitable basis with a level playing field. > RIPE, the registry which I consider most advanced in terms of IPv4 market policies, and the registry which processes the largest number of transfers, has already agreed to send addresses via a one-way policy to other RIRs. This is a logical fallacy in my opinion. You consider them the most advanced essentially because they have the most transfers and the least restrictions. Sure, the most transfers is a direct consequence of having the least restrictions, but that doesn?t mean it?s the best or most optimal policy. We must ask ourselves whether the goal is to maximize the mobility of IPv4 address resources, or, to ensure the fairest and best distribution of them to those with need. RIPE does a great job of mobility, to be sure. However, I think there?s plenty of evidence that they are not so good at fairest or best distribution. > LACNIC and AFRINIC have discussed one-way policies, and I think it is easy to understand, from their perspectives, the fear of allowing already scarce addresses to leave those regions. I have heard the fear that this would provide incentive for networks in their region to convert to CGN in order to sell their resources to the wealthy nations who already enjoy many addresses. While I recognize and understand the fear in question, I think it?s not as likely to materialize as some would have us believe. I also think that it?s much less of a concern once the free pool in the region is fully depleted. I notice you specifically don?t address CNNIC or KRNIC (both of which are NIRs which are relatively rich in addresses, but have existing one-way policies rather than theoretical one-way policies). The reality is that at this time, this proposal would not affect AFRINIC or LACNIC where one way policies are a purely theoretical discussion so far, but would immediately impact APNIC, KRNIC, and CNNIC directly because of the one-way policies in KRNIC and CNNIC and the current policy in APNIC allowing transfers to those NIRs. > But the bottom line is that address flow is a result of market forces and not policy. When the supply is in one region and the demand in another, forces act as one would expect to move addresses. But when registry stewards stand athwart that flow and say ?Stop! Our regard for fairness is outraged!? then, like water finds its level, addresses will find their way to those in need. The net result is things like zombie corporations changing hands, leases which are invisible to Whois, artificial pricing imbalances, and overall unpleasantness. Will some of this happen? Sure. However, since at least in the case of KRNIC and CNNIC, there are strong barriers to routing addresses which haven?t actually been transferred into the respective NIRs within those countries, it actually becomes much more difficult to circumvent the official transfer policies in a useful way. > Let?s accept one-way transfers as a recognition of the reality of the historical artifact of address allocation, and as a step in the direction of a true global market, albeit a half-step. This proposal, on the other hand, is a step backwards. Those one-way regions are not suppliers of addresses to the market, so requiring outbound transfers from them will have no effect. On the other hand, denying needed addresses to these address-poor regions will affect them direly. Let?s not. This is a really bad idea and if we don?t put a stop to it now, it will likely never get corrected. Owen > > Regards, > Mike Burns > > > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Rudolph Daniel > Sent: Wednesday, August 23, 2017 9:15 AM > To: Owen DeLong > > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-PPML 2017-6 draft policy > > Thank you Owen, and I remember those exact words when the policy was formulated and I accept that too. Of course, the community did not, at that time see the loop hole we are currently trying to close. So I was being cautious in that whilst we can modify the wording, to achieve a close, is arin staff also confident that it can be implemented. Of course I also appreciate that what ever we as a community do, there is always some out there looking or searching for yet another loop hole. > rd > > > Rudi Daniel > danielcharles consulting > > > > On Tue, Aug 22, 2017 at 6:15 PM, Owen DeLong > wrote: >> It is achievable because ARIN will evaluate the policy of each RIR in this regard prior to approving the transfer. >> >> Owen >> >>> On Aug 18, 2017, at 12:36 , Rudolph Daniel > wrote: >>> >>> " Recipient RIR policy must not permit transfers to other RIRs or NIRs whose policies do not support bi-directional transfers." >>> Whereas I am in support of closing this loophole, I cannot be sure that this is actually achievable... >>> rd >>> >>> On Aug 17, 2017 6:01 PM, > wrote: >>>> Send ARIN-PPML mailing list submissions to >>>> arin-ppml at arin.net >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> or, via email, send a message with subject or body 'help' to >>>> arin-ppml-request at arin.net >>>> >>>> You can reach the person managing the list at >>>> arin-ppml-owner at arin.net >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of ARIN-PPML digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>> 1. Re: Revised: Draft Policy ARIN-2017-5: Equalization of >>>> Assignment Registration requirements between IPv4 and IPv6 >>>> (Paul McNary) >>>> 2. Draft Policy 2017-6: Improve Reciprocity Requirements for >>>> Inter RIR Transfers (WOOD Alison * DAS) >>>> 3. Re: Revised: Draft Policy ARIN-2017-5: Equalization of >>>> Assignment Registration requirements between IPv4 and IPv6 >>>> (hostmaster at uneedus.com ) >>>> 4. Re: Revised: Draft Policy ARIN-2017-5: Equalization of >>>> Assignment Registration requirements between IPv4 and IPv6 >>>> (David Farmer) >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Thu, 17 Aug 2017 15:49:47 -0500 >>>> From: Paul McNary > >>>> To: "arin-ppml at arin.net " > >>>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: >>>> Equalization of Assignment Registration requirements between IPv4 and >>>> IPv6 >>>> Message-ID: <7460ee99-c116-7c0a-b726-2267de135596 at cameron.net > >>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>> >>>> Sorry I typed the numbers backwards, yes, that is what I meant. :-) >>>> >>>> A /48 is smaller than a /47 and would not be required to be registered? >>>> A /47 would need to be >>>> >>>> >>>> On 8/17/2017 1:30 PM, Chris Woodfield wrote: >>>> > The opposite - a /47 is 2 /48s aggregated. >>>> > >>>> > -C >>>> > >>>> >> On Aug 17, 2017, at 11:26 AM, Paul McNary > wrote: >>>> >> >>>> >> A /47 is smaller than a /48 and would not be required to be registered? >>>> >> >>>> >> >>>> >> On 8/17/2017 12:50 PM, hostmaster at uneedus.com wrote: >>>> >>> I note that any ISP size reassignment, with the recommended /48 for each end user site, will be /47 or larger, which must always be registered. >>>> >>> >>>> >>> Thus, I think 6.5.5.5 language is unneeded, since any LIR/ISP reassignment will be large enough to already trigger registration. >>>> >>> >>>> >>> Under the current policy, LIR's and ISP's are equal, so usually both terms are stated in any policy that mentions them. >>>> >>> >>>> >>> May I also suggest that if we are going to require registration upon downstream request for IPv6, that we consider placing the same language and requirements for IPv4 customers as well? And if we do, where do we draw the minimum line? Maybe a /32.... >>>> >>> >>>> >>> Also, good catch on the cut and paste error..... >>>> >>> >>>> >>> Albert Erdmann >>>> >>> Network Administrator >>>> >>> Paradise On Line Inc. >>>> >>> >>>> >>> >>>> >>> On Thu, 17 Aug 2017, Leif Sawyer wrote: >>>> >>> >>>> >>>> Thanks for the feedback, David. >>>> >>>> >>>> >>>> I've added the fix for 6.5.5.2, since we're already in the section. >>>> >>>> >>>> >>>> I've also modified the text for 6.5.5.4 as well, because I think your suggesting is a little cleaner. >>>> >>>> >>>> >>>> I'm not sure what the point of 6.5.5.5 is - you're just reiterating 6.5.5.1. >>>> >>>> That said, we could potentially clean up 6.5.5.1 by extending "static IPv6 assignment" >>>> >>>> to "static IPv6 assignment, or allocation," - or something similar. >>>> >>>> >>>> >>>> >>>> >>>> Which also brings to mind the question: LIR or ISP? Both are in use in 6.5.... >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> From: ARIN-PPML [arin-ppml-bounces at arin.net ] on behalf of David Farmer [farmer at umn.edu ] >>>> >>>> Sent: Thursday, August 17, 2017 8:53 AM >>>> >>>> To: hostmaster at uneedus.com >>>> >>>> Cc: arin-ppml at arin.net >>>> >>>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 >>>> >>>> >>>> >>>> [External Email] >>>> >>>> >>>> >>>> Here is a slightly different formulation to consider. I refactored the title a little, and based the phrasing on other parts of section 6.5.5 >>>> >>>> >>>> >>>> 6.5.5.4 Registration Requested by Recipient >>>> >>>> >>>> >>>> If requested by the downstream recipient of a block, each static IPv6 assignment containing a /64 or more addresses, shall be registered, as described in section 6.5.5.1. >>>> >>>> >>>> >>>> I'd like us to think about adding an additional section, based on previous discussions. >>>> >>>> >>>> >>>> 6.5.5.5 Re-allocation to ISPs >>>> >>>> >>>> >>>> Each IPv6 re-allocation to a downstream ISP, regardless of size, intended for further assignment by the downstream ISP's to it's customers, shall be registered, as described in section 6.5.5.1 >>>> >>>> >>>> >>>> Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. I think this is a cut and past error, I think the reference should be to 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with sections 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. >>>> >>>> >>>> >>>> Thanks. >>>> >>>> >>>> >>>> On Wed, Aug 16, 2017 at 6:10 AM, >> wrote: >>>> >>>> I am in favor of the draft, with or without the changes to make it clearer. >>>> >>>> >>>> >>>> I suggest the following language for clarity: >>>> >>>> >>>> >>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM that reads "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that static assignment in ARIN's registration database, the ISP must register that static assignment." >>>> >>>> >>>> >>>> Since "static assignment" is the term in this section, not netblock, I suggest using this term instead of "netblock". "Of any size" is not needed, as the language would require the ISP to register in total whatever size the ISP has assigned to the downstream in the ARIN database if requested by the downstream recipient, as long as it was /64 or more. >>>> >>>> >>>> >>>> This language would also prevent requests to register only part of an assignment. I think this language works in making the intent of the new section more clear. >>>> >>>> >>>> >>>> Albert Erdmann >>>> >>>> Network Administrator >>>> >>>> Paradise On Line Inc. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, 15 Aug 2017, John Santos wrote: >>>> >>>> >>>> >>>> I think that the "/64 or more addresses" and the "regardless of size" are meant to convey that any netblock between a /64 and a /48 can and should be registered if the recipient requests it, even if the block is smaller than the /47 which would make it mandatory. Perhaps there is better wording that would make this clearer. >>>> >>>> >>>> >>>> Three ranges: >>>> >>>> >>>> >>>> 1. smaller than /64: shouldn't be issued, can't be registered. >>>> >>>> 2. /64 through /48: register at recipient's request >>>> >>>> 3. /47 or larger: must be registered >>>> >>>> >>>> >>>> I agree on dynamic assignments >>>> >>>> >>>> >>>> Otherwise, I think this is a much clearer and better update to the proposed policy, and can't find any other reason not to support it. (I.E. this is a tentative vote FOR, if there is such a thing.) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 8/15/2017 3:59 PM, David Farmer wrote: >>>> >>>> I support what I think is the intent, but I have language/editorial nits; >>>> >>>> >>>> >>>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of size" that requires registration? I think logically we need one or the other, or some qualification on "regardless of size" statement. I think it is a good idea to not require registration of less than a /64. But the current language seems contradictory, and therefore confusing, my recommendation is delete "regardless of size", from the sentence and leaving "a /64 or more addresses". I pretty sure we don't want people having an expectation that they can request the registration of "their" /128 address. >>>> >>>> >>>> >>>> 2. Also in 3) below; It would seem to require even dynamic assignments be registered if requested, I don't think that is our intent either, section 6.5.5.1 starts with "Each static IPv6 assignment containing", this needs a similar qualification. >>>> >>>> >>>> >>>> Also, I'm fine with the deltas in the policy statement but it would be helpful to see the final resulting policy block, maybe in a separate email so we can all see how the result reads. >>>> >>>> >>>> >>>> Thanks, I think we are getting close, maybe one or two more turns of the crank. >>>> >>>> >>>> >>>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN > >>> wrote: >>>> >>>> >>>> >>>> The following has been revised: >>>> >>>> >>>> >>>> * Draft Policy ARIN-2017-5: Equalization of Assignment >>>> >>>> Registration requirements between IPv4 and IPv6 >>>> >>>> >>>> >>>> Revised text is below and can be found at: >>>> >>>> https://www.arin.net/policy/proposals/2017_5.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 > >>>> >>>> >> >>>> >>>> >>>> >>>> Draft Policies and Proposals under discussion can be found at: >>>> >>>> https://www.arin.net/policy/proposals/index.html > >>>> >>>> >> >>>> >>>> >>>> >>>> Regards, >>>> >>>> >>>> >>>> Sean Hopkins >>>> >>>> Policy Analyst >>>> >>>> American Registry for Internet Numbers (ARIN) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 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 subdelegation 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" >>>> >>>> >>>> >>>> and >>>> >>>> >>>> >>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to >>>> >>>> the NRPM that reads "If the downstream recipient of a netblock ( a >>>> >>>> /64 or more addresses) requests publishing in ARIN's registration >>>> >>>> database, the ISP must register the netblock, regardless of size." >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> -- >>>> >>>> John Santos >>>> >>>> Evans Griffiths & Hart, Inc. >>>> >>>> 781-861-0670 ext 539 20539> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> 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: >>>> >>>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>>> >>>> Please contact info at arin.net > if you experience any issues. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> =============================================== >>>> >>>> David Farmer Email:farmer at umn.edu > >>>> >>>> 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 (ARIN-PPML at arin.net ). >>>> >>> Unsubscribe or manage your mailing list subscription at: >>>> >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> >>> Please contact info at 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 at arin.net ). >>>> >> Unsubscribe or manage your mailing list subscription at: >>>> >> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> >> Please contact info at arin.net if you experience any issues. >>>> >> >>>> > >>>> > >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 2 >>>> Date: Thu, 17 Aug 2017 20:54:23 +0000 >>>> From: WOOD Alison * DAS > >>>> To: "arin-ppml at arin.net " > >>>> Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity >>>> Requirements for Inter RIR Transfers >>>> Message-ID: >>>> > >>>> Content-Type: text/plain; charset="us-ascii" >>>> >>>> Thank you for the feedback on this draft policy to date. I would appreciate any other thoughts or comments on this draft policy. >>>> >>>> For review, Draft Policy 2017-6 is intended to add the following conditions on Inter RIR transfers to section 8.4: >>>> >>>> Recipient RIR policy must not permit transfers to other RIRs or NIRs whose policies do not support bi-directional transfers. >>>> >>>> And the problem statement on this draft policy is: >>>> >>>> Currently ARIN's requirement that inter-RIR transfer policies be reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a two-hop RIR transfer process can be used to circumvent the intent of the requirement. Rather than eliminate the requirement, a better approach would be to close the loophole. >>>> >>>> All feedback is appreciated. >>>> >>>> Thank you >>>> >>>> -Alison Wood >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: > >>>> >>>> ------------------------------ >>>> >>>> Message: 3 >>>> Date: Thu, 17 Aug 2017 18:00:05 -0400 (EDT) >>>> From: hostmaster at uneedus.com >>>> To: "arin-ppml at arin.net " > >>>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: >>>> Equalization of Assignment Registration requirements between IPv4 and >>>> IPv6 >>>> Message-ID: > >>>> Content-Type: text/plain; charset="x-unknown"; Format="flowed" >>>> >>>> While the most recent drafts have not dealt with IPv4, in the last round >>>> there was a proposal to require registration upon request of the >>>> downstream customer of their IPv6 assignment. >>>> >>>> If we intend to provide that power to require registration for IPv6 >>>> customer assignments upon request, in fairness we should also use the same >>>> language in a new 4.2.3.7.4 to allow static IPv4 customers that same >>>> power. I suggest /32 as the limit, as /29 or more already has required >>>> registration. The same problems identfied in not being able to register >>>> assignments with ARIN for v6 are also true for v4 assignments between >>>> those limits. >>>> >>>> Since both protocols are still being addressed and attempts are being >>>> made by the draft to make v6 equal or better than v4, the title should >>>> remain. The only thing we have done is not shift the v4 limit of /29. >>>> >>>> Albert Erdmann >>>> Network Administrator >>>> Paradise On Line Inc. >>>> >>>> >>>> > While we???re turning the crank, can we please fix the title since IPv4 >>>> > is no longer relevant to the proposal and there???s really no >>>> > equalization happening? >>>> > >>>> > Perhaps ???Improved Registration Requirements for IPv6??? >>>> > >>>> > Owen >>>> >>>> ------------------------------ >>>> >>>> Message: 4 >>>> Date: Thu, 17 Aug 2017 17:01:09 -0500 >>>> From: David Farmer > >>>> To: Leif Sawyer > >>>> Cc: "hostmaster at uneedus.com " >, >>>> "arin-ppml at arin.net " > >>>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: >>>> Equalization of Assignment Registration requirements between IPv4 and >>>> IPv6 >>>> Message-ID: >>>> > >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> On Thu, Aug 17, 2017 at 1:43 PM, David Farmer > wrote: >>>> >>>> > Inline. >>>> > >>>> > On Thu, Aug 17, 2017 at 12:29 PM, Leif Sawyer > wrote: >>>> > >>>> >> Thanks for the feedback, David. >>>> >> >>>> > ... >>>> >>>> > I'm not sure what the point of 6.5.5.5 is - you're just reiterating >>>> >> 6.5.5.1. >>>> >> That said, we could potentially clean up 6.5.5.1 by extending "static >>>> >> IPv6 assignment" >>>> >> to "static IPv6 assignment, or allocation," - or something similar. >>>> >> >>>> > >>>> > ISP re-allocations need to be registered regardless of size or if it is >>>> > being advertised or not. For example, if for some stupid reason a /56 was >>>> > re-allocated to downsterm ISP so they could assign /64s to customers that >>>> > has to be registered, by 6.5.5.1 that wouldn't have to be registered. >>>> > Should you re-allocate a /56, @!@#$ NO!!! But if you did, it has to be >>>> > registered. This is so LEA and other legal requests get directly to the >>>> > correct ISP the first time. I think this is important enough issue that it >>>> > should have it's own section, and not get blended in to 6.5.5.1. >>>> > >>>> > Now should that be part of this policy maybe not, maybe this belongs in >>>> > ARIN-2017-3 or whole new separate policy proposal instead. >>>> > >>>> >>>> Thinking about this for the last couple hours I'm thinking 6.5.5.5 this >>>> should not be part of this policy. As similar text should be added in the >>>> IPv4 section, and this should have a somewhat different problem statement >>>> as well. >>>> >>>> -- >>>> =============================================== >>>> David Farmer Email:farmer at umn.edu >>>> 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 >>>> =============================================== >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: > >>>> >>>> ------------------------------ >>>> >>>> Subject: Digest Footer >>>> >>>> _______________________________________________ >>>> ARIN-PPML mailing list >>>> ARIN-PPML at arin.net >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> >>>> ------------------------------ >>>> >>>> End of ARIN-PPML Digest, Vol 146, Issue 10 >>>> ****************************************** >>> >>> _______________________________________________ >>> 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: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Aug 28 13:38:11 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Aug 2017 10:38:11 -0700 Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers In-Reply-To: References: <415F505D-1A01-4B43-9386-4F29013D8F4B@panix.com> <4603E5A4-8DEB-4F14-BA93-941C0A75D00D@delong.com> Message-ID: <0FC29BBC-0F4C-4471-A703-AE08838533B0@delong.com> > On Aug 23, 2017, at 11:25 , Michael Sinatra wrote: > > On 08/23/17 10:56, David Farmer wrote: > >> You want to break 94% of the transfers between APNIC and ARIN because >> you don't like 6% of them. >> >> AfriNIC is discussing a similar proposal and a similar proposal was >> discussed in LACNIC. >> >> >> Help me understand this, we are going to break transfers to APNIC in >> hopes that ArfNIC and LACNIC won't pass a policy? Please explain how >> you expect that to work. > > Without asserting for/against this proposal, I'd like a bit more > information. ISTR an incident in the AfriNIC region where there was an > abuse of some policy which resulted in the acquisition of resources in > that region for the express (or perhaps covert) purpose of transfer to, > and sale in, the APNIC region. I don?t believe that?s the case? I think that the incident to which you are referring is a little different and I?ll send you more details off-list. AfriNIC policy never (to date) allowed any sort of transfer or sale into APNIC, and I do not know of any such move. > Did such an incident happen and is this (or possibly AfriNIC's proposed) > policy based on that? Any other references that anyone can provide? > (Right now, I am interested in cases, not quantitative studies, although > I am still sympathetic to quantitative arguments.) Will send you more details on the specific case off-list. Owen From rudi.daniel at gmail.com Mon Aug 28 14:01:52 2017 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Mon, 28 Aug 2017 15:01:52 -0300 Subject: [arin-ppml] ARIN-PPML 2017-8 Message-ID: Support changing the definition of community networks. 'The community network's focus should be providing connectivity rather than achieving a profit' Jos? I am still absorbing the isoc language, but 'profit' is not the correct terminology for a not- profit....maybe 'excess' ?? RD On Aug 27, 2017 9:45 PM, wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Revised: Draft Policy ARIN-2017-8: Amend the Definition > of Community Network (Carlton Samuels) > 2. Re: Expanding Scope? :Draft Policy ARIN-2017-8: Amend the > definition of Community Network (Jose R. de la Cruz III) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 25 Aug 2017 10:00:06 -0500 > From: Carlton Samuels > To: ARIN > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the > Definition of Community Network > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > I support this change to the definition of community networks. > > -Carlton Samuels > > source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> > Virus-free. > www.avast.com > source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > ============================== > *Carlton A Samuels* > > *Mobile: 876-818-1799Strategy, Planning, Governance, Assessment & > Turnaround* > ============================= > > On Thu, Aug 24, 2017 at 10:22 AM, ARIN wrote: > > > The following has been revised: > > > > * Draft Policy ARIN-2017-8: Amend the Definition of Community Network > > > > Revised text is below and can be found at: > > https://www.arin.net/policy/proposals/2017_8.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 > > > > Draft Policies and Proposals under discussion can be found at: > > https://www.arin.net/policy/proposals/index.html > > > > Regards, > > > > Sean Hopkins > > Policy Analyst > > American Registry for Internet Numbers (ARIN) > > > > > > > > Draft Policy ARIN-2017-8: Amend the Definition of Community Network > > > > Problem Statement: > > > > The Community Networks section of the NRPM has not been used since > > implementation in January 2010. Proposal ARIN-2016-7, to increase the > > number of use cases, was abandoned by the Advisory Council due to lack of > > feedback. Proposal ARIN 2017-2, to remove all mention of community > networks > > from NRPM was met with opposition by the community. Many responded that > the > > definition of ?community network? was too narrow, which could be the > reason > > for lack of uptake. > > > > Policy statement: > > > > CURRENT NRPM TEXT: > > > > ?2.11. Community Network > > > > A community network is any network organized and operated by a volunteer > > group operating as or under the fiscal support of a nonprofit > organization > > or university for the purpose of providing free or low-cost connectivity > to > > the residents of their local service area. To be treated as a community > > network under ARIN policy, the applicant must certify to ARIN that the > > community network staff is 100% volunteers.? > > > > NEW NRPM TEXT: > > > > ?2.11 Community Network > > > > A community network is a network organized and operated by a volunteer > > group, not-for-profit, non-profit, charitable organization, or > educational > > institution for the purpose of providing free or low-cost connectivity, > or > > other Information Technology services to persons or entities within their > > community. Critical functions may be handled by paid staff, but > volunteers > > play a large role in offering services available through community > > networks.? > > > > Comments: > > > > Timetable for implementation: Immediate > > _______________________________________________ > > 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: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20170825/907149d0/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Sun, 27 Aug 2017 21:45:11 -0400 > From: "Jose R. de la Cruz III" > To: David Farmer > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Expanding Scope? :Draft Policy ARIN-2017-8: > Amend the definition of Community Network > Message-ID: > vdAMxA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > David: > > ISOC proposes that "*Community networks, communications infrastructure > deployed and operated by citizens to meet their own communication needs*" ( > http://www.internetsociety.org/what-we-do/community-networks). > > The problem is *if* ARIN should support this connectivity initiative, and > *how*. The community network's focus should be providing connectivity > rather than achieving a profit. The definition is the problem, as > identifying a "proper" community network will allow to work on a real > solution. > > Jos? R. de la Cruz > jrdelacruz at acm.org > > On Fri, Aug 25, 2017 at 9:42 AM, David Farmer wrote: > > > Ok, then I need to hear from others in the community on the subject > > expanding the scope of the problem statement for this Draft Policy beyond > > the just the Definition of Community Networks at this point; > > > > Should we revise the problem statement beyond it's current scope? > > > > If yes, then what should the revised problem statement include? > > > > Thanks > > > > On Thu, Aug 24, 2017 at 11:19 PM, Kevin Blumberg > > wrote: > > > >> David, > >> > >> > >> > >> I see that the revised text addresses some of the definition issues. > >> Regarding your question I believe that the definition and section 6.5.9 > are > >> intrinsically tied together. > >> > >> > >> > >> Currently the only active part of Community Networks is the state that > it > >> will be considered an end-user regarding ?all ARIN purposes?. I have an > >> issue if this is used by Organizations to act as a way of opting-out of > >> SWIP requirements. With a substantially expanded definition the number > of > >> Organizations that could use the policy is significant. > >> > >> > >> > >> Another interesting problem comes from the new Registration Services > Plan > >> (https://www.arin.net/fees/fee_schedule.html) > >> > >> > >> > >> ?Organizations that choose to convert to the Registration Services Plan > >> will be evaluated as an ISP from a policy perspective when requesting > >> future Internet number resources from ARIN. The applicable annual > >> registration services plan will be invoiced annually based on the > >> organization resources in the ARIN registry.? > >> > >> > >> > >> Kevin Blumberg > >> > >> > >> > >> *From:* David Farmer [mailto:farmer at umn.edu] > >> *Sent:* Thursday, August 24, 2017 3:05 PM > >> *To:* Kevin Blumberg > >> *Cc:* arin-ppml at arin.net > >> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-8: Amend the > >> definition of Community Network > >> > >> > >> > >> Kevin, > >> > >> > >> > >> There was a little confusion, mostly on my part it seems. Cutting to the > >> chase; An older version of the text got sent out with the announcement > of > >> this policy. An updated version of text got sent out earlier today, it > >> addresses some but for sure not all of your points. > >> > >> > >> > >> As for several of the broader points you bring up, I'd like to work on > >> updating the definition for Community Networks first, mostly because > that > >> is the scope of the problem statement focuses on. Once we develop some > >> consensus around a new definition for Community Networks, then I think > we > >> could build on that and look at some of the broader issues you bring up. > >> Would that plan work for you? > >> > >> > >> > >> Thanks > >> > >> > >> > >> On Wed, Aug 23, 2017 at 2:22 PM, Kevin Blumberg > >> wrote: > >> > >> I do not support the policy as written but do support the overall > intent. > >> > >> 1) The definition of a community network has gone from overly specific > to > >> overly broad. An example in Canada there are over 160,000 non-profit and > >> not-for-profit organizations. > >> 2) A volunteer group, that is not an organization, wouldn't be able to > >> get space from ARIN as it requires a business registration (ARIN Staff > >> please confirm). > >> 3) Why is there a limit to only post-secondary institutions? Many rural > >> locations have K-12 that would not qualify. > >> 4) In Canada, a charity is a non-profit organization, more generic terms > >> should be used that covers the entire ARIN serving region. > >> 5) The current Community Networks policy conflicts with the intent of > >> 2017-5 Improved IPv6 Registration Requirements. By placing all space > into > >> End User assignment, Community Networks operating as a ISP collective > for > >> residential subscribers would be unable to reassign static assignments. > >> > >> The current Community Networks policy requires an applicant to qualify > >> under standard end-user requirements (Section 6.5.9.2). If there is no > >> difference to the qualification criteria, why would an organization go > out > >> of the way to qualify as a Community Network? > >> > >> I wrote a policy in 2016 that tried to address some of these issues, it > >> was abandoned at the time ( https://www.arin.net/policy/pr > >> oposals/2016_7.html ) > >> > >> Kevin Blumberg > >> > >> -----Original Message----- > >> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN > >> Sent: Tuesday, August 22, 2017 12:40 PM > >> To: arin-ppml at arin.net > >> Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of > >> Community Network > >> > >> On 17 August 2017 the ARIN Advisory Council (AC) advanced > >> "ARIN-prop-243: Amend the Definition of Community Network" to Draft > >> Policy status. > >> > >> Draft Policy ARIN-2017-8 is below and can be found at: > >> https://www.arin.net/policy/proposals/2017_8.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 > >> > >> Draft Policies and Proposals under discussion can be found at: > >> https://www.arin.net/policy/proposals/index.html > >> > >> Regards, > >> > >> Sean Hopkins > >> Policy Analyst > >> American Registry for Internet Numbers (ARIN) > >> > >> > >> > >> Draft Policy ARIN-2017-8: Amend the Definition of Community Network > >> > >> Problem Statement: > >> > >> The Community Networks section of the NRPM has not been used since > >> implementation in January 2010. Proposal ARIN-2016-7, to increase the > >> number of use cases, was abandoned by the Advisory Council due to lack > of > >> feedback. Proposal ARIN 2017-2, to remove all mention of community > networks > >> from NRPM was met with opposition by the community. Many responded that > the > >> definition of ?community network? was too narrow, which could be the > reason > >> for lack of uptake. > >> > >> Policy statement: > >> > >> CURRENT NRPM TEXT: > >> > >> ?2.11. Community Network > >> > >> A community network is any network organized and operated by a volunteer > >> group operating as or under the fiscal support of a nonprofit > organization > >> or university for the purpose of providing free or low-cost > connectivity to > >> the residents of their local service area. To be treated as a community > >> network under ARIN policy, the applicant must certify to ARIN that the > >> community network staff is 100% volunteers.? > >> > >> NEW NRPM TEXT: > >> > >> ?2.11 Community Network > >> > >> A community network is a network organized and operated by a volunteer > >> group, not-for-profit, non-profit, charitable organization, or > >> post-secondary institution for the purpose of providing free or low-cost > >> connectivity to residents in their service area. Critical functions may > be > >> handled by paid staff, but volunteers play a large role in offering > >> services available through community networks.? > >> > >> Comments: > >> > >> Timetable for implementation: Immediate > >> _______________________________________________ > >> 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: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at 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 at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > >> > >> > >> > >> > >> > >> -- > >> > >> =============================================== > >> David Farmer Email:farmer at umn.edu > >> Networking & Telecommunication Services > >> Office of Information Technology > >> University of Minnesota > >> 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > >> =============================================== > >> > > > > > > > > -- > > =============================================== > > David Farmer Email:farmer at umn.edu > > Networking & Telecommunication Services > > Office of Information Technology > > University of Minnesota > > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > > =============================================== > > > > _______________________________________________ > > 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: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20170827/07180205/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > ------------------------------ > > End of ARIN-PPML Digest, Vol 146, Issue 22 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Mon Aug 28 14:14:33 2017 From: mike at iptrading.com (Mike Burns) Date: Mon, 28 Aug 2017 14:14:33 -0400 Subject: [arin-ppml] ARIN-PPML 2017-6 draft policy In-Reply-To: <02BBAA1A-8231-4BA4-BC94-4AAF3EC33275@delong.com> References: <84C695FE-80CE-44C1-A608-6FC459125827@delong.com> <000801d31c18$766527d0$632f7770$@iptrading.com> <02BBAA1A-8231-4BA4-BC94-4AAF3EC33275@delong.com> Message-ID: <001e01d32029$802458d0$806d0a70$@iptrading.com> Let?s not. This is a really bad idea and if we don?t put a stop to it now, it will likely never get corrected. Owen Hi Owen, In almost 5 years of inter-regional transfers, David Farmer identified two transfers of /22s from ARIN into a one-way situation. At this rate, if it doesn?t ?get corrected?, in just 32 years a whole ARIN /16 will have disappeared! Not really that bad. On the other hand, blocking all transfers to APNIC *is* a really bad idea, as is strong-arming that registry *again* through the threat of preventing access to ARIN address space. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajs at anvilwalrusden.com Mon Aug 28 14:51:58 2017 From: ajs at anvilwalrusden.com (Andrew Sullivan) Date: Mon, 28 Aug 2017 14:51:58 -0400 Subject: [arin-ppml] ARIN-PPML 2017-6 draft policy In-Reply-To: <001e01d32029$802458d0$806d0a70$@iptrading.com> References: <84C695FE-80CE-44C1-A608-6FC459125827@delong.com> <000801d31c18$766527d0$632f7770$@iptrading.com> <02BBAA1A-8231-4BA4-BC94-4AAF3EC33275@delong.com> <001e01d32029$802458d0$806d0a70$@iptrading.com> Message-ID: <20170828185158.pdu5pp4zjwgn7ijy@mx4.yitter.info> On Mon, Aug 28, 2017 at 02:14:33PM -0400, Mike Burns wrote: > Let?s not. This is a really bad idea and if we don?t put a stop to it now, it will likely never get corrected. What exactly needs to get corrected, then? You are arguing from a slippery slope, but nobody seems to be slipping. A -- Andrew Sullivan ajs at anvilwalrusden.com From info at arin.net Tue Aug 29 15:20:53 2017 From: info at arin.net (ARIN) Date: Tue, 29 Aug 2017 15:20:53 -0400 Subject: [arin-ppml] Fwd: Advisory Council Meeting Results - August 2017 In-Reply-To: <1c42fbd2-d4b4-1041-1fc5-c95def85d78e@arin.net> References: <1c42fbd2-d4b4-1041-1fc5-c95def85d78e@arin.net> Message-ID: <2ae92228-c1ad-6d03-5a37-15e08573b72b@arin.net> > The AC has abandoned the following Draft Policy: > > ARIN-2017-2: Removal of Community Networks > > The AC provided the following statement: > > "The ARIN Advisory Council has chosen to abandon Policy Proposal 2017-2, "Removal of Community Networks," due to lack of community support and the introduction of an alternative policy proposal to amend the definition of "community network." > > Anyone dissatisfied with this decision may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. > > The AC has abandoned the following Draft Policy: > > ARIN-2017-7: Retire Obsolete Section 4 from the NRPM > > The AC provided the following statement: > > "The ARIN Advisory Council has chosen to abandon Policy Proposal 2017-7, ?Retire Obsolete Section 4 from the NRPM?. This proposal did not gain sufficient community support to justify continuing to move this policy forward, and as such, we have requested that the policy be abandoned." > > Anyone dissatisfied with this decision may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. The minutes from the ARIN Advisory Council's 17 August 2017 meeting have been published: https://www.arin.net/about_us/ac/ac2017_0817.html The petition deadline for both Draft Policy ARIN-2017-2 and Draft Policy ARIN-2017-7 is 3 September 2017 (in five calendar days). For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) -------- Forwarded Message -------- Subject: Advisory Council Meeting Results - August 2017 Date: Tue, 22 Aug 2017 12:38:43 -0400 From: ARIN To: arin-ppml at arin.net In accordance with the Policy Development Process (PDP), the Advisory Council (AC) met on 17 August 2017. The AC has abandoned the following Draft Policy: ARIN-2017-2: Removal of Community Networks The AC provided the following statement: "The ARIN Advisory Council has chosen to abandon Policy Proposal 2017-2, "Removal of Community Networks," due to lack of community support and the introduction of an alternative policy proposal to amend the definition of "community network." Anyone dissatisfied with this decision may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. The AC has abandoned the following Draft Policy: ARIN-2017-7: Retire Obsolete Section 4 from the NRPM The AC provided the following statement: "The ARIN Advisory Council has chosen to abandon Policy Proposal 2017-7, ?Retire Obsolete Section 4 from the NRPM?. This proposal did not gain sufficient community support to justify continuing to move this policy forward, and as such, we have requested that the policy be abandoned." Anyone dissatisfied with this decision may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. The AC has advanced the following Proposal to Draft Policy status (will be posted separately for discussion): ARIN-prop-243: Amend the Definition of Community Network The AC advances Proposals to Draft Policy status once they are found to be within the scope of the PDP, and contain a clear problem statement and suggested changes to Internet number resource policy text. The AC is continuing to work on: * ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation * ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers * ARIN-2017-5: Improved IPv6 Registration Requirements * ARIN-2017-6: Improve Reciprocity Requirement for Inter-RIR Transfers The PDP can be found at: 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 Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) From hostmaster at uneedus.com Tue Aug 29 21:02:46 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Tue, 29 Aug 2017 21:02:46 -0400 (EDT) Subject: [arin-ppml] Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: I think we got it this time. I support. Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 22 Aug 2017, ARIN wrote: > The following has been revised: > > * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_5.html > > Note that the Draft Policy title has changed from "Equalization of Assignment > Registration requirements between IPv4 and IPv6" > > 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 > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > > 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 > 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 must 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 (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From jschiller at google.com Wed Aug 30 13:15:41 2017 From: jschiller at google.com (Jason Schiller) Date: Wed, 30 Aug 2017 13:15:41 -0400 Subject: [arin-ppml] Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: The new policy (along with pre-existing text) will read as follows: 6.5.5.1. Reassignment information Each static IPv6 assignment 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 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 6.5.5.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. 6.5.5.4 Registration Requested by Recipient 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 must register that assignment as described in section 6.5.5.1. On Tue, Aug 29, 2017 at 9:02 PM, wrote: > I think we got it this time. > > I support. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > > On Tue, 22 Aug 2017, ARIN wrote: > > The following has been revised: >> >> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_5.html >> >> Note that the Draft Policy title has changed from "Equalization of >> Assignment Registration requirements between IPv4 and IPv6" >> >> 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 >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >> >> 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 >> 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 must 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 (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Wed Aug 30 13:27:32 2017 From: jschiller at google.com (Jason Schiller) Date: Wed, 30 Aug 2017 13:27:32 -0400 Subject: [arin-ppml] Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: As I currently ready 6.5.5.1 there are two classes of addresses that are required to be SWIP'd A. any re-allocation or re-assignment that is a /47 or less specific (/46, /45, ...) B. any sub-deligation that will be individually announced I recall there being a third class, any re-allocation. A re-allocation is when I ISP provides addresses to their down stream ISP customer who then in turn will further sub-delegate address space to their customer (who may also be an ISP with customers... and so on). Can I suggest a friendly amendment of: 6.5.5.1. Re-allocation / reassignment information Each static IPv6 re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any size that will be individually announced, ... ___Jason On Wed, Aug 30, 2017 at 1:15 PM, Jason Schiller wrote: > The new policy (along with pre-existing text) will read as follows: > > 6.5.5.1. Reassignment information > Each static IPv6 assignment 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 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 6.5.5.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. > > 6.5.5.4 Registration Requested by Recipient > 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 > must register > that assignment as described in section 6.5.5.1. > > > > On Tue, Aug 29, 2017 at 9:02 PM, wrote: > >> I think we got it this time. >> >> I support. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> >> On Tue, 22 Aug 2017, ARIN wrote: >> >> The following has been revised: >>> >>> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >>> >>> Revised text is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_5.html >>> >>> Note that the Draft Policy title has changed from "Equalization of >>> Assignment Registration requirements between IPv4 and IPv6" >>> >>> 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 >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> Regards, >>> >>> Sean Hopkins >>> Policy Analyst >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> >>> Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >>> >>> 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 >>> 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 must 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 (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at 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 at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006> > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Wed Aug 30 14:04:46 2017 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Wed, 30 Aug 2017 14:04:46 -0400 Subject: [arin-ppml] ARIN-PPML 2017-5 Message-ID: In support of the new policy wording re: swip requirements. https://www.arin.net/policy/proposals/2017_5.html Rudi Daniel On Wed, Aug 30, 2017 at 1:16 PM, wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: ARIN-PPML 2017-6 draft policy (Mike Burns) > 2. Re: ARIN-PPML 2017-6 draft policy (Andrew Sullivan) > 3. Fwd: Advisory Council Meeting Results - August 2017 (ARIN) > 4. Re: Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 > Registration Requirements (hostmaster at uneedus.com) > 5. Re: Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 > Registration Requirements (Jason Schiller) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 28 Aug 2017 14:14:33 -0400 > From: "Mike Burns" > To: "'Owen DeLong'" > Cc: "'Rudolph Daniel'" , > Subject: Re: [arin-ppml] ARIN-PPML 2017-6 draft policy > Message-ID: <001e01d32029$802458d0$806d0a70$@iptrading.com> > Content-Type: text/plain; charset="utf-8" > > Let?s not. This is a really bad idea and if we don?t put a stop to it now, > it will likely never get corrected. > > > > Owen > > > > > > Hi Owen, > > > > In almost 5 years of inter-regional transfers, David Farmer identified two > transfers of /22s from ARIN into a one-way situation. > > > > At this rate, if it doesn?t ?get corrected?, in just 32 years a whole ARIN > /16 will have disappeared! > > Not really that bad. > > > > On the other hand, blocking all transfers to APNIC *is* a really bad idea, > as is strong-arming that registry *again* through the threat of preventing > access to ARIN address space. > > > > Regards, > > Mike > > > > > > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20170828/902e6e0c/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Mon, 28 Aug 2017 14:51:58 -0400 > From: Andrew Sullivan > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-PPML 2017-6 draft policy > Message-ID: <20170828185158.pdu5pp4zjwgn7ijy at mx4.yitter.info> > Content-Type: text/plain; charset=utf-8 > > On Mon, Aug 28, 2017 at 02:14:33PM -0400, Mike Burns wrote: > > Let?s not. This is a really bad idea and if we don?t put a stop to it > now, it will likely never get corrected. > > What exactly needs to get corrected, then? You are arguing from a > slippery slope, but nobody seems to be slipping. > > A > > > -- > Andrew Sullivan > ajs at anvilwalrusden.com > > > ------------------------------ > > Message: 3 > Date: Tue, 29 Aug 2017 15:20:53 -0400 > From: ARIN > To: arin-ppml at arin.net > Subject: [arin-ppml] Fwd: Advisory Council Meeting Results - August > 2017 > Message-ID: <2ae92228-c1ad-6d03-5a37-15e08573b72b at arin.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > > The AC has abandoned the following Draft Policy: > > > > ARIN-2017-2: Removal of Community Networks > > > > The AC provided the following statement: > > > > "The ARIN Advisory Council has chosen to abandon Policy Proposal 2017-2, > "Removal of Community Networks," due to lack of community support and the > introduction of an alternative policy proposal to amend the definition of > "community network." > > > > Anyone dissatisfied with this decision may initiate a petition. The > deadline to begin a petition will be five business days after the AC's > draft meeting minutes are published. > > > > > The AC has abandoned the following Draft Policy: > > > > ARIN-2017-7: Retire Obsolete Section 4 from the NRPM > > > > The AC provided the following statement: > > > > "The ARIN Advisory Council has chosen to abandon Policy Proposal 2017-7, > ?Retire Obsolete Section 4 from the NRPM?. This proposal did not gain > sufficient community support to justify continuing to move this policy > forward, and as such, we have requested that the policy be abandoned." > > > > Anyone dissatisfied with this decision may initiate a petition. The > deadline to begin a petition will be five business days after the AC's > draft meeting minutes are published. > > > The minutes from the ARIN Advisory Council's 17 August 2017 meeting have > been published: > > https://www.arin.net/about_us/ac/ac2017_0817.html > > The petition deadline for both Draft Policy ARIN-2017-2 and Draft Policy > ARIN-2017-7 is 3 September 2017 (in five calendar days). > > For more information on starting and participating in petitions, see PDP > Petitions at: https://www.arin.net/policy/pdp_petitions.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policy and Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > > -------- Forwarded Message -------- > Subject: Advisory Council Meeting Results - August 2017 > Date: Tue, 22 Aug 2017 12:38:43 -0400 > From: ARIN > To: arin-ppml at arin.net > > In accordance with the Policy Development Process (PDP), the Advisory > Council (AC) met on 17 August 2017. > > > > The AC has abandoned the following Draft Policy: > > ARIN-2017-2: Removal of Community Networks > > The AC provided the following statement: > > "The ARIN Advisory Council has chosen to abandon Policy Proposal 2017-2, > "Removal of Community Networks," due to lack of community support and > the introduction of an alternative policy proposal to amend the > definition of "community network." > > Anyone dissatisfied with this decision may initiate a petition. The > deadline to begin a petition will be five business days after the AC's > draft meeting minutes are published. > > > > The AC has abandoned the following Draft Policy: > > ARIN-2017-7: Retire Obsolete Section 4 from the NRPM > > The AC provided the following statement: > > "The ARIN Advisory Council has chosen to abandon Policy Proposal 2017-7, > ?Retire Obsolete Section 4 from the NRPM?. This proposal did not gain > sufficient community support to justify continuing to move this policy > forward, and as such, we have requested that the policy be abandoned." > > Anyone dissatisfied with this decision may initiate a petition. The > deadline to begin a petition will be five business days after the AC's > draft meeting minutes are published. > > > > The AC has advanced the following Proposal to Draft Policy status (will > be posted separately for discussion): > > ARIN-prop-243: Amend the Definition of Community Network > > The AC advances Proposals to Draft Policy status once they are found to > be within the scope of the PDP, and contain a clear problem statement > and suggested changes to Internet number resource policy text. > > > > The AC is continuing to work on: > > * ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation > * ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > * ARIN-2017-5: Improved IPv6 Registration Requirements > * ARIN-2017-6: Improve Reciprocity Requirement for Inter-RIR Transfers > > The PDP can be found at: > 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 > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > ------------------------------ > > Message: 4 > Date: Tue, 29 Aug 2017 21:02:46 -0400 (EDT) > From: hostmaster at uneedus.com > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised/Retitled: Draft Policy ARIN-2017-5: > Improved IPv6 Registration Requirements > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > I think we got it this time. > > I support. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > On Tue, 22 Aug 2017, ARIN wrote: > > > The following has been revised: > > > > * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > > > > Revised text is below and can be found at: > > https://www.arin.net/policy/proposals/2017_5.html > > > > Note that the Draft Policy title has changed from "Equalization of > Assignment > > Registration requirements between IPv4 and IPv6" > > > > 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 > > > > Draft Policies and Proposals under discussion can be found at: > > https://www.arin.net/policy/proposals/index.html > > > > Regards, > > > > Sean Hopkins > > Policy Analyst > > American Registry for Internet Numbers (ARIN) > > > > > > > > Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > > > > 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 > > 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 must 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 (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > > ------------------------------ > > Message: 5 > Date: Wed, 30 Aug 2017 13:15:41 -0400 > From: Jason Schiller > To: hostmaster at uneedus.com > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Revised/Retitled: Draft Policy ARIN-2017-5: > Improved IPv6 Registration Requirements > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > The new policy (along with pre-existing text) will read as follows: > > 6.5.5.1. Reassignment information > Each static IPv6 assignment 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 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 6.5.5.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. > > 6.5.5.4 Registration Requested by Recipient > 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 must > register > that assignment as described in section 6.5.5.1. > > > > On Tue, Aug 29, 2017 at 9:02 PM, wrote: > > > I think we got it this time. > > > > I support. > > > > Albert Erdmann > > Network Administrator > > Paradise On Line Inc. > > > > > > > > On Tue, 22 Aug 2017, ARIN wrote: > > > > The following has been revised: > >> > >> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > >> > >> Revised text is below and can be found at: > >> https://www.arin.net/policy/proposals/2017_5.html > >> > >> Note that the Draft Policy title has changed from "Equalization of > >> Assignment Registration requirements between IPv4 and IPv6" > >> > >> 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 > >> > >> Draft Policies and Proposals under discussion can be found at: > >> https://www.arin.net/policy/proposals/index.html > >> > >> Regards, > >> > >> Sean Hopkins > >> Policy Analyst > >> American Registry for Internet Numbers (ARIN) > >> > >> > >> > >> Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > >> > >> 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 > >> 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 must 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 (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at 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 at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20170830/4b635cb3/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > ------------------------------ > > End of ARIN-PPML Digest, Vol 146, Issue 25 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsawyer at gci.com Wed Aug 30 14:27:36 2017 From: lsawyer at gci.com (Leif Sawyer) Date: Wed, 30 Aug 2017 18:27:36 +0000 Subject: [arin-ppml] Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: The text as published is currently undergoing staff and legal review. I've have noted this particular update for after the S&L - especially if it is something that they call out as a potential risk. Thanks, Leif From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jason Schiller Sent: Wednesday, August 30, 2017 9:28 AM To: hostmaster at uneedus.com Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements [External Email] As I currently ready 6.5.5.1 there are two classes of addresses that are required to be SWIP'd A. any re-allocation or re-assignment that is a /47 or less specific (/46, /45, ...) B. any sub-deligation that will be individually announced I recall there being a third class, any re-allocation. A re-allocation is when I ISP provides addresses to their down stream ISP customer who then in turn will further sub-delegate address space to their customer (who may also be an ISP with customers... and so on). Can I suggest a friendly amendment of: 6.5.5.1. Re-allocation / reassignment information Each static IPv6 re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any size that will be individually announced, ... ___Jason On Wed, Aug 30, 2017 at 1:15 PM, Jason Schiller > wrote: The new policy (along with pre-existing text) will read as follows: 6.5.5.1. Reassignment information Each static IPv6 assignment 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 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 6.5.5.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. 6.5.5.4 Registration Requested by Recipient 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 must register that assignment as described in section 6.5.5.1. On Tue, Aug 29, 2017 at 9:02 PM, > wrote: I think we got it this time. I support. Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 22 Aug 2017, ARIN wrote: The following has been revised: * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_5.html Note that the Draft Policy title has changed from "Equalization of Assignment Registration requirements between IPv4 and IPv6" 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 Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements 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 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 must 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 (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at 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 at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Wed Aug 30 15:22:50 2017 From: farmer at umn.edu (David Farmer) Date: Wed, 30 Aug 2017 14:22:50 -0500 Subject: [arin-ppml] Re-allocations (was: Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements) Message-ID: On Wed, Aug 30, 2017 at 12:27 PM, Jason Schiller wrote: ... > I recall there being a third class, any re-allocation. > > A re-allocation is when I ISP provides addresses to their down stream > ISP customer who then in turn will further sub-delegate address space > to their customer (who may also be an ISP with customers... and so on). > > Jason, I've been working on a separate proposal regarding re-allocations. It really needs a bit of a different problem statement, and there is text needed for both IPv4 and IPv6. Here, is what I have so far; Any comments would be appreciated; Thanks. -------- Policy Proposal Name: Require Registration for Re-allocations to Downstream ISPs Problem Statement: It is critical that the best source for information about the end user associated with any IP address is publicly known. That is not to say that the information about the end user associated with each IP address needs to be publicly known, but that the entity that has a direct customer relationship with, or otherwise knows, the end user for any IP address needs to be publicly known. Frequently civil and criminal litigation today involves electronic evidence of some kind, this evidence is regularly associated with an IP addresses. In such cases, the customer records associated with an IP address may need to be subpoenaed as part of civil or criminal legal proceedings, therefore the proper entity to issue a subpoena to needs to be readily known. When ARIN allocates address space to an ISP this information is provided in it's registration database, and is publicly accessible via Whois. When addresses are re-allocated from an ISP to another downstream ISP, and if this re-allocation is not properly and publicly documented the wrong ISP could be subpoenaed for the customer records associated with an IP address. This wastes the time of judges and other court officials, but even worse it could cause a delays in time-sensitive situations, for instance the kidnapping of a child. For these reasons, the re-allocation of address space to a downstream ISP must be registered in ARIN's WHOIS directory via SWIP before the downstream ISP uses the re-allocated addresses to provide any services to it's customers. Policy statement: Add new subsections X for IPv4 and Y for IPv6 as follows, 4.2.3.7.4 and 6.5.5.5 are recommended respectively; X. Re-allocations to other ISPs Each IPv4 re-allocation to a downstream ISP, regardless of size, must be registered to the downstream ISP in the WHOIS directory via SWIP before the re-allocation is used to provide any services to the downstream ISP's customers. Y. Re-allocations to other ISPs Each IPv6 re-allocation to a downstream ISP, regardless of size, must be registered to the downstream ISP in the WHOIS directory via SWIP before the re-allocation is used to provide any services to the downstream ISP's customers. Comments: a. Timetable for implementation: Immediate b. Anything else The use of RWHOIS, or other distributed Distributed Information Server as described in NRPM section 3.2, for this registration information is not sufficient, the ARIN WHOIS directory needs direct knowledge of each re-allocation to ensure the correct information is provided without needing to access other services. Processes and procedures should be developed for the reporting of incorrect or unregistered re-allocations that result in official legal process going to the wrong entity. ARIN Staff should investigate such reports and work with upstream ISPs to ensure the reported registrations are correct. The imposition of penalties, financial or otherwise, for incorrect or unregistered re-allocations are not directly a policy question, but are more a question of business practice, and should be considered separately by the ARIN Board of Trustees assuming this policy proposal is adopted. Previously in IPv4, slow-start essentially required new ISPs to use a re-allocation from an upstream ISP to develop an allocation history before they could receive a direct allocation from ARIN, even though the term re-allocation wasn't specified in the NRPM. In IPv6 this should not be necessary, most new ISPs should be able to qualify for an initial allocation directly from ARIN. However, there are other reasons for re-allocations in both IPv4 and IPv6 generally, either on a permanent basis or temporarily during a transition, such as the change in ownership of a customer territory or the sale of only part of a network, etc... -- =============================================== David Farmer Email:farmer at umn.edu 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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Wed Aug 30 18:41:54 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 30 Aug 2017 18:41:54 -0400 (EDT) Subject: [arin-ppml] Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: Since 2.15 recommends a /48 for every end site, any ISP getting a sub-delegation to use for customers is going to have a /47 or more, which according to the policy proposal as written will already have a registration requirement solely by its size. Thus, I have little reason to worry about any ISP avoiding registration. I would rather wait for a specific policy proposal for subdelegation, covering both v6 and v4, and not try to add it to this proposal. Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 30 Aug 2017, Jason Schiller wrote: > As I currently ready 6.5.5.1 there are two classes of addresses that are > required to be SWIP'd > A. any re-allocation or re-assignment that is a /47 or less specific (/46, > /45, ...) > B. any sub-deligation that will be individually announced > > I recall there being a third class, any re-allocation. > > A re-allocation is when I ISP provides addresses to their down stream > ISP customer who then in turn will further sub-delegate address space > to their customer (who may also be an ISP with customers... and so on). > > Can I suggest a friendly amendment of: > > > 6.5.5.1. Re-allocation / reassignment information > Each static IPv6 re-allocation, reassignment containing a /47 or more > addresses, or subdelegation > of any size that will be individually announced, ... > > ___Jason > > > > On Wed, Aug 30, 2017 at 1:15 PM, Jason Schiller > wrote: > >> The new policy (along with pre-existing text) will read as follows: >> >> 6.5.5.1. Reassignment information >> Each static IPv6 assignment 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 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 6.5.5.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. >> >> 6.5.5.4 Registration Requested by Recipient >> 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 >> must register >> that assignment as described in section 6.5.5.1. >> >> >> >> On Tue, Aug 29, 2017 at 9:02 PM, wrote: >> >>> I think we got it this time. >>> >>> I support. >>> >>> Albert Erdmann >>> Network Administrator >>> Paradise On Line Inc. >>> >>> >>> >>> On Tue, 22 Aug 2017, ARIN wrote: >>> >>> The following has been revised: >>>> >>>> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >>>> >>>> Revised text is below and can be found at: >>>> https://www.arin.net/policy/proposals/2017_5.html >>>> >>>> Note that the Draft Policy title has changed from "Equalization of >>>> Assignment Registration requirements between IPv4 and IPv6" >>>> >>>> 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 >>>> >>>> Draft Policies and Proposals under discussion can be found at: >>>> https://www.arin.net/policy/proposals/index.html >>>> >>>> Regards, >>>> >>>> Sean Hopkins >>>> Policy Analyst >>>> American Registry for Internet Numbers (ARIN) >>>> >>>> >>>> >>>> Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >>>> >>>> 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 >>>> 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 must 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 (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at 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 at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006> >> >> > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > From owen at delong.com Wed Aug 30 19:42:26 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 30 Aug 2017 16:42:26 -0700 Subject: [arin-ppml] Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: > On Aug 30, 2017, at 15:41 , hostmaster at uneedus.com wrote: > > Since 2.15 recommends a /48 for every end site, any ISP getting a sub-delegation to use for customers is going to have a /47 or more, which according to the policy proposal as written will already have a registration requirement solely by its size. You?d like to think that, but it is sadly not necessarily as true as most of us would like it to be. There are providers out there that are (still) very stingy with IPv6 space for reasons completely passing understanding. > Thus, I have little reason to worry about any ISP avoiding registration. I would rather wait for a specific policy proposal for subdelegation, covering both v6 and v4, and not try to add it to this proposal. For different reasons, I?m in agreement. My reasonings are best explained by David Farmers post on the subject. Owen > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > On Wed, 30 Aug 2017, Jason Schiller wrote: > >> As I currently ready 6.5.5.1 there are two classes of addresses that are >> required to be SWIP'd >> A. any re-allocation or re-assignment that is a /47 or less specific (/46, >> /45, ...) >> B. any sub-deligation that will be individually announced >> >> I recall there being a third class, any re-allocation. >> >> A re-allocation is when I ISP provides addresses to their down stream >> ISP customer who then in turn will further sub-delegate address space >> to their customer (who may also be an ISP with customers... and so on). >> >> Can I suggest a friendly amendment of: >> >> >> 6.5.5.1. Re-allocation / reassignment information >> Each static IPv6 re-allocation, reassignment containing a /47 or more >> addresses, or subdelegation >> of any size that will be individually announced, ... >> >> ___Jason >> >> >> >> On Wed, Aug 30, 2017 at 1:15 PM, Jason Schiller >> wrote: >> >>> The new policy (along with pre-existing text) will read as follows: >>> >>> 6.5.5.1. Reassignment information >>> Each static IPv6 assignment 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 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 6.5.5.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. >>> >>> 6.5.5.4 Registration Requested by Recipient >>> 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 >>> must register >>> that assignment as described in section 6.5.5.1. >>> >>> >>> >>> On Tue, Aug 29, 2017 at 9:02 PM, wrote: >>> >>>> I think we got it this time. >>>> >>>> I support. >>>> >>>> Albert Erdmann >>>> Network Administrator >>>> Paradise On Line Inc. >>>> >>>> >>>> >>>> On Tue, 22 Aug 2017, ARIN wrote: >>>> >>>> The following has been revised: >>>>> >>>>> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >>>>> >>>>> Revised text is below and can be found at: >>>>> https://www.arin.net/policy/proposals/2017_5.html >>>>> >>>>> Note that the Draft Policy title has changed from "Equalization of >>>>> Assignment Registration requirements between IPv4 and IPv6" >>>>> >>>>> 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 >>>>> >>>>> Draft Policies and Proposals under discussion can be found at: >>>>> https://www.arin.net/policy/proposals/index.html >>>>> >>>>> Regards, >>>>> >>>>> Sean Hopkins >>>>> Policy Analyst >>>>> American Registry for Internet Numbers (ARIN) >>>>> >>>>> >>>>> >>>>> Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >>>>> >>>>> 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 >>>>> 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 must 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 (ARIN-PPML at arin.net). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at 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 at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>>> >>> >>> >>> >>> -- >>> _______________________________________________________ >>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006> >>> >>> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >> > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jschiller at google.com Thu Aug 31 10:58:51 2017 From: jschiller at google.com (Jason Schiller) Date: Thu, 31 Aug 2017 10:58:51 -0400 Subject: [arin-ppml] Re-allocations (was: Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements) In-Reply-To: References: Message-ID: David, My thoughts, please take with a grain of salt. 1. Problem statement is fine, but really is just one of many examples of why this data is needed 2. I'd be careful with the use of the word ISP, - I recommend it is better just to drop it - I'd drop the timing part, and leverage pre-existing text instead (as this is simple, convenient, and keeping them in sync makes sense) ------------- 1. Problem statement is fine, but really is just one of many examples of why this data is needed I'm not sure this NEEDS to be separated from the other proposal, but it certainly could be separated. (What I would optimize for is getting both changes through as quickly as possible.) I think your problem statement is good, but is only a sub-set, there are many things that require good contact info. Certainly LEA is a big one, even more critical than a subpoena is suicide threats, death threats, and abductions with timely access is even more critical. The info is also used for technical reasons to determine who is the party best suited to resolve some technical issue. E.g. the IPs are being blackholed by a third party, a machine in the address range is infected with malware, a machine in the address range is misconfigured in a way that leaves it vulnerable to reflection attacks, abuse or hacking attempts for an address in the range, etc. ---------- 2. I'd be careful with the use of the word ISP I would caution the use of the word ISP. I think it reads just fine without it. By definition any time there is a re-allocation, the address space is going to be used by an organization that intends to re-use some of their address space to their own down stream customers. In ARIN terms this makes them and ISP and not an end-user, but I fear people will get wrapped up in the term "ISP" and claim they are not one and need not SWIP. If you think there is enough organizational separation to treat your downstream (B) like a customer... And they (B) think there is enough organizational separation to treat their (B's) downstream (C) like a customer, and therefor request a re-allocation (and not a reassignment)... Then B needs to be registered in whois because they have a re-allocation, and intend to make downstream subdeligations. Now Imagine this is ISP "A" with a customer of University of "B" who has a customer of The "C" department, who has a customer of computer Lab "D". A. B, and C need to be registered because they are all registering sub-delegations. This is regardless of if The "C" department considered themselves an "ISP". X. Re-allocations Each IPv4 re-allocation, regardless of size, must be registered. Y. Re-allocations to other ISPs Each IPv6 re-allocation, regardless of size, must be registered. Also, if you organize this under the same section as (re-)assignments, you share the same 7 day requirement, which makes sense. Also, also it is now a lot less words. ___Jason On Wed, Aug 30, 2017 at 3:22 PM, David Farmer wrote: > > On Wed, Aug 30, 2017 at 12:27 PM, Jason Schiller > wrote: > ... > >> I recall there being a third class, any re-allocation. >> >> A re-allocation is when I ISP provides addresses to their down stream >> ISP customer who then in turn will further sub-delegate address space >> to their customer (who may also be an ISP with customers... and so on). >> >> > Jason, > > I've been working on a separate proposal regarding re-allocations. It > really needs a bit of a different problem statement, and there is text > needed for both IPv4 and IPv6. Here, is what I have so far; > > Any comments would be appreciated; > > Thanks. > > -------- > Policy Proposal Name: > > Require Registration for Re-allocations to Downstream ISPs > > Problem Statement: > > It is critical that the best source for information about the end user > associated with any IP address is publicly known. That is not to say that > the information about the end user associated with each IP address needs to > be publicly known, but that the entity that has a direct customer > relationship with, or otherwise knows, the end user for any IP address > needs to be publicly known. > > Frequently civil and criminal litigation today involves electronic > evidence of some kind, this evidence is regularly associated with an IP > addresses. In such cases, the customer records associated with an IP > address may need to be subpoenaed as part of civil or criminal legal > proceedings, therefore the proper entity to issue a subpoena to needs to be > readily known. When ARIN allocates address space to an ISP this > information is provided in it's registration database, and is publicly > accessible via Whois. When addresses are re-allocated from an ISP to > another downstream ISP, and if this re-allocation is not properly and > publicly documented the wrong ISP could be subpoenaed for the customer > records associated with an IP address. This wastes the time of judges and > other court officials, but even worse it could cause a delays in > time-sensitive situations, for instance the kidnapping of a child. > > For these reasons, the re-allocation of address space to a downstream ISP > must be registered in ARIN's WHOIS directory via SWIP before the downstream > ISP uses the re-allocated addresses to provide any services to it's > customers. > > Policy statement: > > Add new subsections X for IPv4 and Y for IPv6 as follows, 4.2.3.7.4 and > 6.5.5.5 are recommended respectively; > > X. Re-allocations to other ISPs > > Each IPv4 re-allocation to a downstream ISP, regardless of size, must be > registered to the downstream ISP in the WHOIS directory via SWIP before the > re-allocation is used to provide any services to the downstream ISP's > customers. > > Y. Re-allocations to other ISPs > > Each IPv6 re-allocation to a downstream ISP, regardless of size, must be > registered to the downstream ISP in the WHOIS directory via SWIP before the > re-allocation is used to provide any services to the downstream ISP's > customers. > > Comments: > a. Timetable for implementation: Immediate > b. Anything else > > The use of RWHOIS, or other distributed Distributed Information Server as > described in NRPM section 3.2, for this registration information is not > sufficient, the ARIN WHOIS directory needs direct knowledge of each > re-allocation to ensure the correct information is provided without needing > to access other services. > > Processes and procedures should be developed for the reporting of > incorrect or unregistered re-allocations that result in official legal > process going to the wrong entity. ARIN Staff should investigate such > reports and work with upstream ISPs to ensure the reported registrations > are correct. The imposition of penalties, financial or otherwise, for > incorrect or unregistered re-allocations are not directly a policy > question, but are more a question of business practice, and should be > considered separately by the ARIN Board of Trustees assuming this policy > proposal is adopted. > > Previously in IPv4, slow-start essentially required new ISPs to use a > re-allocation from an upstream ISP to develop an allocation history before > they could receive a direct allocation from ARIN, even though the term > re-allocation wasn't specified in the NRPM. In IPv6 this should not be > necessary, most new ISPs should be able to qualify for an initial > allocation directly from ARIN. However, there are other reasons for > re-allocations in both IPv4 and IPv6 generally, either on a permanent basis > or temporarily during a transition, such as the change in ownership of a > customer territory or the sale of only part of a network, etc... > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > > Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Thu Aug 31 14:17:05 2017 From: jschiller at google.com (Jason Schiller) Date: Thu, 31 Aug 2017 14:17:05 -0400 Subject: [arin-ppml] Expanding Scope? :Draft Policy ARIN-2017-8: Amend the definition of Community Network In-Reply-To: References: Message-ID: David, please ask your question again. I don't see any responses, and I for one did not understand the question... I read the problem statement as follows: 1. community networks policy has not been used 2. we tried to remove it on the grounds that it is not used therefore not needed 3. Removal failed because it is needed. 4. claims were made that it is unused because the defintion is too narrow to be useful 5. implied problem we should have a useful community networks policy that gets used. I think the issue here is in the implied statement 5, - Get used for what? - What special treatment should community networks get? - What special treatment do community networks require? One was reduced billing, but that seems to have been addressed by creating reduced billing for a very small category which happens to sweep in most community networks. (The ones not swept in have no problem playing by the regular rules) Or are we simply trying to have a useful defintion of community networks not disappear from the NRPM because the Numbers Community values community networks and while there is no specific special treatment necessary for community networks, there might be a requirement in the future and having a useful definition will enable that when it is needed, and reminds us when making new policy to not forget about community networks? reading the thread, my sense is: 1. Most community networks should be able to get resources as easily as an end-user (does not need to include very large ones who should operate like ISPs) 2. Small-ish community networks should have a financial burden that is no bigger than a small-ish end-user 3. Community networks provide addresses for use on their downstream customer's equipment, so must be an "ISP" under ARIN terms 4. Because of #3, community networks with no requirement for re-allocations, cannot take advantage of end-user $100/resource annual billing 5. Community networks with a requirement for re-allocations must pay a lot more than small-ish end-users. You include Kevin's email about concerns that an overly broad definition of community network could enable and org which today must be an ISP to use this definition to get reclassified as an end-user and avoid SWIP requirements. I agree with those concerns. I see no reason why the current proposal with the current problem statement couldn't also remove or amend 6.5.9 __Jason On Fri, Aug 25, 2017 at 9:42 AM, David Farmer wrote: > Ok, then I need to hear from others in the community on the subject > expanding the scope of the problem statement for this Draft Policy beyond > the just the Definition of Community Networks at this point; > > Should we revise the problem statement beyond it's current scope? > > If yes, then what should the revised problem statement include? > > Thanks > > On Thu, Aug 24, 2017 at 11:19 PM, Kevin Blumberg > wrote: > >> David, >> >> >> >> I see that the revised text addresses some of the definition issues. >> Regarding your question I believe that the definition and section 6.5.9 are >> intrinsically tied together. >> >> >> >> Currently the only active part of Community Networks is the state that it >> will be considered an end-user regarding ?all ARIN purposes?. I have an >> issue if this is used by Organizations to act as a way of opting-out of >> SWIP requirements. With a substantially expanded definition the number of >> Organizations that could use the policy is significant. >> >> >> >> Another interesting problem comes from the new Registration Services Plan >> (https://www.arin.net/fees/fee_schedule.html) >> >> >> >> ?Organizations that choose to convert to the Registration Services Plan >> will be evaluated as an ISP from a policy perspective when requesting >> future Internet number resources from ARIN. The applicable annual >> registration services plan will be invoiced annually based on the >> organization resources in the ARIN registry.? >> >> >> >> Kevin Blumberg >> >> >> >> *From:* David Farmer [mailto:farmer at umn.edu] >> *Sent:* Thursday, August 24, 2017 3:05 PM >> *To:* Kevin Blumberg >> *Cc:* arin-ppml at arin.net >> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-8: Amend the >> definition of Community Network >> >> >> >> Kevin, >> >> >> >> There was a little confusion, mostly on my part it seems. Cutting to the >> chase; An older version of the text got sent out with the announcement of >> this policy. An updated version of text got sent out earlier today, it >> addresses some but for sure not all of your points. >> >> >> >> As for several of the broader points you bring up, I'd like to work on >> updating the definition for Community Networks first, mostly because that >> is the scope of the problem statement focuses on. Once we develop some >> consensus around a new definition for Community Networks, then I think we >> could build on that and look at some of the broader issues you bring up. >> Would that plan work for you? >> >> >> >> Thanks >> >> >> >> On Wed, Aug 23, 2017 at 2:22 PM, Kevin Blumberg >> wrote: >> >> I do not support the policy as written but do support the overall intent. >> >> 1) The definition of a community network has gone from overly specific to >> overly broad. An example in Canada there are over 160,000 non-profit and >> not-for-profit organizations. >> 2) A volunteer group, that is not an organization, wouldn't be able to >> get space from ARIN as it requires a business registration (ARIN Staff >> please confirm). >> 3) Why is there a limit to only post-secondary institutions? Many rural >> locations have K-12 that would not qualify. >> 4) In Canada, a charity is a non-profit organization, more generic terms >> should be used that covers the entire ARIN serving region. >> 5) The current Community Networks policy conflicts with the intent of >> 2017-5 Improved IPv6 Registration Requirements. By placing all space into >> End User assignment, Community Networks operating as a ISP collective for >> residential subscribers would be unable to reassign static assignments. >> >> The current Community Networks policy requires an applicant to qualify >> under standard end-user requirements (Section 6.5.9.2). If there is no >> difference to the qualification criteria, why would an organization go out >> of the way to qualify as a Community Network? >> >> I wrote a policy in 2016 that tried to address some of these issues, it >> was abandoned at the time ( https://www.arin.net/policy/pr >> oposals/2016_7.html ) >> >> Kevin Blumberg >> >> -----Original Message----- >> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >> Sent: Tuesday, August 22, 2017 12:40 PM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of >> Community Network >> >> On 17 August 2017 the ARIN Advisory Council (AC) advanced >> "ARIN-prop-243: Amend the Definition of Community Network" to Draft >> Policy status. >> >> Draft Policy ARIN-2017-8 is below and can be found at: >> https://www.arin.net/policy/proposals/2017_8.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 >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> Draft Policy ARIN-2017-8: Amend the Definition of Community Network >> >> Problem Statement: >> >> The Community Networks section of the NRPM has not been used since >> implementation in January 2010. Proposal ARIN-2016-7, to increase the >> number of use cases, was abandoned by the Advisory Council due to lack of >> feedback. Proposal ARIN 2017-2, to remove all mention of community networks >> from NRPM was met with opposition by the community. Many responded that the >> definition of ?community network? was too narrow, which could be the reason >> for lack of uptake. >> >> Policy statement: >> >> CURRENT NRPM TEXT: >> >> ?2.11. Community Network >> >> A community network is any network organized and operated by a volunteer >> group operating as or under the fiscal support of a nonprofit organization >> or university for the purpose of providing free or low-cost connectivity to >> the residents of their local service area. To be treated as a community >> network under ARIN policy, the applicant must certify to ARIN that the >> community network staff is 100% volunteers.? >> >> NEW NRPM TEXT: >> >> ?2.11 Community Network >> >> A community network is a network organized and operated by a volunteer >> group, not-for-profit, non-profit, charitable organization, or >> post-secondary institution for the purpose of providing free or low-cost >> connectivity to residents in their service area. Critical functions may be >> handled by paid staff, but volunteers play a large role in offering >> services available through community networks.? >> >> Comments: >> >> Timetable for implementation: Immediate >> _______________________________________________ >> 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: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at 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 at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> >> >> >> >> -- >> >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> =============================================== >> > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: