[address-policy-wg] Re: address-policy-wg digest, Vol 1 #892 - 8 msgs

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

> Send address-policy-wg mailing list submissions to
>        address-policy-wg at 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 at ripe.net
>
> You can reach the person managing the list at
>        address-policy-wg-admin at 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 at icann.org>
> To: Sander Steffann <sander at steffann.nl>, Shane Kerr
>        <shane at time-travellers.org>
> CC: "address-policy-wg at ripe.net" <address-policy-wg at 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 at 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 at sidn.nl>
> To: <address-policy-wg at 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 at sidn.nl
> W http://www.sidn.nl/
>
>
>
> --__--__--
>
> Message: 3
> From: Leo Vegoda <leo.vegoda at icann.org>
> To: "address-policy-wg at ripe.net" <address-policy-wg at 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 at syr.edu>
> To: <address-policy-wg at 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>
> <!--
>  /* Font Definitions */
>  @font-face
>        {font-family:TimesNewRomanPS-BoldItalicMT;
>        panose-1:0 0 0 0 0 0 0 0 0 0;}
> @font-face
>        {font-family:TimesNewRomanPS-ItalicMT;
>        panose-1:0 0 0 0 0 0 0 0 0 0;}
> @font-face
>        {font-family:LucidaSans-Demi;
>        panose-1:0 0 0 0 0 0 0 0 0 0;}
>  /* Style Definitions */
>  p.MsoNormal, li.MsoNormal, div.MsoNormal
>        {margin:0in;
>        margin-bottom:.0001pt;
>        font-size:12.0pt;
>        font-family:"Times New Roman";}
> a:link, span.MsoHyperlink
>        {color:blue;
>        text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
>        {color:purple;
>        text-decoration:underline;}
> span.EmailStyle17
>        {mso-style-type:personal-compose;
>        font-family:Arial;
>        color:windowtext;}
> @page Section1
>        {size:8.5in 11.0in;
>        margin:1.0in 1.25in 1.0in 1.25in;}
> div.Section1
>        {page:Section1;}
> -->
> </style>
>
> </head>
>
> <body lang=3DEN-US link=3Dblue vlink=3Dpurple>
>
> <div class=3DSection1>
>
> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D3
> face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>Regional =
> Address
> Registries, Governance and Internet Freedom</span></font><o:p></o:p></p>
>
> <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
> style=3D'font-size:
> 10.0pt'><o:p> </o:p></span></font></p>
>
> <p class=3DMsoNormal style=3D'text-autospace:none'><b><i><font size=3D2
> face=3D"Times New Roman"><span =
> style=3D'font-size:11.0pt;font-weight:bold;
> font-style:italic'>Abstract: </span></font></i></b><i><font =
> size=3D2><span
> style=3D'font-size:11.0pt;font-style:italic'>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></span></font></i></p>
>
> <p class=3DMsoNormal style=3D'text-autospace:none'><i><font size=3D2
> face=3D"Times New Roman"><span =
> style=3D'font-size:11.0pt;font-style:italic'><o:p> </o:p></span></fo=
> nt></i></p>
>
> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2
> face=3D"Times New Roman"><span style=3D'font-size:10.0pt'>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></span></font></p>
>
> <p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2
> face=3D"Times New Roman"><span =
> style=3D'font-size:10.0pt'><o:p> </o:p></span></font></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 at eu.equinix.com>
> To: <address-policy-wg at 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 at 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 at ix.netcom.com>
> Organization: IDNS and Spokesman for INEGroup
> To: Antoin Verschuren <Antoin.Verschuren at sidn.nl>
> CC: address-policy-wg at 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 at 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 at ix.netcom.com
> My Phone: 214-244-4827
>
>
>
>
> End of address-policy-wg Digest
>



-- 
Thanks & Regards,
Arun Kaushik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20081211/2e55dac0/attachment.html>