Segment Routing Centralized BGP Egress Peer Engineering
draft-ietf-spring-segment-routing-central-epe-10

Substantive Comments:

- General: The purpose of this draft is not clear. It claims to describe a solution in places. It's not clear to me if this is a "solution", a set of requirements, or a general exploration of the design possibilities. The shepherd writeup doesn't really help, since it explicitly says this draft describes a "solution", which is usually more of a standards track thing.  I don't mean to say that I think it should not be informational, but a description of _why_ it's informational (in the draft itself) would be helpful. (This is further confused by the heavy use of language like "might", "could be", "likely", etc. throughout parts of the draft.)

 - Requirements Language: The 2119 keywords in this draft are not used in the sense of RFC 2119. That RFC talks explicitly about interoperability among protocol implementations. This draft uses them to define requirement for protocol and architecture design. That's not necessarily a problem, but please change the Requirements Language section to describe the actual usage.

-10: The security considerations are entirely made up of citations to the underlying technology drafts. It should also talk about whether there are new security considerations introduced by there use in the context of this draft. Even if the answer is that there aren't any, it would be helpful to describe the thought processes that lead to that conclusion.

Editorial Comments and Nits:

- 1: The introduction is not really an introduction. I expected to find a description of the purpose of the draft, but all there is is a description of the draft structure.
-- Please expand "SID" on first mention.

-2, first paragraph: missing article before "BGP-EPE capable node"

-4.6: I can't parse the first sentence.

Thanks for your work on this draft.  I agree with Ben's first comment in that the purpose and continued flow of the draft aligned to that purpose could be made more clear.