Last Call Review of draft-ietf-6lo-ap-nd-12
review-ietf-6lo-ap-nd-12-secdir-lc-montville-2020-01-03-00

Request Review of draft-ietf-6lo-ap-nd
Requested revision No specific revision (document currently at 23)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-01-09
Requested 2019-12-19
Authors Pascal Thubert , Behcet Sarikaya , Mohit Sethi , Rene Struik
I-D last updated 2020-01-03
Completed reviews Secdir Last Call review of -12 by Adam W. Montville (diff)
Opsdir Last Call review of -12 by Al Morton (diff)
Genart Last Call review of -12 by Vijay K. Gurbani (diff)
Assignment Reviewer Adam W. Montville
State Completed
Request Last Call review on draft-ietf-6lo-ap-nd by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/-VhQE-KhgDkonpusgk4rDmRHBEM
Reviewed revision 12 (document currently at 23)
Result Ready
Completed 2020-01-03
review-ietf-6lo-ap-nd-12-secdir-lc-montville-2020-01-03-00
Address Protected Neighbor Discovery for Low-power and Lossy Networks, which
guards against address theft, is almost ready for publication.

There are two points that may warrant attention by the ADs:

1. In the first exchange with a 6LR: "When a 6LR receives a NS(EARO)
registration with a new Crypto-ID as a ROVR, it SHOULD challenge by responding
with a NA(EARO) with a status of "Validation Requested"". Under what
circumstances would a challenge not be warranted? In other words, could this
SHOULD be a MUST?

2. The following sentence in 7.1 reads, "The 6LR must protect itself against
overflows and reject excessive registration with a status 2 "Neighbor Cache
Full"". Does that need to be a MUST instead of a must?