Last Call Review of draft-ietf-lisp-rfc6833bis-13

Request Review of draft-ietf-lisp-rfc6833bis
Requested rev. no specific revision (document currently at 28)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-08-31
Requested 2018-08-17
Authors Dino Farinacci, Fabio Maino, Vince Fuller, Albert Cabellos-Aparicio
Draft last updated 2018-09-05
Completed reviews Rtgdir Last Call review of -13 by Jonathan Hardwick (diff)
Secdir Last Call review of -12 by Takeshi Takahashi (diff)
Tsvart Last Call review of -13 by Colin Perkins (diff)
Genart Last Call review of -13 by Pete Resnick (diff)
Genart Telechat review of -15 by Pete Resnick (diff)
Genart Telechat review of -24 by Pete Resnick (diff)
Assignment Reviewer Pete Resnick
State Completed
Review review-ietf-lisp-rfc6833bis-13-genart-lc-resnick-2018-09-05
Reviewed rev. 13 (document currently at 28)
Review result Ready with Nits
Review completed: 2018-09-05


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


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:


Minor issues:


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

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.