<div dir="ltr">Direct Allocation: an RIR, such as ARIN, designates a block of IPs to be used by an <div>organization and their down stream customers. (re-allocations and re-assignments are permitted) </div><div><br></div><div>[Note: if there is a requirement for the organization to hold at least one block of IPs</div><div>that may be used in part or whole by its customers, then all blocks held by that organization</div><div>will be treated as allocations.]<br><div><br></div><div>Direct Assignment: an RIR, such as ARIN, designates a block of IPs to be used by </div></div><div>an organization for use on equipment that they own/manage/are responsible for.</div><div>(re-allocations and re-assignments are not permitted)</div><div><br></div><div><br></div><div><br></div><div>An organization with either a direct allocation, or a re-allocation may sub-delegate a portion </div><div>of their address space for use by their down stream customers. sub-deligations come in two </div><div>types: re-allocations and reassignments.</div><div><br></div><div>Re-allocation: when a sub-deligation is made to a customer, and it is intended to be used</div><div>on the customer's equipment as well as by their downstream customers, then the </div><div>sub-deligation must be a re-allocation.</div><div>(further re-allocations and re-assignments are permitted) </div><div><br></div><div><div>[Note: if there is a requirement for the downstream customer to hold at least one block of IPs</div><div>that may be used in part or whole by its customers, then all blocks held by that organization</div><div>will be treated as re-allocations.]</div></div><div><br></div><div>Reassignment: when a sub-deligation is made to a customer, and it is intended to only </div><div>be used on the customer's equipment for which they own/mange/are responsible for, then the </div><div>sub-deligation must be a re-allocation.</div><div>(further re-allocations and re-assignments are not permitted) </div><div><br></div><div><br></div><div><br></div><div>My sense is people didn't want to say "allocation/assignment" or "re-allocation/reassignment"</div><div>in policy as it is clunky. So in some cases we just shortened it but meant the "when you read </div><div>these requirements about SWIP wrt assignments, it also obviously applies to allocations". </div><div><br></div><div>This blurred the meaning of the terms. Now that we have re-clarified the exact meaning, we find </div><div>there is a whole set of policy that should apply to both, but currently only applies to one because </div><div>we did not mirror the text.</div><div><br></div><div>I think the simple solution is to clearly define sub-deligation to mean both re-allocatiions, and reassignemnts,</div><div>and move all the requirements that apply to both under a sub-deligation section, which a breakout for </div><div>re-assignment specific and reallocation specific bits.</div><div><br></div><div>Thanks,</div><div><br></div><div>__Jason</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 14, 2017 at 11:49 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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Aug 31, 2017 at 9:58 AM, Jason Schiller <span dir="ltr"><<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>></span> wrote:<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">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></blockquote><div><br></div></span><div>One reason I focused on subpoenas is that it's not only an LEA issue, subpoenas involve civil matters as well, this isn't about just LEA and criminal legal system, but it is equally about civil legal system as well. This is about the exceptions society has on us the people that operate the Internet and not just the exceptions of government authorities. I'll add the other time-sensitive situations, I was a little leery of going over the top on that, and maybe underplayed it a little bit too much. </div><span class=""><div> </div><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>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></blockquote><div><br></div></span><div>I'll add technical and abuse issues to the problem statement.</div><span class=""><div> </div><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>----------</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></blockquote><div><br></div></span><div>I think the best way to deal this is to work on the definitions of Assign and Allocate in section 2.5. Further while look at that, I realized there is a grammatical question we should look at as well, is "reallocate" and "reassign" or "sub-allocate" and "sub-assign" the proper terms to use? The definitions in section 2.5 uses "sub-assign", but "reassign" is used several other places in the NRPM, and I believe ARIN Online uses the terms "reallocate" and "reassign".</div><div><br></div><div>---</div><div><a href="http://www.dictionary.com/browse/sub-" target="_blank">http://www.dictionary.com/brow<wbr>se/sub-</a><br></div><div><br></div><div><div>1. a prefix occurring originally in loanwords from Latin (subject; subtract; subvert; subsidy); on this model, freely attached to elements of any origin and used with the meaning “under,” “below,” “beneath” (subalpine; substratum), “slightly,” “imperfectly,” “nearly” (subcolumnar; subtropical), “secondary,” “subordinate” (subcommittee; subplot).</div></div><div><br></div><div><a href="http://www.dictionary.com/browse/re-" target="_blank">http://www.dictionary.com/brow<wbr>se/re-</a><br></div><div><br></div><div><div>1. a prefix, occurring originally in loanwords from Latin, used with the meaning “again” or “again and again” to indicate repetition, or with the meaning “back” or “backward” to indicate withdrawal or backward motion:</div></div><div>---</div><div><br></div><div>I think there is a strong argument for the use of either, however I don't think using both is a good idea, it only leads to additional confusion.</div><div><br></div><div>I think reallocate and reassign are used in more places and sub-allocate and sub-assign are use in fewer locations, causing me to lean toward reallocate and reassign. So I think the definition in section 2.5 should use reassign instead. But what do others think?</div><div><br></div><div>Thanks.</div></div><span class=""><div><br></div>-- <br><div class="m_4770220183921653851m_-1260248187921604619gmail-m_-8764703433181013229gmail-m_2256539188004554108gmail_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>
</span></div></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>