Thanks Matthew
On Wed, Feb 2, 2022 at 5:37 PM Bocci, Matthew (Nokia - GB) < [email protected]> wrote: > Hi Ketan > > > > Thanks for your quick response. > > > > Matthew > > > > *From: *Ketan Talaulikar <[email protected]> > *Date: *Saturday, 29 January 2022 at 05:33 > *To: *Bocci, Matthew (Nokia - GB) <[email protected]> > *Cc: *<[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] <[email protected]>, > [email protected] < > [email protected]> > *Subject: *Re: RtgDir Last Call review: > draft-ietf-spring-segment-routing-policy-14 > > Hi Matthew, > > > > Thanks for your detailed review and please find responses inline below. > > > > Also, we've posted an updated version to address your comments. Request > you to please check and let us know your feedback. > > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-16 > > > > > > MB> Thanks. This looks good to me. See below for some additional responses. > > > > On Fri, Jan 28, 2022 at 5:21 PM Bocci, Matthew (Nokia - GB) < > [email protected]> wrote: > > Hello, > > > > I have been selected as the Routing Directorate reviewer for this draft. > > The Routing Directorate seeks to review all routing or routing-related > > drafts as they pass through IETF last call and IESG review, and > > sometimes on special request. The purpose of the review is to provide > > assistance to the Routing ADs. For more information about the Routing > > Directorate, please see > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > > Although these comments are primarily for the use of the Routing ADs, it > > would be helpful if you could consider them along with any other IETF > > Last Call comments that you receive, and strive to resolve them through > > discussion or by updating the draft. > > > > Document: draft-ietf-spring-segment-routing-policy-14 > > Reviewer: Matthew Bocci > > Review Date: 28 January 2022 > > Intended Status: Standards Track > > > > Summary: > > > > In general, this is a well written document. Thank you. > > > > However, I have some minor concerns about this > > document that I think should be resolved before publication. This mostly > revolve around > > the clarity of the document and the use (or lack thereof) of RFC2119 > language. > > > > Comments: > > > > Major Issues: No major issues found > > > > Minor Issues: > > > > 1) This is a standards track document, but in general I found that clear > specification language > > is missing. For example, in section 2.3: "A headend may be.." Should this > be "A headend MAY be..."? > > There are many other cases like this where MUST/SHOULD/MAY would be better > used rather than > > 'is' or 'can'. > > > > KT> Ack. Fixed in some places and please let us know if we've missed any. > > > > > > 2) The references to control planes for provisioning and maintaining SR > Policies are only > > informational, but they are referred to in a manner in the text that I > read as normative > > (although the language is not always clear). For example, in section 2.5: > "When signaling > > is via PCEP..." and then the paragraph refers to an informative reference > to the > > PCE draft for the SR policy control plane. Given that this is a standards > track architecture > > document, it would be much better to be clear about what the normative > parts of the > > architecture are. If these parts are not normative (for example even if I > use BGP it is not > > mandatory to use it according to a particular specification) then please > be explicit > > and use 'MAY' or 'SHOULD'. > > > > KT> Given that this is an architecture document, it describes the > architecture and not really the protocol mechanisms. This is in line with > other SPRING documents. The normative language for the BGP mechanism is in > the IDR document. The informative references, in this document, to those > protocol mechanisms are only to give a better reference/info to the reader. > > > > MB> I agree you have followed the precedent of the SR architecture > (RFC8402), so I am OK with that. > > > > 3) Section 2.2: Candidate Path and Segment List. This section describes a > hierarchical > > relationship between composite candidate paths, SR Policies, candidate > paths, and segment lists. > > It would be much clearer if you could provide a diagram illustrating this > hierarchy. > > > > KT> The sec 2.13 illustrates this. We will add a forward reference to it > in Sec 2.2. > > > > MB> Thanks. That helps. > > > > 3) Terminology section. Since this draft > > is really the overall guide to all things SR Policy, it would really help > to include a > > terminology section summarising new terms and acronyms. > > > > KT> The document currently describes the constructs in the flow. A > terminology section would just end up repeating the text up front and > without proper context. I prefer to keep the current structure. If there is > any specific terminology that you believe is better dealt with in the > Terminology section, please let us know. > > MB> Accepted > > > > > > Nits: > > > > 1) The definite/indefinite article ('the', 'a', etc) is missing from the > text in many places. > > I would suggest going through the text carefully and correcting these > issues. > > > > KT> Ack. Fixed in a few places. Please let us know if any others were > missed out. > > > > > > 2) Section 2.13: > > > > In the information model: > > > > SR policy POL1 <headend = H1, color = 1, endpoint = E1> > > Candidate-path CP1 <protocol-origin = 20, originator = > > 100:1.1.1.1, discriminator = 1> > > Preference 200 > > Priority 10 > > Weight W1, SID-List1 <SID11...SID1i> > > Weight W2, SID-List2 <SID21...SID2j> > > ^^^^^^^^^ > > > > These are referred to as segment lists in the main text, so maybe you > should align the > > terminology. > > > > KT> Ack. Fixed. > > > > > > Section 4: Segment Types. > > Type A: SR-MPLS Label: "...Additionally, reserved labels..." These are now > commonly > > referred to in MPLS as "special purpose labels". > > > > > > KT> Ack. Fixed. > > > > Thanks, > > Ketan > > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
