Hi Megan I also apologies. I had not noticed this.
Please can I suggest that you apply Jie’s changes and I will review the updated text. Best regards Stewart > On 8 Feb 2025, at 15:01, Dongjie (Jimmy) <jie.d...@huawei.com> wrote: > > Hi Megan, > > Sorry for the late response. It was Chinese New Year holiday and I missed > this mail in my mail box. > > Please find my replies inline: > >> -----Original Message----- >> From: Megan Ferguson <mfergu...@staff.rfc-editor.org> >> Sent: Saturday, February 8, 2025 8:58 AM >> To: Dongjie (Jimmy) <jie.d...@huawei.com>; ta-miyas...@kddi.com; >> lizhenqi...@chinamobile.com; stewart.bry...@gmail.com; >> younglee...@gmail.com >> Cc: teas-...@ietf.org; teas-cha...@ietf.org; Lou Berger <lber...@labn.net>; >> James Guichard <james.n.guich...@futurewei.com>; >> auth48archive@rfc-editor.org; RFC Editor <rfc-edi...@rfc-editor.org> >> Subject: Re: AUTH48: RFC-to-be 9732 <draft-ietf-teas-enhanced-vpn-20> for >> your review >> >> Authors, >> >> Just a friendly reminder that this document awaits your attention. Please >> review our messages below and let us know if you have any questions while >> you complete your AUTH48 review. >> >> We look forward to hearing from you at your earliest convenience. >> >> Thank you. >> >> RFC Editor/mf >> >> >>> On Jan 27, 2025, at 10:39 PM, rfc-edi...@rfc-editor.org wrote: >>> >>> Authors, >>> >>> While reviewing this document during AUTH48, please resolve (as >> necessary) the following questions, which are also in the XML file. >>> >>> 1) <!-- [rfced] Please note that the title of the document has been >>> updated as follows: >>> >>> a) We have cut the abbreviation NRP from the document title. Note >>> that this abbreviation is expanded in the first line of the Abstract. >>> >>> Original: >>> A Framework for Network Resource Partition (NRP) based Enhanced >>> Virtual Private Networks >>> >>> Current: >>> A Framework for Network Resource Partition Based Enhanced Virtual >>> Private Networks >>> >>> b) To avoid awkward hyphenation with "based" might one of the >>> following be an acceptable further update to the document title? >>> >>> Perhaps: >>> A Framework for Enhanced Virtual Private Networks Based on Network >>> Resource Partitions >>> >>> We could also not expand NRP since We see it is expanded in the first >>> line of the Abstract; however, it too suffers from the same "based" >>> hyphenation problem. Perhaps if the title suggestion above is not to >>> your liking, we could try: >>> >>> Perhaps: >>> A Framework for NRP-Based Enhanced Virtual Private Networks >>> >>> [With the first sentence of the Abstract updated to:] >>> >>> This document describes a framework for Enhanced Virtual Private >>> Networks (VPNs) based on Network Resource Partitions (NRPs)... >>> --> > > Thanks for proposing all these options. > > I would prefer the last one: A Framework for NRP-Based Enhanced Virtual > Private Networks, with the suggested update to the abstract. > > >>> >>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >>> the title) for use on https://www.rfc-editor.org/search. --> > > The keywords can be: network slicing, traffic engineering, performance > guarantee > > >>> >>> >>> 3) <!--[rfced] These two sentences from the Introduction seem to have >>> similar examples. To reduce redundancy, might these be compiled >>> in one place? If changes are desired, please let us know how to >>> update using old/new. Note also that similar text exists in the >>> Terminology section. >>> >>> Original: >>> (paragraph 2) >>> ...such as low latency guarantees, bounded jitter, or isolation from >>> other services or customers so that changes in other services >>> >>> and >>> (paragraph 3) >>> ...such as guaranteed resources, latency, jitter, etc. >>> --> > > The first sentence is talking about the customers' requirements to network, > while the second sentence is about the characteristics of the enhanced VPN > service. They are similar while from different angles. I would prefer to keep > them as is. > > >>> >>> 4) <!-- [rfced] Please review the use of RFC 4364 as a reference for >>> L3VPN in the following text as we don't see L3VPN or layer 3 in >>> that document. >>> >>> Original: >>> Examples of technologies to provide VPN services are: IPVPN [RFC2764], >>> L2VPN [RFC4664], L3VPN [RFC4364], and EVPN [RFC7432]. > > Although it is well known that RFC 4364 is about L3VPN, I agree L3VPN or > layer-3 is not used explicitly in that document. It uses IP VPN instead. > > In this draft we can follow that way and replace L3VPN with IP VPN. > > >>> --> >>> >>> >>> 5) <!--[rfced] Please review our update to make this text a bulleted list >>> and let us know any objections. >>> >>> Original: >>> There are several new technologies that provide some assistance with >>> this performance guarantee. Firstly, the IEEE TSN project [TSN] >>> introduces the concept of scheduling of delay- and loss-sensitive >>> packets. FlexE [FLEXE] is also useful to help provide a guaranteed >>> upper bound to latency. DetNet is also of relevance in assuring an >>> upper bound of end-to-end packet latency in the network layer. The >>> use of these technologies to deliver enhanced VPN services needs to be >>> considered when a guaranteed latency service is required. >>> >>> >>> Current: >>> There are several new technologies that provide some assistance with >>> this performance guarantee: >>> >>> * the IEEE TSN project [TSN] introduces the concept of scheduling of >>> delay-sensitive and loss-sensitive packets. >>> >>> * FlexE [FLEXE] is useful to help provide a guaranteed upper bound >>> to latency. >>> >>> * DetNet is of relevance in assuring an upper bound of end-to-end >>> packet latency in the network layer. >>> >>> The use of these technologies to deliver enhanced VPN services needs >>> to be considered when a guaranteed latency service is required. >>> --> > > The above update looks good. Thanks. > > >>> >>> >>> 6) <!--[rfced] In the following text, the use of "both" with 3 items >>> connected with "and"s is a bit confusing. Perhaps a rephrase >>> would benefit the reader? >>> >>> Original: >>> This may introduce scalability concerns both in the implementation (as >>> each enhanced VPN may need to be tracked in the network) and in how >>> many resources need to be reserved and how the services are mapped to >>> the resources (Section 4.4). >>> >>> --> > > How about: > > This may introduce scalability concerns in the implementation, as each > enhanced VPN may need to be tracked in the network. It may also introduce > scalability concerns in deployment, such as how many resources need to be > reserved and how the services are mapped to the resources (Section 4.4). > > >>> >>> >>> 7) <!--[rfced] How may the uses of slashes in the following be clarified >>> for the reader? >>> >>> Original: >>> By combining conventional VPNs with TE/QoS/security techniques, an >>> enhanced VPN offers a variety of means to honor customer's >>> requirements. >>> >>> Perhaps: >>> By combining conventional VPNs with TE, QoS, and security techniques, >>> an enhanced VPN offers a variety of means to honor customer's >>> requirements. >>> --> > > The update looks good, thanks. > > >>> >>> >>> 8) <!--[rfced] Does the following rewording correctly capture your >>> intent? >>> >>> Original: >>> The way to achieve the characteristics demand... >>> >>> Perhaps: >>> The way to meet the enhanced VPN service's demand for certain >>> characteristics (such as guaranteed or predictable performance) is >>> by... >>> > > The rewording looks good to me. > > >>> --> >>> >>> >>> 9) <!--[rfced] Does the following rewording correctly capture your >>> intent? >>> >>> Original: >>> With the approach of abstraction,... >>> >>> Perhaps: >>> Using the abstraction approach... > > This is OK. > > >>> --> >>> >>> >>> 10) <!--[rfced] Is "service SLA" redundant? Or is it an SLA specifically >>> about services? >>> >>> Original: >>> This means that during the lifetime of an enhanced VPN service, >>> closed-loop optimization is needed so that the delivered service >>> always matches the ordered service SLA. >>> >>> Perhaps: >>> This means that during the lifetime of an enhanced VPN service, >>> closed-loop optimization is needed so that the delivered service >>> always matches the ordered SLA. >>> --> > > It is OK to remove "service" as it is already covered by the "S". > > >>> >>> >>> 11) <!--[rfced] Because "requests" can be read as a noun or a verb, might >>> an update such as the following (i.e., the operation requests / >>> the operation's requests) help readers avoid a "garden path" >>> issue? Or is there another way to rephrase? >>> >>> Original: >>> An interface between the enhanced VPN service provider (e.g., >>> operator's network management system) and the enhanced VPN customer >>> (e.g., an organization or a service with enhanced VPN requirement) >>> such that the operation requests and the related parameters can be >>> exchanged without the awareness of other enhanced VPN customers. >>> >>> Perhaps: >>> An interface between the enhanced VPN service provider (e.g., the >>> operator's network management system) and the enhanced VPN customer >>> (e.g., an organization or service with an enhanced VPN requirement) >>> such that the operation's requests and the related parameters can be >>> exchanged without the awareness of other enhanced VPN customers. >>> --> > > How about: > > s/the operation requests/the requests for specific operations > > >>> >>> >>> 12) <!--[rfced] FYI - we have broken this long sentence into a bulleted >>> list for the ease of the reader. Please review and ensure we >>> have maintained your intended meaning. >>> >>> Original: >>> Based on the set of network resource partitions provided by the >>> physical network infrastructure, multiple NRPs can be created, each >>> with a set of dedicated or shared network resources allocated from >>> the physical underlay network, and each can be associated with a >>> customized logical network topology, so as to meet the requirements >>> of different enhanced VPN services or different groups of enhanced >>> VPN services. >>> >>> Current: >>> Based on the set of network resource partitions provided by the >>> physical network infrastructure, multiple NRPs can be created. Each >>> of these NRPs: >>> >>> * has a set of dedicated or shared network resources allocated from >>> the physical underlay network, and >>> >>> * can be associated with a customized logical network topology so as >>> to meet the requirements of different enhanced VPN services or >>> different groups of enhanced VPN services. >>> --> > > Actually the last sentence "so as to meet the requirements... " is related to > both bullets. > > Maybe split it as a separate bullet? > > >>> >>> >>> 13) <!--[rfced] Does this sentence contain a list of three items and an >>> "etc."? If our update does not correctly capture your intent, >>> please let us know. >>> >>> Original: >>> According to the service requirements of connectivity, performance >>> and isolation, etc., enhanced VPN services can be mapped to the >>> appropriate NRPs in the network. >>> >>> Current: >>> According to the service requirements of connectivity, performance, >>> isolation, etc., enhanced VPN services can be mapped to the >>> appropriate NRPs in the network. --> > > Yes, the updated text looks good. > > >>> >>> >>> 14) <!--[rfced] Does this suggested rephrase retain your intended meaning? >>> >>> Original: >>> A path that travels by other than the shortest path through the >>> underlay normally requires state to specify that path. >>> >>> Perhaps: >>> Any path other than the shortest path through the underlay normally >>> requires state to specify that path. >>> > > Yes, the meaning is retained. > > >>> --> >>> >>> >>> 15) <!--[rfced] Does this rephrase capture your intended meaning? >>> >>> Original: >>> FlexE also supports bonding links to create larger links out of >>> multiple low-capacity links. >>> >>> >>> Perhaps: >>> FlexE also supports bonding multiple low-capacity links to create >>> larger links. > > Yes, it is correct. > > >>> --> >>> >>> >>> 16) <!--[rfced] We had two questions about the following sentence: >>> >>> a) Is the repetition of "downstream node" necessary? >>> b) Will the reader understand what "that traffic isolation" is? >>> >>> Original: >>> When packets are received by the downstream node, they need to be >>> processed in a way that preserves that traffic isolation in the >>> downstream node. >>> >>> Perhaps: >>> When packets are received by the downstream node, they need to be >>> processed in a way that preserves traffic isolation. >>> > > This update is OK. > > >>> --> >>> >>> >>> 17) <!--[rfced] Are both of these sentences about GCO? Please review our >>> updates and let us know any objections. >>> >>> Original 1: >>> The control plane of NRP-based enhanced VPNs is likely be based on a >>> hybrid control mechanism that takes advantage of a logically >>> centralized controller for on-demand provisioning and global >>> optimization, whilst still relying on a distributed control plane to >>> provide scalability, high reliability, fast reaction, automatic >>> failure recovery, etc. >>> >>> Current 1: >>> The control plane of NRP-based enhanced VPNs is likely to be based on >>> a hybrid control mechanism that takes advantage of a logically >>> centralized controller for on-demand provisioning and Global >>> Concurrent Optimization (GCO) while still relying on a distributed >>> control plane to provide scalability, high reliability, fast reaction, >>> automatic failure recovery, etc. >>> >>> Original 2: >>> The global concurrent optimization mechanisms as described in >>> [RFC5557] and discussed in [RFC7399] may be helpful, while complete >>> resolution of this situation is as much a commercial issue as it is a >>> technical issue. >>> >>> Current 2: >>> The GCO mechanisms as described in [RFC5557] and discussed in >>> [RFC7399] may be helpful, while complete resolution of this situation >>> is as much a commercial issue as it is a technical issue. > > The first sentence is general and not specifically related to GCO. As > described in the second sentence, GCO can be of help in this case, while it > is not mandatory. > > I’d suggest to keep both sentences as is. > > >>> --> >>> >>> >>> 18) <!--[rfced] Does the following suggested text capture your intended >>> meaning? If not, is there another possible rephrase of the >>> original? >>> >>> Original: >>> Thus, an interface between the enhanced VPN management plane and the >>> 5G network slice management system, and relevant service data models >>> are needed for the coordination of 5G end-to-end network slice >>> management. >>> >>> Perhaps: >>> Thus, the coordination of 5G end-to-end network slice management >>> requires both relevant service data models and an interface between >>> the enhanced VPN management plane and the 5G network slice >> management >>> system. >>> > > Suggest to rephrase it as: > > Thus, the coordination of 5G end-to-end network slice management requires an > interface between the enhanced VPN management plane and the 5G network slice > management system, and relevant service data models. > > >>> --> >>> >>> >>> 19) <!--[rfced] What is the antecedent of "it" in this sentence? Please >>> clarify. >>> >>> Original: >>> Reducing the state in the network is important to enhanced VPNs, as it >>> requires the overlay to be more closely integrated with the underlay >>> than with conventional VPNs. >>> >>> Perhaps: >>> Reducing state in the network is important to enhanced VPNs, as state >>> requires the overlay to be more closely integrated with the underlay >>> than with conventional VPNs. > > Here "it" means "enhanced VPN". > > Suggest to rephrase it as: > > Reducing the state in the network is important to the deployment of enhanced > VPNs, as they require the overlay to be more closely integrated with the > underlay than with conventional VPNs. > > >>> --> >>> >>> >>> 20) <!--[rfced] In the following, what "can reduce the overhead of control >>> channels"? The approach? Please clarify >>> >>> Original: >>> The centralized approach of SDN requires control plane state to be >>> stored in the network, but can reduce the overhead of control channels >>> to be maintained.--> > > How about rephrase it as: The centralized SDN based approach requires... > > >>> >>> >>> 21) <!--[rfced] The verb "consider" seems a bit odd with a non-human >>> subject in the following two sentences. We will update to the >>> suggestions below unless we hear objection. >>> >>> Original: >>> The design of OAM for enhanced VPN services needs to consider the >>> following requirements: >>> >>> Perhaps: >>> The following requirements need to be considered in the design of OAM >>> for enhanced VPN services: >>> >>> >>> Original: >>> Telemetry for enhanced VPN service needs to consider the following >>> requirements: >>> >>> Perhaps: >>> The following requirements need to be considered for telemetry for >>> enhanced VPN service: > > The updates look good, thanks. > >>> >>> --> >>> >>> >>> 22) <!-- [rfced] Please review the reference entry [NGMN-NS-Concept]. >>> >>> The original URL navigates to a search results page that states >>> "Nothing Found". We were unable to find any URL with a title matching >>> the one provided in this reference. (Note: the author element is also >>> unusual). >>> >>> We were able to find the following document that matches some of the >>> information provided in the URL string: >>> >>> >> https://www.ngmn.org/wp-content/uploads/Publications/2016/161010_NG >> MN_ >>> Network_Sl >>> icing_framework_v1.0.8.pdf >>> >>> Is this the correct reference? If so, may we update this reference to >>> use the information from this document? (Note that this reference is a >>> draft of Version 1.0.8). --> > > Thanks, the link you provided point to the right document, it seems the > previous link expired. > > >>> >>> >>> 23) <!--[rfced] We had the following questions related to abbreviation >>> use throughout the document: >>> >>> a) To follow guidance at >>> https://www.rfc-editor.org/styleguide/part2/#exp_abbrev, we will >>> update to expand the following abbreviations on first use only and to >>> use only the abbreviation thereafter unless we hear objection: >>> >>> OAM >>> TE >>> SR >>> VN >>> SAP >>> DetNet >>> NRP >>> >>> Note that we have already made this change with regard to the >>> following terms: >>> >>> L2 >>> L3 >>> L2VPN >>> L3VPN > > Agree with this usage, thanks. > > >>> >>> b) We see two different expansions for OAM in this document: >>> >>> Operation, Administration, and Management (OAM) vs. Operations, >>> Administration, and Maintenance (OAM) >>> >>> We will update to use the latter on the first use in this document and >>> the abbreviation thereafter per RFC 6291. Please let us know any >>> objections. > > Yes the latter is the right one. Please make this change, thanks. > > >>> >>> c) This document expands FlexE as "Flexible Ethernet" while the cited >>> reference uses "Flex Ethernet". Should these be made consistent? >>> Please also review Section 5.1.1 for uses of flexible ethernet if >>> updates are desired. > > Let's make it consistent with the reference (Flex Ethernet), although as I > know Flexible Ethernet is extensively used in many documents in the industry. > > >>> >>> d) FYI: We have expanded the following abbreviations on first use as >>> follows. Please let us know any corrections. >>> >>> MP2MP - Multipoint-to-Multipoint >>> SDN - Software-Defined Networking >>> P2P - point-to-point >>> CE - Customer Edge >>> SRv6 - SR over IPv6 > > For SRv6, please use "Segment Routing over IPv6", all the rest look good. > > >>> >>> e) We have updated the expansion of ACTN for consistency with the >>> normative references to appear as follows: >>> >>> Abstraction and Control of TE Networks (ACTN) > > It looks good. > > >>> --> >>> >>> >>> 24) <!--[rfced] We had the following questions/comments related to >>> terminology use throughout the document: >>> >>> a) We have updated to use lowercase and hyphenated "controlled-load >>> service" throughout (use in RFC 2211 is mixed). >>> >>> b) We have used the form on the left to match use in the normative >>> references. Please let us know any objections. >>> >>> telemetry vs. Telemetry > > Both look good. > > >>> --> >>> >>> >>> 25) <!--[rfced] Please note that there a few places throughout the text >>> where we inserted bulleted lists to attempt to help the reader >>> parse lists or complex sentences. Please review and let us know >>> if any of these updates did not correctly capture your intended >>> meaning.--> > > All the updates look good, thanks. > > >>> >>> >>> 26) <!--[rfced] This document mixed use of citations as a functioning >>> part of a sentence (a noun) and citations as just citations >>> (with no syntactic weight). Where the mixed use might lead the >>> reader to confusion (mixed in close proximity,) we have tried to >>> edit for consistency. Where not used in close proximity, we >>> have left them as they were to limit changes to the doc. Please >>> see more information on this topic for future documents at >>> https://www.rfc-editor.org/styleguide/part2/#citation_usage --> > > Thanks for the editing! > > >>> >>> 27) <!-- [rfced] Please review the "Inclusive Language" portion of the >>> online Style Guide >>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>> and let us know if any changes are needed. Updates of this >>> nature typically result in more precise language, which is >>> helpful for readers. >>> >>> Note that our script did not flag any words in particular, but this >>> should still be reviewed as a best practice. >>> > > Thanks for the pointer, I have checked the text and nothing needs to be > changed. > > Best regards, > Jie > > >>> --> >>> >>> >>> Thank you. >>> >>> RFC Editor/mf >>> >>> >>> *****IMPORTANT***** >>> >>> Updated 2025/01/27 >>> >>> 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://www.rfc-editor.org/faq/). >>> >>> 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://trustee.ietf.org/license-info). >>> >>> * 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://authors.ietf.org/rfcxml-vocabulary>. >>> >>> * 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-edi...@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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxI >>> Ae6P8O4Zc >>> >>> * The archive itself: >>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>> >>> * 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. >>> >>> >>> Files >>> ----- >>> >>> The files are available here: >>> https://www.rfc-editor.org/authors/rfc9732.xml >>> https://www.rfc-editor.org/authors/rfc9732.html >>> https://www.rfc-editor.org/authors/rfc9732.pdf >>> https://www.rfc-editor.org/authors/rfc9732.txt >>> >>> Diff file of the text: >>> https://www.rfc-editor.org/authors/rfc9732-diff.html >>> https://www.rfc-editor.org/authors/rfc9732-rfcdiff.html (side by >>> side) >>> >>> Diff of the XML: >>> https://www.rfc-editor.org/authors/rfc9732-xmldiff1.html >>> >>> >>> Tracking progress >>> ----------------- >>> >>> The details of the AUTH48 status of your document are here: >>> https://www.rfc-editor.org/auth48/rfc9732 >>> >>> Please let us know if you have any questions. >>> >>> Thank you for your cooperation, >>> >>> RFC Editor >>> >>> -------------------------------------- >>> RFC9732 (draft-ietf-teas-enhanced-vpn-20) >>> >>> Title : A Framework for Network Resource Partition (NRP) >> based Enhanced Virtual Private Networks >>> Author(s) : J. Dong, S. Bryant, Z. Li, T. Miyasaka, Y. Lee >>> WG Chair(s) : Oscar Gonzalez de Dios, Vishnu Pavan Beeram, Lou >> Berger >>> >>> Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde >>> >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
