Re: [lisp] WG Last Call on draft-ietf-lisp-eid-block-mgmnt-02

[Geoff Huston <[e-mail]>]

[cc's trimmed - they are all on the LISP WG mailing list in any case I'd guess]

Now that this box has been opened, and if we are discussing tuning these words, then
there is more that could be said. ...

If one of the objectives of this draft is to talk about the requirements of an EID registry,
using RFC5226 is an appropriate guide here.

with that in mind I have the following comments...

1. Avoid the use of "allocation" and "assignment" completely
----

So let me start with the easy one first. In the unicast address space we've managed to 
cloud the concepts of "assignment" and "allocation" with so much overloaded foo that
both terms are best avoided because of their confused and overloaded semantics.

So why not just avoid the use of such terms?

How about in the intro you say:

   The document [I-D.ietf-lisp-eid-block] requested an IPv6 address
   block reservation exclusively for the registration of
   EID prefixes for use in the LISP Experiment.  The rationale, intent, size, and usage of the EID
   address block are described in [I-D.ietf-lisp-eid-block].

   This document proposes a management framework for the registration of
   of EID prefixes from that block, allowing the requesting organisation
   exclusive use of those EID prefixes limited to the duration of the LISP experiment.

which attempts to completely avoid these two terms, and also attempts to use the
term "EID prefix" consistently in the place of various permutations of "EID"
"prefix" and "address"

Continuing with this there you could alter section 4 header to read:

"EID Prefix Registration Policy"


2. Avoid prescriptive registry policy in Section 4.
----

In reading through section 4, there are some words that appear to be overly specific
and overly prescription,. 

For example, you could strip out much of the motivational text in bullet 1 if you said"

1. EID Prefixes are available exclusively for use in the LISP experiment network, and
MUST NOT be separately announced as unicast prefixes outside the context of this 
routing scope of the LISP experimental network.


(i.e. place the onus of use on the party using the EID prefix, and don't try
and make the registry into a policy enforcement body, as that won't work.)


Similarly:

2. EID prefix registrations SHOULD be renewed on a regular basis to ensure their
       use by active participants in the experiment. The registration period is
       proposed to be 12 months. Registration renewal SHOULD NOT cause a change
       in the registered EID prefix. The conditions of registration renewal should
       no different to the conditions of registration.


Is the bullet about subdelegation really necessary? Really? This is a short term experiment. Try to keep the registry function as simple as possible if you want the experiment to succeed. Make it as complex as you can if you want to make the experiment as unattractive as possible. Omit 3.

section 4 and 5 contradict each other. You could simplify this by saying simply:

3. All registrations of EID prefixes cease at the time of the expiration of the experimental 
   LISP EID Block allocation. The further disposition of these prefixes and the associated
   registry entries is to be specified in the announcement of the cessation of this experimental
   allocation.

(ok I used the word "allocation" here - probably not good)

i.e define what we can define (what happens in the next 3 years, and what may happen in the
3 year renewal) but not try and specify what happens thereafter.



3. Avoid extraneous Registry policies in Section 4
----

Is item 6. REALLY a technical registry policy? Really? Or is is it an operational policy about the
way Map Servers interact with the EID prefix registry?

Similarly item 7.

Similarly item 8.

and remove 6, 7 and 8 and instead talk about a recycle time of no less than one week?


So the resultant Section 4 would, with a bit of reordering, look like:

4. EID Prefix Registration Policy

1. EID Prefixes are available exclusively for use in the LISP experiment network, and
   MUST NOT be separately announced as unicast prefixes outside the context of this 
   routing scope of the LISP experimental network.

2. EID prefix registrations SHOULD be renewed on a regular basis to ensure their
   use by active participants in the experiment. The registration period is
   proposed here to be 12 months. Registration renewal SHOULD NOT cause a change
   in the registered EID prefix. The conditions of registration renewal should
   no different to the conditions of the original EID prefix registration.

3. When a EID prefix registration is removed from the registry, then the reuse of the EID
   prefix in a subsequent registration on behalf of a different end user should be avoided
   where possible. If the considerations of overall usage of the EID block prefix requires
   reuse of a previously registered EID prefix, then a minimum delay of at least one week
   between removal and subsequent registration SHOULD be applied by the registry operator.

4. All registrations of EID prefixes cease at the time of the expiration of the experimental 
   LISP EID Block allocation. The further disposition of these prefixes and the associated
   registry entries is to be specified in the announcement of the cessation of this experimental
   allocation.

which is simpler, and I hope far clearer in intent.



4. Nits
---

I am sure that there are others, but this caught my attention:

"Policy outlined in the present document is tight to the existence of"

I think the authors meant "tied"

(Sections 5 and 6 have similar potential for simplification, but perhaps that's best
addressed in separate messages.)


thanks,

  Geoff