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

[Lynne Bartholomew <[e-mail]>]

Hi, Med.

We have changed "which" to "that" per your note below.

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-lastdiff.html
   https://www.rfc-editor.org/authors/rfc9408-lastrfcdiff.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

We have also noted your approval on the AUTH48 status page:

   https://www.rfc-editor.org/auth48/rfc9408

Many thanks to you for your help and patience!

RFC Editor/lb

> On May 24, 2023, at 10:46 PM, <[e-mail]> <[e-mail]> wrote:
> 
> 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.
>