Send ARIN-PPML mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
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-2012-8: Aligning 8.2 and 8.3
Transfer Policy (David Farmer)
2. Re: REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 and 8.3
Transfer Policy (Scott Leibrand)
3. Re: REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 and 8.3
Transfer Policy (Gary Buhrmaster)
4. Re: REVISED: Draft Policy ARIN-2012-8: Aligning 8.2 and 8.3
Transfer Policy (Steve Noble)
----------------------------------------------------------------------
Message: 1
Date: Mon, 10 Dec 2012 16:44:27 -0600
From: David Farmer <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning
8.2 and 8.3 Transfer Policy
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Depending on the traditions you follow, the holidays are or very soon
will be upon us; Nevertheless, please look at the following text and
provide your comments to the AC.
BE ADVISED, the AC is likely to consider sending this text to last call
at its meeting next week. Please let us know your opinion, even if it
is you simply support or not the text as written.
Thanks and Happy Holidays.
On 11/26/12 15:25 , Chris Grundemann wrote:
> I made some updates based on feedback received here, the new text is as
> follows:
>
> ----8<----8<----
> Replace the first paragraph of section 8.2 with the following (second
> paragraph remains unchanged):
>
> ARIN will consider requests for the transfer of number resources in
> the case of mergers and acquisitions under the following conditions:
>
> * The new entity must provide evidence that they have acquired assets
> that use the resources transferred from the current registrant. ARIN
> will maintain an up-to-date list of acceptable types of documentation.
> * The current registrant must not be involved in any dispute as to the
> status of the transferred resources.
> * The new entity must sign an RSA covering all transferred resources.
> * The transferred resources will be subject to ARIN policies.
> * The minimum transfer size is the smaller of the original allocation
> size or the applicable minimum allocation size in current policy.
> ----8<----8<----
>
> Cheers,
> ~Chris
>
>
> On Mon, Nov 19, 2012 at 9:39 PM, Owen DeLong <[email protected]> wrote:
>>
>> On Nov 19, 2012, at 7:56 PM, Jimmy Hess <[email protected]> wrote:
>>
>>> On 11/19/12, Owen DeLong <[email protected]> wrote:
>>>
>>>> IOW, I want to avoid extending the more lenient 8.2 provisions to a sale
>>>> where someone buys $100,000 worth of IP addresses and $20,000 worth of
>>>> hardware and then sells the hardware to $SCRAP_DEALER just to keep the
>>>> addresses.
>>>
>>> IP addresses don't belong to hardware; IP addresses belong to IP
>>> interfaces, attached to hardware, in order to provide connectivity to
>>> a network node for communicating or offering a service. A change
>>> of hardware does not imply that the need for the logical IP interface
>>> goes away. If you send a router to a scrap dealer, that doesn't
>>> mean all the networks it routed necessarily go away.
>>>
>>
>> The above statement was short-hand to explain my intent, not an absolute
>> statement implying that addresses were attached directly to hardware.
>> Put it back in context with what I was responding to.
>>
>>> What about cases, where the acquiring organization finds the hardware
>>> _belongs_ with $TRASH_COLLECTION or $SCRAP_DEALER due to the
>>> obsolescence of said decrepit hardware, and after acquiring, they
>>> will make a non-disruptive reallocation of the hardware used to
>>> provide IT services? Probably by re-consolidating on new
>>> hardware.
>>>
>>
>> The policy language I proposed would not preclude this.
>>
>>> That kind of restructuring does not make renumbering reasonable
>>> and doesn't belong under 8.3.
>>
>> Agreed. However, I want to make sure that 8.2 does not get abused to
>> back-door 8.3 style transfers by adding hardware to the mix and pretending
>> it is an acquisition of a working network.
>>
>> Owen
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List ([email protected]).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact [email protected] if you experience any issues.
>
>
>
--
================================================
David Farmer Email: [email protected]
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
================================================
------------------------------
Message: 2
Date: Mon, 10 Dec 2012 15:25:35 -0800
From: Scott Leibrand <[email protected]>
To: David Farmer <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning
8.2 and 8.3 Transfer Policy
Message-ID:
<cagkmwz6n3eayuhbvrbu3sogsw80oav+yxtzc5zkk0_q_47s...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
No objections here. As far as I can tell the only substantive change
(other than codifying existing practice) is the requirement that "The new
entity must sign an RSA covering all transferred resources." That seems
like a (minor) improvement in policy.
-Scott
On Mon, Dec 10, 2012 at 2:44 PM, David Farmer <[email protected]> wrote:
> Depending on the traditions you follow, the holidays are or very soon will
> be upon us; Nevertheless, please look at the following text and provide
> your comments to the AC.
>
> BE ADVISED, the AC is likely to consider sending this text to last call at
> its meeting next week. Please let us know your opinion, even if it is you
> simply support or not the text as written.
>
> Thanks and Happy Holidays.
>
>
> On 11/26/12 15:25 , Chris Grundemann wrote:
>
>> I made some updates based on feedback received here, the new text is as
>> follows:
>>
>> ----8<----8<----
>> Replace the first paragraph of section 8.2 with the following (second
>> paragraph remains unchanged):
>>
>> ARIN will consider requests for the transfer of number resources in
>> the case of mergers and acquisitions under the following conditions:
>>
>> * The new entity must provide evidence that they have acquired assets
>> that use the resources transferred from the current registrant. ARIN
>> will maintain an up-to-date list of acceptable types of documentation.
>> * The current registrant must not be involved in any dispute as to the
>> status of the transferred resources.
>> * The new entity must sign an RSA covering all transferred resources.
>> * The transferred resources will be subject to ARIN policies.
>> * The minimum transfer size is the smaller of the original allocation
>> size or the applicable minimum allocation size in current policy.
>> ----8<----8<----
>>
>> Cheers,
>> ~Chris
>>
>>
>> On Mon, Nov 19, 2012 at 9:39 PM, Owen DeLong <[email protected]> wrote:
>>
>>>
>>> On Nov 19, 2012, at 7:56 PM, Jimmy Hess <[email protected]> wrote:
>>>
>>> On 11/19/12, Owen DeLong <[email protected]> wrote:
>>>>
>>>> IOW, I want to avoid extending the more lenient 8.2 provisions to a
>>>>> sale
>>>>> where someone buys $100,000 worth of IP addresses and $20,000 worth of
>>>>> hardware and then sells the hardware to $SCRAP_DEALER just to keep the
>>>>> addresses.
>>>>>
>>>>
>>>> IP addresses don't belong to hardware; IP addresses belong to IP
>>>> interfaces, attached to hardware, in order to provide connectivity to
>>>> a network node for communicating or offering a service. A change
>>>> of hardware does not imply that the need for the logical IP interface
>>>> goes away. If you send a router to a scrap dealer, that doesn't
>>>> mean all the networks it routed necessarily go away.
>>>>
>>>>
>>> The above statement was short-hand to explain my intent, not an absolute
>>> statement implying that addresses were attached directly to hardware.
>>> Put it back in context with what I was responding to.
>>>
>>> What about cases, where the acquiring organization finds the hardware
>>>> _belongs_ with $TRASH_COLLECTION or $SCRAP_DEALER due to the
>>>> obsolescence of said decrepit hardware, and after acquiring, they
>>>> will make a non-disruptive reallocation of the hardware used to
>>>> provide IT services? Probably by re-consolidating on new
>>>> hardware.
>>>>
>>>>
>>> The policy language I proposed would not preclude this.
>>>
>>> That kind of restructuring does not make renumbering reasonable
>>>> and doesn't belong under 8.3.
>>>>
>>>
>>> Agreed. However, I want to make sure that 8.2 does not get abused to
>>> back-door 8.3 style transfers by adding hardware to the mix and
>>> pretending
>>> it is an acquisition of a working network.
>>>
>>> Owen
>>>
>>> ______________________________**_________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List ([email protected]).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/**listinfo/arin-ppml<http://lists.arin.net/mailman/listinfo/arin-ppml>
>>> Please contact [email protected] if you experience any issues.
>>>
>>
>>
>>
>>
>
> --
> ==============================**==================
> David Farmer Email: [email protected]
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
> ==============================**==================
> ______________________________**_________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/**listinfo/arin-ppml<http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact [email protected] if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20121210/88b1aee1/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 10 Dec 2012 19:42:02 -0800
From: Gary Buhrmaster <[email protected]>
To: Scott Leibrand <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning
8.2 and 8.3 Transfer Policy
Message-ID:
<camfxtqx_fmkmad+akq+p4dlc5nurphmgeyxh_bhxipnuxiv...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Dec 10, 2012 at 3:25 PM, Scott Leibrand <[email protected]> wrote:
> No objections here. As far as I can tell the only substantive change (other
> than codifying existing practice) is the requirement that "The new entity
> must sign an RSA covering all transferred resources." That seems like a
> (minor) improvement in policy.
Is there any concern from the community regarding the word "an" in
... must sign *an* RSA ...
While any RSA is better than none, I seem to recall a similar
wording was interpreted by ARIN in a way that caused some
members of the community some consternation (i.e. it allowed
a Legacy RSA).
Gary
------------------------------
Message: 4
Date: Mon, 10 Dec 2012 20:27:59 -0800
From: Steve Noble <[email protected]>
To: Gary Buhrmaster <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] REVISED: Draft Policy ARIN-2012-8: Aligning
8.2 and 8.3 Transfer Policy
Message-ID:
<cajjtgxmzj-jz6i_5_w4227zpmduj-8wdq9qgnjomiqjdw_v...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
TL;DR I don't agree with forcing people under RSAs especially the
latest one just "because".
I've been on the other side of the "which version of the RSA"
discussion. ARIN refuses to allow you to re-sign or sign a copy of
the RSA that applied at the time of the registration/transfer/action
unless it is the current RSA. All ARIN really has to do is refuse to
accept the RSA. ARIN is a monopoly, if they do not accept a document
from you, there is not much you can do.
Remember, because of ARINs own mistake (and I very much do thank John
for researching and correcting it) I was caught in a circle where I
could not update a ASN that I had the right to update, that I paid for
every year. Had John not found the issue, there would be over 2000
other organizations caught in the same limbo.
On Mon, Dec 10, 2012 at 7:42 PM, Gary Buhrmaster
<[email protected]> wrote:
> On Mon, Dec 10, 2012 at 3:25 PM, Scott Leibrand <[email protected]>
> wrote:
>> No objections here. As far as I can tell the only substantive change (other
>> than codifying existing practice) is the requirement that "The new entity
>> must sign an RSA covering all transferred resources." That seems like a
>> (minor) improvement in policy.
>
> Is there any concern from the community regarding the word "an" in
>
> ... must sign *an* RSA ...
>
> While any RSA is better than none, I seem to recall a similar
> wording was interpreted by ARIN in a way that caused some
> members of the community some consternation (i.e. it allowed
> a Legacy RSA).
>
> Gary
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 90, Issue 3
****************************************
