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

[Lynne Bartholomew <[e-mail]>]

Dear IANA,

We are preparing this document for publication.

Please make the following update on <https://www.iana.org/assignments/xml-registry/ns/yang/ietf-sap-ntw.txt>:

OLD:  
N/A, the requested URI is an XML namespace.  
 
NEW:  
N/A; the requested URI is an XML namespace.

Thank you!

RFC Editor/lb

> On Jun 8, 2023, at 8:25 AM, Lynne Bartholomew <[e-mail]> wrote:
> 
> Hi, Qin.  No worries, and thank you for the email.
> 
> We have noted your approval on the AUTH48 status page:
> 
>   https://www.rfc-editor.org/auth48/rfc9408
> 
> As we now have all approvals, we will prepare this document for publication shortly.
> 
> Thanks again!
> 
> RFC Editor/lb
> 
>> On Jun 6, 2023, at 6:01 PM, Qin Wu <[e-mail]> wrote:
>> 
>> Lynne:
>> Apologize for late reply. The changes proposed in the latest version look good, I approve publication of this document.
>> 
>> -Qin 
>> -----邮件原件-----
>> 发件人: Lynne Bartholomew [mailto:[e-mail]] 
>> 发送时间: 2023年5月26日 22:35
>> 收件人: [e-mail]
>> 抄送: [e-mail]; [e-mail]; [e-mail]; Qin Wu <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
>> 主题: Re: AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for your review
>> 
>> 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.
>>> 
>> 
>> 
>> 
> 
> 
> 
>