Re: [auth48] [AD] AUTH48: RFC-to-be 9390 <draft-ietf-dime-group-signaling-14> for your review

[Mark Jones <[e-mail]>]

Good morning Alanna,

I have reviewed the changes in the latest version.  With Rob's feedback 
incorporated, I approve its publication.

I echo the thanks for all the excellent feedback and editorial work.

Regards
Mark


On 2023-04-20 06:18, Marco Liebsch wrote:
> Dear Alanna,
>
> I could not spot any remaining item that needs to be fixed. I approve the publication of the latest version of the document
> after having Robert's feedback to section 4.1.1 taken into account.
>
> Many thanks for your work on the document.
>
> Best regards,
> marco
>
> -----Original Message-----
> From: Alanna Paloma <[e-mail]>
> Sent: Donnerstag, 20. April 2023 02:29
> To: [e-mail]; [e-mail]; Marco Liebsch <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [AD] AUTH48: RFC-to-be 9390 <draft-ietf-dime-group-signaling-14> for your review
>
> 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 <[e-mail]> 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, [e-mail] wrote:
>>>
>>> Dear Alana,
>>>
>>> Thank you for your quick feedback.
>>> Please find our response below.
>>>
>>> Regards,
>>>
>>> Lionel
>>>
>>>
>>> Orange Restricted
>>>
>>>> -----Message d'origine-----
>>>> De : Alanna Paloma <[e-mail]> Envoyé : mardi 11 avril 2023
>>>> 22:40 À : MORAND Lionel INNOV/NET <[e-mail]>;
>>>> [e-mail] Cc : [e-mail]; [e-mail];
>>>> [e-mail]; dime- [e-mail]; [e-mail];
>>>> [e-mail]; 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, [e-mail] wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Thank you for your patience.
>>>>> Please find below our feedback.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Lionel
>>>>>
>>>>>
>>>>> Orange Restricted
>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : [e-mail] <[e-mail]> Envoyé :
>>>>>> vendredi 24 mars 2023 18:08 À : [e-mail];
>>>>>> [e-mail]; MORAND Lionel INNOV/NET <[e-mail]> Cc :
>>>>>> [e-mail]; [e-mail];
>>>>>> [e-mail]; [e-mail]; [e-mail];
>>>>>> [e-mail] 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, [e-mail] 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
>>>>>>
>>>>>> *  [e-mail] (the RPC team)
>>>>>>
>>>>>> *  other document participants, depending on the stream (e.g.,
>>>>>>     IETF Stream participants are your working group chairs, the
>>>>>>     responsible ADs, and the document shepherd).
>>>>>>
>>>>>> *  [e-mail], which is a new archival mailing list
>>>>>>     to preserve AUTH48 conversations; it is not an active discussion
>>>>>>     list:
>>>>>>
>>>>>>    *  More info:
>>>>>>       https://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,
>>>>>>       [e-mail] will be re-added to the CC list and
>>>>>>       its addition will be noted at the top of the message.
>>>>>>
>>>>>> You may submit your changes in one of two ways:
>>>>>>
>>>>>> An update to the provided XML file — OR — An explicit list of
>>>>>> changes in this format
>>>>>>
>>>>>> Section # (or indicate Global)
>>>>>>
>>>>>> OLD:
>>>>>> old text
>>>>>>
>>>>>> NEW:
>>>>>> new text
>>>>>>
>>>>>> You do not need to reply with both an updated XML file and an
>>>>>> explicit list of changes, as either form is sufficient.
>>>>>>
>>>>>> We will ask a stream manager to review and approve any changes
>>>>>> that seem beyond editorial in nature, e.g., addition of new text,
>>>>>> deletion of text, and technical changes.  Information about stream
>>>>>> managers can be found in the FAQ.  Editorial changes do not
>>>>>> require approval from a
>>>> stream manager.
>>>>>>
>>>>>> Approving for publication
>>>>>> --------------------------
>>>>>>
>>>>>> To approve your RFC for publication, please reply to this email
>>>>>> stating that you approve this RFC for publication.  Please use
>>>>>> ‘REPLY ALL’, as all the parties CCed on this message need to see your approval.
>>>>>>
>>>>>>
>>>>>> 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.