Re: [Gen-art] Genart last call review of draft-ietf-lisp-rfc6833bis-13

[Dino Farinacci <[e-mail]>]

> 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