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.