Subject: [Sidrops] Mirja Kühlewind's No Objection on draft-ietf-sidrops-bgpsec-rollover-03: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 07 Nov 2017 06:14:19 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-sidrops-bgpsec-rollover-03: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-rollover/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This document really reads like it should be an informational document, or
maybe a BCP. Further, the shepherd write-up says "Internet Standard final
status" but I see Proposed Standard in the datatracker...? I would recommend to
go for BCP if the wg can agree to that.

Also, should ietf-sidr-rtr-keying maybe be a normative reference, or is this
just one example? The use of this reference in section 3.1 isn’t clear to me
with this respect: „The key rollover process is dependent on the key
provisioning mechanisms adopted by an AS [I-D.ietf-sidr-rtr-keying].“

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Tue, 28 Nov 2017 01:48:12 +0000

Hi Mirja,

Thanks for your review. Please see replies prefaced with BEW:

> On Nov 7, 2017, at 6:14 AM, Mirja Kühlewind <[email-masked]> wrote:
> 

BEW: The original intended status was Proposed Standard. Specifying a status of BCP seems 
reasonable to me. I don’t have any objection to such a change if the WG wishes it.  

> provisioning mechanisms adopted by an AS [I-D.ietf-sidr-rtr-keying].“

BEW: Upon reflection, I agree this reference should be normative. Thanks.

Thanks,
Brian

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

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 28 Nov 2017 07:10:37 -0800

On November 27, 2017 at 8:48:20 PM, Brian Weis (bew) ([email-masked]) wrote:

Hi!

> go for BCP if the wg can agree to that.

BEW: The original intended status was Proposed Standard. Specifying a
status of BCP seems
reasonable to me. I don’t have any objection to such a change if the WG
wishes it.

Given that the document describes a process I would have leaned towards BCP
as well…but BGPSec is not deployed, so that seems a little too much as it
wouldn’t really be documenting the “best current practice”.

FWIW, I’m fine leaving the status as is in hopes that the process will be
used if/when BGPSec is deployed.  I wouldn’t object to Informational either.

This saves me a DISCUSS. ;-)

Thanks!

Alvaro.

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Tue, 28 Nov 2017 17:08:32 +0000

Hi Alvaro,

Thanks for your note. Comments are referenced with BEW:.

On Nov 28, 2017, at 7:10 AM, Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:

On November 27, 2017 at 8:48:20 PM, Brian Weis (bew) ([email-masked]<mailto:[email-masked]>) wrote:

Hi!

Given that the document describes a process I would have leaned towards BCP as well…but BGPSec is not deployed, so that seems a little too much as it wouldn’t really be documenting the “best current practice”.

FWIW, I’m fine leaving the status as is in hopes that the process will be used if/when BGPSec is deployed.  I wouldn’t object to Informational either.

BEW: I think it’s still fair to plan for BGPsec to be deployed, and so standards track would be a reasonable status.

BEW: Thanks! For the record, based on Alexey’s comment I reviewed the rest of the informative references, and I believe [I-D.ietf-sidr-rtr-keying] is the only one that should be promoted to normative.

Thanks,
Brian

Thanks!

Alvaro.

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