[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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
