Wes, I agree that inserting a reference in bgpsec-protocol (and bgpsec-overview) and then publishing as-migration as part of the bgpsec document set (along with the router certificate profile, the algorithm document, etc) is a good way forward.
I need to do a careful review of the latest version of as-migration (I really haven't looked at the -01). I will get to that before we meet in Toronto. Also, I am open to suggestions with regards to where to insert a reference to as-migration -- but I will try to suggestion for how to link the two documents in time for Toronto. - Matt Lepinski On Mon, Jul 7, 2014 at 12:40 PM, George, Wes <[email protected]> wrote: > > From: Matthew Lepinski <[email protected]> > Date: Friday, July 4, 2014 at 6:16 PM > To: "[email protected]" <[email protected]> > Subject: [sidr] New version draft-ietf-sidr-bgpsec-protocol > > I submitted a new version of the bgpsec protocol document. This revision > includes a fair number of editorial changes but does not include any > normative changes. > > Now that the BGPSEC requirements document is essentially done, I look > forward to discussing the protocol document again in Toronto. In > particular, between now and the Toronto meeting I will write up (and send > to the list) a brief comparison between the requirements in the final > version of the reqs draft and what we deliver in the protocol document. > > The only open issue in the protocol document that I am aware of is the > following: > > [snip] > > Matt - > > One additional change I think is necessary is to add a reference to > ietf-sidr-as-migration. This is effectively an extension of the BGPSec > protocol that is contained in a separate document. If the BGPSec doc was > already done, I'd most likely be using the metadata of as-migration to > update RFCnnnn so that the link would exist from the BGPSec protocol doc in > addition to the normative reference to -protocol from as–migration, but in > the current form where it's trivial to update the -protocol draft, I think > that should instead be accomplished by a forward reference, and then the > two documents will simply be part of the group of interdependent docs that > get released for BGPSec (assuming of course that -as–migration passes LC). > > That said, my quick scan of –protocol didn't reveal an obvious place to > insert that reference, so if you or others have ideas of where it should > go, I'm happy to contribute a few lines of wrapper text. > > Thanks, > > > > Wes > > Anything below this line has been added by my company’s mail server, I > have no control over it. > > ----------- > > > ------------------------------ > 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 [email protected] https://www.ietf.org/mailman/listinfo/sidr
