On Fri, Mar 30, 2012 at 4:21 AM, Murphy, Sandra <[email protected]> wrote: > Brian, Chris. > > The usecases draft was intended to describe origin validation use cases. > > Route leaks (and other path validation issues) might need their own usecases > draft. > > But I don't think we should add those cases to this draft.
fair enough. (it seems to me) > --Sandy > > ________________________________________ > From: [email protected] [[email protected]] on behalf > of Christopher Morrow [[email protected]] > Sent: Thursday, March 29, 2012 7:21 PM > To: Brian Dickson > Cc: Sriram, Kotikalapudi; Chris Morrow; Murphy, Sandra; Murphy, Sandra; > [email protected] list > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt > > On Thu, Mar 29, 2012 at 3:11 PM, Brian Dickson > <[email protected]> wrote: > >> I think the use cases are likely to be informed by protocol design, so even > > s/informed by protocol design/altered if the protocol design changes/ > > I'm not sure if the protocol design's going to change the use-cases... > you're still going to want to secure a route. (not an important point) > >> I have a few examples that I can think of, which would necessarily depend > <snip> >> I'd prefer this to be added to a "raft" of IDs, for which there is no rush >> to publish until they are all completed, after which the timing would be >> appropriate. > > I'm not against this, though we've got a document hanging out post > WGLC (perhaps it ought to be re-reviewed if the changes were > significant... anyway) and we'll have to keep kicking it each 5.5 > months to stay 'alive'. (again, not super important, and see below as > well) > >> Here's an example of use-case, which depends on certain assumptions (which >> may or may not be appropriate, but which are fodder for discussion): >> >> Suppose there is an Edge-AS "E", and transit providers to "E", which would >> be "X" and "Y". >> >> Suppose "E" does not do BGPSEC (per se), but wants to have BGPSEC signing >> done "for her", by "X" and "Y". >> >> (Ignore for the moment that the _current_ designs don't support that, that >> is an entirely other rat-hole for the moment.) > > hrm, in: > > <http://tools.ietf.org/id/draft-ietf-sidr-bgpsec-ops-04.txt> > > section-6 there's discussion of 'only sign your one prefix, do nothing > else complex' which fits the model, albeit requiring the end site to > run some small number of commands on their device. If they wanted to > hand their private key materials to the upstreams they could do the > signing, but that seems icky (to me). > > I don't know that, if implications are understood by the end site and > configurations available for use on their side, end-sites would want > to hand over control of their IP assets in this way. Running the > signing on their side should be simple enough, and low/no-cost. > >> And publishing something IMHO prematurely, locks the WG into that RFC, >> making revising it much harder, than if it were still in-WG and >> not-yet-published. > > I think the authors said something like: "send text" where you think > it is fit to be inserted... If other folks want to delay/re-review > they need to speak up. Consensus so far was that the document was > ready to move along. > > -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
