Hi Tero, (apologies for the delay to reply as I was out of office). Thanks for the review. An attempt to address your review can be seen at: https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-attachment-circuit.txt&url_2=https://boucadair.github.io/attachment-circuit-model/Tero-Kivinen-Review/draft-ietf-opsawg-teas-attachment-circuit.txt. Please see inline. Cheers, Med > -----Message d'origine----- > De : Tero Kivinen via Datatracker <noreply@xxxxxxxx> > Envoyé : jeudi 15 août 2024 23:22 > À : secdir@xxxxxxxx > Cc : draft-ietf-opsawg-teas-attachment-circuit.all@xxxxxxxx; > last-call@xxxxxxxx; opsawg@xxxxxxxx > Objet : Secdir last call review of draft-ietf-opsawg-teas- > attachment-circuit-15 > > 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. [Med] This is a service model, not a device model. That is, we don't describe how the provider will actually implement a service request that asks for the activation of L3/L2 encryption. Updated the text to cite an example of how a service request can be honored. > > 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. [Med] This is discussed in 5.2.2.1. A provider maintains and exposes a set of profiles that can be referenced in a service request. These profiles are unambiguously identified y a reference that can be included in a service request. Added a pointer to the section where profiles are discussed. > > 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. [Med] We do have only a very few set of security-related parameters that can be conveyed in a service request (control of encryption layer, reference to a profile that is shared using a secure means). This structure leverages existing RFCs such as 8299. Tweaked the text to better convey the intent. Hope this is better. > > -- > > 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. > > -- [Med] Agree. Updated the text accordingly. > > 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. [Med] I still think this is a matter of editing taste. The reference list has the full details to cross check if needed. > > 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 > [Med] Fixed. Thanks. > > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
