I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is 'Ready'.

draft-ietf-ccamp-layer1-types specifies a YANG module for describing the common data types, groupings and identities for use in YANG [RFC7950] data models of Layer 1 networks, such as for example Optical Transport Networking.

The security section asserts that potential security issues do not derived from the particulars of the Yang modules, but from potential unauthorized access to the data and unauthorized modification of the data. Access is expected to be protected using either SSH for NETCONF or HTTPS for RESTCONF, as per standard practice. I would not expect a Yang module to state anything else. 

I do not have enough expertise in Optical Transport Networking and other Layer 1 networks to evaluate the details of the specification. I assume that other reviewers will conduct such specialized review.

And now, a side remark, not related to this specific document but applying to the general practice of saying "just use NETCONF with SSH or RESTCONF with TLS", but SSH and HTTPS support a variety of authentication mechanisms. SSH, for example, can authenticate a client using a public key, a password, a host identity, or even nothing. HTTPS has a similar range of options. Some of those options are much more vulnerable than others -- password based authentication, for example, is vulnerable to phishing attacks and password reuse. 

The NETCONF and RESTCONF specifications leave the choice of authentication to the organization deploying the Yang based management, with statements like "the identity of the SSH client MUST also be verified and authenticated by the SSH server according to local policy". I did not find a specification of what the local policy should be. It would be nice if the safety of network infrastructure could not be defeated by a password-based attack, or other simple attacks. It might be useful to do some work here, and provide practical guidance on the deployment of strong authentication mechanisms.