On Mar 20, 2013, at 2:26 PM, Russ White <ru...@riw.us> wrote: >> I never argued with addressing the risks that might be posed; I was pointing >> out that the risk does not equate (on its own) with a reachability event, as >> alluded to by the paper. > > That all depends on the policy undertaken by each specific provider, > doesn't it?
Correct. We have an ID which makes recommendations (but it is still up to each provider what their specific policy will be) >From <draft-ietf-sidr-origin-ops-20> - "Announcements with Valid origins SHOULD be preferred over those with NotFound or Invalid origins, if the latter are accepted at all. Announcements with NotFound origins SHOULD be preferred over those with Invalid origins. Announcements with Invalid origins SHOULD NOT be used, but MAY be used to meet special operational needs. In such circumstances, the announcement SHOULD have a lower preference than that given to Valid or NotFound. When first deploying origin validation, it may be prudent to not drop announcements with Invalid orgins until inspection of logs, SNMP, or other data indicate that the correct result would be obtained." > How can you tell the difference between a route with no ROA > because the registry has decertified, and a route with no ROA simply > because one hasn't ever been created? No ROA is no ROA... Should give way to routes with Valid origins. > It seems, to me, that there's a problem in here that's likely to bite > someone in the butt once things really start to deploy (if they ever > really do start to deploy). If that's the case, you might want to make some suggestions of alternative text for "Section 5. Routing Policy" of draft-ietf-sidr-origin-ops-20>. As it is, it looks fairly solid in describing the situation at initial deployment and factors that an operator might want to consider in setting their local policy. Thanks! /John _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
