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 rev. no specific revision (document currently at 10)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-10-11
Requested 2016-09-21
Draft 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 Lonvick (diff)
Opsdir Last Call review of -07 by Susan Hares (diff)
Rtgdir Early review of -06 by Danny McPherson (diff)
Assignment Reviewer Susan Hares
State Completed
Review review-ietf-lisp-crypto-07-opsdir-lc-hares-2016-10-12
Reviewed rev. 07 (document currently at 10)
Review result Has Nits
Review completed: 2016-10-12

Review
review-ietf-lisp-crypto-07-opsdir-lc-hares-2016-10-12

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