Matt, Thanks for all your efforts and time in keeping this I-D updated. Some technical and some editorial comments on the new version 10 follow.
Technical comments: 1. At the top of sec. 5.1, say something like – Here we focus only on validation of BGPSEC_Path or Secure_Path attribute. And refer to RFC 6811 for the recommended origin validation algorithm. 2. In sec. 5.1 and 5.2, wherever there is mention of validation of *BGPSEC update message*, it should be replaced by “validation of BGPSEC_Path (or Secure_Path or Signature_Block). 3. In sec. 7 (Security Considerations), the vulnerability to replay attacks is currently not mentioned? Should it be mentioned? Editorial comments: 1. Some references to Internet Drafts have old dates (not showing the actual updated dates). 2. Perhaps RFC 6811 should be a normative reference. 3. p. 5, 1st para: “A BGP speaker SHOULD NOT advertise the capability of BGPSEC support for a particular AFI unless it has also advertised the multiprotocol extension capability for the same AFI combination [3].” s/ a particular AFI/ a particular set of AFIs/ 4. p. 7, para 1: s/in the same way/ in a similar way/ 5. The following sentence is repeated on pages 6 and 7: “A BGPSEC update message containing the BGPSEC_Path attribute MUST NOT contain the AS_PATH attribute.” 6. p. 7, para 2: s/for one AS number/for each AS number/ 7. p. 7, para 2: s/secure path segment/ Secure_Path segment/ 8. p. 8, para 4: “(The pCount field is also useful in managing AS Number migrations, see [18] for details.)” Could be replaced with: (The pCount field is also useful in managing route servers (see Section 4.2) and AS Number migrations, see [18] for details.) 9. p. 10, para 2: “When originating a new route advertisement and sending it to an internal peer, the BGPSEC speaker creates a new BGPSEC_Path attribute with zero Secure_Path segments and zero Signature Segments.” This sentence is a bit verbose. There is no BGPSEC_Path attribute if it has zero Secure_Path segments and zero Signature Segments. So why not reword it simply as: “When originating a new route advertisement and sending it to an internal peer, the BGPSEC speaker sends only the NLRI (to an iBGP peer).” 10. The last paragraph on p.11 and the top two paragraphs on p.12 can be moved to the preamble of Section 4 (to a spot just before start of Sec. 4.1). This is because these three paragraphs are generally applicable to both Sections 4.1 and 4.2. 11. p.13, 2nd last para: s/ to the RPKI router corresponding to the BGPSEC speaker / to the RPKI router *certificate* corresponding to the BGPSEC speaker/ 12. p.16, para 2: s/ in the Subject Key Identifier extension of the RPKI router corresponding to / in the Subject Key Identifier extension of the RPKI router *certificate* corresponding to/ 13. p.17, last para: s/ the most recently added Secure_Path *segments*/ the most recently added Secure_Path *segment*/ (make “segments” singular) 14. p 18, para 3: s/ for a signature produced by a BGPSEC speaker outside of a confederation/ for a signature produced by a *peer* BGPSEC speaker outside of a confederation/ 15. In Sections 5.1 and 5.2, search “update message” and see if it should be replaced by “BGPSEC_Path attribute” or Secure_Path” or “Signature_Block” as the case may be. (In the context of validation) 16. p.28, 3 rd last para: s/ A BGPSEC speaker/ a BGPSEC speaker/ (should be lower case A) Sriram _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
