Locator/ID Separation Protocol (LISP) Map-Server Interface
RFC 6833

Note: This ballot was opened for revision 15 and is now closed.

(Jari Arkko) Yes

(Ron Bonica) (was Discuss) No Objection

Comment (2011-10-04)
No email
send info
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

(Stewart Bryant) (was Discuss) No Objection

Comment (2012-03-06)
No email
send info
Thank you for addressing my concerns

(Gonzalo Camarillo) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2012-03-07)
No email
send info
Perfect. Thank you for working to address my concerns.

(Stephen Farrell) (was Discuss) No Objection

Comment (2012-01-06)
No email
send info
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.

(Russ Housley) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2011-10-06)
No email
send info
#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 ;)

(Wesley Eddy) (was No Objection) No Record

Comment (2011-10-05 for -)
No email
send info
I support the first 2 parts of Stephen's DISCUSS