Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for your review
Lynne Bartholomew <lbartholomew@amsl.com> Thu, 08 June 2023 15:25 UTC
Return-Path: <lbartholomew@amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E652EC151090; Thu, 8 Jun 2023 08:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRDkm4EM_hJU; Thu, 8 Jun 2023 08:25:39 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF42CC151086; Thu, 8 Jun 2023 08:25:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 72531424CD3C; Thu, 8 Jun 2023 08:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMmugKZSLC5K; Thu, 8 Jun 2023 08:25:39 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2601:646:8b00:6da0:71fd:5f2f:a6a5:edcf]) by c8a.amsl.com (Postfix) with ESMTPSA id 25955424B440; Thu, 8 Jun 2023 08:25:39 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
From: Lynne Bartholomew <lbartholomew@amsl.com>
In-Reply-To: <7803bde3867b42abae3b9f186d0f5e28@huawei.com>
Date: Thu, 08 Jun 2023 08:25:28 -0700
Cc: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "oscar.gonzalezdedios@telefonica.com" <oscar.gonzalezdedios@telefonica.com>, "samier.barguil_giraldo@nokia.com" <samier.barguil_giraldo@nokia.com>, "victor.lopez@nokia.com" <victor.lopez@nokia.com>, "opsawg-ads@ietf.org" <opsawg-ads@ietf.org>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "rwilton@cisco.com" <rwilton@cisco.com>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E5751F43-FE2A-473C-8D70-70FE406AA507@amsl.com>
References: <7803bde3867b42abae3b9f186d0f5e28@huawei.com>
To: Qin Wu <bill.wu@huawei.com>
X-Mailer: Apple Mail (2.3731.200.110.1.12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/Llxhrwn4h808yNVSWtaGEVTcYec>
Subject: Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-opsawg-sap-15> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jun 2023 15:25:45 -0000
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 <bill.wu@huawei.com> 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:lbartholomew@amsl.com] > 发送时间: 2023年5月26日 22:35 > 收件人: mohamed.boucadair@orange.com > 抄送: rfc-editor@rfc-editor.org; oscar.gonzalezdedios@telefonica.com; samier.barguil_giraldo@nokia.com; Qin Wu <bill.wu@huawei.com>; victor.lopez@nokia.com; opsawg-ads@ietf.org; opsawg-chairs@ietf.org; adrian@olddog.co.uk; rwilton@cisco.com; auth48archive@rfc-editor.org > 主题: 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, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> 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 <lbartholomew@amsl.com> Envoyé : mercredi 24 >>> mai 2023 20:44 À : BOUCADAIR Mohamed INNOV/NET >>> <mohamed.boucadair@orange.com> Cc : rfc-editor@rfc-editor.org; >>> oscar.gonzalezdedios@telefonica.com; >>> samier.barguil_giraldo@nokia.com; bill.wu@huawei.com; >>> victor.lopez@nokia.com; opsawg-ads@ietf.org; opsawg-chairs@ietf.org; >>> adrian@olddog.co.uk; rwilton@cisco.com; 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, mohamed.boucadair@orange.com 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, mohamed.boucadair@orange.com 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, mohamed.boucadair@orange.com wrote: >>>> >>>> Dear RFC Editor, all, >>>> >>>> Please see inline. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> Envoyé : >>>>> lundi 22 mai 2023 22:44 À : BOUCADAIR Mohamed INNOV/NET >>>>> <mohamed.boucadair@orange.com>; >>>>> oscar.gonzalezdedios@telefonica.com; >>>>> samier.barguil_giraldo@nokia.com; bill.wu@huawei.com; >>>>> victor.lopez@nokia.com Cc : rfc-editor@rfc-editor.org; >>>>> opsawg-ads@ietf.org; opsawg- chairs@ietf.org; adrian@olddog.co.uk; >>>>> rwilton@cisco.com; auth48archive@rfc-editor.org 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, rfc-editor@rfc-editor.org 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 >>>>> >>>>> * rfc-editor@rfc-editor.org (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). >>>>> >>>>> * auth48archive@rfc-editor.org, 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, >>>>> auth48archive@rfc-editor.org 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. >> > > >
- [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-opsaw… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Victor Lopez (Nokia)
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Oscar González de Dios
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Qin Wu
- Re: [auth48] AUTH48: RFC-to-be 9408 <draft-ietf-o… Lynne Bartholomew
- [auth48] [IANA] Re: AUTH48: RFC-to-be 9408 <draft… Lynne Bartholomew
- [auth48] [IANA #1274572] [IANA] Re: AUTH48: RFC-t… Amanda Baber via RT
- Re: [auth48] [IANA #1274572] [IANA] Re: AUTH48: R… Lynne Bartholomew