Oh, one other thing: If anyone on this list thinks that instead of referencing as-migration, that we are better off merging as-migration into bgpsec-protocol, this would be a great time to speak up.
(That is, it is not too late to pull the solution from as-migration directly into bgpsec-protocol, but if we are going to go down that road, we should do it as soon as possible!) On Mon, Jul 7, 2014 at 1:03 PM, Matthew Lepinski <mlepinski.i...@gmail.com> wrote: > 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 <wesley.geo...@twcable.com> > wrote: > >> >> From: Matthew Lepinski <mlepinski.i...@gmail.com> >> Date: Friday, July 4, 2014 at 6:16 PM >> To: "sidr@ietf.org" <sidr@ietf.org> >> 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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
