On Nov 7, 2012, at 6:10 PM, Christopher Morrow wrote: > On Wed, Nov 7, 2012 at 5:47 PM, Eric Osterweil <[email protected]> > wrote: >> >> On Nov 7, 2012, at 4:11 PM, Christopher Morrow wrote: > > just as broke, bug lodged (I hope) for a fix.
But, but, it works for me... jk ;) >> <broken record> >> The offer to provide input to the threats and requirements docs is a genuine >> attempt to help. For real! :) I have the sneaking suspicion that this >> week's... >> err, event... cost some people some sleep. I feel like we _should_ be >> addressing it, no? >> </broken record> > > don't disagree, haven't disagreed. (I think) I hear ya, but I feel like this obviates our need to begin discussions with new design proposals. How can I offer you a design if we don't agree on what it should do, right? > nor did filtering on the upstream/customer peerings (clearly)... so > folk that want to fall back on 'but de filterz!!' .. are also in > failville. Which of the parties was filtering? > maybe? folk have to see a benefit to any of this in order for it to > move into production use. Right on... I think that kind of thinking is really what's motivating a lot of leak-based-discussion. Quick wins might come in plugging leaks, so... on to the threats doc? :-P > if as a first step resource certification > work gets me better filtering and/or more people filtering because > more reliable filtering is possible, good. Yeah, we're on the same page w/ resource certification being a prerequisite. > eventually though, people will realize that: > 1) not everyone is filtering > 2) not everyone will filter > 3) the only solution left is something in the bgp update :( > > if there is another '3', let's talk about that. Just to follow the same logic, could I not say, 1) not everyone is running bgpsec [clearly, it's not here yet] 2) not everyone will run bgpsec [therefore there will be isolated islands] 3) the only solution left can't be something in the bgp update? > where else does the data from which you make a decision about 'leak or > not' come from? My understanding is that we need to fallback to intent. With some way to expose and verify intent, we get there. Discussing how to do that seems like the right first step, imho. >> seem to be enough complexities in the policy semantics that the amount >> of effort needed to get the minimum level of expressiveness into BGP >> could be a non-starter... Just my 0.02... > > perhaps you could explain more/better this problem. Maybe I could just say, today we have a very complex policy specification language, and it's not clear how much of it is used, by whom, and to what extent... If we were to say, ``throw it all in an update,'' I think we'd see BGP updates bigger than the bgpsec updates. As of now, if we can't agree that leaks are a problem worth addressing and/or we can't agree on what leaks actually are, how could we _not_ use a very verbose language to expose relevant policy? >>> I think techically rpki is just the jumble of certificate data and roas >>> that talk about: <snip> > this is less concerning... and it's beside the discussion of leak-or-not. Yeah, but I didn't bring it... I just wanted to clarify the above comment. I didn't mean to distract, but felt the clarification was important. > as noted on-list more than one time I'd love to see some scaling and > such work done on the certificate repository... that's not today's > problem though. Yeah, working on that for sure... >> What are we (as a wg) trying to solve? I.e. shouldn't we be talking about >> threats >> and requirements? > > i think we are/were. Then I would propose that the insistence on only submitting solutions before allowing requirements discussions is not appropriate. Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
