Locator/ID Separation Protocol (LISP) Map-Server Interface
draft-ietf-lisp-ms-16

Perfect. Thank you for working to address my concerns.

Section 4.2

You say:

"In addition to the set of EID-prefixes defined for each ETR that may register, a Map Server is typically also be configured with one or more aggregate prefixes that define the part of the EID numbering space assigned to it."

Grammar.
----------------------------------------------------------------------------


Section 4.3:

You say:

"If any of the registered ETRs for the EID-prefix have requested proxy reply service, then the Map Server answered the request instead of forwarding it."

Grammar

#1) I support Stephen's discusses.

#2) s1: I support Ron's discuss about the term "Map Server" is overloaded.

#3) Half-tongue-in-cheek: what no ping message to see if the peer is alive? ;)

#4) s2: Maybe add to the last paragraph: "the port number assignments".  I figured oh this protocol does have some assignments - they do they're just not in this draft ;)

After much discussion I didn't manage to convince the authors to
add good-looking text on this, so eventually, I folded;-)

#2 This discuss point is "moved" from -alt: after discussion and 
clarification the fix is apparently better here. There is a minor interop
issue even with the manual keying implied here - some text is needed 
to say that implementations MUST, e.g. do whatever it is that's been 
tested and interop'd (or some subset of that that's sufficient) which I 
think basically amounts to specifying some inputs that MUST be usable 
as secrets (or the equivalent).

This is an interoperability issue though and not just a deployment 
problem - if two nodes implement different stuff and one has a key 
installed already then absent this text it might not be possible to get 
those two nodes to interop if the already installed key on node1 cannot 
be entered into node2 somehow.

Thank you for addressing my concerns