Skip to main content

Last Call Review of draft-ietf-lisp-crypto-07
review-ietf-lisp-crypto-07-opsdir-lc-hares-2016-10-12-00

Request Review of draft-ietf-lisp-crypto
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-10-11
Requested 2016-09-21
Authors Dino Farinacci , Brian Weis
I-D last updated 2016-10-12
Completed reviews Genart Last Call review of -09 by Pete Resnick (diff)
Secdir Last Call review of -07 by Chris M. Lonvick (diff)
Opsdir Last Call review of -07 by Susan Hares (diff)
Rtgdir Early review of -06 by Danny R. McPherson (diff)
Assignment Reviewer Susan Hares
State Completed
Request Last Call review on draft-ietf-lisp-crypto by Ops Directorate Assigned
Reviewed revision 07 (document currently at 10)
Result Has nits
Completed 2016-10-12
review-ietf-lisp-crypto-07-opsdir-lc-hares-2016-10-12-00
Dino and Brian:



I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the  IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments

just like any other last call comments.



Status of draft:  Ready with nits

Caveat:  I am not a crypto expert.  I am not a lisp expert.



Nits (#1-#4), #5 nit/minor



#1 Introduction p. 2 – It would be nice to expand the definitions of ITR, PITR,
ETR, RTR in their first use.  This is common editorial usage.



#2 p. 3 – it would really nice if this document indicate why the requirement
were chosen for the solution space on page 3 paragraph 1.  I realize that once
you choose these requirements, the rest of the work falls out.   What’s
important for OPS-DIR is whether you believe these requirement help make the
system with crypto operate faster, with less overhead, or make it easier to
manage.  If this is stated in an architecture document, a reference would be
nice.



#3 Again, inquiring minds want to know on page p 5 – why you decided not to use
the “R” bit for this use case and reserve it for the LISP-DDT security.  If
there was an architectural choice, it would be nice to know it links to that
point.



#4 p. 9 last paragraph (editorial/



/When an ITR or PITR receives a packet to be encapsulated, they will/

To

/When an ITR or PITR receives a packet to be encapsulated, the device will/



#5 p. 11, section 1.



Does the changing of keys via RLOC-probing cause of a problem if the ITRs or
ETRS are mobile or going up/down at the time a map-cache is added?  Or in
another way, is there any chance that fluctuation in the systems connectivity
can get the system into a state where the keys are out of date between peers. 
If so, how do devices in the system get back in sync.

 [#5 – may be understood better by crypto expert]



Sue Hares

shares at ndzh.com