Re: [sidr] BGPsec draft and extended messages

2017-03-15 Thread Sriram, Kotikalapudi (Fed)
Wes, Comments inline below marked with [ks]. > >Being pragmatic, I understand that the risk is low for exceeding the max size >without extended message support based on the average AS-path length, but I >have concerns about the suggested solution that treats unsigned updates as a >fallback

Re: [sidr] BGPsec draft and extended messages

2017-03-15 Thread Wes George
I’m behind on mail but Sriram suggested I pay attention to this, so here’s a drive-by comment, and if this comes up in SIDROps in Chicago I’ll do my best to attend and participate in the discussion there. Being pragmatic, I understand that the risk is low for exceeding the max size without

Re: [sidr] BGPsec draft and extended messages

2017-03-15 Thread Susan Hares
Alvaro: Thank you for working through these issues at this late time. IDR is talking input on this topic. So it would be good to post a summary of your discussion to the IDR list. If it is useful, we can still set aside time for the authors (or SIDR WG chairs) to present their

Re: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-21

2017-03-15 Thread Sean Turner
> On Mar 2, 2017, at 03:36, Shucheng LIU wrote: > > ** Editorial ** > > *Section 4 > >> BGPsec Router Certificates always include the BGPsec Rouer EKU >>value; therefore, request without the value result in > certificates >>with the value; and, > >

Re: [sidr] BGPsec draft and extended messages

2017-03-15 Thread Alvaro Retana (aretana)
Hi! [Speaking as AD] The requirement for Extended Messages has been in the BGPSec draft since the beginning (at least the WG -00 version). Changing it now would mean a significant deviation in the process – but not impossible. Before committing to supporting any change to the document, I

Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07

2017-03-15 Thread Tim Bruijnzeels
Hi Chris, > On 13 Mar 2017, at 15:21, Chris Morrow wrote: > > but, having 2 versions of the validation > algorithm and seeing published data for both OID sets for a single > prefix/publication bundle will be very problematic. There's no > proscribed 'prefer new over old'