I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is Ready. I have a few purely editorial suggestions below. I also have a question which is perhaps out of scope for the review of this document, which is why I say ready as opposed to with nits or almost ready. The document explains that BGPsec is a new protocol that will be deployed over years. Is there a plan or intent to update this document as the community gains experience? The Introduction section is great with pointers to relevant documents. We need to do more of that kind of thing. My nits follow, and all are optional, in the hopes of increasing clarify. Section 1: BGPsec need be spoken only by an AS's eBGP speaking, AKA border, routers, I suggest the following (if I got the meaning right); hyphenate and use or not AKA BGPsec need be spoken only by an AS's eBGP-speaking, or border, routers, Should section 2 be merged into section 1? ROA should be spelled out when first used. Section 4, "A large operator ... may accept" Perhaps deploy, not accept? I think the "On the other extreme" is redundant and could be removed. Section 5 change the comma to a colon in the first sentence? In "The operator should be aware..." change to "An" ? Similarly in section 6, "Operators might need to ..." Change to "An operator"? This is part of having overall consistency about one/the/an operator reference. A level of nit we don't ordinarily think about :) Section 7, spell out iBGP at first use? Section 9, perhaps add a sentence like: "This document outlines some of the operational issues defined there" or some such. Section 11, are you thinking three parties or two? If three, put the design group last; if two, put the two names in parens. Thanks for writing this.