> From: "Vasileios Lakafosis (lakafosi)" <[email protected]>
> Below please find a few comments of mine.
Thanks; as with others who commented, if it's not discussed, I agree with it.
Some comments below.
Noel
---------
> General - [whole document]
> - You tend to use the verb "switch" for xTRs. Is that correct/intended
That's short for the generic "packet switch". I have made that clear in the
glossary (doing so on the first use would have made some already much-tweaked
text even more convoluted).
> please choose between "user interface" or "client interface". I would go
> with the second one, as the first one can bring wrong associations to a
> totally new-comer.
Good catch. I use the term "user data packet" a lot, to indicate user's packets;
is that problematic too, or acceptable?
> You do include solutions/contributions offered when describing a LISP
> feature and it's real nice (given you are skipping technical details
> because of brevity of doc). This is _not_ the case, though, for
> sections:
> - [4.5] Security
> - [12.4] Liveness
> Here you only discuss the necessity, rather than what they at least
> offer or intend to offer.
"Security" I already talked about in a reply to Michiel; basically, there are
a long list of completely different, very complex mechanisms, and it's simply
impossible to describe them briefly. (It would take a really large chunk of
text to even briefly explain them, and that would be grossly out of place in"
the "Overview" section. There are forward refs to three of them:
requesting mappings can be secured (see <xref target="xTRs-Security"/>), as
can registering of xTRs (see <xref target="Mapping-Interface-Register"/>);
the key indexing database of the mapping system is also secured (see <xref
target="Mapping-Security"/>)
For "Neighbour Liveness", note that it says:
Solving a related problem, neighbour reachability (below) subsumes handling
this fault mode, however.
and if you look in the "Neighbour Reachability" it does give some details of
the various ways of doing that.
> ["Local Uses"]
> What do you mean by "application-specific data"?
Err, that's a euphemism for a use-case that I was told about in confidence...
:-)
> ["xTRs"]
> "now-normal"
> I would put this in double quotes.
Err, why? It's not a euphemism, it's a straight English compound adjective
('that are now normal').
> ["Indexing Sub-system"]
> This section should not be so much tied to DDT.
Well DDT (and the now-obsolescent ALT) are the only two that LISP is _actually
being used with_ - at least, AFAIK. ALT is covered in Appendix "The ALT
Mapping Indexing Sub-system", and DDT here.
> It should be highlighted that _any_ database that meets the requirements
> could be used. And there ware plenty of examples. And this gives
> versatility to LISP.
I believe the point has been previously made (in "Indexing Sub-systema") that
it's easy to replace the indexing subsystem:
which would allow the actual indexing sub-system to be replaced without
needing to modify the clients
But I'll make it a bit more explicit.
> ["DDT Overview"] 5th paragraph
> This seems wrong. The DDT leaf nodes _are_ MSs
No, not according to the 'indexing sub-system'/'client interface-subsystem'
definition; by definition, the MS's are on the _other_ side of the 'indexing
subsystem interface', and thus cannot be 'DDT leaf nodes'.
> 2nd paragraph "necessarily smaller"
> Redundant as it cannot be larger anyways as only parts can be delegated
> to children.
Yes, but is there any harm in spending two words to make it explicit? It may
be obvious to you, but not everyone is that clued... :-)
> ["An Ordinary Packet's Processing"]
> It would be helpful to add a paragraph about the reason of/benefits from
> the existence of the LISP header.
This is explained below, in "UDP Encapsulation Details"; I have added a forward
ref, is that good enough?
> ["When to Encapsulate"]
> 3rd paragraph: did you intend to say "despite the fact" or "although"
> instead of "because"?
Ah, no? Re-reading the paragraph in question, it seems to be fairly clear?
However, I have added an additional explanatory clause.
> ["Map-Register and Map-Notify Messages"] and elsewhere
> "and its AFI"
> Why keep mentioning AFIs? Doesn't it go without saying?
Perhaps, but I'd rather be explicity (it's only a couple of words), rather
than having the reader wonder 'hmm, I wonder if they left off the AFI there -
and if so, why'.
> ["The DDT Indexing Sub-system"]
> - 3rd paragraph: You may want to use "DDT nodes" everywhere (as in the
> draft) instead of the term "servers".
See my reply to Dino about this; a "DDT node" is an abstract node, in the
namespace delegation hierarchy. A "DDT server" is an actual machine which one
can send packets to. I _hope_ I have used these terms consistently in the
document; if not, let me know. I will add entries in the Glossary to make them
explicit.
> - 6th paragraph: "{{I think this case has been mentioned already;
> check.}}" yes, it has been. So, I would remove the next paragraph
> "Delegations are"
Huh? The following paragraph has nothing to do with the one before it:
the first speaks of MS's proxy-replying on behalf of ETRs; the second
is about MRs caching delegations.
> ["Mobile Device Support"]
> The way 13.2 is written (with all these problems outlined and no
> solutions provided) gives the impression to the new-comer that mobility
> does not work in LISP today, which is absolutely wrong
This entire section ("Current Improvements") has been moved out of this
document. I'll save this comment for when I look at it.
> [whole document]
> No need to introduce new paragraphs at:
> - [12.4] between 3rd and 4th paragraph
You were right on the first one, but this one I'm going to leave: the two
paragraphs talk about distinctly different concepts, and I think it is
beneficial to underline this by the use of two separate paragraphs.
> [4.2] 1st paragraph
> no verb in the secondary "that" clause or confusing subject ("packets")
> if "switches" is the verb
I think this was not actually the case, but it's OBE because that text is
different now.
> Structure-related comments
> ["Initial Applications - Mobility"] and ["Mobile Device Support"]
> - Mobility (although indeed in different enough degree of
> instantiations) has been around since almost the early days of LISP
> itself. As such I wold remove it from improvements and move the [13.2]
> text into [5.5].
> - No reference(s) provided in current [5.5]
Well, the second section is now gone (see above), and I'm thinking of
temporarily (in this RFC version) supressing the first one too, as Mobility is
out-of-scope for the WG, and is not covered in the existing LISP document set.
This has nothing to do with my person opinion of LISP mobility - _I_ think
it's neat. But...
> ["Mapping Cache Performance"]
> - Shouldn't this section follow mapping [6.2]? And be a subsection of
> that one?
No, because the the mapping cache is in the XTR.
> 3rd paragraph -- Description of first effort seems too long (also
> compared to the rest ones). Feel free to drop out some details if
possible.
Done already. :-)
http://www.ietf.org/mail-archive/web/lisp/current/msg04635.html
(I came to the same conclusion independently.)
> ["xTRs"] first paragraph
> if [9.x] are "advanced topics" then it "automatically" makes them
> candidates for removal given the prior email discussion about keeping
> the _Intro_ document short. But I believe [9.1], [9.8], a few details in
> [9.2] are indeed (fundamental) helpful to be included in this
> document. Just pointing out in case you were looking to somehow cut down
> the size of the document.
Well, they are 'advanced' compared to the prior coverage of xTRs (in "Major
Functional Subsystems - xTRs"). Since they all cover moderately low-level
engineering details, not high-level architectural things, I don't believe they
are suitable for relocation to the 'Perspective' document. (Some architectural
aspects already have been moved over.)
And they are in the 'second half', which the Preface explicity says is not
part of the 'basic introduction'... :-)
> ["The Mapping System"] 1st paragraph
> Here you refer to only "indexing subsystem" and the "mappings" although
> you mentioned _3_ subsections above [in 6.2.1].
Already fixed to name three here too.
> ["Internetworking Mechanism"]
> Shouldn't [11.3], [11.4], [11.5] and [11.6] be subsections of [11.2]?
Perhaps, but then the nesting would get too deep: I don't think XML2RFC puts
levels past 3 into the TOC, so someone looking into the TOC for, say, PITRs
and PETRs would not find them. Since there's nothing in the section after
those sub-sections, I made them peers of their intro section, rather than
children.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
