Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-nmrg-ibn-intent-classification-08> for your review
rfc-editor@rfc-editor.org Tue, 20 September 2022 01:41 UTC
Return-Path: <wwwrun@rfcpa.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 AB510C1522AA; Mon, 19 Sep 2022 18:41:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.659
X-Spam-Level:
X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.998, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 h1b8gahX_gtC; Mon, 19 Sep 2022 18:41:15 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org [50.223.129.200]) (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 47EC1C1522BA; Mon, 19 Sep 2022 18:41:15 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 06571E535F; Mon, 19 Sep 2022 18:41:15 -0700 (PDT)
To: lichen.bri@chinatelecom.cn, olga.havel@huawei.com, adriana.olariu@huawei.com, pedro@nict.go.jp, jcnobre@inf.ufrgs.br, diego.r.lopez@telefonica.com
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, irsg@irtf.org, laurent.ciavaglia@rakuten.com, auth48archive@rfc-editor.org
Content-type: text/plain; charset="UTF-8"
Message-Id: <20220920014115.06571E535F@rfcpa.amsl.com>
Date: Mon, 19 Sep 2022 18:41:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/8tDATTnBXqmRFltJ0OKQEJj6jbQ>
Subject: Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-nmrg-ibn-intent-classification-08> 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: Tue, 20 Sep 2022 01:41:19 -0000
Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file. 1) <!-- [rfced] FYI: The following references are not cited in the text and have been removed. Please let us know any objections. [RFC2119] [RFC7575] [RFC8328] [RFC3198] [RFC6020] [RFC7285] [I-D.du-anima-an-intent] [I-D.ietf-supa-generic-policy-info-model] [RFC8992] --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!--[rfced] Please ensure that the guidelines listed in Section 2.1 of RFC 5743 have been adhered to in this document. --> 4) <!--[rfced] May we update the Abstract with regard to the following definite and indefinite articles (a/the)? Original: Intent is an abstract, high-level policy used to operate the network. Intent-based management system includes an interface for users to input requests and an engine to translate the intents into the network configuration and manage their life-cycle. Perhaps: Intent is an abstract, high-level policy used to operate a network. An intent-based management system includes an interface for users to input requests and an engine to translate the intents into the network configuration and manage their life cycle. --> 5) <!--[rfced] We note that "intent" is defined in more than one way in this document (in the Abstract, "Definitions", and "What is Intent" sections). Original: Intent is an abstract, high-level policy used to operate the network. and Intent: A set of operational goals (that a network should meet) and outcomes (that a network is supposed to deliver), defined in a declarative manner without specifying how to achieve or implement them. and all of Section 4.1. (What is Intent) Would it be helpful to the reader if these definitions were made more uniform? --> 6) <!--[rfced] The use of "vision" seems a bit odd in this sentence. Could another word better convey the idea? Original: The vision of intent-based networks has attracted a lot of attention... Perhaps: The idea of intent-based networks has attracted a lot of attention... --> 7) <!-- [rfced] Section 1.1: we had the following questions regarding the first few paragraphs. a) Might we update the first few paragraphs of the Introcution as follows? This includes changes to reduce redundancy, improve readability, and make a few grammatical updates. Please review carefully and let us know if this works for you. Original: 1.1. Research activities Intent-based networking is an active research topic which spans across different areas that could benefit from an intent classification and taxonomy. One such area is intent expression and recognition ([Bezahaf21], [Bezahaf19]), NILE [Jacobs18]). The use of a common classification can provide consistency in the understanding of the various forms of intent expressions being proposed and investigated. Another area where this intent classification could contribute is the orchestration of cognitive autonomous RANs [Banerjee21] where intents are classified based on their content. The work carried in intent network verification [Tian19] where the authors are proposing new intent language is another candidate where intent classification could be used advantageously. Perhaps: 1.1. Research Activities Intent-based networking is an active research topic spanning across different areas that could benefit from an intent classification and taxonomy. Some examples include: - intent expression and recognition ([Bezahaf21] [Bezhaf19] NILE [Jacobs18]). The use of a common classification could provide consistency in the understanding of the various forms of intent expressions being proposed and investigated. - the orchestration of cognitive autonomous radio access networks (RANs) [Banerjee21] where intents are classified based on their content. - intent network verification [Tian19], where the authors are working to propose new intent language. b) In the following sentence, may we remove "NILE" as it does not appear to be a reference and is mentioned in [Jacobs18]? Or is there some other text missing to describe "NILE"? Note that the updated text might appear differently based on your reply to the previous query. Original: One such area is intent expression and recognition ([Bezahaf21], [Bezhaf19]), NILE [Jacobs18]). Perhaps: One such area is intent expression and recognition ([Bezahaf21], [Bezhaf19], [Jacobs18]). --> 8) <!--[rfced] Please review the updates to this text that we made in order to expand the abbreviation "IBN" on first use (to ensure we have correctly captured your intent with regard to the use of "based"). Original: ...for proposing self-generated Intent-based systems [Bezhaf19], for advancing IBN-based VNF placement solutions... Edited: ...for proposing self-generated Intent-based systems [Bezhaf19], for advancing Internet-Based Network (IBN) Virtual Network Function (VNF) placement solutions... --> 9) <!-- [rfced] In the following sentence, may we update the past tense "came up with" to "come up with"? Original: The SDOs usually came up with their own way of specifying an intent, and with their own understanding of what an intent is. Perhaps: The SDOs usually come up with their own way of specifying an intent with their own understanding of what an intent is. --> 10) <!--[rfced] Might "intended intent users" be tough to read? Is there a word we could use instead of "intended" or a way to rephrase for the ease of the reader? Original: Besides that, each SDO defines a set of terms and level of abstraction, its intended intent users, and the applications and usage scenarios. --> 11) <!-- [rfced] Should the last sentence following the bullet points in Section 1.2 be included in the bulleted list along with the other features proposed by SDOs? Original: - It must be vendor agnostic in the sense that it abstracts the network capabilities, or the network infrastructure from the intent user, and it can be ported across different platforms. - It must provide an easy-to-use interface, which simplifies the intent users' interaction with the intent system through the usage of familiar terminology or concepts. It should be able to detect and resolve intent conflicts, which include, for example, static (compile-time) conflicts and dynamic (run-time) conflicts. Perhaps: - It must be vendor agnostic in the sense that it abstracts the network capabilities, or the network infrastructure from the intent user, and it can be ported across different platforms. - It must provide an easy-to-use interface, which simplifies the interaction of intent users with the intent system through the usage of familiar terminology or concepts. - It should be able to detect and resolve intent conflicts, which include, for example, static (compile-time) conflicts and dynamic (run-time) conflicts. --> 12) <!--[rfced] Please note that we have updated the expansion of O&M to match guidance we received on RFC 6291. Please review and let us know any objections. Original: Operations & Maintenance Current: OAM & Maintenance --> 13) <!-- [rfced] In the following category for Intent Users, should commas be placed to better separate the intent users? Original: Network Operator Service Designers/App Developer Service Operators Customers/Subscribe rs Cloud Administrator Underlay Network Administrator Application Developers Customer/Ten ants Enterprise Administrator Application Developers End-Users Perhaps: Network Operators, Service Designers / App Developers, Service Operators, Customers/Subscribers Cloud Administrators, Underlay Network Administrators, Application Developers, Customers/Tenants Enterprise Administrators, Application Developers, End-Users --> 14) <!-- [rfced] In the following sentence, may we remove "rate" after 1080p? It may be clear enough to readers without it. Original: For carrier networks scenario, for example, if a customer/subscriber wants to watch high-definition video, then the intent is to convert the video image to 1080p rate. --> 15) <!-- [rfced] In the following sentence, do operators want both more technical visibility and network visibility? If not, how might we clarify? Original: Customers, application developers and end-users must not be required to set IP addresses, VLANs, subnets, ports, while operators may still want to have more technical and network visibility. Perhaps: Customers, application developers, and end users must not be required to set IP addresses, VLANs, subnets, or ports, whereas operators may still want to have more technical network visibility. Or perhaps: Customers, application developers, and end users must not be required to set IP addresses, VLANs, subnets, or ports, whereas operators may still want to have both more technical and network visibility. --> 16) <!-- [rfced] Was it intended to use the first person "my" in the following bullet point? Original: All stakeholders would benefit from the simpler interfaces, like: - Request gold VPN service between my sites A, B, and C Perhaps: All stakeholders would benefit from simpler interfaces, such as: - Request gold VPN service between sites A, B, and C --> 17) <!-- [rfced] We've updated APP to "Application-specific function" per its usage in past RFCs. Please let us know if this is incorrect. --> 18) <!-- [rfced] In the following definition for "Partially automated network", the second sentence appears to be a fragment. How might we complete it? Original: Level 1 - Partially automated network: Automated scripts are used to automate service provisioning, network deployment, and maintenance. Shallow perception of network status and decision making suggestions of machine. --> 19) <!-- [rfced] May we update the definition for "Level 2 - Automated network:" to be a complete sentence to match other definitions in the list? Original: Level 2 - Automated network: Automation of most service provisioning, network deployment, and maintenance of a comprehensive perception of network status and local machine decision making. Perhaps: Level 2 - Automated network: Automated scripts are used to automate most service provisioning, network deployment, and maintenance of a comprehensive perception of network status and local machine decision-making. --> 20) <!-- [rfced] May we update the definition for "Level 2" and "Level 3" to use complete sentences? Original: Level 2 - Automated network: Automation of most service provisioning, network deployment, and maintenance of a comprehensive perception of network status and local machine decision making. - simple intent on service provisioning Level 3 - Self-optimization network: Deep awareness of network status and automatic network control, meeting requirements of intent users of the network. Perhaps: Level 2 - Automated network: This entails the automation of most service provisioning, network deployment, and maintenance of a comprehensive perception of network status and local machine decision-making. - simple intent on service provisioning Level 3 - Self-optimization network: This entails a deep awareness of network status and automatic network control, meeting requirements of intent users of the network. --> 21) <!--[rfced] The use of "adapt to and adjust to meet people's intentions" is a bit difficult to parse. We have updated as follows. Please review and confirm that we have maintained your intended meaning. Original: In different network environments and network conditions, the network can automatically adapt to and adjust to meet people's intentions. Current: In different network environments and network conditions, the network can automatically adapt and adjust to meet people's intentions. --> 22) <!--[rfced] Please review our edits to the following text to ensure we have maintained the intended meaning (i.e., confirm that "resource scope" is the name of the category). Original: For example, for the DC intent solution, a new category is identified, i.e. resource scope, and the classification table has been extended accordingly. Current: For example, for the DC intent solution, a new category "resource scope" is identified, and the classification table has been extended accordingly --> 23) <!--[rfced] Might we update "use/add" in the following to clarify the relationship? Original: 8. Identify any new categories and use/add the newly identified categories. Perhaps: 8. Identify any new categories. Use and add the newly identified categories. --> 24) <!--[rfced] We had the following questions regarding Figure 2: a) In the text leading up to Figure 2, we see "intent solutions", "intent user types", "intent types", and "intent scope". However, in the figure itself, we see simply "Solutions". Should this be made "Intent Solutions"? Or should "Intent User Types", "Intent Type", and "Intent Scope" be made "User Types", "Type", and "Scope" assuming that the "Intent" on the far left applies to all of them? b) Should the "Intent Types" include the word "Intent"? For example, "Customer Service" instead of "Customer Service Intent"? Note that we do not see "Carrier Intent Solution" in the first box or "Connectivity Scope" etc. c) Should "Solutions" and "Intent User Types" be made singular to match "Intent Type" and "Intent Scope" and others? --> 25) <!-- [rfced] In the following sentence, was "apps of type video" intended? Would "video apps" or "video-type apps" work better? Original: Example: Request reliable service during peak traffic periods for apps of type video. --> 26) <!-- [rfced] In the following sentence, is "path P" being backed up, or is it itself a "backup path"? Original (name is backup path P): Example: Request migration of all services in network N to backup path P. Perhaps (in order to back path P up): Example: Request migration of all services in network N to back up path P. --> 27) <!-- [rfced] In the following description, should SLA be in a sequential list with the other items? (note: multiple instances). Original: Service operator's customer orders, customer service / SLA. Perhaps: Service operator's customer orders, customer service, or SLA. --> 28) <!--[rfced] Please review the tense shift indicated by "A service chain intent expressed" to confirm that this action should not be simple present tense (as seen in the sentence before). Original: In this PoC [POC-IBN], a slice intent expresses a request for a network slice with two types of components: a set of top layer virtual functions, and a set of virtual switches and/or routers of L2/L3 VNFs. A service chain intent expressed a request for a service operated through a chain of service components running in L4-L7 virtual functions. --> 29) <!-- [rfced] We had the following questions regarding Table 4 (Intent Classification for Data Center Network Solutions): a) While we've made the figure in Section 6.3.3 a table, it does not quite fit the maximum allowable width. Is there any way we can shorten the table to make it fit? Would we be able to shorten the columns C1 - C4 under "Network Scope"? Note: Similar instance in Section 6.4.3. Original: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Intent | Intent | Intent | NF | Network | ABS |L-C | | User | Type | Scope |Scope| Scope | | | | | ++++++++++++++++++++++++++++++++++++++++++++++++ | | |C1|C2|C3|C4|C1|C2|C1|C2|C3|C4|C5|C6|C1|C2|C1|C2| Perhaps: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Intent | Intent | Intent | NF | Network | ABS |L-C | | User | Type | Scope |Scope| Scope | | | | | +++++++++++++++++++++++++++++++++++++++++++ | | |C1|C2|C3|C4|C1|C2|C1-C4|C5|C6|C1|C2|C1|C2| b) Also note that the text output of the table in Section 6.3.3 does not span out the headers (e.g., Intent Scope, NF Scope, etc.) in the way that HTML output does. --> 30) <!-- [rfced] In the following sentence, was "connnectivity communication" intended or "community and communication"? Original: Configuration of VMs, DB Servers, app servers, and connectivity, communication between VMs. Perhaps: Configuration of VMs, DB Servers, app servers, and connectivity communication between VMs. --> 31) <!-- [rfced] In the following example, does the API also request configuration of DB servers? Original: Example: API to request configuration of VMs, or DB Servers. Perhaps: Example: API to request configuration of VMs or DB Servers. --> 32) <!--[rfced] We have made this update for parallel structure. Please let us know any objections. (Two sentences only to show relationship - no change suggested for the second line.) Original: 1. The intent solution is for the data center. and 1. The intent solution for both intents is carrier network. Edited (only a change to the first line): 1. The intent solution is data center. and 1. The intent solution for both intents is carrier network. --> 33) <!--[rfced] Is it known that "more details of these security intents" will be described in a future document(s)? Perhaps "will", "might", or "could" would be more appropriate here? Original: More details of these security intents would be described in future documents that specify architecture, functionality, user... Perhaps: More details of these security intents will be described in future documents that specify architecture, functionality, user... --> 34) <!-- [rfced] Would you like the references to be alphabetized or left in their current order? --> 35) <!-- [rfced] FYI: For reference [ONF], we've updated the target site to the non-parsing <https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-rep orts/TR-523_Intent_Definition_Principles.pdf> to <https://opennetworking.wpengine.com/wp-content/uploads/2014/10/TR-523_Intent_Defini tion_Principles.pdf> and have updated the title to "Intent NBI - Definition and Principles". Please let us know if this is not correct. --> 36) <!--[rfced] Please note that we have updated to point to RFC-to-be 9315 (I-D.irtf-nmrg-ibn-concepts-definitions) assuming that it will be published prior to this document (see http://www.rfc-editor.org/auth48/rfc9315). If this is not the case, we can revert the reference to point to the I-D or hold this document to be published simultaneously. Please advise.--> 37) <!-- [rfced] Terminology: we had the following questions related to terminology throughout the document. a) We have lowercased "autonomous networks" throughout - please let us know if anything needs to be done to make "autonomous network" and "autonomous driving network" uniform. --> 38) <!-- [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. --> Thank you. RFC Editor/re/mf *****IMPORTANT***** Updated 2022/09/19 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-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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * 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/rfc9316.xml https://www.rfc-editor.org/authors/rfc9316.html https://www.rfc-editor.org/authors/rfc9316.pdf https://www.rfc-editor.org/authors/rfc9316.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9316-diff.html https://www.rfc-editor.org/authors/rfc9316-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9316-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9316 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9316 (draft-irtf-nmrg-ibn-intent-classification-08) Title : Intent Classification Author(s) : C. Li, O. Havel, A. Olariu, P. Martinez-Julia, J. Nobre, D. Lopez WG Chair(s) : Area Director(s) :
- [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-nmrg-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Olga Havel
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Olga Havel
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Olga Havel
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Ciavaglia, Laurent
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Olga Havel
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Reuben Esparza
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Olga Havel
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… lichen6@chinatelecom.cn
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Reuben Esparza
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… lichen6@chinatelecom.cn
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… lichen6@chinatelecom.cn
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Jéferson Campos Nobre
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Reuben Esparza
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Adriana Olariu
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Adriana Olariu
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Reuben Esparza
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Pedro Martinez-Julia
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Olga Havel
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Reuben Esparza
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Diego R. Lopez
- Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-n… Reuben Esparza