Subject: RE: Again no multi6 at IETF#56

From: "Michel Py" <[email-masked]>
Date: Tue, 11 Mar 2003 09:17:12 -0800

>> Randy Bush wrote:
>> to be blunt, where's the protein?

> Masataka Ohta wrote:
> I'm glad to know that you asked for not a
> requirement draft but the protein.

Me too. Middle schoolers need proteins.

Michel.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 12 Mar 2003 03:11:53 +0859 ()

> Me too. Middle schoolers need proteins.

Can we meet at:

	Transitions Planning BOF (6bonebof)

	Tuesday, March 18 at 1700-1800

and state an opinion that 6bone address management responsibilities
should be transferred to RIRs only after multihoming issues are solved?

It seems to be that it is a (perhaps the only) rough consensus of multi6.

Or, does so many of us think v6 addresses may be widely assigned
without multihoming issues solved?

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 11 Mar 2003 19:59:52 +0100

> without multihoming issues solved?

I am not following your reasoning. I don't see why we should not move 
address management to where it belongs, and what that have to do with 
the multi6 issue?

- kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 12 Mar 2003 09:08:13 +0859 ()

Kurt;

> address management to where it belongs, and what that have to do with 

Huh?

Are you saying it already belongs to where it belongs that there
should be no BoF?

							Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2003 09:11:50 +0200 (EET)

> without multihoming issues solved?

Certainly.

Quit the excuses already.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 12 Mar 2003 21:24:56 +0100

> Are you saying it already belongs to where it belongs that there
I am saying that address registration and allocation/assignment 
management belongs with the RIRs.

- kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Mar 2003 08:12:56 +0859 ()

Kurt;

> management belongs with the RIRs.

How, do you think, it should be managed?

"just like IPv4" is not an answer.

						Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Mar 2003 08:09:13 +0100

> "just like IPv4" is not an answer.

And your suggestion is?

- kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Mar 2003 23:08:32 +0859 ()

Kurtis;

> > "just like IPv4" is not an answer.

Have a consensus at multi6 meetings.

Have them.

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Mar 2003 15:24:50 +0100

> Have a consensus at multi6 meetings.

On assignment policy and registration? Wow.

- kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Mar 2003 00:24:59 +0859 ()

Kurt;

> On assignment policy and registration?

Of course.

It is impossible for RIRs to define an assignment policy unless
they recognize how multihomed sites should be treated.

							Masataka Ohta

---

From: Bob Hinden <[email-masked]>
Date: Thu, 13 Mar 2003 09:23:24 -0800

I think the answer is that the RIRs can do allocations based on the 
technical requirements given to them by the IETF.

Bob

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Mar 2003 18:39:22 +0100

> technical requirements given to them by the IETF.

Hmm. This depends on what you mean. Policy is today decided by the 
membership of the RIRs. I think that RIRs should do allocations 
according to the policy set by the RIRs members. The IETF should set 
technical standards for the protocols using those addresses or making 
up those addresses. If those protocols require limitations in policy, 
that should be declared in the protocol specification. I think you will 
find it hard to get the RIR membership to agree on having policy set 
outside the RIR membership.

If you want to influence the allocation policy, go the RIRs meetings.

- kurtis -

---

From: David Conrad <[email-masked]>
Date: Thu, 13 Mar 2003 10:18:07 -0800

Um.  No.  See http://www.arin.net/policy/ipep.html

---

From: Bob Hinden <[email-masked]>
Date: Thu, 13 Mar 2003 10:37:17 -0800

Kurt,

>membership of the RIRs. I think that RIRs should do allocations according 
>to the policy set by the RIRs members. The IETF should set technical 
>standards for the protocols using those addresses or making up those 
>addresses. If those protocols require limitations in policy, that should 
>be declared in the protocol specification. I think you will find it hard 
>to get the RIR membership to agree on having policy set outside the RIR 
>membership.

The policy has to be consistent with the technical constraints.  The IETF 
needs to define what the technical requirements (i.e., what works, waht 
doesn't work, what the limitations are, scaling properties, etc.) in order 
for the RIR to create the policy that is practical.

>If you want to influence the allocation policy, go the RIRs meetings.

Agreed.  But the policy needs to consistent with the technical 
requirements.  For example there are technical limitations of routing 
protocols that relate to the number of routes and interconnections between 
ISPs.  If the RIRs were to adopt a policy that did not take these technical 
requirements it would result in an Internet that didn't work.

Bob

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Mar 2003 19:56:32 +0100

Bob,

>> that should be declared in the protocol specification. I think you 
>> will find it hard to get the RIR membership to agree on having policy 
>> set outside the RIR membership.
>
> The policy has to be consistent with the technical constraints.  The 
> IETF needs to define what the technical requirements (i.e., what 
> works, waht doesn't work, what the limitations are, scaling 
> properties, etc.) in order for the RIR to create the policy that is 
> practical.

As IPv6 build IIDs out of MAC addresses, should the IETF make rules on 
how MAC addresses are assigned? From what I remember there is an 
agreement between the RIRs and the IETF on who does what, right? Making 
the claim above implies changing a lot more than IETF specs.

I agree with you that it is up to the IETF to set the technical 
specifications, but to say that the IETF decides "in order for the RIRs 
to create the policy that is practical" is dangerous.

> protocols that relate to the number of routes and interconnections 
> between ISPs.  If the RIRs were to adopt a policy that did not take 
> these technical requirements it would result in an Internet that 
> didn't work.
>

You can do this in multiple ways. You could (playing the devils 
advocate) argue that the IETF should create technical specifications 
that can handle the policy of the RIRs. After all, to a large extent 
the RIR membership is most likely a better representation of 
"end-users" (for some definition of users) than the IETF is. A better 
way to move forward is most likely to have the IETF _cooperate_ with 
the RIRs on a working policy.

I still to some extend fail to see the underlaying problem though.

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Mar 2003 20:37:13 +0100 (CET)

On Thu, 13 Mar 2003, Kurt Erik Lindqvist wrote:

> "end-users" (for some definition of users) than the IETF is.

I don't agree. Even if ISPs (overwhelming majority of RIR membership)
represent end-users better than vendors (majority of IETF membership)
there is only one RIR policy and users don't get to choose, while there
are usually many ways to implement some functionality that are endorsed
by the IETF and not being endorsed by the IETF doesn't mean it can't be
implemented or used. Having a choice is always the better option.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Mar 2003 20:52:00 +0100

> implemented or used. Having a choice is always the better option.

I think you need to go and check the RIR policies. They are not the 
same. They are similar, but not the same.

Besides that, the RIRs have a similar policy in order not create 
competition for a resource that is considered limited and i order to 
limit routing table growth (the problem that is trying to be solved by 
having the IETF set the policy) . If the resource is not limited and 
routing table growth is not an issue, let each RIR set their own policy.

Now, if your argument is that we should have multiple RIRs that compete 
with cost between eachother - that is definitely out of scope for the 
IETF. I then suggest you take this to the LIR-WG, ARIN policy list etc.

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Mar 2003 21:24:59 +0100 (CET)

> same. They are similar, but not the same.

Addresses are hard to get and I need to pay. Those are the parts that
bother me. The rest, I don't care much about...  :-)

> routing table growth is not an issue, let each RIR set their own policy.

Ok, I'll hold you to that when we've solved the multihoming problem.
(Address space isn't scarce anymore with v6 of course.)

> IETF.

Not at all. What I'm saying is that if we have a choice whether the IETF
or the RIRs can make a certain policy, this is a no-brainer: the IETF.
Only when the scarcity issues come into play you need the RIRs. That's
what they're good at, lets not distract them with anything else.

But this is all moot most of the time, as the RIRs do existing stuff
while the IETF tries to build new stuff. So the overlap isn't that big.

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Mar 2003 17:27:05 -0500

> "end-users" (for some definition of users) than the IETF is.

problem is that the rirs, aside from missing protocol folk, are
also missing router/backbone ops folk.  so they get a very narrow
view.

> A better way to move forward is most likely to have the IETF
> _cooperate_ with the RIRs on a working policy.

bingo!

randy

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Mar 2003 23:52:29 +0859 ()

David;

> Um.  No.  See http://www.arin.net/policy/ipep.html

Are you saying "Board of Trustees", "ARIN Advisory Council" and
or general public" related to ARIN decision will make decisions
just randomly without having knowledge on technical requirements?

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 15 Mar 2003 00:06:32 +0859 ()

Iljitsch;

> bother me. The rest, I don't care much about...  :-)

IPv6 addresses will be easy to get and you need not to pay much.

However, TLAs will be harder to get and you need to pay a lot more.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 15 Mar 2003 00:03:31 +0859 ()

Kurt;

> same. They are similar, but not the same.

They don't have to be similar but they have to be consistent.

> routing table growth is not an issue, let each RIR set their own policy.

Wrong. If the resource is not limited and routing table growth is
not an issue, don't let each RIR set their own policy. Just assign
as much resource as demanded.

However, routing table is a limited resource and routing table size
is an issue.

						Masataka Ohta

---

From: Bob Hinden <[email-masked]>
Date: Fri, 14 Mar 2003 09:29:30 -0800

Randy,

>also missing router/backbone ops folk.  so they get a very narrow

I agree.  It's not clear to me that either the IETF or the RIRs represent 
the "end-users".  The RIRs are focused on their members who are mostly ISPs 
and the IETF is populated by people from vendors, standards professionals, 
some ISPs, and researchers.  IMHO neither groups primary focus is the 
"end-users".  I would think that the ISOC could possibly fill this role.

> > _cooperate_ with the RIRs on a working policy.

YES!

Bob

---

From: David Conrad <[email-masked]>
Date: Fri, 14 Mar 2003 12:05:18 -0800

Silly rhetorical question.

As the URL documents, RIR policies are established via public policy 
meetings in which interested parties, including those affected by the 
policies, can provide input.  Technical implications of policies are 
part of the input.  Have you ever been to a RIR public policy meeting?

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Fri, 14 Mar 2003 12:11:56 -0800

This is not particularly related to multi6.

>> > _cooperate_ with the RIRs on a working policy.

Perhaps, say, Thomas Narten, Takeshi Arano, or David Kessens could work 
with ARIN and the other RIRs to come up with IPv6 policies?  Or maybe 
folks from IPng like Bob Hinden could run drafts of proposals for 
addressing architectures by the RIRs for input?

Oh.  Wait.

Rgds,
-drc

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 15 Mar 2003 07:34:09 +0859 ()

drc;

> with ARIN and the other RIRs to come up with IPv6 policies?

None of them is IETF.

Moreover,

> Or maybe 

IPng WG has no idea on addressing architecture for multihoming.

IPng WG has no idea on how global routing table size should
be managed.

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 14 Mar 2003 15:03:17 +0100

> bother me. The rest, I don't care much about...  :-)

...for IPv4. For IPv6 this is true for a reason. The very reason that 
it's being argued that the IETF should 'help' the RIRs.

If you actually go and look at the policy you will find that IP 
addresses are allocated/assigned with various ease by various RIRs.

> or the RIRs can make a certain policy, this is a no-brainer: the IETF.

You will find that _a lot_ of people disagrees with you. They will say 
it's a no-brainer to have the RIRs set the policy. The IETF is not 
about policy.

> what they're good at, lets not distract them with anything else.

No. The RIRs do much more than that. They provided a number of services 
around a policy. Registration is one of them. Do you really expect the 
IETF to set the policy, have the RIRs register this and ask people to 
pay for this without having a thing to say? I think you need to go to 
some more RIR meetings.

> while the IETF tries to build new stuff. So the overlap isn't that big.

..which is why I fail to see what this discussion is about. The RIRs do 
registry and address policy. The IETF do architecture, protocols and 
some technology. There are well established rules to handle the overlap.

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 14 Mar 2003 12:37:23 +0100

> they recognize how multihomed sites should be treated.

Fist I think we need a 'somewhat' wider consensus on how do deal with 
multihomed sites, before the IETF starts giving directions to the 
RIRs...

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 14 Mar 2003 18:22:56 +0100

> also missing router/backbone ops folk.  so they get a very narrow

I guess this to some extend varies a bit between the RIRs, but in 
general I agree. Still, it's a better representation than vendors 
voting on the policy...

- kurtis -

---

From: David Conrad <[email-masked]>
Date: Fri, 14 Mar 2003 18:57:20 -0800

Ohta-san,

>> with ARIN and the other RIRs to come up with IPv6 policies?

True, however at least two of the three are quite active in IPv6 
related issues within the IETF and I think it safe to assume technical 
concerns from the IETF (and elsewhere) were taken into account during 
the development of the current v6 policies.

> IPng WG has no idea on how global routing table size should

Yes.  However, the RIRs have come under significant criticism in the 
past for being perceived as road blocks to IPv6 allocations and have, 
in fact, reduced the requirements for v6 space.  Even in this list, 
they are criticized for making obtaining address space 'hard'.

Seems they are damned if they do and damned if they don't.

Rgds,
-drc

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Mar 2003 21:58:45 -0500

> general I agree. Still, it's a better representation than vendors 

rofl!

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 15 Mar 2003 19:09:39 +0859 ()

drc;

> they are criticized for making obtaining address space 'hard'.

Significant criticism by who?

The primary obstacles for IPv6 deployment have been:

	0) Supession, not reduction, of IPv4 address consumption.

	1) Complexity of protocol such as ND, IPsec and routing header
	useful for no meaningful purposes.

	2) People insisting on keeping complex useless features and not
	introducing necessary features.

> Seems they are damned if they do and damned if they don't.

They are never damned. There are other people to be damned.

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 16 Mar 2003 06:16:20 +0100

> They don't have to be similar but they have to be consistent.

Which is what I meant and what they are.

> as much resource as demanded.

The resource is limited.

- kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 16 Mar 2003 14:33:02 +0859 ()

Kurt;

> Which is what I meant and what they are.

How can you be sure they are consistent? Note that they may not
be similar.

> > as much resource as demanded.

Then, we need some policy to deny some assignment based on the
technical reasoning on why, how and how seriously the resource
is limited.

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 16 Mar 2003 07:20:57 +0100

> Seems they are damned if they do and damned if they don't.

The RIRs had a period of a complete open policy that I think lasted for 
two years. 200 applied. I wouldn't blame the RIRs.

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 16 Mar 2003 18:57:59 +0100

> How can you be sure they are consistent? Note that they may not

I know the three policies fairly well. They are not similar but they 
are fairly consistent. They are at least not diverse enough to create 
competition among the RIRs (which is what started this part of the 
thread).

> technical reasoning on why, how and how seriously the resource

The resource is limited as there is a fixed number of addresses. The 
RIRs was created to handled and manage policy for a limited resource. 
Let's use them for that. The IETF was created to develop standards let 
them handle that.

I fail to see what problem you are trying to point out here.

- kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 17 Mar 2003 18:58:50 +0859 ()

Kurt;

> are fairly consistent.

How can you be sure they are consistent? What is the evaluation
criteria?

> They are at least not diverse enough to create 

You are saying they are similar.

> Let's use them for that. The IETF was created to develop standards let 

So, IETF must supply standards and technical rationals behind them.

> I fail to see what problem you are trying to point out here.

I see no problem not to let RIRs assign IPv6 addresses.

							Masataka Ohtaq

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 19 Mar 2003 01:40:16 +0100

> How can you be sure they are consistent? What is the evaluation

This is starting to be off-topic and I think we should move this to a 
more appropriate list like LIR-WG for RIPE.

I know the policies of the different regions fairly well.

- kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 19 Mar 2003 11:56:31 +0859 ()

Kurt;

> I know the policies of the different regions fairly well.

But, you don't know how to compare them.

> more appropriate list like LIR-WG for RIPE.

No. For the comparison, you need technical requirement to be discussed
here.

							Masataka Ohta