Hi Yingzhen, Thanks for the quick response. Please see below. > [Yingzhen]: yes, this document focuses on the SR-MPLS data plane. However there is ietf-segment-routing.yang module defined as the generic frame, which is meant to be augmented by different data planes, including both SR-MPLS and SRv6. This was the consensus between the authors of this draft and authors of SRv6 YANG model. If you think the abstract and introduction is not clear, please let us know. Right. I believe this point should be clarified in the introduction with an informative reference to the SRv6 YANG draft. > [Yingzhen]: for ingress/egress nodes, do you mean SR policy? which is defined in a separate draft: https://tools.ietf.org/html/draft-raza-spring-sr-policy-yang-03 Right, again I suggest to clarify this point in the draft. Cheers, Tal. On Tue, Dec 8, 2020 at 10:13 PM Yingzhen Qu <yingzhen.ietf@xxxxxxxxx> wrote: > > Hi Tal, > > Thank you for your review and comments, we have published version -29 to address your comments. Please see my detailed answers below inline. > > Thanks, > Yingzhen > > On Tue, Dec 8, 2020 at 3:52 AM Tal Mizrahi <tal.mizrahi.phd@xxxxxxxxx> 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-sr-yang-28 >> Reviewer: Tal Mizrahi >> Review Date: 08-Dec-2020 >> Intended Status: Standards Track >> >> >> Summary: >> I have some minor concerns about this document that I think should be >> resolved before publication. >> >> >> Comments: >> The document defines a YANG data model for MPLS segment routing. The >> document is in good shape, and I believe it is almost ready for >> publication. >> >> My comments are mainly about the need for a clear definition of the >> scope of the document. While these comments do not require major >> changes in the document, a bit of rephrasing and clarifying text will >> go a long way here. >> >> >> Issues: >> - The document is focused on SR-MPLS, while RFC8402 discusses both >> SR-MPLS and SRv6. I am sure there is a good reason for this, but it is >> important to point out at the very beginning of the document that it >> does not cover SRv6 and preferably also the reason for this. > > > [Yingzhen]: yes, this document focuses on the SR-MPLS data plane. However there is ietf-segment-routing.yang module defined as the generic frame, which is meant to be augmented by different data planes, including both SR-MPLS and SRv6. This was the consensus between the authors of this draft and authors of SRv6 YANG model. If you think the abstract and introduction is not clear, please let us know. > >> >> - It is important to clarify the scope of the YANG models in the >> introduction: do they refer only to SR routers, or also to SR >> ingress/egress nodes? > > > [Yingzhen]: for ingress/egress nodes, do you mean SR policy? which is defined in a separate draft: https://tools.ietf.org/html/draft-raza-spring-sr-policy-yang-03 > >> >> - The Common Types module is mentioned for the first time in Section >> 8. It would be appropriate to mention it and describe its purpose in >> Section 3. > > > [Yingzhen]: Good suggestion. I added a small paragraph for the common yang module. > >> >> - In the following text it would be more accurate to replace: "with >> Segment Routing (SR)." ==> "with MPLS Segment Routing (SR)." >> >> "This augments routing data model (RFC 8349) >> with Segment Routing (SR)."; >> > [Yingzhen]: fixed. > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
