Re: [Teas] New Version Notification for draft-ietf-teas-ietf-network-slice-nbi-yang-09.txt

["Wubo (lana)" <[e-mail]>]

Hi Med,

Thanks for your helpful comments. Please see the responses inline.

Regards,
Bo 

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Wednesday, February 28, 2024 9:24 PM
To: Wubo (lana) <[e-mail]>; TEAS WG <[e-mail]>
Cc: Qin Wu <[e-mail]>
Subject: RE: New Version Notification for draft-ietf-teas-ietf-network-slice-nbi-yang-09.txt

Hi Bo, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Wubo (lana) <[e-mail]> Envoyé : mercredi 28 février 
> 2024 11:37 À : BOUCADAIR Mohamed INNOV/NET 
> <[e-mail]>; TEAS WG <[e-mail]> Cc : Qin Wu 
> <[e-mail]> Objet : RE: New Version Notification for 
> draft-ietf-teas-ietf-network- slice-nbi-yang-09.txt
> 
> Hi Med,
> 
> Thanks for your valuable comments. Please see my replies inline.
> 
> Thanks,
> Bo
> 
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Tuesday, February 20, 2024 7:34 PM
> To: Wubo (lana) <[e-mail]>; TEAS WG <[e-mail]>
> Cc: Qin Wu <[e-mail]>
> Subject: RE: New Version Notification for draft-ietf-teas-ietf- 
> network-slice-nbi-yang-09.txt
> 
> Hi Bo, all,
> 
> Many thanks for taking care of the comments.
> 
> I have to read the full version, but here are some few comments from 
> reading the diff:
> 
> * data nodes used for monitoring (e.g., incoming-bw-value) should be 
> of type gauge.
> * I think that this has to be fixed for the set of *-performance- 
> metrics-packet metrics
> * btw, as you are reusing *-performance-metrics-packet groupings and 
> these groupings has default values, I wonder whether you assessed the 
> implications on the reported values in the NSSM.
> [Bo Wu] Thanks for the comments. I have created issue#78 in GitHub to 
> track this issue. And I think your suggestions make sense.
> 

[Med] Thanks.

> * target-connectivity-construct-id uses an absolute path, while a 
> relative one should be used.
> [Bo Wu] The absolute path is for input parameters of current() 
> function. We will check this again.
> 

[Med] Wouldn't this be broken as there are many services indexed by a service "id"?

                   type leafref {
                     path
                       "/ietf-nss:network-slice-services"
                     + "/ietf-nss:slice-service"
                     + "/ietf-nss:connection-groups"
                     + "/ietf-nss:connection-group[id"
                     + "=current()/../target-connection-group-id]"
                     + "/ietf-nss:connectivity-construct/ietf-nss:id";

[Bo Wu] Thanks for pointing this out. We will correct as follows:
                type leafref {
                  path
                    "../../../../../ietf-nss:connection-groups"
                  + "/ietf-nss:connection-group[ietf-nss:id="
                  + "current()/../target-connection-group-id]"
                  + "/ietf-nss:connectivity-construct/ietf-nss:id";
                }



> * I think that a  hint about which layer will be used to implement the 
> service is still needed (layer 2, layer 3, etc.) [Bo Wu] The model has 
> defined "service-tag" to indicate the service type. We also give 
> explanations in the text and examples. Here is the usage in B.1.
> Example-1:
>     "slice-service": [
>       {
>         "id": "slice1",
>         "description": "example slice1",
>         "service-tags": {
>           "tag-type": [
>             {
>               "tag-type": "ietf-nss:service-tag-service",
>               "value": [
>                 "L3"
>               ]
>             }
>           ]
>         },
> Hope this is clear. Thanks.

[Med] Indeed! Thanks. It would helpful to update this "description" statement to have something useful to digest the intent when reading the YANG module.

         container service-tags {
           description
             "Container for the list of service tags.";


The description in 5.2 is thus better. Would it be possible with the intended usage to cover this case, e.g., when an L2 slice is requested but such L2 techniques are used to implement a slice, the service request will be rejected? If so, can we please make that explicit? 
[Bo Wu] Thanks for the suggestion. We will improve the descriptions as follows:

      container service-tags {
        description
          "Container for a list of service tags for management 
		  purposes, such as policy constraints 
		  (e.g., Layer 2 or Layer 3 technology realization), 
		  classification (e.g., customer names, opaque values).";

> 
> Thanks again for your effort on this document.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Teas <[e-mail]> De la part de Wubo (lana) Envoyé :
> > samedi 17 février 2024 10:34 À : TEAS WG <[e-mail]> Cc : Qin Wu 
> > <[e-mail]> Objet : [Teas] FW: New Version Notification for
> > draft-ietf-teas-ietf- network-slice-nbi-yang-09.txt
> >
> > Hi Med, all,
> >
> > Thank you again for another detailed review.
> > We've created issues #61-74 on GitHub to track your in-depth reviews 
> > of version 08.
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C12cd07c727034fc7b2
> >
> b208dc3849320c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384471342
> >
> 27522348%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> >
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1I%2F9jr0Q1fD1l%2BDG8
> > PTPQuYuRwZIvRySPQI8bzw6rBg%3D&reserved=0
> > ub.com%2Flana-wu%2Fietf-ns-
> >
> nbi%2Fissues&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cad2d16dcd
> >
> cea450891d408dc2f9b9ee4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> >
> 38437592635965151%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> >
> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Btytlw0S1IZr
> > 0gZTSrvZpqjVVAacQVUo30qx4XKtgik%3D&reserved=0
> >
> > After discussion, the authors have made the following changes in
> rev-
> > 09:
> > 1. #61: Align with the IETF network slicing framework RFC XXXX
> network
> > slicing.
> > Fixed
> > 2. # 62, # 64: PE and CE information exposure:
> > Added the following text:
> > For customer accessing the PE node information, the customer 
> > management system can obtain the topology information exposed by the 
> > NCE before the service request, such as the SAP topology or abstract 
> > TE topology.
> > 3. #63: SDP QoS policy:
> > Added rate-limit per cos as you suggested.
> > 4. #65: SDP MTU definition:
> > Replaced "MUST" with behavior as your suggestion.
> > 5. #66: Added NS monitoring examples in the appendix.
> > 6. #67: NSS precompute
> > We add new admin state "admin-compute-only" and NETCONF "test-only"
> > actions.
> > 7. #68: Definition of "service-tag-opaque"
> > Clarify that opaque value can be used for administrative purposes
> such
> > as filtering.
> > 8. #69: For "service-slos"
> > We recommend keeping "metric-unit" as a string. In this way,
> customers
> > can flexibly select time units ( e.g. second, milliseconds, 
> > microseconds), bandwidth units (),or loss unit (percent, ). We will 
> > discuss this definition in a separate topic.
> > 9. #70: "ac-tag"
> > We add the tag identifiers of the CVLAN and SVLAN on the basis of
> the
> > VLAN.
> > 10. #71: Add NSC scope to SDP "node-id"
> > 11. #72: YANG leafref typedef
> > We add a typedef for reusing SLO-SLE template. We think that SDP 
> > leafref is related to the definition of the context node and is not 
> > applicable to typedef.
> > # 73 Appendix C. the Complete Model Tree:
> > We recommend keeping the complete tree for reference.
> >
> > Please see the Diff:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> >
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C12cd07c727034fc7b2
> >
> b208dc3849320c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384471342
> >
> 27530196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> >
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jBKQOvskRZfWhIPqi%2B3
> > rIRGi1b5m4or7NNxIvSmbDck%3D&reserved=0
> > or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-teas-ietf-network-
> > slice-nbi-yang-
> >
> 09&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cad2d16dcdcea450891d
> >
> 408dc2f9b9ee4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63843759263
> >
> 5971998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> >
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=PFHICH4sMBWJ1dJv6JfXAl
> > 0Y4vYh3tCPekU7I3X4t5A%3D&reserved=0.
> >
> > Thanks,
> > Bo Wu
> >
> > -----Original Message-----
> > From: [e-mail] <[e-mail]>
> > Sent: Saturday, February 17, 2024 5:17 PM
> > To: Wubo (lana) <[e-mail]>; Dhruv Dhody 
> > <[e-mail]>; John Mullooly <[e-mail]>; Reza
> Rokui
> > <[e-mail]>; Tarek Saad <[e-mail]>
> > Subject: New Version Notification for draft-ietf-teas-ietf-network- 
> > slice-nbi-yang-09.txt
> >
> > A new version of Internet-Draft
> > draft-ietf-teas-ietf-network-slice-nbi-yang-09.txt has been 
> > successfully submitted by Bo Wu and posted to the IETF repository.
> >
> > Name:     draft-ietf-teas-ietf-network-slice-nbi-yang
> > Revision: 09
> > Title:    A YANG Data Model for the RFC AAAA Network Slice Service
> > Date:     2024-02-17
> > Group:    teas
> > Pages:    120
> > URL:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%
> 2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C12cd07c727034fc7b2b
> 208dc3849320c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63844713422
> 7535763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=fwLVZLhGOTPNO8%2F3hcb5
> IaRWYEgIf9VBwdins4FNzZI%3D&reserved=0.
> > ietf.org%2Farchive%2Fid%2Fdraft-ietf-teas-ietf-network-slice-nbi-
> yang-
> >
> 09.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cad2d16dcdcea450
> >
> 891d408dc2f9b9ee4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384375
> >
> 92635977364%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> >
> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=wBb0EOjowpux4yAqAt
> > d3fsKQnkh5HXhn%2Bl6XRDCqWaI%3D&reserved=0
> > Status:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> >
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C12cd07c727034fc7b2
> >
> b208dc3849320c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384471342
> >
> 27539788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> >
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=VAPC3QY2nFUHU8XiznPKH
> > %2B0pxAWW%2FpxtrnvvdyqLHXM%3D&reserved=0
> > tracker.ietf.org%2Fdoc%2Fdraft-ietf-teas-ietf-network-slice-nbi-
> >
> yang%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cad2d16dcdcea45
> >
> 0891d408dc2f9b9ee4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638437
> >
> 592635981429%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> >
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ZSnykhfnmzYF1Erm%
> > 2BPiwjiXieAINJYOVEy%2FJdMOuzOc%3D&reserved=0
> > HTMLized:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> >
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C12cd07c727034fc7b2
> >
> b208dc3849320c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384471342
> >
> 27543564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> >
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=y8%2BuG%2FNemcWbGVJ0E
> > JS7yoAtQXeBj7cGvl2jY7JL7Gk%3D&reserved=0
> > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teas-ietf-network-slice-
> > nbi-
> >
> yang&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cad2d16dcdcea45089
> >
> 1d408dc2f9b9ee4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638437592
> >
> 635985384%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> >
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Gp3gbr95R03er4OyzvW6
> > nZDsSAAZOY9v0q%2BRspO8x18%3D&reserved=0
> > Diff:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> >
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C12cd07c727034fc7b2
> >
> b208dc3849320c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384471342
> >
> 27547267%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> >
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=E3KUmDipGL07vCa6bOZBR
> > XLVV0t5PCAL3zTje6BTalk%3D&reserved=0
> > or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-teas-ietf-network-
> > slice-nbi-yang-
> >
> 09&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cad2d16dcdcea450891d
> >
> 408dc2f9b9ee4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63843759263
> >
> 5989260%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> >
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=qFqSNHAjjjwCKeBlGahPGV
> > mwaF07kcNtvc%2Fr4zwxO3s%3D&reserved=0
> >
> > Abstract:
> >
> >    This document defines a YANG data model for RFC AAAA Network
> Slice
> >    Service.  The model can be used in the Network Slice Service
> >    interface between a customer and a provider that offers RFC AAAA
> >    Network Slice Services.
> >
> >
> >
> > The IETF Secretariat
> >
> >
> > _______________________________________________
> > Teas mailing list
> > [e-mail]
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%
> 2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C12cd07c727034fc7b2b
> 208dc3849320c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63844713422
> 7551019%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KDu%2F7I%2BcDlfKipFuHs
> sAQFrBIlL6vk2CNOkdgFWYyME%3D&reserved=0.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fteas&data=05%7C02%7Cmohamed.boucadair%
> >
> 40orange.com%7Cad2d16dcdcea450891d408dc2f9b9ee4%7C90c7a20af34b40bfbc48
> >
> b9253b6f5d20%7C0%7C0%7C638437592635993274%7CUnknown%7CTWFpbGZsb3d8eyJW
> >
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%
> >
> 7C%7C&sdata=KmlICt34XCRQrFxpsNrtlHmjT9ZucOWmcUzTMEY38z4%3D&reserved=0
> ______________________________________________________________________
> ______________________________________
> 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.

____________________________________________________________________________________________________________
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.