Hang on, and notwithstanding the request for WGLC. I think the use cases are likely to be informed by protocol design, so even if they are baked, I'd argue that at best that would be only halfway baked.
I have a few examples that I can think of, which would necessarily depend significantly on design choices which have been made "by default", but which may turn out to be poor choices, or where later discoveries could result in better choices. 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. 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.) What "E" would want to do, is have a delegation, controlled by "E", towards both "X" and "Y" which allow "X" and "Y" to create proxy-path-signatures and proxy-originations, of "X E" and "Y E" respectively. This is about origination, is related partly to BGPSEC requirements/architecture/design/protocol, and necessarily has to do with RP validation based on ROAs. It would be, in theory, possible for _either_ X _or_ Y to completely opaquely proxy for "E", but not for "E" to maintain control, nor to have both X _and_ Y proxy, transparently or opaquely. I don't think we need to fully address this use case just yet, but rather it is an example of something that justifies putting the WGLC on hold, or at least holding it at immediate-post-WGLC state, for further revision pending other work on the protocol. Having decisions based on prior work, rather than informed experience in deployment, and subsequently locked in, is an example of "bad design" methodology. 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. (It may turn out to eventually be unchanged, but we should not presuppose that. This applies not just to this doc, but pretty much all the docs. We can make progress on them and "freeze" them without publishing them piece-meal, and I think the WG output would be much better for doing so.) Brian On Thu, Mar 29, 2012 at 2:11 PM, Christopher Morrow <[email protected] > wrote: > Alright, I'll tackle that tomorrow morning. > > -chris > (cochair) > > On Fri, Dec 9, 2011 at 9:03 AM, Sriram, Kotikalapudi > <[email protected]> wrote: > > Sandy, > > Chris, > > > > The WGLC on this doc ended 09/22/2011. > > We (the authors) submitted a substantially revised version on October > 31, 2011, > > taking into careful consideration all comments that were received during > the WGLC. > > Please see Warren's note (attached below). > > The authors feel that this document is now ripe and ready for wrapping > up the WGLC. > > Thanks. > > > > Sriram > > ________________________________________ > > From: Warren Kumari [[email protected]] > > Sent: Thursday, November 03, 2011 1:06 PM > > To: Sriram, Kotikalapudi > > Cc: Warren Kumari; Randy Bush; [email protected] list > > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt > > > > On Oct 31, 2011, at 7:56 PM, Sriram, Kotikalapudi wrote: > > > >> In this revised version, we (authors) have made changes with careful > consideration > >> of all the comments (mostly of editorial nature) received from Warren > and Randy. > >> > >> http://www.ietf.org/mail-archive/web/sidr/current/msg03349.html > >> http://www.ietf.org/mail-archive/web/sidr/current/msg03306.html > >> http://www.ietf.org/mail-archive/web/sidr/current/msg03305.html > >> http://www.ietf.org/mail-archive/web/sidr/current/msg03304.html > >> > >> We have also made many other edits throughout the doc to improve > >> clarity and readability. > > > > > > Thank you. > > > > I support this moving forward (which is just a formality, I supported it > before as well, this all just makes it (IMO) better).. > > > > W > > > >> > >> Sriram > >> ________________________________________ > >> > >> Title : Use Cases and Interpretation of RPKI Objects > for Issuers and Relying Parties > >> Author(s) : Terry Manderson > >> Kotikalapudi Sriram > >> Russ White > >> Filename : draft-ietf-sidr-usecases-03.txt > >> Pages : 30 > >> Date : 2011-10-31 > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-03.txt > >> > > > > _______________________________________________ > > sidr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
