On 8 Jul 2014, at 3:02 pm, Matthew Lepinski <mlepinski.i...@gmail.com> wrote:
> So I have no preference with regards to one document or two. (That is, if the > working group wants to merge the BGPSec algs document with 6485bis, I see > nothing wrong with fewer documents.) > > However, I believe that there is a good reason to have a distinct set of > algorithms for creating BGPSEC signatures and for signing RPKI certificates. I can understand that perspective, and it makes sense to me, But that does not necessarily imply two RFCs. I think we need to keep an eye on the entire framework, and as we add pieces to the RPKI we should clearly understand where and how they interlock. For that reason, I would like to see a single RPKI algorithms and key length spec that encompasses the entire RPKI use domain. If there is a need to split this document to make the distinction between use in the certificate and authority domain and use within the router-to-router domain then thats fine, but that split would (in my opinion) be within a single specification document, rather than more documents. Geoff > In particular, the devices that we envision producing BGPSEC signatures are > different than the devices that are currently signing RPKI certificates. > Additionally, signature length seems to be a non issue today with regards to > signing RPKI certificates, but signature length is a more important > consideration for BGPSEC signatures. That is, the trade offs in what makes a > good signature algorithm are somewhat different when it comes to BGPSEC and I > don't think we want to artificially force the two signature algorithms (for > RPKI certs and for BGPSEC) to be the same. That is the original reason for > producing the bgpsec-algs document (of course, this document was first > written before it became clear that we needed to do a bis for 6485, and so > perhaps it we should revisit whether we want one document or two). > > - Matt Lepinski > > On Jul 8, 2014 12:49 AM, "Geoff Huston" <g...@apnic.net> wrote: > well I would like to understand why there appears to be two parallel efforts > to update RFC6485, and it was I suppose a question that is correctly passed > to the chairs, given that the chairs wanted rfc6485bis produced, and > I assume that the chairs similarly approved the WG adoption of bgpsec-algs. > > The original desire was to isolate the structure and framework from the > crypto, > which is why RFC6485 was produced in the first place, but now it appears that > we > are fragmenting this and producing multiple crypto profiles. > > > Geoff > > > (I was told recently that the DNS specs now span a few hundred RFCs. For a > widely deployed > active protocol I can kinda see that, but I'm not sure that there is merit in > SIDR at this > point in time to take this same quantity of RFCs as an objective! :-) ) > > > > > > > > On 8 Jul 2014, at 9:42 am, Sandra Murphy <sa...@tislabs.com> wrote: > > > > > On Jul 7, 2014, at 7:00 PM, Geoff Huston <g...@apnic.net> wrote: > > > > > >> the header of draft-ietf-sidr-bgpsec-algs-08 says: > >> "Updates: 6485 (if approved) " > >> > >> > >> so I'm still confused about the two 6485 update drafts. > >> > >> > > > > > > Ah. So your original question was: > > > >> > >> Whats the relationship between this draft and draft-ietf-sidr-rfc6485bis? > > > > So you want to know if bgpsec-algs is updating the original RFC6485 or > > updating rfc6485bis? > > > > --Sandy, speaking as regular ol' member > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
