On Apr 18, 2017, at 9:08 AM, Alvaro Retana (aretana) <[email protected]> wrote: > Note that 9.1.1. says that if “the route is ineligible, the route MAY NOT > serve as an input to the next phase of route selection”. IOW, even if routes > are “ineligible” they can still be used (because of the MAY), which is not > what is wanted.
Oh cool, MAY NOT is actually not a special term defined in RFC 2119. It doesn't have any special meaning despite the ALL CAPS. I think the plain English of it is clear in context -- the authors meant MUST NOT in 2119-speak. I think this is actually an erratum against 4271. To make matters worse, there is one other occurrence of MAY NOT in 4271, and in that case the intent is clearly the other way around -- in 4271, section 5, we have "Others are discretionary and MAY or MAY NOT be sent in a particular UPDATE message". I'll plan to open errata against 4271 for these. IMO the language in draft-ietf-grow-bgp-reject-05 is OK. --John _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
