> Reviewer: Pete Resnick > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Thanks a lot for your review Pete. > Document: draft-ietf-lisp-rfc6833bis-13 > Reviewer: Pete Resnick > Review Date: 2018-09-05 > IETF LC End Date: 2018-08-31 > IESG Telechat date: 2018-09-13 > > Summary: Ready with Nits > > By no means my area of expertise, but particularly comparing this document to > 6833, it's clear what changed and the new material looks reasonable. One > overall nitty thing below. > > Major issues: > > None. > > Minor issues: > > None. > > Nits/editorial comments: > > Somebody went a bit "2119-mad" in this document. In particular, *most* of the > MAYs are just goofy and wrong, and many of the SHOULDs shouldn't be there. When > you're putting in a 2119 keyword, they should point out a place where an > implementer needs to look to make sure they get their implementation correct. A > lot of these aren't helpful in that regard. A few examples: Well we were encouraged by the working group. I will fix this up a bit. Thanks for your opinion. > In 8.2: > > In addition to the set of EID-Prefixes defined for each ETR that MAY > register, > > That's not a protocol option being described. > > (such as those > indicating whether the message is authoritative and how returned > Locators SHOULD be treated) > > That's not a piece of implementation advice. Fixed. > > In 8.3: > > This MAY occur if a Map Request is > received for a configured aggregate EID-Prefix for which no more- > specific EID-Prefix exists; > > If "MAY" can be replaced with "might or might not", you probably want "may" or > "can”. Used “can”. > Unless also acting > as a Map-Resolver, a Map-Server SHOULD never receive Map-Replies; > > That's a statement of fact, not an implementation instruction. > > Please go through and get rid of the bogus ones. If it's not an indication of > an implementation option (or lack thereof), it shouldn't be 2119ed. Done. Thanks again. Dino
