Subject: [spring] Ben Campbell's No Objection on draft-ietf-spring-segment-routing-central-epe-07: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Dec 2017 20:00:53 -0800

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.)

 - 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.

---

From: "Gaurav Dawra (gdawra)" <[email-masked]>
Date: Tue, 19 Dec 2017 08:59:49 +0000

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-masked]> wrote:

    
    
    Substantive Comments:

<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>

<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>

    - 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>