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: ARIN-prop-183 Section 8.4 Transfer enhancement
(Christoph Blecker)
2. Re: ARIN-prop-183 Section 8.4 Transfer enhancement (Ron Grant)
3. Re: ARIN-prop-183 Section 8.4 Transfer enhancement (Michael Burns)
4. Re: ARIN-prop-183 Section 8.4 Transfer enhancement (David Farmer)
5. Re: ARIN-prop-183 Section 8.4 Transfer enhancement (David Farmer)
6. Re: ARIN-prop-183 Section 8.4 Transfer enhancement
(Martin Hannigan)
----------------------------------------------------------------------
Message: 1
Date: Tue, 30 Oct 2012 10:31:23 -0700
From: Christoph Blecker <[email protected]>
To: Michael Burns <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] ARIN-prop-183 Section 8.4 Transfer
enhancement
Message-ID:
<CADx2oGFJAs-hgQ2guu7z7GT=vxlpklhpup3k_wpaelhyz_u...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Tue, Oct 30, 2012 at 10:14 AM, Michael Burns <[email protected]> wrote:
> Hi Ron,
>
> You have identified a distinction between ASNs and IPv4 addresses, but is it
> really a difference?
> What does it matter that the one is in short supply and the other isn't?
>
> Both are resources used in the running of the Internet.
> Both come from the same source.
> Both are part of the all-important registry.
> Both are items that holders are desirous of transferring.
>
> What is the downside to taking a step towards registry accuracy?
> Are we worried about speculation and hoarding of ASNs now?
>
>
> Regards,
>
> Mike Burns
> IPTrading.com
>
>
>
>
>
> Ron wrote:
> I disagree with the proposal, which as it stands attempts to conflate
> "IPv4 address resources" with Autonomous System Numbers.
>
>
> I don't think that the transfers have anything to do with each other,
> and shouldn't be governed by the same principles. The language "IPv4
> number resources and ASNs" suggests that some ASNs are "IPv4" and some
> are not.
>
> IPv4 addresses are a legacy resource in exceedingly short and dwindling
> supply, which cannot easily be replaced by IPv6 addresses (regardless of
> our desire to do so). They are also amenable to aggregation. And they'll
> eventually go away.
>
> ASNs are NOT in short supply. A 4-byte ASN means we have room in the
> world for...uh...4 billion ISPs and multi-homers? Is that right? (wow,
> talk about competition!). And ASN aggregation is meaningless, so
> "efficient utilization" isn't really a desirable goal.
>
>> From what my attention-addled brain gathers, the ASN transfer market is
>
> about "vanity numbers" - i.e. low 2-byte or memorable ASNs. If there's
> really a need for Inter-RIR transfers of vanity numbers, by all means
> let's create a proposal in conjunction with other RIRs - but adding them
> to the existing IPv4 transfer policy is jut going to make discussions
> about the transfer policy more difficult. It will also make sunsetting
> said policies in an IPv6 world impossible, since 4-byte ASNs will be
> with us for MUCH longer than IPv4 addresses.
Multiple people, including the originator have indicated that there is
some sort of black market of ASNs. I find a hard time believing this
is the case. The fact is, an ASN is some random number that is only
used by networking people. It's only value is A) that it's unique, B)
it's identifiable via a registry, and C) this idea by some that a
smaller number is automatically better. If the ASN isn't identifiable
via a registry, what value does the ASN have?
Is there any statistics or proof for the community that there are
networks actively utilizing ASNs, that are assigned to somebody else
registry, and would have a claim to them as far as a transfer is
concerned?
Cheers,
Christoph
------------------------------
Message: 2
Date: Tue, 30 Oct 2012 10:36:46 -0700
From: Ron Grant <[email protected]>
To: Michael Burns <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] ARIN-prop-183 Section 8.4 Transfer
enhancement
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I'd like to modify my previousy message to read:
"which, oddly, I am not opposed to".
(I don't actually care about inter-RIRs at all, have no knowledge of any
need, but admit that I'd be the last person anyone would tell)
On 12-10-30 10:29 AM, Ron Grant wrote:
> - Allow the transfer of ASNs between RIRs
>
> which, oddly, I am ALSO in favour of. If we allow it "intra" we should
> allow it "inter".
>
--
Ron Grant Managed DSL/T1/Wireless/Fibre
Skyway West Business Internet Internet and Private Networking
[email protected] Bonding and Fail Over Solutions
ph: 604 737 2113 Virtual Data Centre and Private Clouds
fax: 604 482 1299 http://www.skywaywest.com
Sales, Support and Billing http://www.skywaywest.com/contact-us.htm
------------------------------
Message: 3
Date: Tue, 30 Oct 2012 13:47:51 -0400
From: "Michael Burns" <[email protected]>
To: "Ron Grant" <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] ARIN-prop-183 Section 8.4 Transfer
enhancement
Message-ID: <14A752C6EC3748DCB5327D92A2FAA03B@MPC>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=response
Hi Ron,
I don't really see the danger.
If we have to address hoarding wrt 8.4, we will be doing the same with 8.3.
And if you would be in support of an "8.5" now, so as to keep these things
separate, we could always add it then.
But why risk Whois integrity now over this potential future problem?
That said, I wouldn't mind if it were a separate 8.5 section.
Regards,
Mike
The proposal states two goals: to
- Correct inconsistent language in 8.4 eg "IPv4 Address" v. "IPv4 Number
Resource(s)"
which is a trivial change that I'm sure we'd all agree with, and to
- Allow the transfer of ASNs between RIRs
which, oddly, I am ALSO in favour of. If we allow it "intra" we should
allow it "inter".
I just don't think we should muddy the IPv4 transfer process with them.
Speculation and hoarding? Exactly! These ARE things we should be worried
about wrt IPv4 addresses, but NOT wrt ASNs. So if we start discussing
change to 8.4 to address hoarding issues, we shouldn't have to also
discuss making exceptions for ASNs, or complicating the language by
having to twist ourselves around it. I'll give long odds that we'll be
modifying 8.4 again and again over the years, and can you imagine the
extra work because of the one phrase: " and ASNs"?
If inter-RIR transfer of ASNs is a worthy goal, surely it deserves it's
own process, not just tacked onto the IPv4 process....?
On 12-10-30 10:14 AM, Michael Burns wrote:
> Hi Ron,
>
> You have identified a distinction between ASNs and IPv4 addresses, but is
> it really a difference?
> What does it matter that the one is in short supply and the other isn't?
>
> Both are resources used in the running of the Internet.
> Both come from the same source.
> Both are part of the all-important registry.
> Both are items that holders are desirous of transferring.
>
> What is the downside to taking a step towards registry accuracy?
> Are we worried about speculation and hoarding of ASNs now?
>
>
> Regards,
>
> Mike Burns
> IPTrading.com
>
>
>
>
> Ron wrote:
> I disagree with the proposal, which as it stands attempts to conflate
> "IPv4 address resources" with Autonomous System Numbers.
>
>
> I don't think that the transfers have anything to do with each other,
> and shouldn't be governed by the same principles. The language "IPv4
> number resources and ASNs" suggests that some ASNs are "IPv4" and some
> are not.
>
> IPv4 addresses are a legacy resource in exceedingly short and dwindling
> supply, which cannot easily be replaced by IPv6 addresses (regardless of
> our desire to do so). They are also amenable to aggregation. And they'll
> eventually go away.
>
> ASNs are NOT in short supply. A 4-byte ASN means we have room in the
> world for...uh...4 billion ISPs and multi-homers? Is that right? (wow,
> talk about competition!). And ASN aggregation is meaningless, so
> "efficient utilization" isn't really a desirable goal.
>
> From what my attention-addled brain gathers, the ASN transfer market is
> about "vanity numbers" - i.e. low 2-byte or memorable ASNs. If there's
> really a need for Inter-RIR transfers of vanity numbers, by all means
> let's create a proposal in conjunction with other RIRs - but adding them
> to the existing IPv4 transfer policy is jut going to make discussions
> about the transfer policy more difficult. It will also make sunsetting
> said policies in an IPv6 world impossible, since 4-byte ASNs will be
> with us for MUCH longer than IPv4 addresses.
>
>
>
>
--
Ron Grant Managed DSL/T1/Wireless/Fibre
Skyway West Business Internet Internet and Private Networking
[email protected] Bonding and Fail Over Solutions
ph: 604 737 2113 Virtual Data Centre and Private Clouds
fax: 604 482 1299 http://www.skywaywest.com
Sales, Support and Billing http://www.skywaywest.com/contact-us.htm
------------------------------
Message: 4
Date: Tue, 30 Oct 2012 14:39:51 -0500
From: David Farmer <[email protected]>
To: Martin Hannigan <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] ARIN-prop-183 Section 8.4 Transfer
enhancement
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/30/12 11:05 , Martin Hannigan wrote:
> APNIC inter-rir transfer
------------------------------
Message: 5
Date: Tue, 30 Oct 2012 15:11:50 -0500
From: David Farmer <[email protected]>
To: Martin Hannigan <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] ARIN-prop-183 Section 8.4 Transfer
enhancement
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sorry about that last message it escaped.
On 10/30/12 11:05 , Martin Hannigan wrote:
> We saw that with regional ASN transfers that once you provided the
> mechanism, it was utilized. We knew the demand was there since many
> knew of the quite public secret that ASN's were traded on a regular
> basis. I'm not sure how someone could assert that this wasn't also
> happening internationally.
I have no doubt, but the other RIR's need to decide to implement ASN
Transfers for themselves, ARIN shouldn't and I don't think can force
them to implement ASN transfers that is for those communities to decide.
> Section 5 of the APNIC inter-rir transfer might be interpreted to
> accommodate this type of transfer as well as RIPE 2012-7 since it
> doesn't differentiate a legacy "internet resource". I can't speak for
> the policy proposers in the RIPE region and nor do I pretend to, but
> in the latter case, it's possible that we don't need this proposal at
> all since theoretically, the RIPE region proposal (if adopted) clearly
> states the definition of a legacy resources as prior to the creation
> of the RIPE NCC and does not differentiate between ASN's and IP
> addresses. One might also assume that based on the language you might
> be able to bring your resource directly to the RIPE NCC, get their
> services agreement which if adopted would be much more conducive to
> retaining the value of a resource, and simply register the transfer
> there.
Both of these seem to be fairly specific in dealing with Resources that
are already under the control of APNIC or RIPE as part of Early
Registration Transfers (ERX). Not general Inter-RIR transfers as
envisioned by 8.4 of ARIN's NRPM or section 4 of APNIC's transfer policy.
> Making it "easy" to utilize ARIN's process, even if it turns out to be
> inferior to other regions, has value. It makes a transfer cheaper for
> one thing and instills a level of trust on the part of a US based
> transferee since familiarity with a legal system is part of that trust
> mechanism. It also insures that the supply of ASN's is efficiently
> used and that the all important registry is updated and as accurate as
> possible. I thought the latter part was the important bit to be
> honest.
Section 8.4 is fairly specific that there needs to be a reciprocal
policy at the other RIR, if you remember I argued against that, but that
is ARIN's policy.
I'm willing to accept this on to the docket in order to not create a
catch-22, and make it clear ARIN is willing to consider this of other
RIRs are too. However, I'm not sure significant effort should be put
into it until at least ASN transfers have been proposed at another RIR.
------------------------------
Message: 6
Date: Tue, 30 Oct 2012 16:32:43 -0400
From: Martin Hannigan <[email protected]>
To: David Farmer <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] ARIN-prop-183 Section 8.4 Transfer
enhancement
Message-ID:
<CAMDXq5NAYm_5hQS5MDYdBweF_h=r_0mgzp6wwmpnedrlqeg...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Oct 30, 2012 at 4:11 PM, David Farmer <[email protected]> wrote:
> Sorry about that last message it escaped.
>
>
> On 10/30/12 11:05 , Martin Hannigan wrote:
>
>> We saw that with regional ASN transfers that once you provided the
>> mechanism, it was utilized. We knew the demand was there since many
>> knew of the quite public secret that ASN's were traded on a regular
>> basis. I'm not sure how someone could assert that this wasn't also
>> happening internationally.
>
>
> I have no doubt, but the other RIR's need to decide to implement ASN
> Transfers for themselves, ARIN shouldn't and I don't think can force them to
> implement ASN transfers that is for those communities to decide.
>
That's not what is being proposed. Just because ARIN makes something
available does not mean that another region has to do anything. We
learned that with the first version of inter-rir transfer which was a
global policy that tried to implicitly set conditions that would
normally be under the other RIR's control. We still did it in this
regional version of inter-rir transfer and forced the others to
require need.
That skullduggery is already complete. This proposal simply allows for
ASN's to be more reliably documented. I'm not sure where it implies
that anyone has to do anything other than to do what they already do
except do it in the light instead of in the dark.
>
>> Section 5 of the APNIC inter-rir transfer might be interpreted to
>> accommodate this type of transfer as well as RIPE 2012-7 since it
>> doesn't differentiate a legacy "internet resource". I can't speak for
>> the policy proposers in the RIPE region and nor do I pretend to, but
>> in the latter case, it's possible that we don't need this proposal at
>> all since theoretically, the RIPE region proposal (if adopted) clearly
>> states the definition of a legacy resources as prior to the creation
>> of the RIPE NCC and does not differentiate between ASN's and IP
>> addresses. One might also assume that based on the language you might
>> be able to bring your resource directly to the RIPE NCC, get their
>> services agreement which if adopted would be much more conducive to
>> retaining the value of a resource, and simply register the transfer
>> there.
>
>
> Both of these seem to be fairly specific in dealing with Resources that are
> already under the control of APNIC or RIPE as part of Early Registration
> Transfers (ERX). Not general Inter-RIR transfers as envisioned by 8.4 of
> ARIN's NRPM or section 4 of APNIC's transfer policy.
>
I think we can agree to disagree. I would assume that is the case in
the APNIC region, but no so much in the RIPE region. It will be
interesting to see 2012-7 play out since it appears to have great and
constructive interest in the RIPE region.
>
>> Making it "easy" to utilize ARIN's process, even if it turns out to be
>> inferior to other regions, has value. It makes a transfer cheaper for
>> one thing and instills a level of trust on the part of a US based
>> transferee since familiarity with a legal system is part of that trust
>> mechanism. It also insures that the supply of ASN's is efficiently
>> used and that the all important registry is updated and as accurate as
>> possible. I thought the latter part was the important bit to be
>> honest.
>
>
> Section 8.4 is fairly specific that there needs to be a reciprocal policy at
> the other RIR, if you remember I argued against that, but that is ARIN's
> policy.
>
+1
> I'm willing to accept this on to the docket in order to not create a
> catch-22, and make it clear ARIN is willing to consider this of other RIRs
> are too. However, I'm not sure significant effort should be put into it
> until at least ASN transfers have been proposed at another RIR.
>
Why bother working on policy if you aren't going to take it seriously?
That also implies that we don't take registry accuracy seriously FWIW.
Best,
-M<
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 88, Issue 29
*****************************************
