2008/12/11 <address-policy-wg-request@ripe.net>

Send address-policy-wg mailing list submissions to
address-policy-wg@ripe.net

To subscribe or unsubscribe via the World Wide Web, visit
http://www.ripe.net/mailman/listinfo/address-policy-wg
or, via email, send a message with subject or body 'help' to
address-policy-wg-request@ripe.net

You can reach the person managing the list at
address-policy-wg-admin@ripe.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of address-policy-wg digest..."

Today's Topics:

1. Re: IPv6 assignment for the RIPE meetingnetwork (John L. Crain)
2. 2008-05 Revised/New Discussion Phase set (Anycasting Assignments for TLD's and Tier 0/1 ENUM) (Antoin Verschuren)
3. Re: 2008-05 Revised/New Discussion Phase set
(Anycasting Assignments for TLD's and Tier 0/1 ENUM) (Leo Vegoda)
4. New paper on RIRs by Internet Governance Project (Milton L Mueller)
5. DRAFT: allocating resources to the RIPE NCC (Remco van Mook)
6. Re: 2008-05 Revised/New Discussion Phase set
(Anycasting Assignments for TLD's and Tier 0/1 ENUM) (Jeffrey A. Williams)

--__--__--

Message: 1
From: "John L. Crain" <john.crain@icann.org>
To: Sander Steffann <sander@steffann.nl>, Shane Kerr
<shane@time-travellers.org>
CC: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net>
Date: Tue, 9 Dec 2008 09:58:16 -0800
Subject: Re: [address-policy-wg] IPv6 assignment for the RIPE meetingnetwork

Hi folks,

One other way that this could be handled is to ask one of the other RIRs to
assess the resource request. I'm trying to remember how we did this in the
past with IPv4, am sure Daniel remembers, but I think we asked IANA to chec=
k
the assignment. Any of the other RIRs will have Hostmasters or Resource
Analysts that are highly familiar with the RIPE area policies.

I would advise against making anything more cumbersome than it needs to be.
Am sure the other RIRs have the same issue and a simple policy of review by
another RIR would solve the issue for all.

John

On 08/12/2008 05:21, "Sander Steffann" <sander@steffann.nl> wrote:

> Hello Shane,
>> I'd just like to mention as a tiny historical note, that the RIPE NCC
>> was founded in part to organise RIPE meetings.
>>
>> Look at 3.3 of the first RIPE NCC Activity Plan:
>>
>> ftp://ftp.ripe.net/ripe/docs/ripe-035.txt
>>
> Thank you for the reference.
>> The conflict of interest having the RIPE NCC evaluate it's own request f=
or
>> resources is real, but I think we must all admit totally symbolic. We're
>> talking about very small blocks here, so seriously considering the idea =
of
>> incorporating a new company to fill out some paperwork makes me wonder i=
f I'm
>> about to see a rabbit with a stopwatch running past
>> declaring "I'm late, I'm late!". (*)
> :-)
>
> All the paperwork needs to be correct though, so we need an official way
> to give the NCC resources. Remco van Mook suggested a solution
> (http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00=
745.h
> tml)
> and offered to try to write a formal policy proposal
> (http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00=
823.h
> tml).
>
> I think this is the best way forward and we should give Remco some time
> to work on that policy proposal.
> Sander
>

--__--__--

Message: 2
Subject: [address-policy-wg] 2008-05 Revised/New Discussion Phase set (Anycasting Assignments for TLD's and Tier 0/1 ENUM)
Date: Wed, 10 Dec 2008 12:21:40 +0100
From: "Antoin Verschuren" <Antoin.Verschuren@sidn.nl>
To: <address-policy-wg@ripe.net>

PDP Number: 2008-05
Anycasting Assignments for TLD's and Tier 0/1 ENUM

While I strongly support the proposal for more than 1 anycast assignment
per TLD/ENUM tier1 operator, I do have some problems with the definition
of the ENUM tier1 operators.

Where it says:

"ENUM operators as defined by the ITU"

I think it should say:

"ENUM tier0/1 operators as defined by RIPE NCC"

I wouldn't want the ITU to determine who should get address space, and
the counterpart for IANA in the ENUM space is RIPE NCC.
I see the ITU more in the role ICANN has with regards to TLD's, or
perhaps even the US DOC.

Antoin Verschuren

Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525500
F +31 26 3525505
M +31 6 23368970
E antoin.verschuren@sidn.nl
W http://www.sidn.nl/

--__--__--

Message: 3
From: Leo Vegoda <leo.vegoda@icann.org>
To: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net>
Date: Wed, 10 Dec 2008 06:08:42 -0800
Subject: Re: [address-policy-wg] 2008-05 Revised/New Discussion Phase set
(Anycasting Assignments for TLD's and Tier 0/1 ENUM)

Hi,

I'm happy to see the removal of an external reference in this policy
proposal. The current policy refers to the 'IANA Administrative Procedure
for Root Zone Name Server Delegation and Glue Data'. It's possible that a
change to that document could have a knock-on effect on RIPE policy. As
such, I'm glad to see a change to self-contained policy.

Regards,

Leo Vegoda

--__--__--

Message: 4
Date: Wed, 10 Dec 2008 10:13:18 -0500
From: Milton L Mueller <mueller@syr.edu>
To: <address-policy-wg@ripe.net>
Subject: [address-policy-wg] New paper on RIRs by Internet Governance Project

------_=_NextPart_001_01C95AD9.D45EE8D6
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Regional Address Registries, Governance and Internet Freedom

=20

Abstract: Regional Internet Address Registries (RIRs) are private,
nonprofit and transnational governance entities that evolved organically
with the growth of the Internet to manage and coordinate Internet
Protocol addresses. The RIR's management of Internet address resources
is becoming more contentious and more central to global debates over
Internet governance. This is happening because of two transformational
problems: 1) the depletion of the IPv4 address space; and 2) the attempt
to introduce more security into the Internet routing system. We call
these problems "transformational" because they raise the stakes of the
RIR's policy decisions, make RIR processes more formal and
institutionalized, and have the potential to create new, more
centralized control mechanisms over Internet service providers and
users. A danger in this transition is that the higher stakes and
centralized control mechanisms become magnets for political contention,
just as ICANN's control of the DNS root did. In order to avoid a repeat
of the problems of ICANN, we need to think carefully about the
relationship between RIRs, governments, and Internet freedom. In
particular, we need to shield RIRs from interference by national
governments, and strengthen and institutionalize their status as neutral
technical coordinators with limited influence over other areas of
Internet governance.

=20

Download: http://internetgovernance.org/pdf/RIRs-IGP-hyderabad.pdf=20

=20

------_=_NextPart_001_01C95AD9.D45EE8D6
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>

</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

Regional =
Address
Registries, Governance and Internet Freedom<o:p></o:p>

<o:p> </o:p>

Abstract: Regional Internet Address =
Registries
(RIRs) are private, nonprofit and transnational governance entities that
evolved organically with the growth of the Internet to manage and =
coordinate
Internet Protocol addresses. The RIR’s management of Internet =
address
resources is becoming more contentious and more central to global =
debates over
Internet governance. This is happening because of two transformational
problems: 1) the depletion of the IPv4 address space; and 2) the attempt =
to
introduce more security into the Internet routing system. We call these
problems “transformational” because they raise the stakes of =
the
RIR’s policy decisions, make RIR processes more formal and
institutionalized, and have the potential to create new, more =
centralized
control mechanisms over Internet service providers and users. A danger =
in this
transition is that the higher stakes and centralized control mechanisms =
become
magnets for political contention, just as ICANN’s control of the =
DNS root
did. In order to avoid a repeat of the problems of ICANN, we need to =
think
carefully about the relationship between RIRs, governments, and Internet
freedom. In particular, we need to shield RIRs from interference by =
national
governments, and strengthen and institutionalize their status as neutral
technical coordinators with limited influence over other areas of =
Internet
governance.<o:p></o:p>

<o:p> </o:p></fo=
nt>

Download: <a
href=3D"http://internetgovernance.org/pdf/RIRs-IGP-hyderabad.pdf">http://=
internetgovernance.org/pdf/RIRs-IGP-hyderabad.pdf</a>
<o:p></o:p>

<o:p> </o:p>

</div>

</body>

</html>

------_=_NextPart_001_01C95AD9.D45EE8D6--

--__--__--

Message: 5
Date: Wed, 10 Dec 2008 21:05:43 +0100
From: "Remco van Mook" <Remco.vanMook@eu.equinix.com>
To: <address-policy-wg@ripe.net>
Subject: [address-policy-wg] DRAFT: allocating resources to the RIPE NCC

Dear all,

Please find below my first attempt at a policy for allocating resources
to the NCC. I think it should be a separate ripe document. Please let me
know what you think and where it needs some more polishing. I want to
publish the formal proposal soon, so the policy can potentially be
adopted well in time for the next RIPE meeting.=20

Best,

Remco

Number: (assigned by the RIPE NCC)
Policy Proposal Name: Allocating resources to the RIPE NCC=09=20
Author:=20
name: Remco van Mook
email: remco@eu.equinix.com
organisation: Equinix

Proposal Version: 1.0

Submission Date: TBD
=09=20
Suggested RIPE WG for discussion and publication: address policy
=09=20
Proposal Type: new

Policy Term: permanent
=09
Summary of proposal:=20
This proposal sets the way in which the RIPE NCC can get resources
allocated to itself.=09=20

Policy text:=20=09
Current (if modify):
none

New:

Abstract:
This document describes how the RIPE NCC can get resources allocated to
itself.

1.0 Introduction
The RIPE NCC is an independent association and serves as one of five
Regional Internet Registries (RIRs). Its service region incorporates
Europe, the Middle East, and Central Asia. The RIPE NCC is responsible
for the allocation and assignment of Internet Protocol (IP) address
space, Autonomous System Numbers (ASNs) and the management of reverse
domain names within this region.=20

1.1 Scope
This document describes the policy for allocating resources to the RIPE
NCC. This policy applies to all resources, current and future, allocated
to the RIPE NCC, its subsidiaries or affiliates. This document does not
describe any specific resource or a policy restricted to a specific
resource; it does however impact how the resource-specific policies
should be interpreted when applied to the RIPE NCC as the entity
requesting resources. This document does not describe or impact any
policy where it is applied to regular LIRs.

2.0 RIPE NCC as a resource-holder
Any resources allocated to the RIPE NCC will be registered in the RIPE
database under the LIR identity of 'eu.ripencc'. All policies set for
allocating resources to LIRs apply equally to the RIPE NCC. RIPE NCC as
a resource holder should fulfill the same basic requirements that are
also expected of normal LIRs, such as returning unused resources. Since
the RIPE NCC cannot sign a contract with itself, the requirement for an
explicit contract as set by various policies does not apply for this
particular case. While the RIPE NCC will still handle the administrative
tasks involved with allocating resources itself, it will not evaluate
the validity of their own requests.=20

3.0 Pool of Arbiters
Defined in ripe-174, the pool of Arbiters has been appointed by the RIPE
NCC Executive Committee (and approved by the AGM). The arbiters function
is to mediate in a conflict between the RIPE NCC and one of its members.
In addition to executing the RIPE NCC Conflict Arbitration Procedure,
the pool of arbiters will also evaluate the validity of all requests for
resources made by the RIPE NCC.=20

4.0 Evaluating a request
The evaluation of an allocation request made by the RIPE NCC will be
done by a team of at least 3 of the arbiters. The arbiters will respond
to any new request within one month. For the purpose of evaluating, the
request will be treated as if it was filed by a normal LIR. If the
request is approved, the resources will then be allocated by the RIPE
NCC and registered in the RIPE database.

5.0 Conflict resolution
Should the pool of arbiters reject a request, or if the request cannot
be granted by applying the standard LIR policies, the RIPE NCC can file
a request to the RIPE plenary meeting to have its case heard. It is then
up to the RIPE plenary to decide whether the request should be granted
or not. At no point can the RIPE NCC allocate resources to itself
without prior consent of either the pool of arbiters or the RIPE
plenary.

Rationale:
All resource-holders in the RIPE NCC service area are now being required
to have a contractual relationship with the RIPE NCC, directly or
indirectly. There is however one entity that cannot sign a contract with
the RIPE NCC - the NCC itself. This policy cleans up the current variety
in which the NCC has allocated resources to itself and sets a standard
way for the RIPE NCC to get further resources allocated. For all means
and purposes the RIPE NCC will be treated as a LIR and will follow the
same policies as a LIR; however the role the RIPE NCC has in analysing
and evaluating any request by an LIR is instead done by members of the
pool of arbiters.

Arguments supporting the proposal
Currently there is no standard way for the RIPE NCC to get resources
allocated. This has so far led to an inconsistent picture between the
various resource types; a lot of ad hoc policies and exemptions. This
needs to be cleaned up. One way to look at it is that every single
resource allocated to the RIPE NCC is a conflict of interest between the
RIPE NCC and ALL of its members. Therefore it makes sense that the same
people who arbitrate conflicts between RIPE NCC and its members evaluate
the requests for resources as filed by the RIPE NCC.

Arguments opposing the proposal=20
None.

This email is from Equinix Europe Limited or one of its associated/subsidia=
ry companies. This email, and any files transmitted with it, contains infor=
mation which is confidential, may be legally privileged and is solely for t=
he use of the intended recipient. If you have received this email in error,=
please notify the sender and delete this email immediately. Equinix Europ=
e Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Stree=
t, Thomas More Square, London E1W 1YW. Registered in England and Wales No. =
6293383.

--__--__--

Message: 6
Date: Tue, 09 Dec 2008 20:10:11 -0800
From: "Jeffrey A. Williams" <jwkckid1@ix.netcom.com>
Organization: IDNS and Spokesman for INEGroup
To: Antoin Verschuren <Antoin.Verschuren@sidn.nl>
CC: address-policy-wg@ripe.net
Subject: Re: [address-policy-wg] 2008-05 Revised/New Discussion Phase set
(Anycasting Assignments for TLD's and Tier 0/1 ENUM)

Antoin and all,

Good point. I certainly wouldn't want the ITU doing so either.
But you know that there are some that are yet again pushing
the ITU as having some sort of authority, however defined, to
make such determinations...

Antoin Verschuren wrote:

> PDP Number: 2008-05
> Anycasting Assignments for TLD's and Tier 0/1 ENUM
>
> While I strongly support the proposal for more than 1 anycast assignment
> per TLD/ENUM tier1 operator, I do have some problems with the definition
> of the ENUM tier1 operators.
>
> Where it says:
>
> "ENUM operators as defined by the ITU"
>
> I think it should say:
>
> "ENUM tier0/1 operators as defined by RIPE NCC"
>
> I wouldn't want the ITU to determine who should get address space, and
> the counterpart for IANA in the ENUM space is RIPE NCC.
> I see the ITU more in the role ICANN has with regards to TLD's, or
> perhaps even the US DOC.
>
> Antoin Verschuren
>
> Technical Policy Advisor
> SIDN
> Utrechtseweg 310
> PO Box 5022
> 6802 EA Arnhem
> The Netherlands
>
> T +31 26 3525500
> F +31 26 3525505
> M +31 6 23368970
> E antoin.verschuren@sidn.nl
> W http://www.sidn.nl/

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
Abraham Lincoln
"YES WE CAN!" Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng. INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
jwkckid1@ix.netcom.com
My Phone: 214-244-4827

End of address-policy-wg Digest