Subject: [Sidrops] AD review of draft-ietf-sidrops-bgpsec-rollover

From: Warren Kumari <[email-masked]>
Date: Tue, 3 Oct 2017 09:44:28 -0700

Hello,

Thank you to the editors and WG for your efforts on
this document, it's a well written and easy to understand
draft.  I do have a few comments that I’d like addressed
before I start IETF LC — addressing these now will avoid
issues later in the process.

Questions:
1: Section 2.  Introduction
"This document provides general recommendations for that process.
Certificate Practice Statements (CPS) documents MAY reference these
recommendations."

I do not understand the use of a 2119 MAY here -- can it be made
lowercase instead? I really don't understand what it is trying to
accomplish.

2: 3.1.  A proposed process for BGPsec router key rollover
"If there is no staging period, routing information may be lost."
I do not have any better text to suggest, but I don't really think
that routing information gets "lost" - when the session is fixed, the
information still gets through -- perhaps "routing may be disrupted"?

My comments are mostly editorial nits.
1: There are some IDNITs -- a number of the drafts are now RFCs:
== Outdated reference: draft-ietf-sidr-bgpsec-ops has been published as RFC
     8207

== Outdated reference: draft-ietf-sidr-bgpsec-protocol has been published
     as RFC 8205

== Outdated reference: draft-ietf-sidr-rpki-rtr-rfc6810-bis has been
     published as RFC 8210

2: Section 3.  Key rollover in BGPsec
   "An BGPsec router certificate SHOULD be replaced ..."
s/An/A/

2: Section 3.  Key rollover in BGPsec
"Protection against withdrawel supporession and replay attacks"
 -- typos in "withdrawel" and "supporession"

3: Section 3.1.  A proposed process for BGPsec router key rollover
"However, If an administrator"
s/If/if/

4: Section 6.  Security Considerations
"When certificates containing a new public key are provisioning ahead"
s/provisioning/provisioned/

Please let me know once these are addressed, so I can start LC.

Thanks again,
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Tue, 3 Oct 2017 22:09:09 +0000

Hi Warren,

Thanks for your careful review.

On Oct 3, 2017, at 9:44 AM, Warren Kumari <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

Questions:

Hmmmm, since the subject of the MAY is not this document (i.e., is the CPS),
then use of requirements language does seem improper. We’ve changed
this to lower case as suggested.

information still gets through -- perhaps "routing may be disrupted”?

Yes, “routing may be disrupted” was the intent. We’ve replaced this phrase with
"routing may be disrupted due to the inability of a BGPsec router to validate
BGPsec updates signed with a new private key"

Ack … these RFCs were published after our -01 was published.

All fixed.

Done. <https://tools.ietf.org/html/draft-ietf-sidrops-bgpsec-rollover-02/<https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-rollover/>>.

Thanks!
Brian

Thanks again,
W

--
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]<mailto:[email-masked]>

---

From: Warren Kumari <[email-masked]>
Date: Tue, 3 Oct 2017 15:32:45 -0700

Excellent.

Thank you, I kicked off LC.
W

On Tue, Oct 3, 2017 at 3:09 PM, Brian Weis (bew) <[email-masked]> wrote:
> On Oct 3, 2017, at 9:44 AM, Warren Kumari <[email-masked]> wrote:
>
> Hello,
>
> Done. <https://tools.ietf.org/html/draft-ietf-sidrops-bgpsec-rollover-02/>.
>
> Thanks!
> Brian
>
>
> Thanks again,
> W
>
>
> --
> Email: [email-masked]