David,
After reading your email it is clear to me that the IETF should
consider to work with the RIRs instead or going around them.
It will save us all time and effort.
And responding your question:
> Can you think of any reason why there should be different allocation
> policies for EIDs based on where you live?
I do not think any technical reason. But as ISP I would prefer to deal
with an RIR rather to IANA or to a new entity.
Regards,
as
On 02/03/2013 19:47, David Conrad wrote:
> Arturo,
>
> On Mar 2, 2013, at 1:27 AM, Arturo Servin <[email protected]
> <mailto:[email protected]>> wrote:
>>
>> As far as I can tell, EID space is not Internet routable IPv6
>> Unicast space.
>>
>> Yes, that is ok, but does it have the same constraints of registration
>> and conservation?
>
> Registration: yes.
> Conservation: maybe, but likely in the same way IEEE MAC prefixes need
> to be conserved.
>
>> Is anybody able to use the whole /16
>>
>> a piece of it, a /20, /32, /48?
>
> It doesn't have to be contiguous.
>
>> It has to be unique?
>
> Obviously.
>
>> Do we need to register it?
>
> Yes.
>
>> If so, do we need a whois/restwhois?
>
> Yes.
>
>> reverse dns?
>
> Maybe -- it isn't clear to me that reverse DNS has much of a future,
> regardless of EIDs.
>
>> who is going to operate those services?
>
> Yet to be determined. I suspect once the set of services that need to
> be provided are established, the IETF could either throw it to IANA to
> figure out how the services will be provided or could do an RFP like
> they did with the RFC editor. As mentioned in my note to Scott, IANA
> already provides a somewhat similar service in the allocation of PENs.
>
>> Can you think of any reason why there should be different allocation
>> policies for EIDs based on where you live?
>
>> And the coordination requirements appear to me to be quite
>> different from those for IPv6 routable unicast addressing.
>> As are the constraints which drive allocation.
>>
>>
>> which are?
>
> EIDs can be a flat namespace. This is fundamentally different than how
> locators must be allocated.
>
> Regards,
> -drc
>
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
