Hey Ben, Thanks a lot for your review. Many thanks and much appreciated!
Please see inline <Gaurav>. Regards, Gaurav On 12/13/17, 8:00 PM, "Ben Campbell" <[email protected]> wrote: Ben Campbell has entered the following ballot position for draft-ietf-spring-segment-routing-central-epe-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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.) <Gaurav> This document Illustrates: . Applicability of SR to solve the BGP EPE problem. . Best practices and set of requirements for protocol and architecture design to achieve such solution. . SR features and other component interactions needed. . Example to distribute EPE information using BGP-LS . Inputs into BGP-EPE Controller to make policy decision. </Gaurav> - 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. <Gaurav> Will update the language in next revision to state following: Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted to define as requirements for protocol and architecture design. </Gaurav> -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. <Gaurav> There is no new security consideration originated as part of the EPE solution illustration. Any new Security consideration is covered as part of the BGP-LS extension document. That’s why this document just refers to the BGP-LS document. I can remove the text in this section and just mention “No new security consideration”. </Gaurav> 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. <Gaurav> Intent was to describe the structure and each section covers more details. Below nits are fixed </Gaurav> -2, first paragraph: missing article before "BGP-EPE capable node" -4.6: I can't parse the first sentence. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
