John: Hi!
My bigger issue with 9.1.1 is that it is the first step of the decision process – the intent, as I understand it, is for the routes not to even reach that point. If the text in 9.1.1. is interpreted as “MUST NOT” (which is not what it says!), then there is probably more work to be done (in the conceptual model), but it would be ok. However, I really have a hard time changing Normative language… Thanks for chiming in. Alvaro. On 4/19/17, 9:26 AM, "John G. Scudder" <[email protected]> wrote: 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. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
