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

[Amanda Baber via RT <[e-mail]>]

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.
> >>>
> >>
> >>
> >>
> >
> >
> >
> >