Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations
RFC 7215

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

(Jari Arkko) Yes

Comment (2013-08-29 for -10)
No email
send info
Thank you for a well-written and useful document!

A few comments:

Shouldn't Section 2.6 table include the NAT case as well?

I'd probably place a stronger warning on the recursive deployment case. My personal experience is that recursive encapsulation models are not very practical, particularly when something goes wrong and debugging is needed.

>  For more details on P-ETRs see the [RFC6832] draft.


I agree with Stephen that the document needs to be clearer about the lack of currently specified security support, and what the implications of that are.

(Brian Haberman) Yes

(Richard Barnes) No Objection

Comment (2013-08-28 for -10)
No email
send info
Support Sean's points on this.

(Stewart Bryant) No Objection

(Spencer Dawkins) No Objection

Comment (2013-08-28 for -10)
No email
send info
Just one comment ... I'm confused about the Abstract

   This document is a snapshot of different Locator/Identifier
   Separation Protocol (LISP) deployment scenarios.  It discusses the
   placement of new network elements introduced by the protocol,
   representing the thinking of the authors as of Summer 2013.  LISP
   deployment scenarios may have evolved since.  This memo represents
   one stable point in that evolution of understanding.

Is "the thinking of the authors" still an accurate description? I'm only asking because the draft name indicates that it was adopted by the working group, and the shepherd write-up says "The document shepherd believes that there was a clear consensus for publishing the draft as informational RFC", which I could read as "consensus that we think this" or "consensus that it's valuable to publish that some people think this".

I didn't see any reference to this except in the Abstract, so I thought I'd ask.

(Adrian Farrel) (was Discuss) No Objection

Comment (2014-02-12)
No email
send info
Thanks to the authors for the considerable time and effort put in to address my Discuss and Comments.

A much improved version of an important draft.

(Barry Leiba) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2014-01-01 for -11)
No email
send info
Thanks for addressing my concerns.

Happy New Year.