On Mar 21, 2012, at 12:45 PM, Christopher Morrow wrote: > On Wed, Mar 21, 2012 at 12:36 PM, Brian Dickson > <[email protected]> wrote: >> >> >> On Wed, Mar 21, 2012 at 12:10 PM, Christopher Morrow >> <[email protected]> wrote: >>> >>> On Wed, Mar 21, 2012 at 11:50 AM, Brian Dickson >>> <[email protected]> wrote: >>>> >>>> >>>> On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas <[email protected]> >>>> wrote: >>>>> >>>>> By "we" I assume you are asking the bigger question about what the >>>>> broad >>>>> requirements / objectives should be. >>>>> >>>>> The current BGPSEC design, chooses to only focus on the protocol on the >>>>> wire, and starts with the attributes that had both an identified threat >>>>> and a existence proof of a reasonable mechanism to address that threat. >>>>> >>>> >>>> If that statement were true, I think there would be much more support >>>> and >>>> progress >>>> for the bgpsec-protocol component of the SIDR WG. >>>> >>>> However, the current interpretation (by whom, is not clear) seems to be, >>>> that only certain attributes (AS-path and nothing else?) are included in >>>> what is protected. >>>> >>>> Any attempt to discuss inclusion of other attributes, and reasonable >>>> mechanisms >>>> for including those in the protection regime, has been shouted down by a >>>> small group >>>> which includes a self-selected group of implementers. >>>> >>> >>> you seem to want to read: >>> http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01 >>>
Actually, with respect, I think the first stop really ought to be coming to consensus on a requirements document. My experience has been that doing design work without solid requirements can lead to a great deal of rework. Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
