This is YANG model providing configuration and information about Attachment
Circuits.

The section 5.2.5.5 describes the security parts, but it is mostly
content free, I mean I have no idea what it would mean if you say
encryption is enabled on L2, or L3. What protocol is going to provide
that security? On L2 it will depend on the link type, but also on L3 I
think there can be multiple options.

What does the encryption-profile-reference mean? Where does it provide
reference to? I would assume that reference would point quite
different places depending whether your encryption is provided by L2
or L3 etc.

I have no idea how someone would implement security based on the data
available on 5.2.5.5 security tree...

On the other hand usually security is not configured through YANG
models anyways as security people do not want to put their config in
YANG models.

This means it might better to just remove extra configuration based
stuff from this YANG model and just say that security configuration
comes from somewhere else, than try to add so much stuff here that it
would actually allow configuring the security layer.

--

In the security considerations it already lists customer-point as one
of those subtrees that might include sensitive information, but 
I think locations subtree can also include similar data than
customer-point and should be listed as sensitive. 

--

Nits:

1.1.  Scope and Intended Use

   Connectivity services are provided by networks to customers via
   dedicated terminating points, such as Service Functions (SFs)
   [RFC****], Customer Edges (CEs), peer Autonomous System Border
...
   This document adheres to the definition of an Attachment Circuit as
   provided in Section 1.2 of [RFC****], especially:
...

For people who are not familiar of all mappings from the random RFC
numbers to titles of the RFCs it would be better to make sure that
each any RFC number is referenced you also expand the short title for
the document. 

Same is true throughout the whole document. There are several cases
where the RFC titles are already there, but some cases they are
missing, so adding them in all cases would be good.

--

   exposed in the AC service model.  However, these details are exposed
   at the network model per [I-D.xxxx].
   [I-D.yyyyy] specifies augmentations to the

Same for the internet draft names, as those might get changed to RFC
numbers in the future.

--

5.2.5.5.  Security

   encryption to be applied to traffic for a given AC.  Tthe model can

Typo Tthe