Re: Again no multi6 at IETF#56

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Kurt;

> >> 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.
> >
> > 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.
> 
> I think you need to go and check the RIR policies. They are not the 
> same. They are similar, but not the same.

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

> 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.

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