> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of > Paul Hoffman
> the charter limits the topics that are meant to be > fully covered by the protocols. > > Personally, I would prefer to see the threat model document say in the > introduction "the following topics are considered to be BGP security > threats but are not dealt with in this document:" followed by a list [WEG] +1, or even have the document deal with them at least briefly, but be clear that the current scope (or other limitations) makes it difficult to solve them. Not to put words in Danny's mouth, but I think that there are two general concerns being raised about this document and the -reqs document. The first, which is far easier to deal with, is that a document(s) that should be relatively solution-agnostic is being tailored to preselect/justify an existing (though still nascent) solution based on the current charter scope. It should be a full discussion of the problem space that leads to selection and prioritization of the important problems to solve, acceptable risks, etc. This then serves as a method to (design and) evaluate a solution, whether there's only one, or whether there are multiples. I too find it a bit strange that we're doing things in the reverse order (or in parallel), as usually these sorts of docs are written because the solution doesn't exist yet, and this helps to clearly articulate the problem space, rather than retroactively defining it. Am I missing something regarding the intent of these documents? The second is more a question of charter, and scope for the solution, which is definitely limited by charter. However, having a more comprehensive document on threats and design requirements may indeed drive a review of the scope and charter, either because it brings to light additional considerations, or because those who actually need to implement the solution on their networks have provided feedback that leads to a different conclusion. I'm not recommending that we analyze the problem forever, because a partial solution that is deployable may indeed be better than a theoretical one that solves more problems, but never materializes (or at the very least takes longer). But there is a balance point between those, and I'm not totally certain we're at that equilibrium yet, regardless of the current charter. There have now been multiple folks expressing concerns over the costs (be they operational, capital, expense, etc) to implement vs the benefit based on what risks are mitigated by the solution vs which are not and the exposure that represents to one's chosen line of business, so there's some value in having an eyes-wide-open discussion about it. Thanks Wes George 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. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
