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

[Lynne Bartholomew <[e-mail]>]

Great; thank you for the quick turnaround, Amanda!

(Not sure how/why "Erik Kline via RT" was in the "Reply-To", but including the address in this email as well.)

RFC Editor/lb

> On Jun 8, 2023, at 2:21 PM, Amanda Baber via RT <[e-mail]> wrote:
> 
> Hi,
> 
> This change is complete:
> 
> https://www.iana.org/assignments/xml-registry/ns/yang/ietf-sap-ntw.txt
> 
> thanks,
> Amanda
> 
> On Thu Jun 08 19:11:27 2023, [e-mail] wrote:
>> 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]; opsawg-
>>>>>> [e-mail];
>>>>>> [e-mail]; [e-mail]; auth48archive@rfc-
>>>>>> editor.org
>>>>>> 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.
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
> 
>