[CCAMP] Review of draft-ietf-ccamp-l1csm-yang

[Adrian Farrel <[e-mail]>]

Hi authors of draft-ietf-ccamp-l1csm-yang,
This is a drive-by review of your work.

It's good to see that L1VPN is alive and well :-)

Best,
Adrian

====

Abstract
Clean up the English as...

OLD
   This document provides a YANG data model for Layer 1 Connectivity
   Service Model (L1CSM).  The intent of this document is to provide a
   Layer 1 service model exploiting YANG data model, which can be
   utilized by a customer network controller to initiate a service
   request connectivity as well as retrieving service states toward a
   Layer 1 network controller communicating with its customer network
   controller.  This YANG model is NMDA-compliant.

NEW
   This document provides a YANG Layer 1 Connectivity Service Model
   (L1CSM).  This model can be utilized by a customer network controller
   to initiate a connectivity service request as well as to retrieve
   service states for a Layer 1 network controller communicating with
   its customer network controller.  This YANG model is NMDA-compliant.
END

---

1.

OLD
   This document provides a YANG data model for L1VPN Connectivity
   Service Model (L1CSM) which can be classified as Network Service YANG
   module per [RFC8199].  The intent of this document is to provide a
   transport service model exploiting YANG data model, which can be
   utilized by a client network controller to initiate a service request
   connectivity request as well as retrieving service states toward a
   transport network controller communicating with the client controller
   via a NETCONF [RFC8341] or a RESTCONF [RFC8040] interface.
NEW
   This document provides a YANG Layer 1 Connectivity Service Model
   (L1CSM) which can be classified as Network Service YANG module per
   [RFC8199].  This model can be utilized by a customer network
   controller to initiate a connectivity service request as well as to
   retrieve service states for a Layer 1 network controller 
   communicating with its customer network controller via a NETCONF 
   [RFC8341] or a RESTCONF [RFC8040] interface.
END

---

1. To avoid the confusion between "model" and "model"!

OLD
   It classifies service
   models as management-based service model, signaling-based service
   model (Basic Mode) and signaling and routing service model (Enhanced
   Mode).
NEW
   It classifies the
   provision of L1VPN services into three service models (not to be 
   confused with YANG models): the management-based service model, the 
   signaling-based service model (Basic Mode), and the signaling and
   routing service model (Enhanced Mode).
END

---

1.

s/Signaling and routing/signaling and routing/
s/describe L1CS YANG model/describe the L1CSM/

---

1. 

This section should end with...

   This YANG model is NMDA-compliant.

---

Section 1.1 and the caption for Figure 1 appear to use a different name
for the YANG model in this document. Is that intentional or some legacy
text?

---

1.1

s/department(s)/departments/

---

I think that Section 2 can become 1.5 and be renamed "Abbreviations"

---

3.

Isn't it customary in the section that includes the tree structure to
also provide some brief explanation of the branches and important leaf
nodes? Or maybe in another section.

---

YANG model....

It might be nice if 'id' was renamed 'uni-id' consistent with 
'service-id'.

Can you confirm that there isn't a need for an OIF flavour of 
'uni-access-type'

You talked a lot in the preamble about L1VPN, but when it comes down to
it, the YANG model only models a P2P connection. This *is* consistent 
with the name of the model, but is confusing in the context of the 
L1VPN. Unless I missed the fact that there may be a higher layer service
model that the customer uses to request an L1VPN (L1SM) and the model in
this document is how the service orchestrator composes the L1VPN out of
P2P connections?

Please move the note about XXXX/YYYY above or next to the first mention
(which is of YYYY in the import clause).

---

Section 6

Rather than a proposal, you should phrase this section as an explicit 
request to IANA.