WG, based on Pete’s response, see diff file. Please let me know if you don’t agree with my changes. And if you think other MAYs or SHOULDs should be changed to lower-case (or not). Dino
<<< text/html; x-unix-mode=0644; name="rfcdiff-6833bis.html": Unrecognized >>>
> On Sep 5, 2018, at 10:17 AM, Pete Resnick <resnick@xxxxxxxxxxxx> wrote: > > 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. >
