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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Alanna,

The change in section 4.1.1 is fine to me, although I wonder whether "In these cases" would scan better than "In such a case", but I'll defer to your better judgement here!

Regards,
Rob


-----Original Message-----
From: Alanna Paloma <[e-mail]> 
Sent: 20 April 2023 01:29
To: [e-mail]; [e-mail]; [e-mail]; Rob Wilton (rwilton) <[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.
>