Re: [OPSAWG] WG LC: draft-ietf-opsawg-sap

Hi Adrian, 

Thanks for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG <opsawg-bounces@ietf.org> De la part de Adrian Farrel
> Envoyé : vendredi 13 mai 2022 19:42
> À : 'Joe Clarke (jclarke)' <jclarke=40cisco.com@dmarc.ietf.org>;
> opsawg@ietf.org
> Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-sap
> 
> Very last minute review comments.
> 
> Thanks for the work on this draft. I think the fundamentals here
> are useful and we are referencing this work from the TEAS network
> slicing work. I also see it being mentioned in the TEAS packet-
> optical integration applicability statement.
> 
> Thanks,
> Adrian
> 
> ===
> 
> Section 2
> 
> You can remove the BCP 14 and the references as you don't use any
> of the key words.
> 
> 

[Med] Done.

---
> 
> While the terms UNI and NNI are expanded adequately, I think there
> is an assumption that the meanings of the terms are understood by
> the readers.
> Do you have a reference for them you could add?
> 

[Med] Made this change: 

OLD:
   Both User-Network Interface (UNI) and Network-to-Network Interface
   (NNI) SAPs are supported in the document.  An example of NNI usage is
   provided in Appendix C.

NEW:
   Given that User-Network Interface (UNI) and Network-to-Network
   Interface (NNI) are reference points that are widely used by
   operators to indicate the demarcation points when delivering
   services, both UNI and NNI SAPs are supported in the document.  The
   reader may refer, e.g., to [MEF6], [MEF17], [RFC6004], or [RFC6215]
   for a discussion on the use of UNI and NNI reference points.  An
   example of NNI usage in a VPN context is provided in Appendix C.

> ---
> 
> I wonder whether at least one of the CEs in one of the examples
> should be dual homed.
> 

[Med] Sure. Also changed the json examples to reflect this.

> ---
> 
> Section 4
> 
> s/seen as an inventory data/seen as inventory data/
> 

[Med] Fixed. Thanks. 

> ---
> 
> Figure 7 is somewhat separated from the text that talks about it
> (starts "Each SAP is characterized...")
> 

[Med] It isn't. The text starting with "Each SAP is characterized..." covers the data nodes under: " +--rw sap* [sap-id]", while the text before is related to this part of Figure 7:

              +--rw service* [service-type]
                 +--rw service-type                   identityref

> ---
> 
> I'm not very comfortable about using I-Ds as references in the
> data model. I understand that the three cases are all for the
> definitions of service types and the references are pretty much
> for information, but I wonder what happens to the module if the
> drafts never become RFCs.
> 

[Med] It is fine to have I-Ds listed as references. The RFC Editor will add the version number of the draft. Please note this is consistent with this part from RFC8407:

      If a YANG module
      contains reference or "description" statements that refer to an
      I-D, then the I-D is included as an informative reference.

Thank you. 

> ---
> 
> 
> 
> 
> -----Original Message-----
> From: OPSAWG <opsawg-bounces@ietf.org> On Behalf Of Joe Clarke
> (jclarke)
> Sent: 22 April 2022 20:00
> To: opsawg@ietf.org
> Subject: [OPSAWG] WG LC: draft-ietf-opsawg-sap
> 
> Hello, Opsawg.  The last round of comments on this draft have been
> discussed/resolved, and we'd like to kick off a three-week WG LC
> for this work.  Please provide any and all feedback on list before
> the end of the day May 13, 2022.
> 
> Authors, if you have suggestions for a good shepherd for this
> document, we'd love to hear them.
> 
> I have requested reviews from Ops and Routing on this work.
> 
> Thanks.
> 
> Joe
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

_________________________________________________________________________________________________________________________

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.