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. Updates to 2012-6 (Bill Sandiford)
2. Re: Updates to 2012-6 (Bill Sandiford)
3. Re: Updates to 2012-6 (Martin Hannigan)
----------------------------------------------------------------------
Message: 1
Date: Wed, 21 Nov 2012 14:21:56 -0500
From: Bill Sandiford <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [arin-ppml] Updates to 2012-6
Message-ID:
<FE7D4327AABC0448A6281C0AC4445C7CE29CF500BE@Exchange2007.HostedMail.local>
Content-Type: text/plain; charset="us-ascii"
All,
Since the conclusion of the Dallas PPM the AC has spent considerable time
working on Draft Policy 2012-6. As a result, we have come up with modified
text as below. You will note that the new policy text makes minimal changes to
the existing policy in the NRPM, but still obtains the goals as intended by the
author and expressed by the community in Dallas.
Please provide comments.
Regards,
Bill
------
Policy text:
4.4. Micro-allocation
ARIN will make IPv4 micro-allocations to critical infrastructure providers of
the Internet, including public exchange points, core DNS service providers
(e.g. ICANN-sanctioned root and ccTLD operators) as well as the RIRs and IANA.
These allocations will be no smaller than a /24. Multiple allocations may be
granted in certain situations.
Exchange point allocations MUST be allocated from specific blocks reserved only
for this purpose. All other micro-allocations WILL be allocated out of other
blocks reserved for micro-allocation purposes.
ARIN will make a list of these blocks publicly available.
Exchange point operators must provide justification for the allocation,
including: connection policy, location, other participants (minimum of two
total), ASN, and contact information. ISPs and other organizations receiving
these micro-allocations will be charged under the ISP fee schedule, while
end-users will be charged under the fee schedule for end-users. This policy
does not preclude exchange point operators from requesting address space under
other policies.
ARIN will place an equivalent of a /16 of IPv4 address space in a reserve for
Critical Infrastructure, as defined in section 4.4. If at the end of the policy
term there is unused address space remaining in this pool, ARIN staff is
authorized to utilize this space in a manner consistent with community
expectations.
ICANN-sanctioned gTLD operators may justify up to the equivalent of an
IPv4 /23 block for each authorized new gTLD, allocated from the free pool or
received via transfer, but not from the above reservation. This limit of a /23
equivalent per gTLD does not apply to gTLD allocations made under previous
policy.
Rationale:
Additional ICANN-sanctioned DNS infrastructure is being added to the Internet
and in quantities greater than anticipated when the micro allocation proposal
was written and adopted.
The original CI pool was created to serve new IXP and new CI requirements. The
pending need is estimated to be over 1000 new gTLD range, which may exhaust the
current /16 reservation before the ARIN free pool is exhausted. Once the
current /16 reservation is exhausted, CI providers would no longer be eligible
to receive address space, either via the general free pool or via transfer.
The original proposal dealt with this by expanding the reservation to a
/15 and allowing CI to draw from the free pool instead of the reservation until
it gets down to a /8. The consensus coming out of the Dallas meeting seems to
be that this is an inadequate solution. As the new expanded gTLD demand will
obliterate any reasonable reservation, leaving no resources for the other IXP
and CI demands that the original reservation was intended to serve. It is
therefore, not possible to services them both out of a common reservation.
In order to ensure continued access to IPv4 number resources by new IXP and DNS
operators alike, the AC is modifying the proposal going into last call to allow
gTLD operators to continue to qualify for micro allocations from the general
free pool or via transfer only, and leaving one /16 reserved for IXP, root, and
ccTLD DNS operators.
As a result of the close examination of the CI policy brought about by this
proposal, the AC has identified a number of issues in the original policy text
that should be addressed. However, the AC is intentionally minimizing the
overall changes to this proposal as much as possible for last call in keeping
with the spirit of the PDP. The AC intends to make future proposals to deal
with these other concerns. The current proposal addresses issues of some
urgency and we did not want to delay it to another policy cycle as a result.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20121121/aa16c961/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 21 Nov 2012 17:05:31 -0500
From: Bill Sandiford <[email protected]>
To: 'Rodney Joffe' <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Updates to 2012-6
Message-ID:
<FE7D4327AABC0448A6281C0AC4445C7CE29CF500C7@Exchange2007.HostedMail.local>
Content-Type: text/plain; charset="us-ascii"
Hi Rodney,
Please note that terminology is not new. It is the terminology that is
currently in the NRPM today.
https://www.arin.net/policy/nrpm.html#four4
Any suggested edits to the text are welcomed.
Bill
-----Original Message-----
From: Rodney Joffe [mailto:[email protected]]
Sent: November 21, 2012 2:56 PM
To: Bill Sandiford
Subject: Re: [arin-ppml] Updates to 2012-6
Bill,
Sorry to be the potential bearer of bad tidings regarding the wording of this
policy, but...
I think the terminology needs to be cleaned up.
Core DNS operators - Thats someone like me (UltraDNS/Neustar).
core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) - I
guess thats confusing.
We are a core DNS service provider. However we will be providing the services
to over 300 of the new TLD registries. If you allocate the /23s to us, the
registry is screwed if they move at some stage to another provider, or do it
themselves. So you should be allocating to the TLD Registry itself, who can
then temporarily assign the /23 to us, but can then move it when needed.
No?
Regards
Rodney
On Nov 21, 2012, at 12:21 PM, Bill Sandiford <[email protected]>
wrote:
> All,
>
> Since the conclusion of the Dallas PPM the AC has spent considerable time
> working on Draft Policy 2012-6. As a result, we have come up with modified
> text as below. You will note that the new policy text makes minimal changes
> to the existing policy in the NRPM, but still obtains the goals as intended
> by the author and expressed by the community in Dallas.
>
> Please provide comments.
>
> Regards,
> Bill
>
> ------
>
> Policy text:
>
> 4.4. Micro-allocation
> ARIN will make IPv4 micro-allocations to critical infrastructure providers of
> the Internet, including public exchange points, core DNS service providers
> (e.g. ICANN-sanctioned root and ccTLD operators) as well as the RIRs and
> IANA. These allocations will be no smaller than a /24. Multiple allocations
> may be granted in certain situations.
>
> Exchange point allocations MUST be allocated from specific blocks reserved
> only for this purpose. All other micro-allocations WILL be allocated out of
> other blocks reserved for micro-allocation purposes.
> ARIN will make a list of these blocks publicly available.
>
> Exchange point operators must provide justification for the
> allocation,
> including: connection policy, location, other participants (minimum of two
> total), ASN, and contact information. ISPs and other organizations receiving
> these micro-allocations will be charged under the ISP fee schedule, while
> end-users will be charged under the fee schedule for end-users. This policy
> does not preclude exchange point operators from requesting address space
> under other policies.
>
> ARIN will place an equivalent of a /16 of IPv4 address space in a reserve for
> Critical Infrastructure, as defined in section 4.4. If at the end of the
> policy term there is unused address space remaining in this pool, ARIN staff
> is authorized to utilize this space in a manner consistent with community
> expectations.
>
> ICANN-sanctioned gTLD operators may justify up to the equivalent of an
> IPv4 /23 block for each authorized new gTLD, allocated from the free pool or
> received via transfer, but not from the above reservation. This limit of a
> /23 equivalent per gTLD does not apply to gTLD allocations made under
> previous policy.
>
> Rationale:
>
> Additional ICANN-sanctioned DNS infrastructure is being added to the Internet
> and in quantities greater than anticipated when the micro allocation proposal
> was written and adopted.
>
> The original CI pool was created to serve new IXP and new CI requirements.
> The pending need is estimated to be over 1000 new gTLD range, which may
> exhaust the current /16 reservation before the ARIN free pool is exhausted.
> Once the current /16 reservation is exhausted, CI providers would no longer
> be eligible to receive address space, either via the general free pool or via
> transfer.
>
> The original proposal dealt with this by expanding the reservation to
> a
> /15 and allowing CI to draw from the free pool instead of the reservation
> until it gets down to a /8. The consensus coming out of the Dallas meeting
> seems to be that this is an inadequate solution. As the new expanded gTLD
> demand will obliterate any reasonable reservation, leaving no resources for
> the other IXP and CI demands that the original reservation was intended to
> serve. It is therefore, not possible to services them both out of a common
> reservation.
>
> In order to ensure continued access to IPv4 number resources by new IXP and
> DNS operators alike, the AC is modifying the proposal going into last call to
> allow gTLD operators to continue to qualify for micro allocations from the
> general free pool or via transfer only, and leaving one /16 reserved for IXP,
> root, and ccTLD DNS operators.
>
> As a result of the close examination of the CI policy brought about by this
> proposal, the AC has identified a number of issues in the original policy
> text that should be addressed. However, the AC is intentionally minimizing
> the overall changes to this proposal as much as possible for last call in
> keeping with the spirit of the PDP. The AC intends to make future proposals
> to deal with these other concerns. The current proposal addresses issues of
> some urgency and we did not want to delay it to another policy cycle as a
> result.
>
> _______________________________________________
> 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.
------------------------------
Message: 3
Date: Wed, 21 Nov 2012 21:35:24 -0500
From: Martin Hannigan <[email protected]>
To: Bill Sandiford <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Updates to 2012-6
Message-ID:
<CAMDXq5NMmnoeqmtt5F-xeMTn+p=f3bghrmt92vxkkd4g49a...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I think Rodney's comments are solid. Moves may also be involuntary and
forcing transactions through the transfer process seems like
unnecessary overhead that simply slows things down and could cause
real damage.
The terminology "ICANN sanctioned" is in error as well. ICANN doesn't
sanction TLD's, they enter into agreements and become "contracted
parties". It is consistent with ICANN terminology which I think that
in this case it makes sense to align as much as possible and feasible.
Best,
-M<
On Wed, Nov 21, 2012 at 5:05 PM, Bill Sandiford
<[email protected]> wrote:
> Hi Rodney,
>
> Please note that terminology is not new. It is the terminology that is
> currently in the NRPM today.
>
> https://www.arin.net/policy/nrpm.html#four4
>
> Any suggested edits to the text are welcomed.
>
> Bill
>
> -----Original Message-----
> From: Rodney Joffe [mailto:[email protected]]
> Sent: November 21, 2012 2:56 PM
> To: Bill Sandiford
> Subject: Re: [arin-ppml] Updates to 2012-6
>
> Bill,
>
> Sorry to be the potential bearer of bad tidings regarding the wording of this
> policy, but...
>
> I think the terminology needs to be cleaned up.
>
> Core DNS operators - Thats someone like me (UltraDNS/Neustar).
> core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) -
> I guess thats confusing.
>
> We are a core DNS service provider. However we will be providing the services
> to over 300 of the new TLD registries. If you allocate the /23s to us, the
> registry is screwed if they move at some stage to another provider, or do it
> themselves. So you should be allocating to the TLD Registry itself, who can
> then temporarily assign the /23 to us, but can then move it when needed.
>
> No?
>
> Regards
> Rodney
>
> On Nov 21, 2012, at 12:21 PM, Bill Sandiford <[email protected]>
> wrote:
>
>> All,
>>
>> Since the conclusion of the Dallas PPM the AC has spent considerable time
>> working on Draft Policy 2012-6. As a result, we have come up with modified
>> text as below. You will note that the new policy text makes minimal changes
>> to the existing policy in the NRPM, but still obtains the goals as intended
>> by the author and expressed by the community in Dallas.
>>
>> Please provide comments.
>>
>> Regards,
>> Bill
>>
>> ------
>>
>> Policy text:
>>
>> 4.4. Micro-allocation
>> ARIN will make IPv4 micro-allocations to critical infrastructure providers
>> of the Internet, including public exchange points, core DNS service
>> providers (e.g. ICANN-sanctioned root and ccTLD operators) as well as the
>> RIRs and IANA. These allocations will be no smaller than a /24. Multiple
>> allocations may be granted in certain situations.
>>
>> Exchange point allocations MUST be allocated from specific blocks reserved
>> only for this purpose. All other micro-allocations WILL be allocated out of
>> other blocks reserved for micro-allocation purposes.
>> ARIN will make a list of these blocks publicly available.
>>
>> Exchange point operators must provide justification for the
>> allocation,
>> including: connection policy, location, other participants (minimum of two
>> total), ASN, and contact information. ISPs and other organizations receiving
>> these micro-allocations will be charged under the ISP fee schedule, while
>> end-users will be charged under the fee schedule for end-users. This policy
>> does not preclude exchange point operators from requesting address space
>> under other policies.
>>
>> ARIN will place an equivalent of a /16 of IPv4 address space in a reserve
>> for Critical Infrastructure, as defined in section 4.4. If at the end of the
>> policy term there is unused address space remaining in this pool, ARIN staff
>> is authorized to utilize this space in a manner consistent with community
>> expectations.
>>
>> ICANN-sanctioned gTLD operators may justify up to the equivalent of an
>> IPv4 /23 block for each authorized new gTLD, allocated from the free pool or
>> received via transfer, but not from the above reservation. This limit of a
>> /23 equivalent per gTLD does not apply to gTLD allocations made under
>> previous policy.
>>
>> Rationale:
>>
>> Additional ICANN-sanctioned DNS infrastructure is being added to the
>> Internet and in quantities greater than anticipated when the micro
>> allocation proposal was written and adopted.
>>
>> The original CI pool was created to serve new IXP and new CI requirements.
>> The pending need is estimated to be over 1000 new gTLD range, which may
>> exhaust the current /16 reservation before the ARIN free pool is exhausted.
>> Once the current /16 reservation is exhausted, CI providers would no longer
>> be eligible to receive address space, either via the general free pool or
>> via transfer.
>>
>> The original proposal dealt with this by expanding the reservation to
>> a
>> /15 and allowing CI to draw from the free pool instead of the reservation
>> until it gets down to a /8. The consensus coming out of the Dallas meeting
>> seems to be that this is an inadequate solution. As the new expanded gTLD
>> demand will obliterate any reasonable reservation, leaving no resources for
>> the other IXP and CI demands that the original reservation was intended to
>> serve. It is therefore, not possible to services them both out of a common
>> reservation.
>>
>> In order to ensure continued access to IPv4 number resources by new IXP and
>> DNS operators alike, the AC is modifying the proposal going into last call
>> to allow gTLD operators to continue to qualify for micro allocations from
>> the general free pool or via transfer only, and leaving one /16 reserved for
>> IXP, root, and ccTLD DNS operators.
>>
>> As a result of the close examination of the CI policy brought about by this
>> proposal, the AC has identified a number of issues in the original policy
>> text that should be addressed. However, the AC is intentionally minimizing
>> the overall changes to this proposal as much as possible for last call in
>> keeping with the spirit of the PDP. The AC intends to make future proposals
>> to deal with these other concerns. The current proposal addresses issues of
>> some urgency and we did not want to delay it to another policy cycle as a
>> result.
>>
>> _______________________________________________
>> 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.
>
> _______________________________________________
> 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 89, Issue 16
*****************************************
