Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for your review

[[e-mail]]

Hi Lynne, 

Thank you for taking care of the changes. 

For item 17: s/which/that

Other than that, this version looks good to me and I approve its publication. 

Many thanks for your careful edits. Much appreciated as usual.

Cheers,
Med

> -----Message d'origine-----
> De : Lynne Bartholomew <[e-mail]>
> Envoyé : mercredi 24 mai 2023 20:44
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Re: AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for
> your review
> 
> Hi, Med.
> 
> Thank you for the emails and clarifications!  We have updated this
> document per your notes below.
> 
> Regarding singular vs. plural:  We reverted to the style used in the
> original, even though there are several instances of "VPNs" as used
> in the original (e.g., the second sentence of the Introduction).  We
> followed suit with UNI/NNI vs. UNIs/NNIs and UNI-N (i.e., reverted
> our updates).
> 
> = = = = =
> 
> Regarding this question and your reply:
> 
> >> 1) <!-- [rfced] We changed "A YANG Model" to "A YANG Network
> Model"
> >> in the abbreviated (running) document title to match "Network
> Model"
> >> in the full title.  Please let us know any concerns.
> >>
> >> Original:
> >> A YANG Model for SAPs
> >>
> >> Currently:
> >> A YANG Network Model for SAPs -->
> >>
> >>
> >
> > [Med] The mention of "network model" is important here to insist
> that this is not about a device data model. We can update the title
> to align with the usage in RFC9182/9291:
> >
> > NEW:
> > A YANG Network Data Model for Service Attachment Points (SAPs)
> 
> Perhaps we misunderstood your request.  The expanded "SAPs" made the
> abbreviated title too long.  We received this warning:
> 
> Warning: Expected a title or title abbreviation of not more than 40
> character for the page header, found 62 characters
> 
> We changed the full title to "A YANG Network Data Model for Service
> Attachment Points (SAPs)" and the abbreviated title to "A YANG
> Network Data Model for SAPs".  Please let us know any concerns.
> 
> = = = = =
> 
> Regarding this question and your "NEW" text:
> 
> >> 17) <!-- [rfced] Appendix D:  This sentence did not parse.  We
> >> updated the text per the last sentence of Appendix A, Paragraph
> 1.
> >> If this update is incorrect, please clarify the meaning of "and
> that
> >> none of ...".
> >>
> >> Original:
> >> This is
> >> particularly inferred from the administrative 'service-status'
> >> which
> >> is set to 'ietf-vpn-common:admin-down' for all the services that
> are
> >> supported by these two SAPs and that none of the anomalies
> discussed
> >> in Section 5 are detected.
> >>
> >> Currently:
> >> This is
> >> particularly inferred from the administrative 'service-status',
> which
> >> is set to 'ietf-vpn-common:admin-down' for all the services that
> are
> >> supported by these two SAPs.  Note that none of the anomalies
> >> discussed in Section 5 are detected. -->
> >>
> >
> > [Med] What about:
> >
> > NEW:
> >   This is
> >   particularly inferred from (1) the administrative 'service-
> status' which
> >   is set to 'ietf-vpn-common:admin-down' for all the services that
> are
> >   supported by these two SAPs and (2) the absence of the anomalies
> discussed
> >   in Section 5.
> 
> Is the administrative 'service-status' only sometimes set to 'ietf-
> vpn-common:admin-down' (in which case "which" should be "that"), or
> is it always set to 'ietf-vpn-common:admin-down' (in which case a
> comma should precede the "which")?
> 
> = = = = =
> 
> The latest files are posted here.  Please refresh your browser:
> 
> 
   https://www.rfc-editor.org/authors/rfc9408.txt
   https://www.rfc-editor.org/authors/rfc9408.pdf
   https://www.rfc-editor.org/authors/rfc9408.html
   https://www.rfc-editor.org/authors/rfc9408.xml
   https://www.rfc-editor.org/authors/rfc9408-diff.html
   https://www.rfc-editor.org/authors/rfc9408-rfcdiff.html
   https://www.rfc-editor.org/authors/rfc9408-auth48diff.html

   https://www.rfc-editor.org/authors/rfc9408-alt-diff.html
   https://www.rfc-editor.org/authors/rfc9408-xmldiff1.html
   https://www.rfc-editor.org/authors/rfc9408-xmldiff2.html
   https://www.rfc-editor.org/authors/rfc9408-alt-diff.html 
> Thanks again!
> 
> RFC Editor/lb
> 
> 
> > On May 23, 2023, at 10:29 AM, [e-mail] wrote:
> >
> > Hi Lynne,
> >
> > Sure. The proposed change is as follows:
> >
> > OLD:
> >   *  L3VPNs [RFC4364]
> >
> >   *  Virtual Private LAN Services (VPLSs) [RFC4761] [RFC4762]
> >
> >   *  Virtual Private Wire Services (VPWSs) [RFC8214]
> >
> >   *  BGP MPLS-based Ethernet VPNs [RFC7432]
> >
> >   *  VPWSs in Ethernet VPNs [RFC8214]
> >
> >   *  Provider Backbone Bridging combined with Ethernet VPNs (PBB-
> EVPNs)
> >      [RFC7623]
> >
> >   *  VXLAN-based EVPNs [RFC8365] ("VXLAN" stands for "Virtual
> >      eXtensible Local Area Network")
> >
> >   *  Virtual Networks [RFC8453]
> >
> >   *  Enhanced VPN (VPN+) [ENHANCED-VPN]
> >
> >   *  Network slices [IETF-NETWORK-SLICES]
> >
> >   *  SD-WAN overlay networks [BGP-SDWAN-USAGE]
> >
> >   *  Basic IP connectivity
> >
> > NEW:
> >   *  L3VPN [RFC4364]
> >
> >   *  Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762]
> >
> >   *  Virtual Private Wire Service (VPWS) [RFC8214]
> >
> >   *  BGP MPLS-based Ethernet VPN [RFC7432]
> >
> >   *  VPWS in Ethernet VPN [RFC8214]
> >
> >   *  Provider Backbone Bridging combined with Ethernet VPN (PBB-
> EVPN)
> >      [RFC7623]
> >
> >   *  VXLAN-based EVPN [RFC8365] ("VXLAN" stands for "Virtual
> >      eXtensible Local Area Network")
> >
> >   *  Virtual Networks [RFC8453]
> >
> >   *  Enhanced VPN (VPN+) [ENHANCED-VPN]
> >
> >   *  Network slice service [IETF-NETWORK-SLICES]
> >
> >   *  SD-WAN [BGP-SDWAN-USAGE]
> >
> >   *  Basic IP connectivity
> >
> > Cheers,
> > Med
> 
> 
> = = = = = = = =
> 
> > On May 23, 2023, at 4:28 AM, [e-mail] wrote:
> >
> > Re-,
> >
> > Thanks for sharing this edited version. Overall, the edits look
> good. However:
> >
> > (1) Rather than using the plural form as suggested in the edited
> version, I would maintain the singular form of the services
> (Original) listed right after:
> >
> >   A SAP network topology can be used for one or multiple service
> types
> >   ('service-type').  Examples of supported service types are as
> >   follows:
> >
> > For example, we are referring to "VPN" as a service, not the VPN
> instances of the service. FWIW, this would be consistent with the
> usage in Section 3 of RFC9181.
> >
> > The same apply for the changes in the abstract, but I'm OK to
> maintain the edits in the abstract if you prefer.
> >
> > (2) I'm not sure we need to add "see" when pointing to refs. I
> would revert to the OLD versions. There are many occurrences in the
> edited version.
> >
> > (3) Please make this change in Section 2:
> >
> > OLD:
> >   Attachment Circuit (AC):  A channel that connects a Customer
> Edge
> >      (CE) to a Provider Edge (PE).  The AC may be a physical or
> logical
> >      link (Section 6.1 of [RFC4026]).
> >
> > NEW:
> >   Attachment Circuit (AC):  A channel that connects a Customer
> Edge
> >      (CE) to a Provider Edge (PE).
> >
> > FWIW, this change was shared with the WG since 02/23. The
> rationale can be seen at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> ilarchive.ietf.org%2Farch%2Fmsg%2Fopsawg%2F_Iiv16zSUnnGuSxywvXlROqh2
> AI%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C0db08cfbe50745
> 6f7f9f08db5c871280%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382
> 05510092419895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DF8f31Dp
> wQBzL0SCCEm1WQaz1Z2aBOT1i2IVVt83m4c%3D&reserved=0.
> >
> > Thank you.
> >
> > Cheers,
> > Med
> 
> = = = = = = = =
> 
> > On May 23, 2023, at 12:49 AM, [e-mail] wrote:
> >
> > Dear RFC Editor, all,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : [e-mail] <[e-mail]>
> >> Envoyé : lundi 22 mai 2023 22:44
> >> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> >> [e-mail];
> >> [e-mail]; [e-mail];
> >> [e-mail]
> >> Cc : [e-mail]; [e-mail]; opsawg-
> >> [e-mail]; [e-mail]; [e-mail];
> >> [e-mail]
> >> Objet : Re: AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for
> >> your review
> >>
> >> Authors,
> >>
> >> While reviewing this document during AUTH48, please resolve (as
> >> necessary) the following questions, which are also in the XML
> >> file.
> >>
> >>
> >> 1) <!-- [rfced] We changed "A YANG Model" to "A YANG Network
> >> Model" in the abbreviated (running) document title to match
> >> "Network Model" in the full title.  Please let us know any
> >> concerns.
> >>
> >> Original:
> >> A YANG Model for SAPs
> >>
> >> Currently:
> >> A YANG Network Model for SAPs -->
> >>
> >>
> >
> > [Med] The mention of "network model" is important here to insist
> that this is not about a device data model. We can update the title
> to align with the usage in RFC9182/9291:
> >
> > NEW:
> > A YANG Network Data Model for Service Attachment Points (SAPs)
> >
> >
> >> 2) <!-- [rfced] Abstract and subsequent:  It looks a bit odd to
> >> use "User-Network Interface" for "UNI" but "Network-to-Network
> >> Interface"
> >> for "NNI" and "UNI-N (User-to-Network Interface, Network side)
> >> [RFC6215]" as seen in Section 3.
> >>
> >> Does "User-Network Interface" mean "User-to-Network Interface",
> >
> > [Med] Yes. Both are actually used in existing RFCs. "User-Network
> Interface" is what is used by some other SDOs (see, e.g., the MEF
> refs in the I-D). That's said, we need to be consistent and use the
> same form for both UNI and NNI.
> >
> > as
> >> used in some RFCs?  Or does it mean "the user network's
> >> interface"?
> >>
> >> (Side note:  We see a few instances of "Network-Network
> Interface"
> >> in published RFCs, but "Network-to-Network Interface" is used
> more
> >> often.)
> >
> > [Med] OK to use "*-to-*" for both UNI/NNI.
> >
> >>
> >> Original:
> >> Both User-Network Interface (UNI) and Network-to-  Network
> >> Interface (NNI) are supported in the SAP data model.
> >> ...
> >> 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.
> >> ...
> >> etc. -->
> >>
> >>
> >> 3) <!-- [rfced] Section 1:  This sentence did not parse.  We
> >> updated it as follows.  If this is incorrect, please provide
> >> clarifying text.
> >>
> >> Original:
> >> Whether a SAP topology is dedicated to services of a specific
> >> service type, an individual service, or shared among many
> services
> >> of  different types is deployment specific.
> >>
> >> Currently:
> >> Whether a SAP topology is dedicated to services of a specific
> >> service type or an individual service, or is shared among many
> >> services of different types, is deployment specific. -->
> >>
> >
> > [Med] Works for me. Thanks.
> >
> >>
> >> 4) <!-- [rfced] Section 3:  We changed "the module" to "the
> model"
> >> in the second sentence here, as it appears that the text refers
> to
> >> the model and not to the YANG module provided in Section 6.  If
> >> this update is incorrect, please provide clarifying text.
> >>
> >> Original (the previous sentence is included for context):
> >> The model is also used to retrieve the network reference points
> >> where  a service is being delivered to customers.  For services
> >> that require  resources from peer networks, the module can also
> be
> >> used to expose  NNIs.
> >>
> >> Currently:
> >> The model is also used to retrieve the network  reference points
> >> where a service is being delivered to customers.
> >> For services that require resources from peer networks, the model
> >> can  also be used to expose NNIs. -->
> >>
> >
> > [Med] OK.
> >
> >>
> >> 5) <!-- [rfced] Please review each artwork element in this
> >> document.
> >> Specifically, should any artwork element be tagged as sourcecode
> >> or another element?  For example, are Figures 7, 9, 10, and 12 in
> >> the appendices JSON?
> >
> > [Med] Yes.
> >
> > If yes, should an Informative Reference be
> >> provided - perhaps to RFC 8259 - in text just prior to Figure 7?
> >
> > [Med] I suggest to add the following + list 7951 as an Informative
> Reference:
> >
> > NEW:
> > The message body depicted in the figures is encoded following the
> > the JSON encoding of YANG-modeled data as per [[RFC7951].
> >
> >>
> >> If the current list of preferred values for "type"
> >>
> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >> Fwww.rfc-editor.org%2Fmaterials%2Fsourcecode-
> >>
> types.txt&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Caa068512
> >>
> cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> >>
> 0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> >>
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
> >>
> ata=5NjV1F%2B24%2F8MtaBk3IgE0S0PTB9M31fHpqEG%2BjJoI2k%3D&reserved=
> >> 0)
> >> does not contain an applicable type, then feel free to let us
> >> know.
> >> Also, it is acceptable to leave the "type" attribute not set. -->
> >>
> >>
> >> 6) <!-- [rfced] Section 3:  As we don't see "P node" or "P nodes"
> >> mentioned anywhere else in this document and the next sentence
> >> after
> >> this text mentions Figure 2 (which shows PE nodes), we changed
> >> "P nodes" to "PE nodes" here.  If this is incorrect, please
> >> provide
> >> text that clarifies the meaning of "P nodes".
> >
> > [Med] The OLD version is correct. Please revert back.
> >
> > "P" nodes are hidden in the cloud shown in Figure 2, for example.
> We used to have these nodes drawn there but we removed them to
> simplify the figures.
> >
> > FWIW, please see
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
> tatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4026%23autoid-
> 37&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C0db08cfbe507456f7
> f9f08db5c871280%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382055
> 10092419895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4Ad1rENUXqN
> VFtbzWrWtrTpD7n70XxR4SnEKvVPuB3w%3D&reserved=0.
> >
> > If needed, we can make this change: s/P nodes/P nodes (Section
> 5.3.1 of [RFC4026])
> >
> >>
> >> Original (the next sentence is included for context):
> >> The service orchestration layer does not need to know about all
> >> the
> >> internals of the underlying network (e.g., P nodes).  Figure 2
> >> shows
> >> the abstract network view as seen by a service orchestrator.
> >>
> >> Currently:
> >> The service orchestration layer does not need to know about all
> >> the
> >> internals of the underlying network (e.g., PE nodes). -->
> >>
> >>
> >> 7) <!-- [rfced] Section 4:  We had trouble following the use of
> >> capitalization in this sentence (for example, as compared to
> >> "SAP network model").
> >>
> >> Original:
> >> The SAP network model augments the Network model [RFC8345]
> >> and imports the Network Topology model, while other technology-
> >> specific topology models (e.g., Traffic Engineering (TE)
> >> Topologies
> >> model [RFC8795] or Layer 3 Topologies model [RFC8346]) augment
> >> the
> >> Network Topology model.
> >>
> >> Possibly:
> >> The SAP network model augments the network model defined in
> >> [RFC8345] and imports the network topology model defined in
> >> [RFC8345], while other technology-specific topology models (e.g.,
> >> the model for Traffic Engineering (TE) topologies [RFC8795] or
> >> the
> >> model for Layer 3 topologies [RFC8346]) augment the network
> >> topology model defined in [RFC8345]. -->
> >>
> >
> > [Med] OK.
> >
> >>
> >> 8) <!-- [rfced] Section 4:  We see that "TP" and "TTP" are
> defined
> >> in
> >> this paragraph, but these abbreviations are not used again.
> Which
> >> of
> >> the following update options would you prefer?
> >>
> >> 1. Use "TP" instead of "termination point" in the eight
> subsequent
> >> instances of this term (except for Section 6, where we would
> >> change
> >> "parent termination point" to "parent termination point (TP)" and
> >> then use "TP" in the next sentence).
> >>
> >> 2. Remove the abbreviations from this paragraph and spell out
> >> "termination point".
> >>
> >> Original:
> >> SAPs can be seen as customer-facing termination points (TPs) with
> >> specific service provisions.  However, a difference between SAPs
> >> and
> >> TPs is that links are terminated by a single TP (Section 4.4.6 of
> >> [RFC8345]) while an AC can be terminated by multiple SAPs.  Also,
> >> a
> >> SAP is not a tunnel termination point (TTP) (Section 3.6 of
> >> [RFC8795]) nor a link. -->
> >>
> >
> > [Med] I prefer to leave the Original version with "termination
> point" expanded. The abbreviations are included to help readers
> correlate with other context. I don't think a change is needed here.
> >
> >>
> >> 9) <!-- [rfced] Section 5:  Should "network modules" and "SAP
> >> network
> >> module" in these sentences be "network models" and "SAP network
> >> model"?  We ask (particularly in the case of "SAP network
> module")
> >> because of this sentence from Section 4.4 of [RFC8969], as it
> does
> >> not use the word "module":
> >>
> >> "Service Decomposition allows to decompose service models at the
> >> service level or network models at the network level into a set
> >> of
> >> device models at the device level."
> >>
> >> Original:
> >> |  Leveraging the service types defined in [RFC9181] is meant to
> >> |  ease the correlation between the SAP topology and the
> >> |  corresponding network modules that are used to provision a
> >> |  specific service over a provider's network.
> >> ...
> >> That mapping is used, for example,
> >> when the controller translates this SAP network module into
> >> device
> >> modules (Section 4.4 of [RFC8969]).
> >>
> >> Possibly:
> >> |  Leveraging the service types defined in [RFC9181] is meant to
> >> |  ease the correlation between the SAP topology and the
> >> |  corresponding network models that are used to provision a
> >> |  specific service over a provider's network.
> >> ...
> >> That mapping is used, for example,
> >> when the controller translates this SAP network model into device
> >> models (Section 4.4 of [RFC8969]). -->
> >>
> >
> > [Med] Works for me. Thanks.
> >
> >>
> >> 10) <!-- [rfced] Section 5:  Please clarify the meaning of "in
> >> association" in this sentence.
> >>
> >> Original (the previous sentence is included for context):
> >> The same SAP may appear under distinct service types.  In such a
> >> case, the same identifier is used for these service types in
> >> association.
> >>
> >> Possibly:
> >> The same SAP may appear under distinct service types.  In such a
> >> case, the same identifier is used for these service types in
> >> order to associate them. -->
> >>
> >
> > [Med] What about:
> >
> > NEW:
> >  The same SAP may appear under distinct service types.  In such a
> >  case, the same identifier is used for a shared SAP for each of
> these
> >  service types.
> >
> >
> >>
> >> 11) <!-- [rfced] Section 5:  As we do not see "mode" or "modes"
> >> used
> >> anywhere else in this document, we changed "device modes" to
> >> "device
> >> models" in this sentence.
> >
> > [Med] The change is correct. Thanks for catching this.
> >
> >
> >  If this is incorrect, should the use of
> >> "modes" be clarified for readers?
> >>
> >> Original:
> >> It
> >> is the responsibility of the controller to ensure that consistent
> >> references are used in the SAP and underlying device modes or any
> >> other device inventory mechanism.
> >>
> >> Currently:
> >> The controller is responsible for ensuring that consistent
> >> references are used in the SAP and underlying device models or
> >> any
> >> other device inventory mechanism. -->
> >>
> >>
> >> 12) <!-- [rfced] Sections 5 and 6:  We defined "IRB" as
> >> "Integrated
> >> Routing and Bridging (IRB) interface", per RFC 9135 and other
> >> post-6000 published RFCs.
> >>
> >> Also, please note that in Section 6 we expanded "IP-VRF" as "IP
> >> Virtual Routing and Forwarding" for ease of the reader.
> >>
> >
> > [Med] OK.
> >
> >> Please let us know any concerns.
> >>
> >> Original:
> >> 'interface-type':  Indicates whether a SAP is bound to a physical
> >>    port, a loopback interface, a Link Aggregation Group (LAG)
> >>    interface [IEEE802.1AX], an Integrated Routing Bridge (IRB)
> >> (e.g.,
> >>    [RFC9135]), a local bridge reference, etc.
> >> ...
> >> "Integrated Routing Bridge (IRB). An IRB typically
> >>  connects an IP-VRF to a bridge domain.";
> >>
> >> Currently:
> >> 'interface-type':  Indicates whether a SAP is bound to a physical
> >>    port, a loopback interface, a Link Aggregation Group (LAG)
> >>    interface [IEEE802.1AX], an Integrated Routing and Bridging
> >> (IRB)
> >>    interface (e.g., see [RFC9135]), a local bridge reference,
> >> etc.
> >> ...
> >> "Integrated Routing and Bridging (IRB) interface.  An IRB
> >>  interface typically connects an IP Virtual Routing and
> >>  Forwarding (IP-VRF) entity to a bridge domain."; -->
> >>
> >>
> >> 13) <!-- [rfced] Section 5:  The latest version of
> >> draft-ietf-teas-ietf-network-slices (-19) does not have a
> >> Section 2.1, nor does the version (-18) provided in the original
> >> copy of this document.
> >
> > [Med] That section was renumbered to Section 3.2
> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fa
> uthor-tools.ietf.org%2Fiddiff%3Furl1%3Ddraft-ietf-teas-ietf-network-
> slices-16%26url2%3Ddraft-ietf-teas-ietf-network-slices-
> 17%26difftype%3D--
> html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C0db08cfbe507456
> f7f9f08db5c871280%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63820
> 5510092576163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KkFAYskXL
> 21ew74%2Fntlb1YH7PhVpXlR%2BLMs13aBX5kc%3D&reserved=0).
> >
> > What about:
> >
> > s/Section 2.1 of [I-D.ietf-teas-ietf-network-slices]/the "Core
> Terminology" Section of [I-D.ietf-teas-ietf-network-slices]
> >
> >
> > Please see
> >>
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >> Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teas-ietf-
> network-
> >> slices-
> >>
> 19&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Caa068512cee4460
> >>
> 9f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
> >>
> 203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> >>
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4p4
> >> ZMp%2Fa%2FEGEBxPsKQEOs1bVFLF21uIZx8M0kDSexOQ%3D&reserved=0>,
> >> and let us know which section number should be cited.
> >>
> >> Original:
> >> Examples of such a reference are: a site identifier (Section 6.3
> >> of [RFC8299]), a Service Demarcation Point (SDP) identifier
> >> (Section 2.1 of [I-D.ietf-teas-ietf-network-slices]), and the IP
> >> address of a peer Autonomous System Border Router (ASBR). -->
> >>
> >>
> >> 14) <!-- [rfced] Section 6:  Informative Reference RFC 8343 is
> not
> >> mentioned anywhere else in this document.  Is an "import"
> >> statement
> >> missing in the YANG module (in which case it should be a
> Normative
> >> Reference instead)?
> >>
> >
> > [Med] We used to have an import in a previous version, but forgot
> to remove it when we updated the design. Please remove 8343 for the
> references and make this change:
> >
> > OLD:
> >   This module imports types from [RFC6991], [RFC8343], [RFC8345],
> and
> >   [RFC9181].
> >
> > NEW:
> >   This module imports types from [RFC6991], [RFC8345], and
> >   [RFC9181].
> >
> >> Also, because RFC 8453 is referenced in the YANG module, may we
> >> add
> >> "This module also references [RFC8453]." after the "This module
> >> imports" sentence?
> >>
> >
> > [Med] We don't need this change as the ref is already called out
> in Section 5.
> >
> >> Original:
> >> This module imports types from [RFC6991], [RFC8343], [RFC8345],
> >> and
> >> [RFC9181].
> >> ...
> >> reference
> >>   "RFC 8453: Framework for Abstraction and Control of TE
> >>              Networks (ACTN)";
> >> ...
> >> Under Informative References:
> >> [RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
> >>            Management", RFC 8343, DOI 10.17487/RFC8343, March
> >> 2018,
> >>
> >>
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >> Fwww.rfc-
> >>
> editor.org%2Finfo%2Frfc8343&data=05%7C01%7Cmohamed.boucadair%40ora
> >>
> nge.com%7Caa068512cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b
> >>
> 9253b6f5d20%7C0%7C0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8e
> >>
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> >>
> 7C3000%7C%7C%7C&sdata=bg339ojOWZvxVQkbkw9eXQtuazGdWaM6dX5iy62NXqM%
> >> 3D&reserved=0>. -->
> >>
> >>
> >> 15) <!-- [rfced] Section 6:  Does "independent" refer to
> >> "Indicates"
> >> (in which case it should be "independently"), or does it refer to
> >> "operational status" (in which case the current text is correct)?
> >>
> >
> > [Med] It refers to the "operational status".
> >
> >> Original:
> >> "Indicates the operational status of the SAP,
> >>  independent of any service provisioned over it."; -->
> >>
> >>
> >> 16) <!-- [rfced] Security Considerations:  It appears that RPC
> >> operations
> >> do not apply to this document.  Please confirm.
> >>
> >
> > [Med] ACK.
> >
> >> If you have any questions, please see
> >>
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >> Fwiki.ietf.org%2Fgroup%2Fops%2Fyang-security-
> >>
> guidelines&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Caa06851
> >>
> 2cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> >>
> C0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> >>
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
> >>
> data=7hC%2FMAswX%2Fot7p8qwtaWrZfrRRzpOwwLl2EUWnWlZjU%3D&reserved=0
> >>>
> >> for details. -->
> >>
> >>
> >> 17) <!-- [rfced] Appendix D:  This sentence did not parse.  We
> >> updated
> >> the text per the last sentence of Appendix A, Paragraph 1.  If
> >> this
> >> update is incorrect, please clarify the meaning of "and that none
> >> of ...".
> >>
> >> Original:
> >> This is
> >> particularly inferred from the administrative 'service-status'
> >> which
> >> is set to 'ietf-vpn-common:admin-down' for all the services that
> >> are
> >> supported by these two SAPs and that none of the anomalies
> >> discussed
> >> in Section 5 are detected.
> >>
> >> Currently:
> >> This is
> >> particularly inferred from the administrative 'service-status',
> >> which
> >> is set to 'ietf-vpn-common:admin-down' for all the services that
> >> are
> >> supported by these two SAPs.  Note that none of the anomalies
> >> discussed in Section 5 are detected. -->
> >>
> >
> > [Med] What about:
> >
> > NEW:
> >   This is
> >   particularly inferred from (1) the administrative 'service-
> status' which
> >   is set to 'ietf-vpn-common:admin-down' for all the services that
> are
> >   supported by these two SAPs and (2) the absence of the anomalies
> discussed
> >   in Section 5.
> >
> >>
> >> 18) <!-- [rfced] Please review the "Inclusive Language" portion
> of
> >> the
> >> online Style Guide at
> >>
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >> Fwww.rfc-
> >>
> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C
> >>
> 01%7Cmohamed.boucadair%40orange.com%7Caa068512cee44609f0ca08db5b05
> >>
> 5b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382038511140727
> >>
> 26%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> >>
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FxEg4CmJqMrsXj
> >> xFxczqrWX%2FhaHMphrGkImd8eCWeHE%3D&reserved=0>,
> >> and let us know if any changes are needed.
> >>
> >> Note that our script did not flag any words in particular, but
> >> this
> >> should still be reviewed as a best practice. -->
> >>
> >>
> >
> > [Med] ACK.
> >
> >> 19) <!-- [rfced] The following term was used inconsistently in
> >> this
> >> document.  We chose to use the latter form.  Please let us know
> >> any
> >> objections.
> >>
> >> IETF network slice / IETF Network Slice (per
> >>   draft-ietf-teas-ietf-network-slices-19) -->
> >>
> >
> > [Med] OK.
> >
> >>
> >> Thank you.
> >>
> >> RFC Editor/lb/rv
> >>
> >>
> >>
> >> On May 22, 2023, at 1:30 PM, [e-mail] wrote:
> >>
> >> *****IMPORTANT*****
> >>
> >> Updated 2023/05/22
> >>
> >> RFC Author(s):
> >> --------------
> >>
> >> Instructions for Completing AUTH48
> >>
> >> Your document has now entered AUTH48.  Once it has been reviewed
> >> and
> >> approved by you and all coauthors, it will be published as an
> RFC.
> >> If an author is no longer available, there are several remedies
> >> available as listed in the FAQ
> >>
> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >> Fwww.rfc-
> >>
> editor.org%2Ffaq%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%
> >>
> 7Caa068512cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5
> >>
> d20%7C0%7C0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> >>
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> >>
> C%7C%7C&sdata=3X0NPJbD6s7SjNjcCgf3d4pr7%2FD3w7esNWzUEH0TK%2Fw%3D&r
> >> eserved=0).
> >>
> >> You and you coauthors are responsible for engaging other parties
> >> (e.g., Contributors or Working Group) as necessary before
> >> providing
> >> your approval.
> >>
> >> Planning your review
> >> ---------------------
> >>
> >> Please review the following aspects of your document:
> >>
> >> *  RFC Editor questions
> >>
> >>  Please review and resolve any questions raised by the RFC Editor
> >>  that have been included in the XML file as comments marked as
> >>  follows:
> >>
> >>  <!-- [rfced] ... -->
> >>
> >>  These questions will also be sent in a subsequent email.
> >>
> >> *  Changes submitted by coauthors
> >>
> >>  Please ensure that you review any changes submitted by your
> >>  coauthors.  We assume that if you do not speak up that you
> >>  agree to changes submitted by your coauthors.
> >>
> >> *  Content
> >>
> >>  Please review the full content of the document, as this cannot
> >>  change once the RFC is published.  Please pay particular
> >> attention to:
> >>  - IANA considerations updates (if applicable)
> >>  - contact information
> >>  - references
> >>
> >> *  Copyright notices and legends
> >>
> >>  Please review the copyright notice and legends as defined in
> >>  RFC 5378 and the Trust Legal Provisions
> >>  (TLP -
> >>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >> trustee.ietf.org%2Flicense-
> >>
> info%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Caa068512ce
> >>
> e44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> >>
> 7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> >>
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat
> >> a=B0gciAKpYepmwZWLRH6Tbv4JE6IEMdCZWUaybG3OrMc%3D&reserved=0).
> >>
> >> *  Semantic markup
> >>
> >>  Please review the markup in the XML file to ensure that elements
> >> of
> >>  content are correctly tagged.  For example, ensure that
> >> <sourcecode>
> >>  and <artwork> are set correctly.  See details at
> >>
> >>
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >> Fauthors.ietf.org%2Frfcxml-
> >>
> vocabulary&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Caa06851
> >>
> 2cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> >>
> C0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> >>
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
> >>
> data=IcRNNGnHecShyTp1hHzpP2vQPzREsoWILEQ%2B%2BsbNXn8%3D&reserved=0
> >>> .
> >>
> >> *  Formatted output
> >>
> >>  Please review the PDF, HTML, and TXT files to ensure that the
> >>  formatted output, as generated from the markup in the XML file,
> >> is
> >>  reasonable.  Please note that the TXT will have formatting
> >>  limitations compared to the PDF and HTML.
> >>
> >>
> >> Submitting changes
> >> ------------------
> >>
> >> To submit changes, please reply to this email using 'REPLY ALL'
> as
> >> all
> >> the parties CCed on this message need to see your changes. The
> >> parties
> >> include:
> >>
> >>  *  your coauthors
> >>
> >>  *  [e-mail] (the RPC team)
> >>
> >>  *  other document participants, depending on the stream (e.g.,
> >>     IETF Stream participants are your working group chairs, the
> >>     responsible ADs, and the document shepherd).
> >>
> >>  *  [e-mail], which is a new archival mailing
> >> list
> >>     to preserve AUTH48 conversations; it is not an active
> >> discussion
> >>     list:
> >>
> >>    *  More info:
> >>
> >>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >> mailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-
> >>
> 4Q9l2USxIAe6P8O4Zc&data=05%7C01%7Cmohamed.boucadair%40orange.com%7
> >>
> Caa068512cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d
> >>
> 20%7C0%7C0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> >>
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> >>
> %7C%7C&sdata=5K2ALQOAyoHogs8kmSa6eYHpDGLAfUtNE8ojWfxcOEQ%3D&reserv
> >> ed=0
> >>
> >>    *  The archive itself:
> >>
> >>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>
> mailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C
> >>
> 01%7Cmohamed.boucadair%40orange.com%7Caa068512cee44609f0ca08db5b05
> >>
> 5b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382038511140727
> >>
> 26%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> >>
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BRtJa3WaEgZliR
> >> ajCaGS%2FdUC5tFiu3axU9yZXszk8tE%3D&reserved=0
> >>
> >>    *  Note: If only absolutely necessary, you may temporarily opt
> >> out
> >>       of the archiving of messages (e.g., to discuss a sensitive
> >> matter).
> >>       If needed, please add a note at the top of the message that
> >> you
> >>       have dropped the address. When the discussion is concluded,
> >>       [e-mail] will be re-added to the CC
> >> list and
> >>       its addition will be noted at the top of the message.
> >>
> >> You may submit your changes in one of two ways:
> >>
> >> An update to the provided XML file
> >> - OR -
> >> An explicit list of changes in this format
> >>
> >> Section # (or indicate Global)
> >>
> >> OLD:
> >> old text
> >>
> >> NEW:
> >> new text
> >>
> >> You do not need to reply with both an updated XML file and an
> >> explicit
> >> list of changes, as either form is sufficient.
> >>
> >> We will ask a stream manager to review and approve any changes
> >> that seem
> >> beyond editorial in nature, e.g., addition of new text, deletion
> >> of text,
> >> and technical changes.  Information about stream managers can be
> >> found in
> >> the FAQ.  Editorial changes do not require approval from a stream
> >> manager.
> >>
> >>
> >> Approving for publication
> >> --------------------------
> >>
> >> To approve your RFC for publication, please reply to this email
> >> stating
> >> that you approve this RFC for publication.  Please use 'REPLY
> >> ALL',
> >> as all the parties CCed on this message need to see your
> approval.
> >>
> >
> >


_________________________________________________________________________________________________________________________

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.