Re: [auth48] [AD] AUTH48: RFC-to-be 9390 <draft-ietf-dime-group-signaling-14> for your review
Alanna Paloma <apaloma@amsl.com> Thu, 20 April 2023 00:28 UTC
Return-Path: <apaloma@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 26FBBC16B5AE; Wed, 19 Apr 2023 17:28:56 -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 zsVg4eJw04ds; Wed, 19 Apr 2023 17:28:52 -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 382B9C16B5AB; Wed, 19 Apr 2023 17:28:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C0F88424B443; Wed, 19 Apr 2023 17:28:51 -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 l9Y4c9CJDkG6; Wed, 19 Apr 2023 17:28:51 -0700 (PDT)
Received: from amss-mbp.attlocal.net (unknown [IPv6:2600:1700:bac0:1070:d55c:6bcb:cb4:2d68]) by c8a.amsl.com (Postfix) with ESMTPSA id 417ED424B42D; Wed, 19 Apr 2023 17:28:51 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Alanna Paloma <apaloma@amsl.com>
In-Reply-To: <82F2CB31-B904-4A7E-BD07-C00932FBB533@amsl.com>
Date: Wed, 19 Apr 2023 17:28:50 -0700
Cc: "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "dime-ads@ietf.org" <dime-ads@ietf.org>, "dime-chairs@ietf.org" <dime-chairs@ietf.org>, "jounikor@gmail.com" <jounikor@gmail.com>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8B62FE02-39BD-4686-BE96-64B9AD2B70D6@amsl.com>
References: <20230324170823.8845E1FCF27@rfcpa.amsl.com> <5967_1681204800_64352640_5967_44_1_73da6c6449d74cc79749d0d41418ad71@orange.com> <6344C81D-60B4-4456-BD3E-B2B99D7CAB12@amsl.com> <5812_1681300763_64369D1B_5812_96_1_7b39490fddd041509b406b9970edaf99@orange.com> <82F2CB31-B904-4A7E-BD07-C00932FBB533@amsl.com>
To: lionel.morand@orange.com, "mark@azu.ca" <mark@azu.ca>, "marco.liebsch@neclab.eu" <marco.liebsch@neclab.eu>, "rwilton@cisco.com" <rwilton@cisco.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/kQacVW3BAWt_qTsfeJjrXRPYVfk>
Subject: Re: [auth48] [AD] AUTH48: RFC-to-be 9390 <draft-ietf-dime-group-signaling-14> 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, 20 Apr 2023 00:28:56 -0000
Authors and *Robert, This is a friendly reminder that we await your approvals prior to moving this document forward in the publication process. *Robert (AD) - Please review and approve of the updated text in Section 4.1.1 in the diff file below: https://www.rfc-editor.org/authors/rfc9390-auth48diff.html The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9390.xml https://www.rfc-editor.org/authors/rfc9390.txt https://www.rfc-editor.org/authors/rfc9390.html https://www.rfc-editor.org/authors/rfc9390.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9390-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9390-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9390-lastdiff.html (last version to this one) The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9390 Thank you, RFC Editor/ap > On Apr 12, 2023, at 3:43 PM, Alanna Paloma <apaloma@amsl.com> wrote: > > Hi Lionel, > > Thank you for your reply. We have updated the files accordingly. > > We will await any further changes you may have and approvals from each author and the AD prior to moving forward in the publication process. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9390.xml > https://www.rfc-editor.org/authors/rfc9390.txt > https://www.rfc-editor.org/authors/rfc9390.html > https://www.rfc-editor.org/authors/rfc9390.pdf > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9390-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9390-auth48diff.html (AUTH48 changes) > https://www.rfc-editor.org/authors/rfc9390-lastdiff.html (last version to this one) > > The AUTH48 status page for this document is available here: > https://www.rfc-editor.org/auth48/rfc9390 > > Thank you, > RFC Editor/ap > >> On Apr 12, 2023, at 4:59 AM, lionel.morand@orange.com wrote: >> >> Dear Alana, >> >> Thank you for your quick feedback. >> Please find our response below. >> >> Regards, >> >> Lionel >> >> >> Orange Restricted >> >>> -----Message d'origine----- >>> De : Alanna Paloma <apaloma@amsl.com> >>> Envoyé : mardi 11 avril 2023 22:40 >>> À : MORAND Lionel INNOV/NET <lionel.morand@orange.com>; >>> rwilton@cisco.com >>> Cc : rfc-editor@rfc-editor.org; mark@azu.ca; marco.liebsch@neclab.eu; dime- >>> ads@ietf.org; dime-chairs@ietf.org; jounikor@gmail.com; auth48archive@rfc- >>> editor.org >>> Objet : Re: [AD] AUTH48: RFC-to-be 9390 <draft-ietf-dime-group-signaling-14> for >>> your review >>> >>> Hi Lionel and AD*, >>> >>> *Robert - As the AD, please review and approve of the updated text in Section >>> 4.1.1 in the diff file below: >>> https://www.rfc-editor.org/authors/rfc9390-auth48diff.html >>> >>> Lionel - Thank you for your reply. We have updated the files accordingly. Please >>> note that we have some additional queries: >>> >>> 1) You provided the following expansions for the listed acronyms: >>> >>>> GASR: Group-Abort-Session-Request >>>> GASA: Group-Abort-Session-Answer >>>> GSTA: Group-Session-Termination-Answer >>>> GSTR: Group-Session-Termination-Request >>> >>> We have added preceding text to introduce the acronyms. Please review and let us >>> know of any concerns. >>> >>> Current: >>> Additionally, the following acronyms are used in the tables below. >>> >>> GASR: Group-Abort-Session-Request >>> >>> GASA: Group-Abort-Session-Answer >>> >>> GSTA: Group-Session-Termination-Answer >>> >>> GSTR: Group-Session-Termination-Request >> >> [[LM]] Thank you! >> >>> >>> 2) Please clarify if “re-authorization request” or “Re-Authorization Request (RAR)” >>> should be made consistent. If so, which form should be used throughout the >>> document? >>> >>>>> 11) <!--[rfced] Throughout the text, the following terminology >>>>> appears to be used inconsistently. Please review these occurrences >>>>> and let us now if/how they may be made consistent. >>>>> >>>>> re-authorization request vs. Re-Authorization Request (RAR) >>>>> --> >>>> >>>> [[LM]] OK! >> >> [[LM]] Sorry 😊 The point is that there is no inconsistency issue. One is "service-specific re-authorization request" whereas RAR is a one these re-authorization command defined in RFC6733. But I realized that we have missed something: RAR should be "Re-Auth-Request" and RAA should "Re-Auth-Answer" in some places. >> Moreover the coma (,) should be removed in "service-specific, server-initiated request". Both changes are addressed below. >> >> 4.2.2. Removing a Session from a Session Group >> >> OLD: >> >> When the Diameter server decides to remove a session from one or multiple particular session groups or from all session groups to which the session has been assigned beforehand, the server sends a Re-Authorization Request (RAR) or a service-specific, server-initiated request to the client, indicating the session in the Session-Id AVP of the request. The client sends a Re-Authorization Answer (RAA) or a service-specific answer to respond to the server's request. >> >> NEW: >> >> When the Diameter server decides to remove a session from one or multiple particular session groups or from all session groups to which the session has been assigned beforehand, the server sends a Re-Auth-Request (RAR) or a service-specific server-initiated request to the client, indicating the session in the Session-Id AVP of the request. The client sends a Re-Auth-Answer (RAA) or a service-specific answer to respond to the server's request. >> >> 4.2.3. Mid-session Group Assignment Modifications >> >> OLD: >> >> When a Diameter server decides to update assigned groups mid-session, it sends a Re-Authorization Request (RAR) message or a service-specific request to the client identifying the session for which the session group lists are to be updated. The client responds with a Re-Authorization Answer (RAA) message or a service-specific answer. >> >> NEW: >> >> When a Diameter server decides to update assigned groups mid-session, it sends a Re-Auth-Request (RAR) message or a service-specific request to the client identifying the session for which the session group lists are to be updated. The client responds with a Re-Auth-Answer (RAA) message or a service-specific answer. >> >> >> 4.4.1. Sending Group Commands >> >> OLD: >> >> For example, when a server sends a Re-Authorization Request (RAR) or a service-specific, server-initiated request to the client, it indicates to the client to follow the request according to one of three possible procedures. >> >> NEW: >> >> For example, when a server sends a Re-Auth-Request (RAR) or a service-specific server-initiated request to the client, it indicates to the client to follow the request according to one of three possible procedures. >> >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9390.xml >>> https://www.rfc-editor.org/authors/rfc9390.txt >>> https://www.rfc-editor.org/authors/rfc9390.html >>> https://www.rfc-editor.org/authors/rfc9390.pdf >>> >>> The relevant diff files have been posted here: >>> https://www.rfc-editor.org/authors/rfc9390-diff.html (comprehensive diff) >>> https://www.rfc-editor.org/authors/rfc9390-auth48diff.html (AUTH48 changes) >>> >>> Please review the document carefully and contact us with any further updates you >>> may have. Note that we do not make changes once a document is published as >>> an RFC. >>> >>> We will await any further changes you may have and approvals from each author >>> and the *AD prior to moving forward in the publication process. >>> >>> For the AUTH48 status of this document, please see: >>> https://www.rfc-editor.org/auth48/rfc9390 >>> >>> Thank you, >>> RFC Editor/ap >>> >>>> On Apr 11, 2023, at 2:19 AM, lionel.morand@orange.com wrote: >>>> >>>> Hi, >>>> >>>> Thank you for your patience. >>>> Please find below our feedback. >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> >>>> Orange Restricted >>>> >>>>> -----Message d'origine----- >>>>> De : rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> Envoyé : >>>>> vendredi 24 mars 2023 18:08 À : mark@azu.ca; marco.liebsch@neclab.eu; >>>>> MORAND Lionel INNOV/NET <lionel.morand@orange.com> Cc : >>>>> rfc-editor@rfc-editor.org; dime-ads@ietf.org; dime-chairs@ietf.org; >>>>> jounikor@gmail.com; rwilton@cisco.com; auth48archive@rfc-editor.org >>>>> Objet : Re: AUTH48: RFC-to-be 9390 >>>>> <draft-ietf-dime-group-signaling-14> 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] Please insert any keywords (beyond those that appear >>>>> in the title) for use on https://www.rfc-editor.org/search. --> >>>> >>>> [[LM]] Nothing to add. >>>> >>>>> >>>>> >>>>> 2) <!--[rfced] For clarity, may we update this sentence below? >>>>> >>>>> Original: >>>>> If the Diameter server accepts the client's request for a group >>>>> assignment, the server MUST assign the new session to each of the one >>>>> or multiple identified session groups when present in the Session- >>>>> Group-Info AVP. >>>>> >>>>> Perhaps: >>>>> If the Diameter server accepts the client's request for a group >>>>> assignment, the server MUST assign the new session to each (one or more) >>>>> of the identified session groups when present in the Session- >>>>> Group-Info AVP. >>>>> --> >>>> >>>> [[LM]] We agree! >>>> >>>>> >>>>> >>>>> 3) <!--[rfced] May we update instances of "service-specific auth" to >>>>> be "service-specific authorization"? >>>>> >>>>> Original: >>>>> When sending the response to the client, e.g., a service-specific auth >>>>> response as per NASREQ AA-Answer [RFC7155], the server MUST include >>>>> all Session-Group-Info AVPs as received in the client's request. >>>>> >>>>> Perhaps: >>>>> When sending the response to the client, e.g., a service-specific authorization >>>>> response as per NASREQ AA-Answer [RFC7155], the server MUST include >>>>> all Session-Group-Info AVPs as received in the client's request. >>>>> --> >>>> >>>> [[LM]] in the present case, it can only be "authorization". And, as it is "e.g." it is >>> fine to say "service-specification authorization". >>>> >>>>> >>>>> >>>>> 4) <!-- [rfced] We are having trouble parsing the latter part of this sentence. >>>>> Please consider whether the suggested update correctly conveys the >>>>> intended meaning. >>>>> >>>>> Original: >>>>> In such case, the response to the group command MUST >>>>> NOT identify any group but identify solely the single session for >>>>> which the command has been processed. >>>>> >>>>> Suggested: >>>>> In such case, the response to the group command MUST >>>>> NOT identify any group other than the single session for >>>>> which the command has been processed. >>>>> --> >>>> >>>> [[LM]] The node can request to process a request for all sessions assigned to >>> one or multiple groups identified in the request. But the receiving node can decide >>> to treat the request only for the Session-Id included in the request. >>>> >>>> Proposed clarification: >>>> >>>> OLD: >>>> >>>> In such case, the response to the group command MUST >>>> NOT identify any group but identify solely the single session for >>>> which the command has been processed. >>>> >>>> NEW: >>>> >>>> In such case, the response to the group command MUST >>>> NOT include any group identifier but only the Session-Id identifying the >>> session for >>>> which the command has been processed. >>>> >>>>> >>>>> >>>>> 5) <!-- [rfced] Please review each artwork element in the xml file. >>>>> Specifically, should any artwork element be tagged as sourcecode or >>>>> another element? >>>>> --> >>>> >>>> [[LM]] OK. None of the artwork element should be tagged as sourcecode. >>>> >>>>> >>>>> >>>>> 6) <!-- [rfced] Is the following general guidance for future >>>>> registries, or is it guidance for IANA in setting up these two >>>>> registries and it should be removed since the registries have already been >>> created? >>>>> >>>>> Original: >>>>> The AVP names can be used as registry names >>>>> --> >>>> >>>> [[LM]] only guidance for IANA. Can be removed when processed. >>>>> >>>>> >>>>> 7) <!-- [rfced] Would you like the references to be alphabetized or >>>>> left in their current order? >>>>> --> >>>> >>>> [[LM]] no specific preference. It is actually based on the first occurrence but any >>> order would be fine for us. >>>> >>>>> >>>>> >>>>> 8) <!--[rfced] We have lowercased "Service-Specific" in the sentence >>>>> below, as there are case no occurrences of the capitalized form used in RFC >>> 6733. >>>>> Please let us know if you have any conerns. >>>>> >>>>> Original: >>>>> As in [RFC6733], the term >>>>> Service-Specific below refers to a message defined in a Diameter >>>>> application (e.g., Mobile IPv4, NASREQ). >>>>> >>>>> Perhaps: >>>>> As in [RFC6733], the term >>>>> 'service-specific' below refers to a message defined in a Diameter >>>>> application (e.g., Mobile IPv4, NASREQ). >>>>> --> >>>> >>>> [[LM]] OK! >>>> >>>>> >>>>> >>>>> 9) <!--[rfced] Should Tables 2 and 3 have titles? Please review, and >>>>> provide titles if desired. --> >>>>> >>>> [[LM]] OK! For sake of clarity: >>>> >>>> OLD: >>>> >>>> Table 2 >>>> >>>> NEW: >>>> >>>> Table 2: Group Authorization Session State Machine for Stateful Client >>>> >>>> OLD: >>>> >>>> Table 3 >>>> >>>> New: >>>> >>>> Table 3: Group Authorization Session State Machine for Stateful Server >>>> >>>>> >>>>> 10) <!--[rfced] How should the following acronyms that appear in >>>>> Tables 2 and 3 be expanded? Would it be helpful to include text that >>>>> precedes Tables 2 and 3 to define the expansions of these acronyms? >>>>> >>>>> GASR >>>>> GASA >>>>> GSTA >>>>> GSTR >>>>> --> >>>>> >>>> >>>> [[LM]] it would not arm to list all of them: >>>> >>>> GASR: Group-Abort-Session-Request >>>> GASA: Group-Abort-Session-Answer >>>> GSTA: Group-Session-Termination-Answer >>>> GSTR: Group-Session-Termination-Request >>>> >>>>> >>>>> 11) <!--[rfced] Throughout the text, the following terminology >>>>> appears to be used inconsistently. Please review these occurrences >>>>> and let us now if/how they may be made consistent. >>>>> >>>>> result code vs. Result-Code >>>> >>>> [[LM]] No inconsistency here. "result code" is a value. "Result-Code" is the AVP. >>>> >>>>> re-authorization request vs. Re-Authorization Request (RAR) >>>>> --> >>>> >>>> [[LM]] OK! >>>> >>>>> >>>>> >>>>> 12) <!-- [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. >>>>> >>>>> For example, please consider whether "natively" should be updated. >>>>> --> >>>> >>>> [[LM]] only one occurrence. >>>> >>>> OLD: >>>> >>>> Newly defined Diameter applications may natively support Diameter >>>> session grouping and group operations. Such applications provide >>>> intrinsic discovery for the support of session grouping capability >>>> using the assigned Application Id advertised during the capability >>>> exchange phase described in Section 5.3 of [RFC6733]. >>>> >>>> NEW: >>>> >>>> Newly defined Diameter applications may intrinsically support Diameter >>>> session grouping and group operations. In such a case, there is no need >>>> of a specific discovery mechanism for the support of session grouping >>>> capability besides the discovery of the Application Id assigned to the >>>> application advertised during the capability exchange phase described in >>>> Section 5.3 of [RFC6733]. >>>> >>>>> >>>>> >>>>> >>>>> Thank you. >>>>> >>>>> RFC Editor >>>>> >>>>> >>>>> On Mar 24, 2023, at 10:05 AM, rfc-editor@rfc-editor.org wrote: >>>>> >>>>> *****IMPORTANT***** >>>>> >>>>> Updated 2023/03/24 >>>>> >>>>> 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/rfc9390.xml >>>>> https://www.rfc-editor.org/authors/rfc9390.html >>>>> https://www.rfc-editor.org/authors/rfc9390.pdf >>>>> https://www.rfc-editor.org/authors/rfc9390.txt >>>>> >>>>> Diff file of the text: >>>>> https://www.rfc-editor.org/authors/rfc9390-diff.html >>>>> https://www.rfc-editor.org/authors/rfc9390-rfcdiff.html (side by >>>>> side) >>>>> >>>>> Diff of the XML: >>>>> https://www.rfc-editor.org/authors/rfc9390-xmldiff1.html >>>>> >>>>> The following files are provided to facilitate creation of your own >>>>> diff files of the XML. >>>>> >>>>> Initial XMLv3 created using XMLv2 as input: >>>>> https://www.rfc-editor.org/authors/rfc9390.original.v2v3.xml >>>>> >>>>> XMLv3 file that is a best effort to capture v3-related format updates >>>>> only: >>>>> https://www.rfc-editor.org/authors/rfc9390.form.xml >>>>> >>>>> >>>>> Tracking progress >>>>> ----------------- >>>>> >>>>> The details of the AUTH48 status of your document are here: >>>>> https://www.rfc-editor.org/auth48/rfc9390 >>>>> >>>>> Please let us know if you have any questions. >>>>> >>>>> Thank you for your cooperation, >>>>> >>>>> RFC Editor >>>>> >>>>> -------------------------------------- >>>>> RFC9390 (draft-ietf-dime-group-signaling-14) >>>>> >>>>> Title : Diameter Group Signaling >>>>> Author(s) : M. Jones, M. Liebsch, L. Morand >>>>> WG Chair(s) : Jouni Korhonen, Lionel Morand >>>>> Area Director(s) : Warren Kumari, Robert Wilton >>>>> >>>> >>>> >>> ______________________________________________________________________ >>>> ___________________________________________________ >>>> >>>> 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. >> >> _________________________________________________________________________________________________________________________ >> >> 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 9390 <draft-ietf-dime-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9390 <draft-ietf-d… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9390 <draft-ietf-d… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9390 <draft-ietf-d… lionel.morand
- Re: [auth48] AUTH48: RFC-to-be 9390 <draft-ietf-d… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9390 <draft-ietf-d… lionel.morand
- Re: [auth48] [AD] AUTH48: RFC-to-be 9390 <draft-i… Alanna Paloma
- Re: [auth48] [AD] AUTH48: RFC-to-be 9390 <draft-i… lionel.morand
- Re: [auth48] [AD] AUTH48: RFC-to-be 9390 <draft-i… Alanna Paloma
- Re: [auth48] [AD] AUTH48: RFC-to-be 9390 <draft-i… Alanna Paloma
- Re: [auth48] [AD] AUTH48: RFC-to-be 9390 <draft-i… lionel.morand
- Re: [auth48] [AD] AUTH48: RFC-to-be 9390 <draft-i… Rob Wilton (rwilton)
- Re: [auth48] [AD] AUTH48: RFC-to-be 9390 <draft-i… Marco Liebsch
- Re: [auth48] [AD] AUTH48: RFC-to-be 9390 <draft-i… Mark Jones
- Re: [auth48] AUTH48: RFC-to-be 9390 <draft-ietf-d… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9390 <draft-ietf-d… lionel.morand