>> You're apparently trying to separate the idea of proving an update >> traveled a specific path from the idea of using this information to >> actually filter or determine any other policy. I don't see how you can >> separate the two --can you explain how you can? > > If you can establish the former (that the route did travel across the path it > said it did), that outcome can be used as input to policy. This is exactly > analogous to draft-ietf-sidr-pfx-validate-01, BTW. > > Divide, conquer. A commonly used trick in computing. :-)
Hmmm... This is what I thought. 1. Shane and I are arguing that you can't --or shouldn't-- imply policy based on which AS a particular piece of routing information went through multiple hops from you (I hope that's right, Shane). 2. You answered: > I interpret the proposed charter item to be asking not "if AS_B *should* in > fact be announcing which of AS_A's routes or in what form" but rather roughly > "if AS_B *did* in fact announce which of AS_A's routes and in what form". 3. My question was --it seems you're trying to say, "no, I don't want to infer policy from this, I just want to prove what happened." At which point I asked --what's the difference if, in fact, you intend to act based on what you perceive as "what happened?" In trying to "divide and conquer," you're actually assuming step 2 from step 1 --and the assumption is what I think we need to drive out into the open air and discuss by building a set of requirements other than, "I want to prove what happened." :-) Russ
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
