Hello Adam Many thanks for your review 😊 Please see below: > 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? Yes I guess it is a MUST, unless the registration is rejected for another reason, e.g., the overflow below. Unless someone posts against it I'll make the change with the next revision. > 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? Yes, I suppose so. I'll make that change too. Many thanks again Adam! Pascal -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
