Reviewer: Tero Kivinen Review result: Has Issues 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 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
