Hello,

I have been selected as the Routing Directorate reviewer for this
draft. The Routing Directorate seeks to review all routing or
routing-related drafts as they pass through IETF last call and IESG
review, and sometimes on special request. The purpose of the review is
to provide assistance to the Routing ADs. For more information about
the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Last Call comments that you receive, and strive to resolve them
through discussion or by updating the draft.

Document: draft-ietf-sidrops-rtr-keying-01
Reviewer: Dhruv Dhody
Review Date: 14 Dec 2018
IETF LC End Date: Unknown
Intended Status: Standard

Summary:

   I have some minor concerns about this document that I think should be
   resolved before publication.

Comments:

   This document describe the provisioning of BGPsec-speaking routers with the
   appropriate public-private key-pairs. It describes two ways - Router Driven
   and Operator Driven of doing this. This document does not provide any
   protocol extensions.

   Thank you for including Appendix B, it helped a lot.

Major Issues:

   No major issues found.

Minor Issues:

   (1) I am not sure about the status of the document. Since this document
   does not define any protocol extensions, this document reads to me as
   Informational or BCP. I am quite sure this is going to be asked during IESG
   reviews, it would be good idea to discuss and conclude on this early on.

   (2) I also find 'sub-methods' to describe the two different mechanism (or
   models) as incorrect.
   Also, did the authors/WG consider making Router-driven as default and
   operator-driven to be used with utmost care and only when router-driven is
   not possible?

   (3) Introduction mentions only Section 8, suggest to include some more text
   that describes the flow of the document to increase the readability.

   (4) Section 4/5 used AS number and the BGP Identifier; where as Appendix B
   says subject name and serial number for the router. We should link these
   somehow.

   (5) Section 5.2.1 has 'AS's End Entity (EE) private key' and AS's EE
   certificate(s); This is not clear, is this 'AS's key and certificate'
   belongs to the management station? Can you add a sentence clarifying this.

   (6) It feels like, this document uses SHOULD as a default level. I am not
   sure if that is right in every instance of its use.

Nits:

   - section 4
     s/a BGP Identifier of 0 may be used/a BGP Identifier of 0 MAY be used/
   - section 5
     s/transmits the AS it has chosen or the router/transmits the AS
it has chosen on the router/
   - section 7
     s/certs-ony/certs-only
   - section 9
     Took me a while to parse this, might be helpful to make a list or
     rephrase -

         When an active router key is to be revoked, the process of requesting
         the CA to revoke, the process of the CA actually revoking the
         router's certificate, and then the process of re-keying/renewing the
         router's certificate, (possibly distributing a new key and
         certificate to the router), and distributing the status, takes time
         during which the operator must decide how they wish to maintain
         continuity of operations, with or without the compromised private
         key, or whether they wish to bring the router offline to address the
         compromise.

   - section 10
     Does not parse -

         ..employees that no longer need access to a
         routers SHOULD be removed the router to ensure only those authorized
         have access to a router.