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

[Lynne Bartholomew <[e-mail]>]

Hi, Samier and Victor.

We have noted your approvals on the AUTH48 status page:

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

Thank you!

RFC Editor/lb

> On May 31, 2023, at 6:15 AM, Victor Lopez (Nokia) <[e-mail]> wrote:
> 
> Hi
>  I’m good to go too.
>  Thanks
>  Regards,
>  Victor
>  From: Samier Barguil Giraldo (Nokia) <[e-mail]>
> Date: Wednesday, 31 May 2023 at 07:24
> To: Lynne Bartholomew <[e-mail]>, [e-mail] <[e-mail]>
> Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail]<[e-mail]>, Victor Lopez (Nokia) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
> Subject: RE: AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for your review
> Hello Lynne, 
> 
> This version looks good to me and I approve its publication.
> 
> Regards,
> 
> Samier Barguil
> 
> -----Original Message-----
> From: Lynne Bartholomew <[e-mail]> 
> Sent: Friday, May 26, 2023 6:35 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; Samier Barguil Giraldo (Nokia) <[e-mail]>; [e-mail]; Victor Lopez (Nokia) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for your review
> 
> 
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
> 
> 
> 
> Hi, Med.
> 
> We have changed "which" to "that" per your note below.
> 
> The latest files are posted here.  Please refresh your browser:
> 
>    https://www.rfc-editor.org/authors/rfc9408.txt
>    https://www.rfc-editor.org/authors/rfc9408.pdf
>    https://www.rfc-editor.org/authors/rfc9408.html
>    https://www.rfc-editor.org/authors/rfc9408.xml
>    https://www.rfc-editor.org/authors/rfc9408-diff.html
>    https://www.rfc-editor.org/authors/rfc9408-rfcdiff.html
>    https://www.rfc-editor.org/authors/rfc9408-auth48diff.html
>    https://www.rfc-editor.org/authors/rfc9408-lastdiff.html
>    https://www.rfc-editor.org/authors/rfc9408-lastrfcdiff.html
> 
>    https://www.rfc-editor.org/authors/rfc9408-xmldiff1.html
>    https://www.rfc-editor.org/authors/rfc9408-xmldiff2.html
>    https://www.rfc-editor.org/authors/rfc9408-alt-diff.html
> 
> We have also noted your approval on the AUTH48 status page:
> 
>    https://www.rfc-editor.org/auth48/rfc9408
> 
> Many thanks to you for your help and patience!
> 
> RFC Editor/lb
> 
> > On May 24, 2023, at 10:46 PM, <[e-mail]> <[e-mail]> wrote:
> >
> > Hi Lynne,
> >
> > Thank you for taking care of the changes.
> >
> > For item 17: s/which/that
> >
> > Other than that, this version looks good to me and I approve its publication.
> >
> > Many thanks for your careful edits. Much appreciated as usual.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Lynne Bartholomew <[e-mail]> Envoyé : mercredi 24 
> >> mai 2023 20:44 À : BOUCADAIR Mohamed INNOV/NET 
> >> <[e-mail]> Cc : [e-mail]; 
> >> [e-mail];
> >> [e-mail]; [e-mail]; 
> >> [e-mail]; [e-mail]; [e-mail]; 
> >> [e-mail]; [e-mail]; [e-mail] 
> >> Objet : Re: AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for 
> >> your review
> >>
> >> Hi, Med.
> >>
> >> Thank you for the emails and clarifications!  We have updated this 
> >> document per your notes below.
> >>
> >> Regarding singular vs. plural:  We reverted to the style used in the 
> >> original, even though there are several instances of "VPNs" as used 
> >> in the original (e.g., the second sentence of the Introduction).  We 
> >> followed suit with UNI/NNI vs. UNIs/NNIs and UNI-N (i.e., reverted 
> >> our updates).
> >>
> >> = = = = =
> >>
> >> Regarding this question and your reply:
> >>
> >>>> 1) <!-- [rfced] We changed "A YANG Model" to "A YANG Network
> >> Model"
> >>>> in the abbreviated (running) document title to match "Network
> >> Model"
> >>>> in the full title.  Please let us know any concerns.
> >>>>
> >>>> Original:
> >>>> A YANG Model for SAPs
> >>>>
> >>>> Currently:
> >>>> A YANG Network Model for SAPs -->
> >>>>
> >>>>
> >>>
> >>> [Med] The mention of "network model" is important here to insist
> >> that this is not about a device data model. We can update the title 
> >> to align with the usage in RFC9182/9291:
> >>>
> >>> NEW:
> >>> A YANG Network Data Model for Service Attachment Points (SAPs)
> >>
> >> Perhaps we misunderstood your request.  The expanded "SAPs" made the 
> >> abbreviated title too long.  We received this warning:
> >>
> >> Warning: Expected a title or title abbreviation of not more than 40 
> >> character for the page header, found 62 characters
> >>
> >> We changed the full title to "A YANG Network Data Model for Service 
> >> Attachment Points (SAPs)" and the abbreviated title to "A YANG 
> >> Network Data Model for SAPs".  Please let us know any concerns.
> >>
> >> = = = = =
> >>
> >> Regarding this question and your "NEW" text:
> >>
> >>>> 17) <!-- [rfced] Appendix D:  This sentence did not parse.  We 
> >>>> updated the text per the last sentence of Appendix A, Paragraph
> >> 1.
> >>>> If this update is incorrect, please clarify the meaning of "and
> >> that
> >>>> none of ...".
> >>>>
> >>>> Original:
> >>>> This is
> >>>> particularly inferred from the administrative 'service-status'
> >>>> which
> >>>> is set to 'ietf-vpn-common:admin-down' for all the services that
> >> are
> >>>> supported by these two SAPs and that none of the anomalies
> >> discussed
> >>>> in Section 5 are detected.
> >>>>
> >>>> Currently:
> >>>> This is
> >>>> particularly inferred from the administrative 'service-status',
> >> which
> >>>> is set to 'ietf-vpn-common:admin-down' for all the services that
> >> are
> >>>> supported by these two SAPs.  Note that none of the anomalies 
> >>>> discussed in Section 5 are detected. -->
> >>>>
> >>>
> >>> [Med] What about:
> >>>
> >>> NEW:
> >>>  This is
> >>>  particularly inferred from (1) the administrative 'service-
> >> status' which
> >>>  is set to 'ietf-vpn-common:admin-down' for all the services that
> >> are
> >>>  supported by these two SAPs and (2) the absence of the anomalies
> >> discussed
> >>>  in Section 5.
> >>
> >> Is the administrative 'service-status' only sometimes set to 'ietf- 
> >> vpn-common:admin-down' (in which case "which" should be "that"), or 
> >> is it always set to 'ietf-vpn-common:admin-down' (in which case a 
> >> comma should precede the "which")?
> >>
> >> = = = = =
> >>
> >> The latest files are posted here.  Please refresh your browser:
> >>
> >>
> >   https://www.rfc-editor.org/authors/rfc9408.txt
> >   https://www.rfc-editor.org/authors/rfc9408.pdf
> >   https://www.rfc-editor.org/authors/rfc9408.html
> >   https://www.rfc-editor.org/authors/rfc9408.xml
> >   https://www.rfc-editor.org/authors/rfc9408-diff.html
> >   https://www.rfc-editor.org/authors/rfc9408-rfcdiff.html
> >   https://www.rfc-editor.org/authors/rfc9408-auth48diff.html
> >
> >   https://www.rfc-editor.org/authors/rfc9408-alt-diff.html
> >   https://www.rfc-editor.org/authors/rfc9408-xmldiff1.html
> >   https://www.rfc-editor.org/authors/rfc9408-xmldiff2.html
> >   https://www.rfc-editor.org/authors/rfc9408-alt-diff.html
> >> Thanks again!
> >>
> >> RFC Editor/lb
> >>
> >>
> >>> On May 23, 2023, at 10:29 AM, [e-mail] wrote:
> >>>
> >>> Hi Lynne,
> >>>
> >>> Sure. The proposed change is as follows:
> >>>
> >>> OLD:
> >>>  *  L3VPNs [RFC4364]
> >>>
> >>>  *  Virtual Private LAN Services (VPLSs) [RFC4761] [RFC4762]
> >>>
> >>>  *  Virtual Private Wire Services (VPWSs) [RFC8214]
> >>>
> >>>  *  BGP MPLS-based Ethernet VPNs [RFC7432]
> >>>
> >>>  *  VPWSs in Ethernet VPNs [RFC8214]
> >>>
> >>>  *  Provider Backbone Bridging combined with Ethernet VPNs (PBB-
> >> EVPNs)
> >>>     [RFC7623]
> >>>
> >>>  *  VXLAN-based EVPNs [RFC8365] ("VXLAN" stands for "Virtual
> >>>     eXtensible Local Area Network")
> >>>
> >>>  *  Virtual Networks [RFC8453]
> >>>
> >>>  *  Enhanced VPN (VPN+) [ENHANCED-VPN]
> >>>
> >>>  *  Network slices [IETF-NETWORK-SLICES]
> >>>
> >>>  *  SD-WAN overlay networks [BGP-SDWAN-USAGE]
> >>>
> >>>  *  Basic IP connectivity
> >>>
> >>> NEW:
> >>>  *  L3VPN [RFC4364]
> >>>
> >>>  *  Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762]
> >>>
> >>>  *  Virtual Private Wire Service (VPWS) [RFC8214]
> >>>
> >>>  *  BGP MPLS-based Ethernet VPN [RFC7432]
> >>>
> >>>  *  VPWS in Ethernet VPN [RFC8214]
> >>>
> >>>  *  Provider Backbone Bridging combined with Ethernet VPN (PBB-
> >> EVPN)
> >>>     [RFC7623]
> >>>
> >>>  *  VXLAN-based EVPN [RFC8365] ("VXLAN" stands for "Virtual
> >>>     eXtensible Local Area Network")
> >>>
> >>>  *  Virtual Networks [RFC8453]
> >>>
> >>>  *  Enhanced VPN (VPN+) [ENHANCED-VPN]
> >>>
> >>>  *  Network slice service [IETF-NETWORK-SLICES]
> >>>
> >>>  *  SD-WAN [BGP-SDWAN-USAGE]
> >>>
> >>>  *  Basic IP connectivity
> >>>
> >>> Cheers,
> >>> Med
> >>
> >>
> >> = = = = = = = =
> >>
> >>> On May 23, 2023, at 4:28 AM, [e-mail] wrote:
> >>>
> >>> Re-,
> >>>
> >>> Thanks for sharing this edited version. Overall, the edits look
> >> good. However:
> >>>
> >>> (1) Rather than using the plural form as suggested in the edited
> >> version, I would maintain the singular form of the services
> >> (Original) listed right after:
> >>>
> >>>  A SAP network topology can be used for one or multiple service
> >> types
> >>>  ('service-type').  Examples of supported service types are as
> >>>  follows:
> >>>
> >>> For example, we are referring to "VPN" as a service, not the VPN
> >> instances of the service. FWIW, this would be consistent with the 
> >> usage in Section 3 of RFC9181.
> >>>
> >>> The same apply for the changes in the abstract, but I'm OK to
> >> maintain the edits in the abstract if you prefer.
> >>>
> >>> (2) I'm not sure we need to add "see" when pointing to refs. I
> >> would revert to the OLD versions. There are many occurrences in the 
> >> edited version.
> >>>
> >>> (3) Please make this change in Section 2:
> >>>
> >>> OLD:
> >>>  Attachment Circuit (AC):  A channel that connects a Customer
> >> Edge
> >>>     (CE) to a Provider Edge (PE).  The AC may be a physical or
> >> logical
> >>>     link (Section 6.1 of [RFC4026]).
> >>>
> >>> NEW:
> >>>  Attachment Circuit (AC):  A channel that connects a Customer
> >> Edge
> >>>     (CE) to a Provider Edge (PE).
> >>>
> >>> FWIW, this change was shared with the WG since 02/23. The
> >> rationale can be seen at:
> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> >> ilarchive.ietf.org%2Farch%2Fmsg%2Fopsawg%2F_Iiv16zSUnnGuSxywvXlROqh2
> >> AI%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C0db08cfbe50745
> >> 6f7f9f08db5c871280%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382
> >> 05510092419895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> >> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DF8f31Dp
> >> wQBzL0SCCEm1WQaz1Z2aBOT1i2IVVt83m4c%3D&reserved=0.
> >>>
> >>> Thank you.
> >>>
> >>> Cheers,
> >>> Med
> >>
> >> = = = = = = = =
> >>
> >>> On May 23, 2023, at 12:49 AM, [e-mail] wrote:
> >>>
> >>> Dear RFC Editor, all,
> >>>
> >>> Please see inline.
> >>>
> >>> Cheers,
> >>> Med
> >>>
> >>>> -----Message d'origine-----
> >>>> De : [e-mail] <[e-mail]> Envoyé : 
> >>>> lundi 22 mai 2023 22:44 À : BOUCADAIR Mohamed INNOV/NET 
> >>>> <[e-mail]>; 
> >>>> [e-mail];
> >>>> [e-mail]; [e-mail]; 
> >>>> [e-mail] Cc : [e-mail]; 
> >>>> [e-mail]; opsawg- [e-mail]; [e-mail]; 
> >>>> [e-mail]; [e-mail] Objet : Re: AUTH48: 
> >>>> RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for your review
> >>>>
> >>>> Authors,
> >>>>
> >>>> While reviewing this document during AUTH48, please resolve (as
> >>>> necessary) the following questions, which are also in the XML file.
> >>>>
> >>>>
> >>>> 1) <!-- [rfced] We changed "A YANG Model" to "A YANG Network
> >>>> Model" in the abbreviated (running) document title to match
> >>>> "Network Model" in the full title.  Please let us know any
> >>>> concerns.
> >>>>
> >>>> Original:
> >>>> A YANG Model for SAPs
> >>>>
> >>>> Currently:
> >>>> A YANG Network Model for SAPs -->
> >>>>
> >>>>
> >>>
> >>> [Med] The mention of "network model" is important here to insist
> >> that this is not about a device data model. We can update the title
> >> to align with the usage in RFC9182/9291:
> >>>
> >>> NEW:
> >>> A YANG Network Data Model for Service Attachment Points (SAPs)
> >>>
> >>>
> >>>> 2) <!-- [rfced] Abstract and subsequent:  It looks a bit odd to
> >>>> use "User-Network Interface" for "UNI" but "Network-to-Network
> >>>> Interface"
> >>>> for "NNI" and "UNI-N (User-to-Network Interface, Network side)
> >>>> [RFC6215]" as seen in Section 3.
> >>>>
> >>>> Does "User-Network Interface" mean "User-to-Network Interface",
> >>>
> >>> [Med] Yes. Both are actually used in existing RFCs. "User-Network
> >> Interface" is what is used by some other SDOs (see, e.g., the MEF
> >> refs in the I-D). That's said, we need to be consistent and use the
> >> same form for both UNI and NNI.
> >>>
> >>> as
> >>>> used in some RFCs?  Or does it mean "the user network's
> >>>> interface"?
> >>>>
> >>>> (Side note:  We see a few instances of "Network-Network
> >> Interface"
> >>>> in published RFCs, but "Network-to-Network Interface" is used
> >> more
> >>>> often.)
> >>>
> >>> [Med] OK to use "*-to-*" for both UNI/NNI.
> >>>
> >>>>
> >>>> Original:
> >>>> Both User-Network Interface (UNI) and Network-to-  Network
> >>>> Interface (NNI) are supported in the SAP data model.
> >>>> ...
> >>>> Given that User-Network Interface (UNI) and Network-to-Network
> >>>> Interface (NNI) are reference points that are widely used by
> >>>> operators to indicate the demarcation points when delivering
> >>>> services, both UNI and NNI SAPs are supported in the document.
> >>>> ...
> >>>> etc. -->
> >>>>
> >>>>
> >>>> 3) <!-- [rfced] Section 1:  This sentence did not parse.  We
> >>>> updated it as follows.  If this is incorrect, please provide
> >>>> clarifying text.
> >>>>
> >>>> Original:
> >>>> Whether a SAP topology is dedicated to services of a specific
> >>>> service type, an individual service, or shared among many
> >> services
> >>>> of  different types is deployment specific.
> >>>>
> >>>> Currently:
> >>>> Whether a SAP topology is dedicated to services of a specific
> >>>> service type or an individual service, or is shared among many
> >>>> services of different types, is deployment specific. -->
> >>>>
> >>>
> >>> [Med] Works for me. Thanks.
> >>>
> >>>>
> >>>> 4) <!-- [rfced] Section 3:  We changed "the module" to "the
> >> model"
> >>>> in the second sentence here, as it appears that the text refers
> >> to
> >>>> the model and not to the YANG module provided in Section 6.  If
> >>>> this update is incorrect, please provide clarifying text.
> >>>>
> >>>> Original (the previous sentence is included for context):
> >>>> The model is also used to retrieve the network reference points
> >>>> where  a service is being delivered to customers.  For services
> >>>> that require  resources from peer networks, the module can also
> >> be
> >>>> used to expose  NNIs.
> >>>>
> >>>> Currently:
> >>>> The model is also used to retrieve the network  reference points
> >>>> where a service is being delivered to customers.
> >>>> For services that require resources from peer networks, the model
> >>>> can  also be used to expose NNIs. -->
> >>>>
> >>>
> >>> [Med] OK.
> >>>
> >>>>
> >>>> 5) <!-- [rfced] Please review each artwork element in this
> >>>> document.
> >>>> Specifically, should any artwork element be tagged as sourcecode
> >>>> or another element?  For example, are Figures 7, 9, 10, and 12 in
> >>>> the appendices JSON?
> >>>
> >>> [Med] Yes.
> >>>
> >>> If yes, should an Informative Reference be
> >>>> provided - perhaps to RFC 8259 - in text just prior to Figure 7?
> >>>
> >>> [Med] I suggest to add the following + list 7951 as an Informative
> >> Reference:
> >>>
> >>> NEW:
> >>> The message body depicted in the figures is encoded following the
> >>> the JSON encoding of YANG-modeled data as per [[RFC7951].
> >>>
> >>>>
> >>>> If the current list of preferred values for "type"
> >>>>
> >> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>> Fwww.rfc-editor.org%2Fmaterials%2Fsourcecode-
> >>>>
> >> types.txt&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Caa068512
> >>>>
> >> cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> >>>>
> >> 0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> >>>>
> >> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
> >>>>
> >> ata=5NjV1F%2B24%2F8MtaBk3IgE0S0PTB9M31fHpqEG%2BjJoI2k%3D&reserved=
> >>>> 0)
> >>>> does not contain an applicable type, then feel free to let us
> >>>> know.
> >>>> Also, it is acceptable to leave the "type" attribute not set. -->
> >>>>
> >>>>
> >>>> 6) <!-- [rfced] Section 3:  As we don't see "P node" or "P nodes"
> >>>> mentioned anywhere else in this document and the next sentence
> >>>> after
> >>>> this text mentions Figure 2 (which shows PE nodes), we changed
> >>>> "P nodes" to "PE nodes" here.  If this is incorrect, please
> >>>> provide
> >>>> text that clarifies the meaning of "P nodes".
> >>>
> >>> [Med] The OLD version is correct. Please revert back.
> >>>
> >>> "P" nodes are hidden in the cloud shown in Figure 2, for example.
> >> We used to have these nodes drawn there but we removed them to
> >> simplify the figures.
> >>>
> >>> FWIW, please see
> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
> >> tatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4026%23autoid-
> >> 37&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C0db08cfbe507456f7
> >> f9f08db5c871280%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382055
> >> 10092419895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> >> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4Ad1rENUXqN
> >> VFtbzWrWtrTpD7n70XxR4SnEKvVPuB3w%3D&reserved=0.
> >>>
> >>> If needed, we can make this change: s/P nodes/P nodes (Section
> >> 5.3.1 of [RFC4026])
> >>>
> >>>>
> >>>> Original (the next sentence is included for context):
> >>>> The service orchestration layer does not need to know about all
> >>>> the
> >>>> internals of the underlying network (e.g., P nodes).  Figure 2
> >>>> shows
> >>>> the abstract network view as seen by a service orchestrator.
> >>>>
> >>>> Currently:
> >>>> The service orchestration layer does not need to know about all
> >>>> the
> >>>> internals of the underlying network (e.g., PE nodes). -->
> >>>>
> >>>>
> >>>> 7) <!-- [rfced] Section 4:  We had trouble following the use of
> >>>> capitalization in this sentence (for example, as compared to
> >>>> "SAP network model").
> >>>>
> >>>> Original:
> >>>> The SAP network model augments the Network model [RFC8345]
> >>>> and imports the Network Topology model, while other technology-
> >>>> specific topology models (e.g., Traffic Engineering (TE)
> >>>> Topologies
> >>>> model [RFC8795] or Layer 3 Topologies model [RFC8346]) augment
> >>>> the
> >>>> Network Topology model.
> >>>>
> >>>> Possibly:
> >>>> The SAP network model augments the network model defined in
> >>>> [RFC8345] and imports the network topology model defined in
> >>>> [RFC8345], while other technology-specific topology models (e.g.,
> >>>> the model for Traffic Engineering (TE) topologies [RFC8795] or
> >>>> the
> >>>> model for Layer 3 topologies [RFC8346]) augment the network
> >>>> topology model defined in [RFC8345]. -->
> >>>>
> >>>
> >>> [Med] OK.
> >>>
> >>>>
> >>>> 8) <!-- [rfced] Section 4:  We see that "TP" and "TTP" are
> >> defined
> >>>> in
> >>>> this paragraph, but these abbreviations are not used again.
> >> Which
> >>>> of
> >>>> the following update options would you prefer?
> >>>>
> >>>> 1. Use "TP" instead of "termination point" in the eight
> >> subsequent
> >>>> instances of this term (except for Section 6, where we would
> >>>> change
> >>>> "parent termination point" to "parent termination point (TP)" and
> >>>> then use "TP" in the next sentence).
> >>>>
> >>>> 2. Remove the abbreviations from this paragraph and spell out
> >>>> "termination point".
> >>>>
> >>>> Original:
> >>>> SAPs can be seen as customer-facing termination points (TPs) with
> >>>> specific service provisions.  However, a difference between SAPs
> >>>> and
> >>>> TPs is that links are terminated by a single TP (Section 4.4.6 of
> >>>> [RFC8345]) while an AC can be terminated by multiple SAPs.  Also,
> >>>> a
> >>>> SAP is not a tunnel termination point (TTP) (Section 3.6 of
> >>>> [RFC8795]) nor a link. -->
> >>>>
> >>>
> >>> [Med] I prefer to leave the Original version with "termination
> >> point" expanded. The abbreviations are included to help readers
> >> correlate with other context. I don't think a change is needed here.
> >>>
> >>>>
> >>>> 9) <!-- [rfced] Section 5:  Should "network modules" and "SAP
> >>>> network
> >>>> module" in these sentences be "network models" and "SAP network
> >>>> model"?  We ask (particularly in the case of "SAP network
> >> module")
> >>>> because of this sentence from Section 4.4 of [RFC8969], as it
> >> does
> >>>> not use the word "module":
> >>>>
> >>>> "Service Decomposition allows to decompose service models at the
> >>>> service level or network models at the network level into a set
> >>>> of
> >>>> device models at the device level."
> >>>>
> >>>> Original:
> >>>> |  Leveraging the service types defined in [RFC9181] is meant to
> >>>> |  ease the correlation between the SAP topology and the
> >>>> |  corresponding network modules that are used to provision a
> >>>> |  specific service over a provider's network.
> >>>> ...
> >>>> That mapping is used, for example,
> >>>> when the controller translates this SAP network module into
> >>>> device
> >>>> modules (Section 4.4 of [RFC8969]).
> >>>>
> >>>> Possibly:
> >>>> |  Leveraging the service types defined in [RFC9181] is meant to
> >>>> |  ease the correlation between the SAP topology and the
> >>>> |  corresponding network models that are used to provision a
> >>>> |  specific service over a provider's network.
> >>>> ...
> >>>> That mapping is used, for example,
> >>>> when the controller translates this SAP network model into device
> >>>> models (Section 4.4 of [RFC8969]). -->
> >>>>
> >>>
> >>> [Med] Works for me. Thanks.
> >>>
> >>>>
> >>>> 10) <!-- [rfced] Section 5:  Please clarify the meaning of "in
> >>>> association" in this sentence.
> >>>>
> >>>> Original (the previous sentence is included for context):
> >>>> The same SAP may appear under distinct service types.  In such a
> >>>> case, the same identifier is used for these service types in
> >>>> association.
> >>>>
> >>>> Possibly:
> >>>> The same SAP may appear under distinct service types.  In such a
> >>>> case, the same identifier is used for these service types in
> >>>> order to associate them. -->
> >>>>
> >>>
> >>> [Med] What about:
> >>>
> >>> NEW:
> >>> The same SAP may appear under distinct service types.  In such a
> >>> case, the same identifier is used for a shared SAP for each of
> >> these
> >>> service types.
> >>>
> >>>
> >>>>
> >>>> 11) <!-- [rfced] Section 5:  As we do not see "mode" or "modes"
> >>>> used
> >>>> anywhere else in this document, we changed "device modes" to
> >>>> "device
> >>>> models" in this sentence.
> >>>
> >>> [Med] The change is correct. Thanks for catching this.
> >>>
> >>>
> >>> If this is incorrect, should the use of
> >>>> "modes" be clarified for readers?
> >>>>
> >>>> Original:
> >>>> It
> >>>> is the responsibility of the controller to ensure that consistent
> >>>> references are used in the SAP and underlying device modes or any
> >>>> other device inventory mechanism.
> >>>>
> >>>> Currently:
> >>>> The controller is responsible for ensuring that consistent
> >>>> references are used in the SAP and underlying device models or
> >>>> any
> >>>> other device inventory mechanism. -->
> >>>>
> >>>>
> >>>> 12) <!-- [rfced] Sections 5 and 6:  We defined "IRB" as
> >>>> "Integrated
> >>>> Routing and Bridging (IRB) interface", per RFC 9135 and other
> >>>> post-6000 published RFCs.
> >>>>
> >>>> Also, please note that in Section 6 we expanded "IP-VRF" as "IP
> >>>> Virtual Routing and Forwarding" for ease of the reader.
> >>>>
> >>>
> >>> [Med] OK.
> >>>
> >>>> Please let us know any concerns.
> >>>>
> >>>> Original:
> >>>> 'interface-type':  Indicates whether a SAP is bound to a physical
> >>>>   port, a loopback interface, a Link Aggregation Group (LAG)
> >>>>   interface [IEEE802.1AX], an Integrated Routing Bridge (IRB)
> >>>> (e.g.,
> >>>>   [RFC9135]), a local bridge reference, etc.
> >>>> ...
> >>>> "Integrated Routing Bridge (IRB). An IRB typically
> >>>> connects an IP-VRF to a bridge domain.";
> >>>>
> >>>> Currently:
> >>>> 'interface-type':  Indicates whether a SAP is bound to a physical
> >>>>   port, a loopback interface, a Link Aggregation Group (LAG)
> >>>>   interface [IEEE802.1AX], an Integrated Routing and Bridging
> >>>> (IRB)
> >>>>   interface (e.g., see [RFC9135]), a local bridge reference,
> >>>> etc.
> >>>> ...
> >>>> "Integrated Routing and Bridging (IRB) interface.  An IRB
> >>>> interface typically connects an IP Virtual Routing and
> >>>> Forwarding (IP-VRF) entity to a bridge domain."; -->
> >>>>
> >>>>
> >>>> 13) <!-- [rfced] Section 5:  The latest version of
> >>>> draft-ietf-teas-ietf-network-slices (-19) does not have a
> >>>> Section 2.1, nor does the version (-18) provided in the original
> >>>> copy of this document.
> >>>
> >>> [Med] That section was renumbered to Section 3.2
> >> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fa
> >> uthor-tools.ietf.org%2Fiddiff%3Furl1%3Ddraft-ietf-teas-ietf-network-
> >> slices-16%26url2%3Ddraft-ietf-teas-ietf-network-slices-
> >> 17%26difftype%3D--
> >> html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C0db08cfbe507456
> >> f7f9f08db5c871280%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63820
> >> 5510092576163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> >> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KkFAYskXL
> >> 21ew74%2Fntlb1YH7PhVpXlR%2BLMs13aBX5kc%3D&reserved=0).
> >>>
> >>> What about:
> >>>
> >>> s/Section 2.1 of [I-D.ietf-teas-ietf-network-slices]/the "Core
> >> Terminology" Section of [I-D.ietf-teas-ietf-network-slices]
> >>>
> >>>
> >>> Please see
> >>>>
> >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>> Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teas-ietf-
> >> network-
> >>>> slices-
> >>>>
> >> 19&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Caa068512cee4460
> >>>>
> >> 9f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
> >>>>
> >> 203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> >>>>
> >> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4p4
> >>>> ZMp%2Fa%2FEGEBxPsKQEOs1bVFLF21uIZx8M0kDSexOQ%3D&reserved=0>,
> >>>> and let us know which section number should be cited.
> >>>>
> >>>> Original:
> >>>> Examples of such a reference are: a site identifier (Section 6.3
> >>>> of [RFC8299]), a Service Demarcation Point (SDP) identifier
> >>>> (Section 2.1 of [I-D.ietf-teas-ietf-network-slices]), and the IP
> >>>> address of a peer Autonomous System Border Router (ASBR). -->
> >>>>
> >>>>
> >>>> 14) <!-- [rfced] Section 6:  Informative Reference RFC 8343 is
> >> not
> >>>> mentioned anywhere else in this document.  Is an "import"
> >>>> statement
> >>>> missing in the YANG module (in which case it should be a
> >> Normative
> >>>> Reference instead)?
> >>>>
> >>>
> >>> [Med] We used to have an import in a previous version, but forgot
> >> to remove it when we updated the design. Please remove 8343 for the
> >> references and make this change:
> >>>
> >>> OLD:
> >>>  This module imports types from [RFC6991], [RFC8343], [RFC8345],
> >> and
> >>>  [RFC9181].
> >>>
> >>> NEW:
> >>>  This module imports types from [RFC6991], [RFC8345], and
> >>>  [RFC9181].
> >>>
> >>>> Also, because RFC 8453 is referenced in the YANG module, may we
> >>>> add
> >>>> "This module also references [RFC8453]." after the "This module
> >>>> imports" sentence?
> >>>>
> >>>
> >>> [Med] We don't need this change as the ref is already called out
> >> in Section 5.
> >>>
> >>>> Original:
> >>>> This module imports types from [RFC6991], [RFC8343], [RFC8345],
> >>>> and
> >>>> [RFC9181].
> >>>> ...
> >>>> reference
> >>>>  "RFC 8453: Framework for Abstraction and Control of TE
> >>>>             Networks (ACTN)";
> >>>> ...
> >>>> Under Informative References:
> >>>> [RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
> >>>>           Management", RFC 8343, DOI 10.17487/RFC8343, March
> >>>> 2018,
> >>>>
> >>>>
> >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>> Fwww.rfc-
> >>>>
> >> editor.org%2Finfo%2Frfc8343&data=05%7C01%7Cmohamed.boucadair%40ora
> >>>>
> >> nge.com%7Caa068512cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b
> >>>>
> >> 9253b6f5d20%7C0%7C0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8e
> >>>>
> >> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> >>>>
> >> 7C3000%7C%7C%7C&sdata=bg339ojOWZvxVQkbkw9eXQtuazGdWaM6dX5iy62NXqM%
> >>>> 3D&reserved=0>. -->
> >>>>
> >>>>
> >>>> 15) <!-- [rfced] Section 6:  Does "independent" refer to
> >>>> "Indicates"
> >>>> (in which case it should be "independently"), or does it refer to
> >>>> "operational status" (in which case the current text is correct)?
> >>>>
> >>>
> >>> [Med] It refers to the "operational status".
> >>>
> >>>> Original:
> >>>> "Indicates the operational status of the SAP,
> >>>> independent of any service provisioned over it."; -->
> >>>>
> >>>>
> >>>> 16) <!-- [rfced] Security Considerations:  It appears that RPC
> >>>> operations
> >>>> do not apply to this document.  Please confirm.
> >>>>
> >>>
> >>> [Med] ACK.
> >>>
> >>>> If you have any questions, please see
> >>>>
> >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>> Fwiki.ietf.org%2Fgroup%2Fops%2Fyang-security-
> >>>>
> >> guidelines&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Caa06851
> >>>>
> >> 2cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> >>>>
> >> C0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> >>>>
> >> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
> >>>>
> >> data=7hC%2FMAswX%2Fot7p8qwtaWrZfrRRzpOwwLl2EUWnWlZjU%3D&reserved=0
> >>>>>
> >>>> for details. -->
> >>>>
> >>>>
> >>>> 17) <!-- [rfced] Appendix D:  This sentence did not parse.  We
> >>>> updated
> >>>> the text per the last sentence of Appendix A, Paragraph 1.  If
> >>>> this
> >>>> update is incorrect, please clarify the meaning of "and that none
> >>>> of ...".
> >>>>
> >>>> Original:
> >>>> This is
> >>>> particularly inferred from the administrative 'service-status'
> >>>> which
> >>>> is set to 'ietf-vpn-common:admin-down' for all the services that
> >>>> are
> >>>> supported by these two SAPs and that none of the anomalies
> >>>> discussed
> >>>> in Section 5 are detected.
> >>>>
> >>>> Currently:
> >>>> This is
> >>>> particularly inferred from the administrative 'service-status',
> >>>> which
> >>>> is set to 'ietf-vpn-common:admin-down' for all the services that
> >>>> are
> >>>> supported by these two SAPs.  Note that none of the anomalies
> >>>> discussed in Section 5 are detected. -->
> >>>>
> >>>
> >>> [Med] What about:
> >>>
> >>> NEW:
> >>>  This is
> >>>  particularly inferred from (1) the administrative 'service-
> >> status' which
> >>>  is set to 'ietf-vpn-common:admin-down' for all the services that
> >> are
> >>>  supported by these two SAPs and (2) the absence of the anomalies
> >> discussed
> >>>  in Section 5.
> >>>
> >>>>
> >>>> 18) <!-- [rfced] Please review the "Inclusive Language" portion
> >> of
> >>>> the
> >>>> online Style Guide at
> >>>>
> >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>> Fwww.rfc-
> >>>>
> >> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C
> >>>>
> >> 01%7Cmohamed.boucadair%40orange.com%7Caa068512cee44609f0ca08db5b05
> >>>>
> >> 5b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382038511140727
> >>>>
> >> 26%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> >>>>
> >> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FxEg4CmJqMrsXj
> >>>> xFxczqrWX%2FhaHMphrGkImd8eCWeHE%3D&reserved=0>,
> >>>> and let us know if any changes are needed.
> >>>>
> >>>> Note that our script did not flag any words in particular, but
> >>>> this
> >>>> should still be reviewed as a best practice. -->
> >>>>
> >>>>
> >>>
> >>> [Med] ACK.
> >>>
> >>>> 19) <!-- [rfced] The following term was used inconsistently in
> >>>> this
> >>>> document.  We chose to use the latter form.  Please let us know
> >>>> any
> >>>> objections.
> >>>>
> >>>> IETF network slice / IETF Network Slice (per
> >>>>  draft-ietf-teas-ietf-network-slices-19) -->
> >>>>
> >>>
> >>> [Med] OK.
> >>>
> >>>>
> >>>> Thank you.
> >>>>
> >>>> RFC Editor/lb/rv
> >>>>
> >>>>
> >>>>
> >>>> On May 22, 2023, at 1:30 PM, [e-mail] wrote:
> >>>>
> >>>> *****IMPORTANT*****
> >>>>
> >>>> Updated 2023/05/22
> >>>>
> >>>> RFC Author(s):
> >>>> --------------
> >>>>
> >>>> Instructions for Completing AUTH48
> >>>>
> >>>> Your document has now entered AUTH48.  Once it has been reviewed
> >>>> and
> >>>> approved by you and all coauthors, it will be published as an
> >> RFC.
> >>>> If an author is no longer available, there are several remedies
> >>>> available as listed in the FAQ
> >>>>
> >> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>> Fwww.rfc-
> >>>>
> >> editor.org%2Ffaq%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%
> >>>>
> >> 7Caa068512cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5
> >>>>
> >> d20%7C0%7C0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> >>>>
> >> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> >>>>
> >> C%7C%7C&sdata=3X0NPJbD6s7SjNjcCgf3d4pr7%2FD3w7esNWzUEH0TK%2Fw%3D&r
> >>>> eserved=0).
> >>>>
> >>>> You and you coauthors are responsible for engaging other parties
> >>>> (e.g., Contributors or Working Group) as necessary before
> >>>> providing
> >>>> your approval.
> >>>>
> >>>> Planning your review
> >>>> ---------------------
> >>>>
> >>>> Please review the following aspects of your document:
> >>>>
> >>>> *  RFC Editor questions
> >>>>
> >>>> Please review and resolve any questions raised by the RFC Editor
> >>>> that have been included in the XML file as comments marked as
> >>>> follows:
> >>>>
> >>>> <!-- [rfced] ... -->
> >>>>
> >>>> These questions will also be sent in a subsequent email.
> >>>>
> >>>> *  Changes submitted by coauthors
> >>>>
> >>>> Please ensure that you review any changes submitted by your
> >>>> coauthors.  We assume that if you do not speak up that you
> >>>> agree to changes submitted by your coauthors.
> >>>>
> >>>> *  Content
> >>>>
> >>>> Please review the full content of the document, as this cannot
> >>>> change once the RFC is published.  Please pay particular
> >>>> attention to:
> >>>> - IANA considerations updates (if applicable)
> >>>> - contact information
> >>>> - references
> >>>>
> >>>> *  Copyright notices and legends
> >>>>
> >>>> Please review the copyright notice and legends as defined in
> >>>> RFC 5378 and the Trust Legal Provisions
> >>>> (TLP -
> >>>>
> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>>> trustee.ietf.org%2Flicense-
> >>>>
> >> info%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Caa068512ce
> >>>>
> >> e44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> >>>>
> >> 7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> >>>>
> >> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat
> >>>> a=B0gciAKpYepmwZWLRH6Tbv4JE6IEMdCZWUaybG3OrMc%3D&reserved=0).
> >>>>
> >>>> *  Semantic markup
> >>>>
> >>>> Please review the markup in the XML file to ensure that elements
> >>>> of
> >>>> content are correctly tagged.  For example, ensure that
> >>>> <sourcecode>
> >>>> and <artwork> are set correctly.  See details at
> >>>>
> >>>>
> >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>> Fauthors.ietf.org%2Frfcxml-
> >>>>
> >> vocabulary&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Caa06851
> >>>>
> >> 2cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> >>>>
> >> C0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> >>>>
> >> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
> >>>>
> >> data=IcRNNGnHecShyTp1hHzpP2vQPzREsoWILEQ%2B%2BsbNXn8%3D&reserved=0
> >>>>> .
> >>>>
> >>>> *  Formatted output
> >>>>
> >>>> Please review the PDF, HTML, and TXT files to ensure that the
> >>>> formatted output, as generated from the markup in the XML file,
> >>>> is
> >>>> reasonable.  Please note that the TXT will have formatting
> >>>> limitations compared to the PDF and HTML.
> >>>>
> >>>>
> >>>> Submitting changes
> >>>> ------------------
> >>>>
> >>>> To submit changes, please reply to this email using 'REPLY ALL'
> >> as
> >>>> all
> >>>> the parties CCed on this message need to see your changes. The
> >>>> parties
> >>>> include:
> >>>>
> >>>> *  your coauthors
> >>>>
> >>>> *  [e-mail] (the RPC team)
> >>>>
> >>>> *  other document participants, depending on the stream (e.g.,
> >>>>    IETF Stream participants are your working group chairs, the
> >>>>    responsible ADs, and the document shepherd).
> >>>>
> >>>> *  [e-mail], which is a new archival mailing
> >>>> list
> >>>>    to preserve AUTH48 conversations; it is not an active
> >>>> discussion
> >>>>    list:
> >>>>
> >>>>   *  More info:
> >>>>
> >>>>
> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>>> mailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-
> >>>>
> >> 4Q9l2USxIAe6P8O4Zc&data=05%7C01%7Cmohamed.boucadair%40orange.com%7
> >>>>
> >> Caa068512cee44609f0ca08db5b055b54%7C90c7a20af34b40bfbc48b9253b6f5d
> >>>>
> >> 20%7C0%7C0%7C638203851114072726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> >>>>
> >> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> >>>>
> >> %7C%7C&sdata=5K2ALQOAyoHogs8kmSa6eYHpDGLAfUtNE8ojWfxcOEQ%3D&reserv
> >>>> ed=0
> >>>>
> >>>>   *  The archive itself:
> >>>>
> >>>>
> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>>>
> >> mailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C
> >>>>
> >> 01%7Cmohamed.boucadair%40orange.com%7Caa068512cee44609f0ca08db5b05
> >>>>
> >> 5b54%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382038511140727
> >>>>
> >> 26%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> >>>>
> >> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BRtJa3WaEgZliR
> >>>> ajCaGS%2FdUC5tFiu3axU9yZXszk8tE%3D&reserved=0
> >>>>
> >>>>   *  Note: If only absolutely necessary, you may temporarily opt
> >>>> out
> >>>>      of the archiving of messages (e.g., to discuss a sensitive
> >>>> matter).
> >>>>      If needed, please add a note at the top of the message that
> >>>> you
> >>>>      have dropped the address. When the discussion is concluded,
> >>>>      [e-mail] will be re-added to the CC
> >>>> list and
> >>>>      its addition will be noted at the top of the message.
> >>>>
> >>>> You may submit your changes in one of two ways:
> >>>>
> >>>> An update to the provided XML file
> >>>> - OR -
> >>>> An explicit list of changes in this format
> >>>>
> >>>> Section # (or indicate Global)
> >>>>
> >>>> OLD:
> >>>> old text
> >>>>
> >>>> NEW:
> >>>> new text
> >>>>
> >>>> You do not need to reply with both an updated XML file and an
> >>>> explicit
> >>>> list of changes, as either form is sufficient.
> >>>>
> >>>> We will ask a stream manager to review and approve any changes
> >>>> that seem
> >>>> beyond editorial in nature, e.g., addition of new text, deletion
> >>>> of text,
> >>>> and technical changes.  Information about stream managers can be
> >>>> found in
> >>>> the FAQ.  Editorial changes do not require approval from a stream
> >>>> manager.
> >>>>
> >>>>
> >>>> Approving for publication
> >>>> --------------------------
> >>>>
> >>>> To approve your RFC for publication, please reply to this email
> >>>> stating
> >>>> that you approve this RFC for publication.  Please use 'REPLY
> >>>> ALL',
> >>>> as all the parties CCed on this message need to see your
> >> approval.
> >>>>
> >>>
> >>>
> >
> >
> > _________________________________________________________________________________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> > Thank you.
> >