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

[Steve KENT <[e-mail]>]

Alvaro,


Thanks for the careful review.


I agree with your suggested edits cited in C2, C3, C4, C6, C7, C8, C9, and C10.


C1: yep, this sentence is broken in a few ways. How about:

"A router holding the private key is authorized to send

   route advertisements (to its peers) identifying the router's ASN as the source of the advertisements.


C5: The allusion to future updates is in anticipation of adopting the relaxed validation procedure that SIDR is about to forward to you. Still, the wording is poor" how about: "…is identical to the validation procedure described in Section 7 of [RFC6487] (and any RFC that updates this procedure), as modified below."


C11: yes, my name should be removed from the Acknowledgements section.


I'll rely on Sean to make these changes, if he concurs.


Steve

________________________________
From: Alvaro Retana (aretana) <[e-mail]>
Sent: Sunday, December 4, 2016 7:58:20 AM
To: [e-mail]
Cc: [e-mail]; Chris Morrow; [e-mail]
Subject: AD Review of draft-ietf-sidr-bgpsec-pki-profiles-18

Dear authors:

Hi!  I just finished reading this document.

I have some comments (please see below) I would like you to address, but I wouldn’t characterize any of them as major, so I’m starting the IETF Last Call and placing this document in the next available IESG Telechat.

Thanks!

Alvaro.


Comments:

C1. From the Introduction: “A router holding the private key is authorized to send route advertisements (to its peers) that contain one or more of the specified AS number as the last item in the AS PATH attribute.”  First of all, if BGPSec is used, then the AS_PATH attribute is not.  Second, what does “one or more of the specified AS number as the last item” mean?  There is only one “last item”…but I’m guessing you might be referring to pre-pending.

C2. “Border Gateway Protocol Security protocol (BGPsec)”  I haven’t seen BGPsec expanded anywhere else like that.  In fact, ID.sidr-bgpsec-protocol just used BGPsec (no expansion).

C3. s/ID.sidr-rfc6485bis/rfc7935

C4. In Section 3.1.3.2. (Extended Key Usage): “As specified in [RFC6487] this extension MUST be marked as non-critical.”  Because the behavior was specified in RFC6487, then the “MUST” shouldn’t be Normative here; s/MUST/must

C5. Section 3.3. (BGPsec Router Certificate Validation) says that the “validation procedure…is identical to the validation procedure described in Section 7 of [RFC6487] (and any RFC that updates this procedure), but using the constraints applied come from this specification.”  It Is strange to me that the phrase inside the parenthesis is included here since there isn’t an update to the procedure – is there a specific reason why you need to call future (unknown) updates out at this point?   BTW, s/using the constraints applied come from this specification/using the constraints from this specification

C6. References.
- RFC6818 can be made Informative.
- RFC6486 and ID.sidr-bgpsec-protocol should be Normative.

C7. s/to an Internet Service Providers (ISP)/ to an Internet Service Provider (ISP)

C8. s/The CA also generate./  (orphan phrase)

C9. s/The [RFC6480]/[RFC6480]

C10. s/3.1.1.1./3.1.1.

C11. “…the efforts of Steve Kent…were instrumental in preparing this work”  Steve is an author.