Last Call Review of draft-ietf-ccamp-l1csm-yang-19
review-ietf-ccamp-l1csm-yang-19-rtgdir-lc-farrel-2022-11-16-00

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 https://trac.ietf.org/trac/rtg/wiki/RtgDir

This review takes place in support of CCAMP working group last call.

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-ccamp-l1csm-yang-19
Reviewer: Adrian Farrel
Review Date: 15 November 2022
IETF LC End Date: Not yet started
Intended Status: Draft Standard

Summary:

This document is basically ready for publication but has nits that should be
considered prior to publication.

Comments:

I did a review of this document at -17, discussed my comments with the
authors, and see that everything was addressed in -19. This review is
of -19.

This document is simple and clear. There are no quality or readability issues.

== Nits ===

1.1

s/using Customer Service/using a Customer Service/

---

1.5

I don't think "EP End Point" is used in the document.

I also don't think
   P Protocol
   C Coding
   O Optical Interface
are used in the document. There is a use of "P" in Figure 1 and 2, but
I doubt you mean "Protocol" in those cases.

But the descrption for protocol-coding-optical-interface has
   "The 3-tuple <p,c,o> where p:protocol type;
    c:coding function; o:optical interface function.
Given that you explain p, c, and o in that text, I don't think you need
them in the abbreviations section.

---

2.

s/The L1CSM YANG data model/The L1CSM/

---

4.

       container endpoint-1 {
         description
           "One end of UNI id's - string and id";

I think this description might be mangled. Possibly...

           "The identifier of one end of the point-to-point connectivity.
            Identifier string and UNI ID.";

---

4.

         leaf uni {
           description
             "This is one end of subscriber L1VC end point ID value =
              UNI-1";
         }

I think this description might be mangled. Possibly...

             "This is the UNI ID of one end of the subscriber L1VC.";

---

4.

       container endpoint-2 {
         description
           "One end of UNI id's - string and id";

I think this description might be mangled. Possibly...

           "The identifier of the other end of the point-to-point
            connectivity. Identifier string and UNI ID.";

---

4.

         leaf uni {
           description
             "This is one other end of subscriber L1VC end point
              ID value = UNI-2";

I think this description might be mangled. Possibly...

             "This is the UNI ID of the other end of the subscriber
              L1VC.";

---

4.

     container l1-connectivity {
       container access {
         container unis {
           description
             "The list of UNI's to be configured";

s/UNI's/UNIs/

---

4.

     container l1-connectivity {
       container access {
         container unis {
           list uni {
             leaf uni-id {
               description "The UNI id of UNI Service Attributes";

s/id/ID/

---

5.

You have...

   unis:

   - id

   Service:

   - service-id

I think that either:
- s/unis/uni/
  and
  s/Service/service/
or:
- s/Service/services/

---

Appendix A

s/describe the UNI endpoints/describe the connection endpoints/