Skip to main content

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

Yes

(Jari Arkko)

No Objection

(Dan Romascanu)
(Gonzalo Camarillo)
(Peter Saint-Andre)
(Robert Sparks)
(Russ Housley)

No Record


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

(Jari Arkko; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection (2012-03-07)
Perfect. Thank you for working to address my concerns.

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()

                            

(Peter Saint-Andre; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) (was Discuss) No Objection

No Objection (2011-10-04)
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

No Objection ()

                            

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2011-10-06)
#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

No Objection (2012-01-06)
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

No Objection (2012-03-06)
Thank you for addressing my concerns

(Wesley Eddy; former steering group member) (was No Objection) No Record

No Record (2011-10-05)
I support the first 2 parts of Stephen's DISCUSS