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

[Lynne Bartholomew <[e-mail]>]

Hi, Oscar.

We have noted your approval on the AUTH48 status page:

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

Thank you!

RFC Editor/lb

> On Jun 1, 2023, at 12:10 AM, Oscar González de Dios <[e-mail]> wrote:
> 
> Hi Lynne,
>                I have reviewed the last version of the document including the last style changes and the document is OK for me.
>                Best Regards,
>                              Oscar  
>  De: Victor Lopez (Nokia) <[e-mail]> 
> Enviado el: miércoles, 31 de mayo de 2023 15:16
> Para: Samier Barguil Giraldo (Nokia) <[e-mail]>; Lynne Bartholomew <[e-mail]>; [e-mail]
> CC: [e-mail]; Oscar González de Dios <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Asunto: Re: AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for your review
>  Hi
>  I’m good to go too.
>  Thanks
>  Regards,
>  Victor
>  From: Samier Barguil Giraldo (Nokia) <[e-mail]>
> Date: Wednesday, 31 May 2023 at 07:24
> To: Lynne Bartholomew <[e-mail]>, [e-mail] <[e-mail]>
> Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail]<[e-mail]>, Victor Lopez (Nokia) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
> Subject: RE: AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for your review
> Hello Lynne, 
> 
> This version looks good to me and I approve its publication.
> 
> Regards,
> 
> Samier Barguil
> 
> -----Original Message-----
> From: Lynne Bartholomew <[e-mail]> 
> Sent: Friday, May 26, 2023 6:35 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; Samier Barguil Giraldo (Nokia) <[e-mail]>; [e-mail]; Victor Lopez (Nokia) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for your review
> 
> 
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
> 
> 
> 
> 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.
> >
> 
> 
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
> 
> The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
> 
> Le informamos de que el responsable del tratamiento de sus datos es la entidad del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el contacto profesional y gestionar la relación establecida con el destinatario o con la entidad a la que está vinculado. Puede contactar con el responsable del tratamiento y ejercitar sus derechos escribiendo a [e-mail]. Puede consultar información adicional sobre el tratamiento de sus datos en nuestra Política de Privacidad.
> 
> We inform you that the data controller is the Telefónica Group entity linked to the sender, for the purpose of maintaining professional contact and managing the relationship established with the recipient or with the entity to which it is linked. You may contact the data controller and exercise your rights by writing to [e-mail]. You may consult additional information on the processing of your data in our Privacy Policy.
> 
> Informamos que o responsável pelo tratamento dos seus dados é a entidade do Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional e administrar a relação estabelecida com o destinatário ou com a entidade à qual esteja vinculado. Você pode entrar em contato com o responsável do tratamento de dados e exercer os seus direitos escrevendo a [e-mail]. Você pode consultar informação adicional sobre o tratamento do seus dados na nossa Política de Privacidade.