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>. 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: 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. 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". 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.
