[Last-Call] Re: Opsdir last call review of draft-ietf-opsawg-ntw-attachment-circuit-12

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux