Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT)

>> so, i think you are referring to >> >>As core BGPsec-capable routers may require large memory and/or modern >>CPUs, origin validation based on the Resource Public Key >>Infrastructure (RPKI), [RFC6811], will occur over some years and >>BGPsec will start to deploy after that. >>

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

> Wait, I thought I wasn’t supposed to duplicate any of the crazy stuff > from 6487 :) duplication opens to errors in copying and makes later changes messier randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT)

> "The considerations for RPKI objects (Certificates, Certificate > Revocation Lists (CRLs), manifests, Ghostbusters Records [RFC6481]), > Trust Anchor Locators (TALs) [RFC6490], cache behaviours of > synchronisation and validation from the section on RPKI Distribution > and Maintenance of

Re: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

On 01/04/2017 09:38 AM, Sean Turner wrote: > >> On Jan 4, 2017, at 05:09, Randy Bush wrote: >> >>> +1 to the comment from Suresh about order. I though that something like >>> what he proposed will minimize memcopies and possibly use of memory why >>> hashing. So I am also curious

[sidr] Terry Manderson's No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT)

Terry Manderson has entered the following ballot position for draft-ietf-sidr-bgpsec-ops-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT)

spencer, [ btw, your mua seems not to do quoting level in its ascii rendering ] > you are at the intersection (well actially union) of two twisty sets of > passages, bgp routing and internet ops. > > > I'm wondering if "the transitive closure of a client's customers" has > > a precise meaning.

Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT)

Hi, Randy, On Jan 4, 2017 18:21, "Randy Bush" wrote: you are at the intersection (well actially union) of two twisty sets of passages, bgp routing and internet ops. > I'm wondering if "the transitive closure of a client's customers" has > a precise meaning. I know what a

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

>>> -4, first paragraph: I found "either" followed by "and/or" a bit >>> confusing. I suggest simply dropping the word "either". >> >>As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers >>are either capable of generating their own public/private >>key-pairs and having

[sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-pki-profiles-20: (with COMMENT)

Stephen Farrell has entered the following ballot position for draft-ietf-sidr-bgpsec-pki-profiles-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-20.txt

I believe this version addresses Stephen’s discuss points as well as the other comments I’ve picked up along the way (minus fighting with nroffedit to add references). spt > On Jan 4, 2017, at 19:58, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line

[sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-20.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests Authors

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

> On Jan 3, 2017, at 16:47, Yaron Sheffer wrote: > > Hi Sean, > > Please see below. > > On 03/01/17 18:12, Sean Turner wrote: >> Yaron, >> >> Thanks for the review. >> >> >>> On Jan 1, 2017, at 11:26, Yaron Sheffer >>> wrote: >>> >>> Reviewer: Yaron

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

In my editor’s copy. spt > On Jan 4, 2017, at 19:19, Stephen Farrell wrote: > > > Hiya, > > Yep, I guess the text below is good enough. > > Thanks, > S. > > On 04/01/17 23:56, Sean Turner wrote: >> Common name encoding options that are supported are >>

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

> On Jan 4, 2017, at 19:39, Stephen Farrell wrote: > > > Hiya, > > On 05/01/17 00:34, Sean Turner wrote: >>> -- >>> >>> > COMMENT: >>>

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

Hiya, On 05/01/17 00:34, Sean Turner wrote: >> -- >> >> COMMENT: >> -- >> >> >> >> - section 2: I think this is a bit badly written: "The use >> of BGPsec

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

> -- > COMMENT: > -- > > > - section 2: I think this is a bit badly written: "The use > of BGPsec Router Certificates in no way affects RPKI RPs > that process

Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT)

you are at the intersection (well actially union) of two twisty sets of passages, bgp routing and internet ops. > I'm wondering if "the transitive closure of a client's customers" has > a precise meaning. I know what a customer is, at the hand-waving > level the academic, overly-idealized,

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

Hiya, Yep, I guess the text below is good enough. Thanks, S. On 04/01/17 23:56, Sean Turner wrote: >Common name encoding options that are supported are >printableString and UTF8String. For BGPsec Router Certificates, it >is RECOMMENDED that the common name attribute contain the

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

Jumping here > On Jan 4, 2017, at 18:11, Stephen Farrell wrote: > > Hiya, > > On 04/01/17 22:15, Rob Austein wrote: >> At Wed, 4 Jan 2017 20:57:24 +, Stephen Farrell wrote: > (1) 3.1.1: Why MUST a CA ensure that the CA name and > Subject name combination is

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-pki-profiles-19: (with COMMENT)

On 4 Jan 2017, at 17:21, Sean Turner wrote: On Jan 4, 2017, at 18:19, Ben Campbell wrote: On 4 Jan 2017, at 16:37, Sean Turner wrote: -2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized versions of 2119 words. This draft does not. It seems different

[sidr] Ben Campbell's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

Ben Campbell has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-pki-profiles-19: (with COMMENT)

> On Jan 4, 2017, at 18:19, Ben Campbell wrote: > > On 4 Jan 2017, at 16:37, Sean Turner wrote: > >> -2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized >>> versions of 2119 words. This draft does not. It seems different 2119 >>> approaches among the

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-pki-profiles-19: (with COMMENT)

On 4 Jan 2017, at 16:37, Sean Turner wrote: -2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized versions of 2119 words. This draft does not. It seems different 2119 approaches among the various bgpsec draft could be confusing to the reader. Where’s that in

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

Hiya, On 04/01/17 22:15, Rob Austein wrote: > At Wed, 4 Jan 2017 20:57:24 +, Stephen Farrell wrote: >> On 04/01/17 20:04, Rob Austein wrote: > ... >>> This draft is a profile of RFC 6487, which is itself a profile of RFC >>> 5280. All of the above is pretty much verbatim from RFC 6487. >>

Re: [sidr] draft-ietf-sidr-bgpsec-protocol

[adding routing-ads] From: Keyur Patel Date: Wednesday, January 4, 2017 at 2:17 PM To: Jonathan Hardwick , "Alvaro Retana (aretana)" , Zhangxian Xian , Jon Hudson Cc: rtg-dir

[sidr] Ben Campbell's No Objection on draft-ietf-sidr-as-migration-06: (with COMMENT)

Ben Campbell has entered the following ballot position for draft-ietf-sidr-as-migration-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-pki-profiles-19: (with COMMENT)

> On Jan 4, 2017, at 16:07, Ben Campbell wrote: > > Ben Campbell has entered the following ballot position for > draft-ietf-sidr-bgpsec-pki-profiles-19: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

At Wed, 4 Jan 2017 20:57:24 +, Stephen Farrell wrote: > On 04/01/17 20:04, Rob Austein wrote: ... > > This draft is a profile of RFC 6487, which is itself a profile of RFC > > 5280. All of the above is pretty much verbatim from RFC 6487. > > Hmm. I wonder if that's the best plan, especially

[sidr] Kathleen Moriarty's No Objection on draft-ietf-sidr-as-migration-06: (with COMMENT)

Kathleen Moriarty has entered the following ballot position for draft-ietf-sidr-as-migration-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)

Hiya, On 04/01/17 21:39, Montgomery, Douglas (Fed) wrote: > The RPKI validating caches *are* the relaying parties for BGPsec, they are > (a) designed to be run on a separate box than the router itself and (b) > their behavior WRT exchanges with RPKI repositories is independent of BGP > message

[sidr] Ben Campbell's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

Ben Campbell has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)

The RPKI validating caches *are* the relaying parties for BGPsec, they are (a) designed to be run on a separate box than the router itself and (b) their behavior WRT exchanges with RPKI repositories is independent of BGP message processing by any of the routers that they serve. Maybe the first

[sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT)

Spencer Dawkins has entered the following ballot position for draft-ietf-sidr-bgpsec-ops-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

[sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

Mirja Kühlewind has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

Thanks for the quick response. On 3 Jan 2017, at 20:00, Randy Bush wrote: thanks for the review. Update: I noted when reviewing other sidr drafts on this telechat agenda that this draft treats 2119 keywords differently than the other drafts. That is, this draft explicitly excludes lower

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

> The issue I saw is that section 2 says readers are expected to > understand bgpsec, and cites the overview for that purpose. Perhaps it > should cite the protocol doc for the "expected to understand" part ok. done. i would be happier if that document was easier to read and more concise. i

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

On 4 Jan 2017, at 6:49, Alvaro Retana (aretana) wrote: On 1/3/17, 9:00 PM, "Randy Bush" wrote: | | -12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as | | needed to understand this document. That suggests it should be a | | normative reference. | |

Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

On Tue, Jan 3, 2017 at 6:31 PM, Randy Bush wrote: > >> ok, i have had coffee. > >> > >> as a bif gedanken experiment, posit a global registry where r0 can say > >> "i can speak bgpsec." i am a distant r1 and receive an unsigned path > >> with r0 in it. > >> o did someone before

[sidr] Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT)

Alissa Cooper has entered the following ballot position for draft-ietf-sidr-bgpsec-ops-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

[sidr] Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

Alissa Cooper has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

[sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

Spencer Dawkins has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT)

Hiya, On 04/01/17 15:44, Randy Bush wrote: >> - general: given where we are with deployment I wonder >> would it be a good idea if this document explicitly said >> sometthing to the effect that "it's early days, this is >> what we think is the BCP but that may change over time, so >> while we

Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT)

> - general: given where we are with deployment I wonder > would it be a good idea if this document explicitly said > sometthing to the effect that "it's early days, this is > what we think is the BCP but that may change over time, so > while we think doing this is right, be careful to not > paint

Re: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

> On Jan 4, 2017, at 05:09, Randy Bush wrote: > >> +1 to the comment from Suresh about order. I though that something like >> what he proposed will minimize memcopies and possibly use of memory why >> hashing. So I am also curious to know answer to his question. > > a vendor

[sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)

Stephen Farrell has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

[sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

Stephen Farrell has entered the following ballot position for draft-ietf-sidr-bgpsec-pki-profiles-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

[sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT)

Stephen Farrell has entered the following ballot position for draft-ietf-sidr-bgpsec-ops-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

On 1/3/17, 9:00 PM, "Randy Bush" wrote: | | -12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as | | needed to understand this document. That suggests it should be a | | normative reference. | | ennie meenie. i think some other reviewer had me push refs

Re: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

> +1 to the comment from Suresh about order. I though that something like > what he proposed will minimize memcopies and possibly use of memory why > hashing. So I am also curious to know answer to his question. a vendor engineer actually implementing requested the change to the current syntax

[sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

Alexey Melnikov has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to