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

[Alanna Paloma <[e-mail]>]

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

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!


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.