<div dir="ltr">David,<div><br></div><div>My thoughts, please take with a grain of salt.</div><div><br></div><div>1. Problem statement is fine, but really is just one of many examples</div><div> of why this data is needed</div><div><br></div><div>2. I'd be careful with the use of the word ISP,</div><div> - I recommend it is better just to drop it</div><div> - I'd drop the timing part, and leverage pre-existing text instead</div><div> (as this is simple, convenient, and keeping them in sync makes sense) </div><div><br></div><div>-------------</div><div><br></div><div><div>1. Problem statement is fine, but really is just one of many examples</div><div> of why this data is needed</div></div><div><br></div><div>I'm not sure this NEEDS to be separated from the other proposal, </div><div>but it certainly could be separated. (What I would optimize for</div><div>is getting both changes through as quickly as possible.)</div><div><br></div><div>I think your problem statement is good, but is only a sub-set, </div><div>there are many things that require good contact info.</div><div><br></div><div>Certainly LEA is a big one, even more critical than a subpoena </div><div>is suicide threats, death threats, and abductions with timely </div><div>access is even more critical.</div><div><br></div><div>The info is also used for technical reasons to determine who is</div><div>the party best suited to resolve some technical issue. E.g. the</div><div>IPs are being blackholed by a third party, a machine in the </div><div>address range is infected with malware, a machine in the address</div><div>range is misconfigured in a way that leaves it vulnerable to reflection</div><div>attacks, abuse or hacking attempts for an address in the range, etc. </div><div><br></div><div>----------</div><div><br></div><div><div>2. I'd be careful with the use of the word ISP</div></div><div><br></div><div><br></div><div>I would caution the use of the word ISP. I think it reads just fine without it.</div><div><br></div><div>By definition any time there is a re-allocation, the address space is going </div><div>to be used by an organization that intends to re-use some of their address </div><div>space to their own down stream customers. In ARIN terms this makes </div><div>them and ISP and not an end-user, but I fear people will get wrapped up in </div><div>the term "ISP" and claim they are not one and need not SWIP.</div><div><br></div><div>If you think there is enough organizational separation to treat your </div><div>downstream (B) like a customer...</div><div><br></div><div>And they (B) think there is enough organizational separation to treat </div><div>their (B's) downstream (C) like a customer, and therefor request a </div><div>re-allocation (and not a reassignment)...</div><div><br></div><div>Then B needs to be registered in whois because they have a </div><div>re-allocation, and intend to make downstream subdeligations.</div><div><br></div><div>Now Imagine this is ISP "A" with a customer of University of "B"</div><div>who has a customer of The "C" department, who has a customer</div><div>of computer Lab "D". A. B, and C need to be registered because</div><div>they are all registering sub-delegations. This is regardless of if</div><div>The "C" department considered themselves an "ISP".</div><div><br></div><div><br></div><div><br></div><div> X. Re-allocations</div><div>Each IPv4 re-allocation, regardless of size, must be registered.</div><div><br></div><div>Y. Re-allocations to other ISPs</div><div><br></div><div>Each IPv6 re-allocation, regardless of size, must be registered.</div><div><br></div><div>Also, if you organize this under the same section as (re-)assignments,</div><div>you share the same 7 day requirement, which makes sense.</div><div><br></div><div>Also, also it is now a lot less words.</div><div><br></div><div>___Jason </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 30, 2017 at 3:22 PM, David Farmer <span dir="ltr"><<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 30, 2017 at 12:27 PM, Jason Schiller <span dir="ltr"><<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>></span> wrote:</div><div class="gmail_quote">...<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I recall there being a third class, any re-allocation.</div><div><br></div><div>A re-allocation is when I ISP provides addresses to their down stream </div><div>ISP customer who then in turn will further sub-delegate address space </div><div>to their customer (who may also be an ISP with customers... and so on).</div><div><br></div></div></blockquote></div><br>Jason,<br><br>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;</div><div class="gmail_extra"><br>Any comments would be appreciated;</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks.</div><div class="gmail_extra"> <br>--------<br>Policy Proposal Name:</div><div class="gmail_extra"><br></div><div class="gmail_extra">Require Registration for Re-allocations to Downstream ISPs<br><br>Problem Statement:<br><br>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. <br><br>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.<br><br>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.<br><br></div><div class="gmail_extra">Policy statement:<br><br>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;<br><br>X. Re-allocations to other ISPs<br><br>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.<br><br>Y. Re-allocations to other ISPs<br><br>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.<br><br>Comments:<br>a. Timetable for implementation: Immediate<br>b. Anything else<br><br>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. <br><br>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.<br><br>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...</div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra">-- <br><div class="m_-4202814917862861951gmail_signature">==============================<wbr>=================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br><a href="https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g">2218 University Ave SE</a> Phone: <a href="tel:(612)%20626-0815" value="+16126260815" target="_blank">612-626-0815</a><br>Minneapolis, MN 55414-3029 Cell: <a href="tel:(612)%20812-9952" value="+16128129952" target="_blank">612-812-9952</a><br>==============================<wbr>================= </div>
</div></font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div>