I concur and I’ve got an editor’s copy with all the changes incorporated. Unless I hear otherwise I’ll hold off on posting until we’ve collected and addressed all of the other IETF LC comments.
spt > On Dec 05, 2016, at 11:37, Steve KENT <[email protected]> wrote: > > 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) <[email protected]> > Sent: Sunday, December 4, 2016 7:58:20 AM > To: [email protected] > Cc: [email protected]; Chris Morrow; [email protected] > 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. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
