On 5/12/14, 6:06 PM, "Danny McPherson" <[email protected]> wrote:
>>still does not do much to provide >> guidance on how such a leak would be systematically identified, > >Nor does it have to in any programmatic way, IMO. It's easy for an >entry level routing person to understand what the problem is here, hell, >they have to deal with them every day. It doesn't have to expand to >every possible reason or define detection mechanisms. That’s exactly my point. We don’t need better understanding of the symptom, which is what documenting an example (or many examples) provides. What we need is a discussion around WHY it’s not possible or practical to prevent unintentional route leaks with existing or proposed (BGPSec) tools - i.e. can’t know intent and/or may not be able to represent intent in existing policy language such that it can be derived from available info. >We didn't say we'd proclaim all is accomplished, we said we'd like to >foster discussions of policy v. intent. This very discussion makes me >think it works, Well, yes, the words “policy” and “intent” did occur more than once, so I guess that’s a discussion in the strictest sense of the word. However I don’t think that it’s been adequately covered in the document even to the point that it would spur a follow-on document. And though it might seem otherwise, IETF shouldn’t be generating documents for the sake of having documents. I don’t see any reason why the discussion of some of the challenges around this problem should be punted to a separate document/discussion. Put another way, I don’t think that this document has enough meat to stand alone with just the example of the problem. >we can certainly encourage more folks to do research, with a stable >reference, which was precisely the intent. > >This draft is only meant >to document the issue above, which you seem to agree that no one would >dispute. It doesn't need to be the kitchen sink for attack vectors. I’m not suggesting that it needs to be the kitchen sink for attack vectors. I’m suggesting that it needs to discuss this *one* more thoroughly, such that folks can actually understand the underlying challenge about why it hasn’t already been addressed and still exists as a real problem in the wild. That will be significantly more helpful if folks are to do research into solutions, or even see if data analysis can lead to a way to derive things like intent and policy more effectively. > We should document what some >believe the problems are before we begin designing solutions, else we'll >end up with more complicated solutions that don't address what me >operators believe to be the key issues. Yes. That’s what I’m asking you to do. I’m not asking for you to design a solution, but discussing existing solutions that don’t work, and why they don’t work helps to more completely define the problem. I consider that a key issue that the document currently does not discuss. Thanks Wes This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
