Note: This ballot was opened for revision 09 and is now closed.
Summary: Has enough positions to pass.
Adrian Farrel
Comment (2014-02-12)
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.
Jari Arkko
Comment (2013-08-29)
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.
s/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.
Richard Barnes
Comment (2013-08-28)
Support Sean's points on this.
Spencer Dawkins
Comment (2013-08-28)
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.
[Sean Turner]
Comment (2014-01-01)
Thanks for addressing my concerns.
Happy New Year.
datatracker.ietf.org
