Locator/ID Separation Protocol (LISP) Map-Server Interface
RFC 6833
Yes
No Objection
No Record
Note: This ballot was opened for revision 15 and is now closed.
(Jari Arkko; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
Perfect. Thank you for working to address my concerns.
(Dan Romascanu; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) (was Discuss) No Objection
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
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
#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 ;)
(Stephen Farrell; former steering group member) (was Discuss) No Objection
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.
(Stewart Bryant; former steering group member) (was Discuss) No Objection
Thank you for addressing my concerns
(Wesley Eddy; former steering group member) (was No Objection) No Record
I support the first 2 parts of Stephen's DISCUSS