On Nov 3, 2011, at 11:33 AM, George, Wes wrote: >> 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.
Another +1. > 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. +1 > 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. +1 -shane > 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 _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
