Firstly, I must note that there are a whole ot of use of "may" as distinct from the normative "MAY" in this document, "should" as distinct from the normative "SHOULD", etc. As thisd is a document intended for a Standards Track, the document needs to be strict about its use of the normative forms of the requirements language as noted in section 1.1 of the document
e.g.: " An AS _may_ originate more than one prefix set. Thus, multiple prefix sets in the database _may_ contain the same origin AS(es). On 01/12/2010, at 4:59 AM, Pradosh Mohapatra wrote: > Hi Geoff, > >> Section 5. Routing Policy >> >> Announcements with invalid origins MAY be used, but SHOULD be less >> preferred than those with valid or unknown. >> >> >> Here I agree with the sentiment in terms of the relativity to valid or >> unknown, but I am worried about the MAY statement here, and I would like the >> document to explain this further. >> >> For example, a simple reading of the document leads one to believe that all >> announcements MAY still be accepted according to the routing policy >> selection allowed in section 5, yet if that were the case then the ability >> of origin validation to "deal with inadvertent mis-advertisement" is >> questionable. >> >> I would prefer the document to look at the implication of _why_ a party MAY >> accept a route that the origination validation framework is leading to a >> local judgement that the route is invalid. i.e. is it because of missing >> information in the relying party's local cache, which may bne resolved over >> time? Is is due to potential circularity of dependence, where parts of the >> RPKI distributed repository lie behind routes that can only be judged as >> valid using certs and ROAs found in that repository? > > I am afraid that any attempt to enumerate the cases where an invalid route > MAY be accepted will be incomplete! Rather, could we add a statement to the > effect that accepting invalid routes is a pure local matter and should be > done with utmost care? works for me Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
