Hi Giuseppe, FWIW, the next version of the draft will include these changes to address your comment: https://github.com/boucadair/attachment-circuit-model/pull/233/files. Cheers, Med > -----Message d'origine----- > De : BOUCADAIR Mohamed INNOV/NET > Envoyé : mardi 3 septembre 2024 15:35 > À : 'Giuseppe Fioccola' <giuseppe.fioccola@xxxxxxxxxx>; ops- > dir@xxxxxxxx > Cc : draft-ietf-opsawg-ntw-attachment-circuit.all@xxxxxxxx; last- > call@xxxxxxxx; opsawg@xxxxxxxx > Objet : RE: Opsdir last call review of draft-ietf-opsawg-ntw- > attachment-circuit-12 > > Hi Giuseppe, > > Thank you for the review. > > The use of these profiles is similar to those in 8299/8466/etc. > > We do have detailed examples to illustrate the use of some of > these profiles in the service model spec. See for example > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-teas- > attachment-circuit-15#name-nfs-deployment > > Would it be OK if we add a pointer to that section and say that > the use is basically similar? > > Cheers, > Med > > > -----Message d'origine----- > > De : Giuseppe Fioccola via Datatracker <noreply@xxxxxxxx> > Envoyé : > > lundi 26 août 2024 18:28 À : ops-dir@xxxxxxxx Cc : > > draft-ietf-opsawg-ntw-attachment-circuit.all@xxxxxxxx; last- > > call@xxxxxxxx; opsawg@xxxxxxxx Objet : Opsdir last call review > of > > draft-ietf-opsawg-ntw- > > attachment-circuit-12 > > > > > > Reviewer: Giuseppe Fioccola > > Review result: Has Issues > > > > This document specifies a network YANG data model for > attachment > > circuits and this is a really relevant work. There is a group > of > > related documents (draft-ietf-opsawg-ntw-attachment-circuit, > > draft-ietf-opsawg-teas-common-ac, draft-ietf-opsawg-teas- > > attachment-circuit, draft-ietf-opsawg-ac-lxsm-lxnm-glue) > > and their relation is explained in section 3. While I found the > > document useful and well-written, it left me with some > questions. > > > > From an OPSDIR point of view, I think that some clarification > would be > > helpful. > > In particular, I would suggest to add more details about the > > specific-provisioning-profiles specifically in section 5.3. It > is > > mentioned that the exact definition of the specific > provisioning > > profiles is local to each service provider, but I think that a > more > > complete explanation, possibly with examples, may help an > implementer > > to better understand how to use these data nodes. In this > regard, it > > would also be great to describe the usage of the different > identifiers > > (i.e. encryption-profile-identifier, qos- profile-identifier, > > failure-detection-profile-identifier, > > forwarding-profile-identifier, routing-profile-identifier) > under the > > valid-provider-identifiers container. I found some > considerations > > about the vulnerability of the specific- provisioning-profiles > > container in the section on Security Considerations and this is > good. > > > > ____________________________________________________________________________________________________________ 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
