Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt

From: [email-masked] (Noel Chiappa)
Date: Wed, 13 Mar 2013 20:11:46 -0400 (EDT)

> From: John Curran <[email-masked]>

    > If it is documented that 'EID-only' addresses are not intended to be
    > traditionally routed, that might help significantly in limiting
    > concerns about potential impact to existing operations

Well, I'm clearly OK with it; does anyone else have a problem with this?

I think we definitely don't want it to be 'another avenue for getting normal
PI space', and so we should put that usage off-limits.

    > The degree of rigor put into "how" we manage the proposed EID block is
    > likely going to vary widely
    > ...
    > should LISP be as successful as hoped 10 years from now, then this
    > "experiment" will be the production approach to managing the EID block.
    > ..
    > if there is any reason not to take the time to fully plan out the
    > management approach as the initial _production_ solution (not
    > experimental), then it has not been expressed on the mailing list.
    > ...
    > Since we are actually establishing the management approach for the
    > identifier space of the future Internet, the task should be scoped
    > accordingly

I'm not sure I agree that that's reasonable. To me, it's like asking Paul
Mockapetris to design the ICANN/IANA/RIR structure when he was doing DNS.

I know _I'm_ not equipped to design the business/etc framework you're to a
degree talking of.

	Noel

---

From: John Curran <[email-masked]>
Date: Wed, 13 Mar 2013 20:43:54 -0400

> I know _I'm_ not equipped to design the business/etc framework you're to a

Apologies, I was unclear - what I meant by "the management approach" was
with respect to the technical requirements for management of the EID block 
(i.e. "eid-block-mgmnt"), not business/political framework.  

Example of possible technical requirements to get nailed down include:
(borrowing slightly from Joel and David's earlier emails)

 - What technical policy requirements are there are there on EID prefix
   issuance to end-sites?  

 - What size IED prefixes do end-sites receive?  Fixed or variable in size, 
   one or multiple per org, contiguous or doesn't matter, etc.  

 - What services need to be provided by any registry issuing EID prefixes?

 - Do any services need to be provided by orgs receiving EID prefixes?

 - Are there any technical constraints on movement/transfer/redelegation 
   of EID prefixes, and/or service continuity issues to worry about?

All of the above answered to make sure that the issued EID prefixes can
technically work the way they are expected to, and without postulating 
on who the registry/registries should be, if there should be a split
registry/registrar model, and related policy/business issues.  Getting
the technical constraints down will allow creation of working registry 
system; the necessary policy/business discussions are different scope.

/John

Disclaimers:  My views alone.  Declared value of content is zero.