Subject: Can the RIRs bypass the IETF and do their own thing?

From: <[email-masked]>
Date: Fri, 11 May 2007 14:35:25 +0100

> If the draft RFC was resurrected

> Would you still think this was an end-run on the RIR process?
> 
> Would you be in support of the draft moving forward?

Seems to me that if the draft is not resurrected, there are no ULA
addresses for ARIN or RIPE to register, regardless of anything that ARIN
or RIPE members might desire.

> If you prefer the RIR process, would you be in favor of a global
policy
> submitted to ARIN that had the provisions of the expired ULA-central
> draft, with the modification of removing "cental authority" and
clearly
> designating how IANA should divide the space among the existing RIRs?

Seems to me that the NRO requires that identical policies be PASSED by
all of the RIRs before they can be considered "global policy". This is
an area where it makes a whole lot of sense to have discussions on
several RIR mailing lists before ANY policy proposal is submitted to ANY
of the 5 RIRs.

I'm not going to quibble with the wording of the draft at this point. I
just wonder whether it is appropriate for the RIR mailing lists to be
used as a working group for writing Internet drafts? It seems to be a
stupid way to proceed because there are at least 5 different mailing
lists involved, one of which is primarily in Spanish. Crossposting is
not a solution.

If people are serious about this central ULA concept then they should
get ONE of the RIRs to set up a working group (RIPE would be my first
choice, ARIN second) and then have all of this discussion in that
working group mailing list. People from all of the 5 RIRs should be
invited to the working group by official RIR postings to whatever lists
are appropriate. Some RIRs have announcement lists for such things or
members-only lists to ensure that the word gets out. Then draft the
document in your ONE SINGLE mailing list discussion, submit it to the
IETF, and only then, after an agreed draft is formally in the IETF
pipeline, submit your global policy proposals to each of the RIRs.

The way this is being done right now is pure madness and I would expect
that the RIR boards will reject any policies that arise through this
UNFAIR AND DISJOINTED process. We have always allowed the IETF to take
first place when it comes to creating new number resources. There is no
good reason to change this for so-called central-ULA addresses. We do
need the technical expertise that is in the IETF to review this before
we can make any kind of policy decisions about a registry for these
addresses. 

I know many people on the RIR policy lists are technical experts, but
that doesn't count, because these are policy lists, not technical ones.
It is one thing for a few technical people to convince a large number of
non-technical people about a topic. It is another thing entirely, for
those few technical people to convince the large number of technical
people who participate in the IETF. It seems to me that the promoters of
central-ULA are trying to bypass the IETF's technical review process and
I don't like this.

--Michael Dillon

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Fred Baker <[email-masked]>
Date: Fri, 11 May 2007 07:14:41 -0700

On May 11, 2007, at 6:35 AM, <[email-masked]> wrote:
> I'm not going to quibble with the wording of the draft at this  
> point. I just wonder whether it is appropriate for the RIR mailing  
> lists to be used as a working group for writing Internet drafts?

I don't see why not, but...

In your email, you noted the disjoint nature of the RIRs and the need  
to cross-post or whatever. Speaking as chair of IPv6 Operations  
([email-masked]), I would invite you and all those interested in  
the effort to use the v6ops list for the purpose and the v6ops  
working group as a venue to do the work. If you would like, we can  
arrange a v6ops interim meeting at the RIR meeting of your choice, or  
it could be discussed in the currently-planned meeting in the third  
week of July in Chicago.

One technical question I would ask. What does a "Central Authority"  
and "IANA Assignment" have to do with a "Local" address of any type?  
It seems in context that the major issue is an address prefix that is  
not advertised to neighboring ISPs and can be generally configured to  
be refused if offered by a neighboring ISP, in the same way that an  
RFC 1918 address is not advertised and is generally refused between  
IPv4 networks. In any draft on this topic, regardless of where it is  
discussed, if central assignment is in view, the reason for having  
such assignment should be clearly stated.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 11 May 2007 23:32:47 +0200

I've already indicated this in previous occasions, but may be not in ppml
...

We are proceeding in parallel, with the ID and the PDP at the same time.
Nothing in the PDP precludes doing so.

The RIRs don't depend on IETF at all, they can define global policies for
things that the IETF failed to complete if that's the case. IANA can be
instructed the same by the RIRs (which a global policy) than by the IETF
itself with an RFC.

Even when the IETF get the document as an RFC, the RIRs need a policy (in
this case no need for a global one) to start using the resource. That's why
both things are needed.

The boards of the RIRs, if the policy reach consensus, should hold the
implementation until the RFC is available or instead, a global policy reach
consensus to replace the function of the RFC. This is something that it is
natural to be done, but again, doesn't preclude to start debating about the
policy and win some time.

If anyone want to discuss about the ULA-central ID, I encourage to bring
that discussion to the ipv6 WG mailing list, no need to create a new one.
For discussions about the policy proposal, use the corresponding RIR mail
exploder.

Regards,
Jordi

> De: <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 11 May 2007 14:35:25 +0100
> Para: <[email-masked]>, <[email-masked]>, <[email-masked]>
> Conversación: Can the RIRs bypass the IETF and do their own thing?
> Asunto: Can the RIRs bypass the IETF and do their own thing?
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 May 2007 13:34:31 +0200

> instructed the same by the RIRs (which a global policy) than by the IETF

Not quite. The RIRs have authority delegated to them by IANA, and IANA
operates under the terms of its MoU and SLA with the IETF. So the RIRs'
scope is to set and implement policy within their delegated authority,
which itself has to be within the terms of the IANA MoU and SLA.

In this case, I would check out section 4.3 of RFC 2860, especially
the clause (b) in the second paragraph. It's clear to me that centrally-
allocated ULAs are in IETF scope under that clause.

That being said, there's no conceivable problem with a draft being
developed by any set of people that want to do so, and the RIR people
are obviously strongly motivated to do so in this case. (Personally,
I see little need for it, since the existing pseudo-random ULAs
are good enough for any practical purpose, but that is a discussion
we can have in the IETF once there is a draft to discuss.)

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 May 2007 13:39:00 +0200

On 2007-05-11 16:14, Fred Baker wrote:
...
> One technical question I would ask. What does a "Central Authority" and 
> "IANA Assignment" have to do with a "Local" address of any type? It 
> seems in context that the major issue is an address prefix that is not 
> advertised to neighboring ISPs and can be generally configured to be 
> refused if offered by a neighboring ISP, in the same way that an RFC 
> 1918 address is not advertised and is generally refused between IPv4 
> networks. In any draft on this topic, regardless of where it is 
> discussed, if central assignment is in view, the reason for having such 
> assignment should be clearly stated.

Fred, the point is that ULAs should be unambiguous, so that if they
happen to meet (e.g. via a VPN, or following a merge of two previously
separate networks) there is no collision. Currently ULAs include
a pseudo-random prefix, which leaves open a theoretical possibility
of collision. Centrally-allocated ULAs would not have this issue.

     Brian

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 14 May 2007 07:45:41 -0500

Thus spake "Brian E Carpenter" <[email-masked]>
> of collision. Centrally-allocated ULAs would not have this issue.

The chance is negligible until you have a number of organizations 
interconnecting that approaches the AS count on the public Internet.  Those 
who are uncomfortable with those odds can get PIv6 space.  ULA Central does 
not solve any problems that the existing tools already solve, and it creates 
new problems of its own.

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 14 May 2007 09:24:19 -0500

Thus spake "Stephen Sprunk" <[email-masked]>
> ULA Central does not solve any problems that the existing tools
> already solve, and it creates new problems of its own.

That should be "don't already solve".

S

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 May 2007 16:40:50 +0200

On 2007-05-14 16:08, Shane Kerr wrote:
> Brian,
> 
> On Mon, May 14, 2007 at 01:34:31PM +0200, Brian E Carpenter wrote:
>>> The RIRs don't depend on IETF at all, they can define global
>>> policies for things that the IETF failed to complete if that's the
>>> case. IANA can be instructed the same by the RIRs (which a global
>>> policy) than by the IETF itself with an RFC.
>> Not quite. The RIRs have authority delegated to them by IANA, and
>> IANA operates under the terms of its MoU and SLA with the IETF. So
>> the RIRs' scope is to set and implement policy within their
>> delegated authority, which itself has to be within the terms of the
>> IANA MoU and SLA.
> 
> The RIRs authority comes from their communities, not from IANA.
> That's what "bottom-up" means.

We're both right. It works because there is a wide consensus to both
listen to the community and respect the mechanisms in place.

     Brian

---

From: Shane Kerr <[email-masked]>
Date: Mon, 14 May 2007 16:08:19 +0200

Brian,

Many industries need a neutral organisation to do business. Airlines
have a system to handle reservations. Many industries use the ISO to
set standards (paint colour, carpet thickness, and so on).
Universities have accreditation bodies to insure a certain quality of
education. And so on.

The ISPs of the world need someone to handle resource allocation. The
RIRs do that. They also do a bunch of other stuff. Really, the RIRs'
scope is whatever their communities think it should be.

If the RIRs decide to allocate numbers from dead:beef::/32 based on
lunar tides, then the IETF and IANA and ICANN can complain about it
all day long, but it's not their decision to make. Of course they can
participate in the policy making process like everyone else. :)

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Mon, 14 May 2007 16:08:19 +0200

Brian,

--
Shane

---

From: Gert Doering <[email-masked]>
Date: Tue, 15 May 2007 10:39:42 +0200

Hi,

On Mon, May 14, 2007 at 03:04:19PM -0400, Dean Anderson wrote:
[..]
> ICANN can end the MoU at any time, and find a new technical consultant.
> The IETF can also end the MoU at any time. But the IETF doesn't have the
> authority to appoint a new IANA operator.
[..]
> The RIR's can do whatever ICANN and the US Government allow them to do.  
> The IETF _can_ be taken out of the picture if there is cause to do so.

Not quite.  If ICANN decides "we won't listen to IETF anymore", or "we
try to inforce non-useful politics to the RIRs" there is no big reason 
why the RIRs couldn't just kick ICANN, install the NRO in its place, and 
change the structure to

      IETF -> NRO -> RIRs

Remember: the existing mechanism works, because the communities (!!) agree 
that it's a useful way to handle address distribution.

The US DoC might have some say for ARIN, but the rest of the world
couldn't care less - and I'm sure that the DoC is well aware of this and
won't try to break apart working structures.

So this is all sort of academic.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  113403

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Ray Plzak <[email-masked]>
Date: Tue, 15 May 2007 05:15:24 -0400

The US DoC has as much say for ARIN as it does for the RIPE NCC. The RIRs existed before ICANN. The relationship between the RIRs and ICANN is defined in the ASO MoU, an agreement between ICANN on the one hand and the NRO on behalf of the RIRs on the other.  There is no mention in the ICANN bylaws of the RIRs.

Ray

> -----Original Message-----
> From: Gert Doering [mailto:[email-masked]]
> Sent: Tuesday, May 15, 2007 4:40 AM
> To: Dean Anderson
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [address-policy-wg] Re: Can the RIRs bypass the IETF and
> do their own thing?
>
> Hi,
>

---

From: Ray Plzak <[email-masked]>
Date: Tue, 15 May 2007 13:22:59 -0400

>
> > The US DoC has as much say for ARIN as it does for the RIPE NCC.
>
> The US DoC, through IANA functions, says, e.g., what IP Address blocks
> each can allocate.  That seems to qualify as 'much say'
>

Didn't say how much say, just said that whatever say it had for ARIN it was the same as it had for the RIPE NCC.

> You seem to be confusing delegation of authority with loss of
> authority.
> The DoC has contracted the IANA function to ICANN and doesn't involve
> itself much, and ultimately plans to get out altogether.  However, the
> IANA operator (ICANN) then has 'much say'.  But the DoC 'get out
> altogether' event hasn't happened yet.  So you can't write out the DoC
> just yet.
>

Don't how you arrived at that conclusion based on a casual observation. Not writing them out, don't know how you got that.

> > The RIRs existed before ICANN. The relationship between the RIRs and
> > ICANN is defined in the ASO MoU, an agreement between ICANN on the
> one
> > hand and the NRO on behalf of the RIRs on the other.  There is no
> > mention in the ICANN bylaws of the RIRs.
>
> The fallacy of this claim was already stated:

What is false about those statements?

 RIRs get their authority
> and IP Address Allocations, etc from IANA.  The fact that RIRs existed
> before ICANN is irrelevant, because IANA existed before the RIRs. And,
> as I noted, IANA functions are now contracted to ICANN. Technically, it
> is in fact the IANA (not ICANN) that has direct control over RIRs. But,
> as I pointed out, ICANN has full control over IANA functions by
> contract
> with the US Government. And, as I pointed out, the IETF is a technical
> consultant to ICANN. The MoUs are just that: Memoranda of
> Understanding.
> MoUs can be terminated, and don't supercede the contracts with the US
> Government.
>

Never intimated anything about authority lines or derivation of authority, just pointing out some of the factors in the relationship between ICANN and the RIRs.

Ray

---

From: <[email-masked]>
Date: Wed, 16 May 2007 10:38:11 +0100

> each can allocate.  That seems to qualify as 'much say'

So it seems that you and Ray are in agreement. All the other details are
not terribly relevant to RIR policy discussions because we have
processes and structures to make sure that everything is done properly.
We have no plans to change any of the structures because at the present
time, they seem to work OK.

As for the matter that started this, central ULAs, there is not need to
worry about who controls what. The fact is that it is customary for new
address types to be defined *FIRST* in the IETF and even if there is the
possibility of an alternate process, we would not dream of exercising
that unless the customary process, via the IETF, had broken down.

The IETF process cannot be considered broken just because a draft has
expired. In fact, expiry of a draft indicates that the original authors
no longer care enough about the matter to progress it further. The WG
chair of IPv6 Operations has already offered the v6ops list
http://www.ietf.org/html.charters/v6ops-charter.html
For those people who *DO* wish to progress a draft for Central ULA
addresses. This is a sign that the IETF process is open for business in
this case.

At this point, I think it is inappropriate to continue the Central ULA
discussion on the RIR policy lists. In fact, if any policy were to come
out of such a discussion, I would vote against it even though my company
could potentially benefit from something like a Central ULA address
block. But at the same time, my company supports the IETF process in
general and I don't believe we would want to be perceived as usurping
the IETF. That is why I would vote against any policy proposal that is
not based on an RFC.

I urge all of you who have an interest in Central ULA addresses, both
pro and con, to take your discussion to the v6ops list. And I urge the
people in favour of Central ULA addresses to write an Internet draft
explaining just what it is that you want to do. At this point in time,
there is no valid draft document so I don't even know what it is that
you are discussing.

--Michael Dillon

---

From: <[email-masked]>
Date: Wed, 16 May 2007 10:38:11 +0100

--Michael Dillon

_______________________________________________
This message sent to you through the ARIN Public Policy Mailing List
([email-masked]).
Manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml

---

From: Shane Kerr <[email-masked]>
Date: Wed, 16 May 2007 11:46:16 +0200

Michael,

[ stripping out a lot of content to just say what I want to say... ]

On Wed, May 16, 2007 at 10:38:11AM +0100, [email-masked] wrote:
> At this point, I think it is inappropriate to continue the Central
> ULA discussion on the RIR policy lists.

Agreed.

> In fact, if any policy were to come out of such a discussion, I
> would vote against it [...]

Me too (well, the RIPE region doesn't vote on policies, but rather say
I would oppose Central ULA proposals).

--
Shane