[arin-ppml] Re-allocations (was: Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements)

Fri Sep 15 10:14:20 EDT 2017

Direct Allocation: an RIR, such as ARIN, designates a block of IPs to be
used by an
organization and their down stream customers.  (re-allocations and
re-assignments are permitted)

[Note: if there is a requirement for the organization to hold at least one
block of IPs
that may be used in part or whole by its customers, then all blocks held by
that organization
will be treated as allocations.]

Direct Assignment:  an RIR, such as ARIN, designates a block of IPs to be
used by
an organization for use on equipment that they own/manage/are responsible
for.
(re-allocations and re-assignments are not permitted)

An organization with either a direct allocation, or a re-allocation may
sub-delegate a portion
of their address space for use by their down stream customers.
sub-deligations come in two
types: re-allocations and reassignments.

Re-allocation: when a sub-deligation is made to a customer, and it is
intended to be used
on the customer's equipment as well as by their downstream customers, then
the
sub-deligation must be a re-allocation.
(further re-allocations and re-assignments are permitted)

[Note: if there is a requirement for the downstream customer to hold at
least one block of IPs
that may be used in part or whole by its customers, then all blocks held by
that organization
will be treated as re-allocations.]

Reassignment: when a sub-deligation is made to a customer, and it is
intended to only
be used on the customer's equipment for which they own/mange/are
responsible for, then the
sub-deligation must be a re-allocation.
(further re-allocations and re-assignments are not permitted)

My sense is people didn't want to say "allocation/assignment"  or
"re-allocation/reassignment"
in policy as it is clunky.  So in some cases we just shortened it but meant
the "when you read
these requirements about SWIP wrt assignments, it also obviously applies to
allocations".

This blurred the meaning of the terms.  Now that we have re-clarified the
exact meaning, we find
there is a whole set of policy that should apply to both, but currently
only applies to one because
we did not mirror the text.

I think the simple solution is to clearly define sub-deligation to mean
both re-allocatiions, and reassignemnts,
and move all the requirements that apply to both under a sub-deligation
section, which a breakout for
re-assignment specific and reallocation specific bits.

Thanks,

__Jason

On Thu, Sep 14, 2017 at 11:49 PM, David Farmer <farmer at umn.edu> wrote:

>
>
> On Thu, Aug 31, 2017 at 9:58 AM, Jason Schiller <jschiller at google.com>
> wrote:
>
>> 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.
>>
>
> 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.
>
>
>> 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.
>>
>
> I'll add technical and abuse issues to the problem statement.
>
>
>> ----------
>>
>> 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".
>>
>
> 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".
>
> ---
> http://www.dictionary.com/browse/sub-
>
> 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).
>
> http://www.dictionary.com/browse/re-
>
> 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:
> ---
>
> 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.
>
> 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?
>
> Thanks.
>
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE
> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g>
>       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: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170915/92df2ac2/attachment.htm>