Diameter Group Signaling
RFC 9390

Received changes through RFC Editor sync (created alias RFC 9390, changed abstract to 'In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions.  In some use cases, Diameter nodes need to apply the same operation to a large group of Diameter sessions concurrently.  The Diameter base protocol commands operate on a single session so these use cases can result in many thousands of command exchanges enforcing the same operation on each session in the group.  In order to reduce signaling, it is desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter node using a single or a few command exchanges.  This document specifies the Diameter protocol extensions to achieve this signaling optimization.', changed pages to 21, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2023-04-25, changed IESG state to RFC Published)

[Ballot comment]
Thanks to Catherine Meadows for the SECDIR review.

** Section 3.3.  I had trouble reconciling the generic design principles espoused here with the more detailed specification of the protocol documented in Section 4.*.

The text here says:

This specification follows the most flexible model where both, a
  Diameter client and a Diameter server can create a new group and
  assign a new identifier to that session group.

And the table in this section says that the client could assign itself to a server owned session group.

Assign a Session to a non-owned Session Group  |    X  |    X  |

However, in Section 4.2.1

  If the Diameter server receives a command request from a Diameter
  client and the command includes at least one Session-Group-Info AVP
  having the SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group-
  Control-Vector AVP set, the server can accept or reject the request
  for group assignment.

It seems to me that this text in Section 4.2.1 is suggesting that the client could ask to be put into a group but the server has the ability reject it, which seems like an implicit permission model.

** Section 7.  In the table in this section the Session-Group-Id is of type OctetString, but in Section 7.3 it is UTF8String.

** Section 10.  Given the flexible permission model suggested in Section 3.3, is cautionary guidance needed to say that specific applications using this capability need to consider the decisions they make based on group membership?

[Ballot comment]
I agree with the other commenters that an editorial pass over the
document before it is sent to the RFC Editor is probably in order; I
only noted the more eggregious nits that have obvious fixes but skipped
the ones where I did not have a resolution ready at hand to suggest.
Barry's remarks about restrictive vs non-restrictive clauses are
particularly important.

I also have several high-level issues that don't quite rise to
discuss-level but seem worth getting resolution on; they mostly involve
edge cases where the current text either leaves me unclear on what is
supposed to happen or seems to present conflicting guidance:

- what's the error handling in cases of partial success?
  * For operations adding/removing sessions to/from groups, it seems that
    the general principle is that the new changes introduced with any
    group-relevant CCF exchange are to be treated atomically: either all
    group additions/removals succeed or all fail (and when it fails the
    session is forced into a single-session fallback mode).  But for
    server-initiated modifications this is enforced by "if the client
    can't do it, the client MUST tear down the affected session(s)", and
    I'm not sure if there's a case where the client can send a new
    request that includes some modifications and the server also tries
    to make some modifications in its response; such a scenario might in
    effect allow partial success and might also be hard to correctly
    interpret.
  * For operations acting on groups, we do allow partial success
    (DIAMETER_LIMITED_SUCCESS) and attempt to mandate fallback to
    single-session operation for affected sessions, but the specifics of
    how the Failed-AVP effectuates this are not clear to me (see my
    comment on Section 4.4.3).

- we require that group identifiers are globally unique, which can be
  done with the diameter-node namespace prefix.  But for the portion
  after that prefix, we seem to suggest reusing the construction from
  Section 8.8 of RFC 6733, which is just (in essence) a 64-bit global
  counter.  In the vein of draft-gont-numeric-ids-sec-considerations,
  that seems overly constrained, in that it reveals sequencing across
  group creation and rate of per-node group creation to the remote peer.
  It seems that a construction akin to a keyed hash of a counter would
  preserve the guaranteed uniqueness property but avoid leaking such
  information to the network.

- the permissions model is a bit unorthodox, with groups "owned" by
  their creator but the binding of a session to a group "owned" by the
  node that performed the binding.  It seems like there is some risk of
  deadlock situations or conflict, e.g., where a client has added a
  session to a group G but the server wants to remove the session from
  G, or where a session is part of a group but the owner of the group
  wants to delete the group.  For the latter case, my understanding is
  that group deletion "trumps" ownership of the session/group binding,
  such that deletion can proceed even while sessions are in the group,
  but I'm less sure what should happen in the former case (or others).

- Is it possible to have a group with no member sessions?  Section 3.3
  suggests that if the last session is removed the group should be
  deleted, but AFAICT this would still require the node performing the
  removal to unset SESSION_GROUP_STATUS_IND, and I didn't see a
  requirement to do that spelled out.  I do see how it is impossible to
  create a group directly in a state with no member sessions.

- Is there a requirement to always send the current state of group
  membership when acting on a session?  I could (perhaps naively)
  imagine a case where due to previous interactions a session belongs to
  groups G1, G2, and G3, but in some subsequent request the client only
  mentions G1.  Does the membership in G2 and G3 get implicitly retained
  in the absence of an explicit unset SESSION_GROUP_ALLOCATION_ACTION or
  are there some other constraints that make such a scenario impossible?

- Is there supposed to be a strong distinction between "including" an
  AVP and "appending" one?  I see that 6733 does make some fairly clear
  distinction between the terms, but it seems that (e.g.) in Section
  4.2.1 we use both phrasings to discuss Session-Group-Info.

Now for some section-by-section (mostly editorial or nit-level) notes.

Abstract, Introduction

  a million concurrent Diameter sessions.  Recent use cases have
  revealed the need for Diameter nodes to apply the same operation to a
  large group of Diameter sessions concurrently.  The Diameter base

I note that the -00 is from 2012; are these use cases still "recent"?

Section 3

As an editorial note, the way the current text jumps in to say that
sessions can be assigned to groups leaves the reader uncertain whether
this is describing preexisting functionality or the new mechanisms added
by this document.  A top-level intro paragraph for Section 3 that says
roughly "to accomodate bulk operations on Diameter sessions, the concept
of session groups is introduced; once sessions are added to a group, a
command acting on the group will affect all the member sessions" might
help.

Section 3.3

If I understand correctly, the lines in the table for "remove a session
from an owned Session Group"/"remove a session from a non-owned Session
Group" mean only that this operation can be done sometimes, not that it
can always be done (per the lines about "created the assignment".  Would
it be helpful to indicate this, perhaps by using a different symbol for
those lines and adding a footnote?

Section 4

While I understand the desire to keep the document structure as it is,
with the actual AVPs specified in Section 7, it would have been very
helpful to have a toplevel introductory paragraph here that mentions or
references that there is a containing Session-Group-Info grouped AVP
that contains the Session-Group-Control-Vector with information about
the action and group, and zero or one(?) Session-Group-Id AVP to
identify the group when a specific group is being identified.  This
would also allow clarifying whether the Session-Group-Id AVP is
currently only defined to appear within the Session-Group-Info.

Section 4.1.1

                                          Such applications provide
  intrinsic discovery for the support of session grouping capability
  using the assigned Application Id advertised during the capability
  exchange phase two Diameter peers establish a transport connection
  (see Section 5.3 of [RFC6733]).

nit: I think there's a missing word here, perhaps "where" after "phase"?

Section 4.2.1

  The client may also indicate in the request that the server is
  responsible for the assignment of the session in one or multiple
  sessions owned by the server.  [...]

nit(?): is this supposed to be "assignment of the session into one or
multiple session *groups* owned by the server"?  I'm having a hard time
understanding it as written.

  If the assignment of the session to one or some of the multiple
  identified session groups fails, the session group assignment is
  treated as failure.  In such case the session is treated as single
  session without assignment to any session group by the Diameter
  nodes.  The server sends the response to the client and MAY include
  those Session-Group-Info AVPs for which the group assignment failed.
  The SESSION_GROUP_ALLOCATION_ACTION flag of included Session-Group-
  Info AVPs MUST be cleared.

I guess I understand the part where the entire set of group-assignment
operations has to succeed or fail as an atomic unit, but this text
perhaps implies some semantics that the server is supposed to only
explicitly include in the response the subset of group assignments that
were unable to be processed, omitting the ones that could have been
processed (but were not processed since a failure on one means that none
of the operations get applied).  If that's the intent, I'd suggest being
a bit more explicit about what is and isn't sent.

  A Diameter client, which sent a request for session initiation to a
  Diameter server and appended a single or multiple Session-Group-Id
  AVPs but cannot find any Session-Group-Info AVP in the associated

(editorial) the phrase "cannot find" makes me wonder how hard it's
expected to be looking; more definitive statements about "not present"
seem more typical for RFC style.

Section 4.2.3

  When a Diameter server enforces an update to the assigned groups mid-

nit: this seems to be the only time we use the word "enforce" in this
sense in the document; previous discussion seems to just use "decides to
make an update" or similar.

  answer.  The client subsequently sends a service-specific re-
  authorization request containing one or multiple Session-Group-Info
  AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the
  Session-Group-Id AVP identifying the session group to which the
  session had been previously assigned.  [...]

nit: I think this has to be "group or groups" to be consistent with the
rest of the doc.

Section 4.4.1

  Either Diameter node (client or server) can request the recipient of
  a request to process an associated command for all sessions assigned
  to one or multiple groups by identifying these groups in the request.
  The sender of the request appends for each group, to which the
  command applies, a Session-Group-Info AVP including the Session-
  Group-Id AVP to identify the associated session group.  Both, the
  SESSION_GROUP_ALLOCATION_ACTION flag as well as the
  SESSION_GROUP_STATUS_IND flag MUST be set.

What's the error handling if one or both listed flags are not set --
just ignore the request?

  Action AVP to ALL_GROUPS (1) or PER_GROUP (2).  If the answer can be
  sent before the complete process of the request for all the sessions
  or if the request timeout timer is high enough, the sender MAY set
  the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2).

(side note) just the phrase "high enough" doesn't give much of an
indication of what the criteria are and what numerical values might be
appropriate.  That said, it's not entirely clear how much guidance we
can really give in this situation.

Section 4.4.2

  If the received request identifies multiple groups in multiple
  appended Session-Group-Id AVPs, the receiver SHOULD process the
  associated command for each of these groups.  If a session has been
  assigned to more than one of the identified groups, the receiver MUST
  process the associated command only once per session.

Why is this only a SHOULD for each group -- what other behaviors could
the receiver do?

Section 4.4.3

  In the case of limited success, the sessions, for which the
  processing of the group command failed, MUST be identified using a
  Failed-AVP AVP as per Section 7.5 of [RFC6733].  [...]

My reading of the referenced part of RFC 6733 is that there is a single
Failed-AVP pointing to a single AVP that could not be processed
properly.  Is there such a single failed AVP in the case where
processing failed for multiple sessions in the group(s)?  It seems that
the "largest containing AVP" that includes all failed groups might be so
large so as to not be useful in indicating the problem.

Section 7.2

  SESSION_GROUP_STATUS_IND (0x00000010)

If there's a mnemonic for the "IND" part of "SESSION_GROUP_STATUS_IND",
that would be helpful to expand.

Section 9.2

The Specification Required policy includes review by Designated Experts;
is there any guidance we should provide to the DEs?

Appendix A.1

      Discon    GASA received                  Cleanup      Idle

Spot-checking against RFC 6733's state machine, the non-group ASA
received case only makes this transition when there was a previous ASR
that was successfully sent.  Is that am important distinction?  (Also,
as an editorial nit, RFC 6733 spells "Clean up" as two words.)

[Ballot comment]
Question:
Are there any implementations of this? A section/appendix documenting the improvements would be nice if so (decrease in CPU / how quickly N sessions can be changed, etc.)


Comment:
I also found some of this to be quite heavy reading, but I'm assuming that the readers are likely to be Diameter implementers who are already involved / willing to put in the work.


Nit:
"to the appended Group-Response-Action AVP ." -- extra space before period. Yes, 'tis a nit, but it would bug me if I didn't mention it...

[Ballot comment]
Thank you for the work put into this document. Like Barry and other ADs, I found this document difficult to read: long and complex sentences do not help the reader (but I am not a native English speaker). Therefore, I trust the responsible AD for the correctness of all the details in the specification. E.g., FSM or time line diagrams would have been helpful.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==


== COMMENTS ==

Any reason why the authors affiliation is not shown ?

The shepherd write-up is dated back in 2018... Is it still applicable ?

-- Section 7.2 --
About the flag bits, I wonder why the values are not 0x01 and 0x02 rather than 0x01 and 0x10. Isn't this a waste of bits ? Should the IANA sub-registry for those flags be mentioned?

[Ballot comment]
I agree with Barry's editorial suggestions.

What does the "*)" in the table in Section 3.3 mean?

From Section 10:

  [...]  if the Diameter client or server is
  compromised, an attacker could launch DoS attacks by terminating a
  large number of sessions with a limited set of commands using the
  session group management concept.

Is it worth mentioning that an attacker could also mess with the set of sessions associated with a group, possibly causing disruptions other than bulk session terminations?

[Ballot comment]
I have to say that I found this to be challenging to read: much of it is very dense, with paragraphs giving sometimes-subtly-different conditions, and I would be reading it thinking, “Does this paragraph apply to my situation?  I don’t think so, but what about the next one?  Wait, maybe it was the other one after all.”  I just have to assume that someon actually implementing Diameter would have an easier time following it.

I have some editorial comments that won’t help with that aspect, but that I hope will help with clarity in general:

— Section 3.1 —

  A session group, which has sessions assigned, can be deleted, e.g.,
  due to a change in multiple users' subscription profile so that the
  group's assigned sessions do not share certain characteristics

It appears that “has sessions assigned” is restrictive (it’s a required description, not just extra information).  If so, it should say, “A session group that has sessions assigned can be deleted, e.g., due to...” without the internal commas.

Another way to put it might be, “A session group can be deleted even if it has sessions assigned, e.g., due to...”

— Section 3.3 —

  This specification follows the most flexible model where both, a
  Diameter client and a Diameter server can create a new group and

Nit: no comma here

  Either the client and the server
  can assign a session to a group.

Nit: “Either the client or the server can”, or “Both the client and the server can”.

  Details about
  enforcing a more constraint permission model

I think the word you want is “constrained”.

— Section 4.2 —

  Diameter AAA
  applications typically assign client and server roles to the Diameter
  nodes, which are referred to as relevant Diameter nodes to utilize
  session grouping and issue group commands.

I’m having trouble parsing this sentence and determining what you’re trying to tell me.  Can you please rephrase or repunctuate it to make it clearer?  What are referred to as “relevant Diameter nodes”?  What goes with “to utilize session grouping”?

  Diameter nodes, which are group-aware, MUST store and maintain an
  entry about the group assignment together with a session's state.

Similar to earlier: is “are group aware” meant to be restrictive (there are Diameter nodes that are group aware and those that are not, and you’re talking about the former), or non-restrictive (all Diameter nodes are group aware, and you’re just pointing that fact out).  It is currently written as non-restrictive, but I think you mean it to be restrictive.  If that is correct, remove both commas and change “which” to “that”.

  A Diameter node MUST also keep a record about sessions, which
  have been assigned to a session group by itself.

The comma shouldn’t be there, and “which” should be “that”.  But it’s a bit awkward anyway: may I suggest rephrasing in active voice as, “Each Diameter node MUST also keep a record about sessions that it has assigned to a session group.”

— Section 4.2.1 —

  If the
  response from the server indicates success in the result code but
  solely the assignment of the session to a session group has been
  rejected by the server, the client treats the session as single
  session without group assignment.

What does “solely” mean in this sentence?

  A Diameter client, which sent a request for session initiation

Please remove the comma (and change “which” to “that”).

— Section 4.2.2 —

  The session, which is to be removed from a group, is

Make it, “The session that is to be removed from the group is”

  When a Diameter client decides to remove a session from all session
  groups, to which the session has been previously assigned,

Remove the comma after “groups”.

  The session, which is to be removed from all groups, to
  which the session has been previously assigned, is identified in the
  Session-Id AVP of the command request.

Make it, “The session that is to be removed from all groups to which it had been previously assigned is identified in the Session-Id AVP of the command request.”

— Section 7.3 —

  The
    portion of the Session-Group-Id MUST identify the
  Diameter node, which owns the session group.

Please remove the comma and change “which” to “that”.

[Ballot comment]
Sec 4.2.3

"The server responds with a  service-specific auth response and includes one or multiple Session- Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and
  the Session-Group-Id AVP identifying the session group, to which the  identified session is to be assigned.  With the same response  message, the server may send one or multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP identifying the session groups from which the
  identified session is to be removed."

s/may/MAY, to match similar text in 4.2.2. Much as in that section, it is a little subtle that the state can be totally inferred by the first requirement, and the second MAY requirement is purely advisory.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dime-group-signaling-13. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the AVP Codes registry on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at:

https://www.iana.org/assignments/aaa-parameters/

five, new AVP Codes are to be registered as follows:

AVP Code: [ TBD-at-Registration ]
Attribute Name: Session-Group-Info
Reference: [ RFC-to-be ]

AVP Code: [ TBD-at-Registration ]
Attribute Name: Session-Group-Control-Vector
Reference: [ RFC-to-be ]

AVP Code: [ TBD-at-Registration ]
Attribute Name: Session-Group-Id
Reference: [ RFC-to-be ]

AVP Code: [ TBD-at-Registration ]
Attribute Name: Group-Response-Action
Reference: [ RFC-to-be ]

AVP Code: [ TBD-at-Registration ]
Attribute Name: Session-Group-Capability-Vector
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the Session-Group-Control-Vector AVP registry. The new registry will be located on the the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at:

https://www.iana.org/assignments/aaa-parameters/

The registry will be managed via Specification Required as defined in RFC 8126. There are initial values in the new registry as follows.

Control Attribute
Flag Name Reference
-----------+----------------------------------+--------------
0x00000001 SESSION_GROUP_ALLOCATION_ACTION [ RFC-to-be ]
0x00000010 SESSION_GROUP_STATUS_IND [ RFC-to-be ]

IANA Question --> Is 0x00000000 reserved? Are all the values from 0x00000011 to 0x11111111 unassigned?

Third, a new registry is to be created called the Session-Group-Capability-Vector AVP registry. The new registry will be located on the the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at:

https://www.iana.org/assignments/aaa-parameters/

The registry will be managed via Standards Action as defined in RFC 8126. There are initial values in the new registry as follows.

Control Attribute
Flag Name Reference
-----------+----------------------------------+--------------
0x00000001 BASE_SESSION_GROUP_CAPABILITY [ RFC-to-be ]

IANA Question --> Is 0x00000000 reserved? Are all the values from 0x00000010 to 0x11111111 unassigned?

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-01-25):

From: The IESG
To: IETF-Announce
CC: dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-group-signaling@ietf.org, jounikor@gmail.com, rwilton@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Diameter Group Signaling) to Proposed Standard


The IESG has received a request from the Diameter Maintenance and Extensions
WG (dime) to consider the following document: - 'Diameter Group Signaling'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-01-25. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  In large network deployments, a single Diameter node can support over
  a million concurrent Diameter sessions.  Recent use cases have
  revealed the need for Diameter nodes to apply the same operation to a
  large group of Diameter sessions concurrently.  The Diameter base
  protocol commands operate on a single session so these use cases
  could result in many thousands of command exchanges to enforce the
  same operation on each session in the group.  In order to reduce
  signaling, it would be desirable to enable bulk operations on all (or
  part of) the sessions managed by a Diameter node using a single or a
  few command exchanges.  This document specifies the Diameter protocol
  extensions to achieve this signaling optimization.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/



No IPR declarations have been submitted directly on this I-D.

Hi,

This is my AD evaluation of draft-ietf-dime-group-signaling-12.

This draft is on the right track, but is not ready for IETF LC. I have a few substantive comments and a number of editorial comments that need to be resolved first.
----------

*** Substantive Comments ***
- General: There were comments in the shepherd’s report that need to be addressed.

§4.1: Why is the SHOULD not a MUST? What would be the consequences of not following it?

§4.1.2, last paragraph: How long should a node remember that another node has announced support for groups? Is that memory forever? What happens if that node ceases to support groups in the future?

§4.2:

- "A Diameter node MUST also keep a record about sessions,
which have been assigned to a session group by itself.”

Is this the same as saying a node MUST record the owner of each group? Why does it matter which node assigned a specific session to a group?

§4.2 and children:

I’d like to see more text about what combinations are allowed and there order of application. For example, if the presence of a Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and Session-Group-Id AVP absent indicates deletion of a session from all groups, what if the message also contains other Session-Group-Info AVPs that assign groups? Is that the same thing as moving a session between groups?

I’d also like to see some earlier text describing the meaning of Session-Id AVPs in group management and group operations. There’s a mention of that in the “format” section, but that seems an odd place to put it.


§4.2.1:

- General: Am I correct to assume that failure of a Diameter command means no groups are assigned? If so, please state that explicitly.

- first paragraph: The “MUST” seems like a statement of fact. That is, there’s no implementation choice to make here.

- "If the Diameter server accepts the client’s request for a group
assignment, but the assignment of the session to one or some of the
multiple identified session groups fails,”

This seems self contradictory; if the assignment fails then how can the server have accepted it? Is there a practical difference between assignment failure and assignment rejection?

- "If the Diameter server receives a command request from a Diameter
client and the command comprises one or multiple Session-Group-Info
AVPs and none of them includes a Session-Group-Id AVP, the server MAY
decide to assign the session to one or multiple session groups.”

Is there an expectation that the server assigns the session to the same number of groups as the the number of Session-Group-Id AVPs included by the client? If not, why would the client ever include more than one.

Is the client prohibited from sending multiple AVPs, some of which contain session IDs and some of which do not?

- "the Diameter client SHOULD NOT retry to request
group assignment for this session, but MAY try to request group
assignment for other new sessions.”

Why is the SHOULD NOT not a MUST NOT?

§4.2.3:
- "When a Diameter server enforces an update to the assigned groups midsession,
it sends a Re-Authorization Request (RAR) message to the
client identifying the session…”

Should that say “or service-specific request”? Or is this operation limited to applications that use RAR?

§4.4.1:

- "If the process of the request
is delay-sensitive, the sender SHOULD NOT set the Group-Response-
Action AVP to ALL_GROUPS (1) or PER_GROUP (2).”

Why not MUST NOT?

- "If the answer can be
sent before the complete process of the request for all the sessions
or if the request timeout timer is high enough, the sender MAY set
the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2).”

Can you offer guidance on how to decide if a timeout timer is high enough?

§5:

- It’s worth mentioning that a stateful proxy must advertise support.

- "Session group related AVPs being defined as optional AVP
SHOULD be ignored by stateless Proxy Agents and SHOULD NOT be removed
from the Diameter commands.”

This seems to put normative requirements on nodes that do not implement this spec. Or is it really a statement of fact?

§7.3: Can you offer guidance on how to ensure sufficient uniqueness? “Eternal” seems like a pretty high bar; is that really the intention?

§10: It doesn’t seem likely that the e2e protection work for Diameter will ever complete, or at least not in the near future. I suggest toning down the hopeful language that talks about it.


*** Editorial Comments and Nits **

- General: The draft needs at least another proofreading and editing pass to improve readability and clarity. In particular, it needs to be proofread for the following:
- plural agreement
- Comma usage (there are many placed incorrectly, and many missing where needed)
- Proper use of “which” vs “that” (and the associated comma use.)
- Convoluted sentence structure

§2: Please use the new boilerplate from RFC 8174.
i
§3.1,
-  first paragraph: “e.g.” requires a comma afterwards: “e.g.,”  (There are several instances of this throughout the draft.)

- "In case of mobile users, the user’s session may get transferred to a
new Diameter client during handover and assigned to a different
group, which is maintained at the new Diameter client, mid-session.”

This is hard to parse. I suggest moving “mid-session” to earlier in the sentence. For example, “… session may get transferred mid-session to a new Diameter client…”

§3.2: I gather this section is an example. If say, please state that explicitly.

§3.3:
- This section uses confusing language to describe which nodes can do what. In particular, it often says “any” node, where I think it means “either the client or the server”. I assume nodes that are not a party to a session-group can’t modify it, correct? Likewise it says “each” node when I think it means “either node”.

- "Prerequisite for deletion
of a session group is that the Diameter node created the session
beforehand, hence the node became the group owner.”

This seems like a complicated way to explain a simple concept. I suggest something to the effect of “A session group may only be deleted by the Diameter node that created it.”

- "The enforcement of more constrained permissions is left to the
specification of a particular group signaling enabled Diameter
application and compliant implementations of such application MUST
enforce the associated permission model.”

This is overly complicated language. I suggest something to the effect of ""Diameter application with explicit support for session groups may define a more constrained permission model.” Also, the MUST is not really appropriate; it’s up to the definitions of those applications to set normative requirements on implementations, not _this_ draft.

- "specification. For example, a more constrained model could require
that a client MUST NOT remove a session from a group which is owned
by the server.”

Please do not use normative keywords in an example; examples are by definition non-normative.

- Default permissions table: I am confused by the “client” and “server” columns. If I understand this section correctly, the role of “client” and “server” is not relevant. (It is telling that each row has the same value in both columns.) Please consider stating this in terms of group “owner” and “non-owner”.

- Editor’s note: If this draft does not consider overruling a node’s assignment, why talk about it at all?  (Although it seems like it _does_ support that, in the sense that a server can reject or change assignments proposed by a client.)

§4.1: Please avoid normative language in the form of “SHOULD…only…”. That can be ambiguous. It’s better to say “SHOULD NOT … unless. For example, “SHOULD NOT perform group operations with a node unless the node has advertised support”.

§4.1.1:

- It seems to me that §4.1.1 and §4.1.2 have “explicit” and “implicit” reversed, in the sense that, if a Diameter application supports groups, then the announcement of group support is “implied” by the announcement of support for the application. OTOH, the use of Session-Group-Capability-Vector is an “explicit” announcement of group support.

- "New Diameter applications may consider support “

s/consider/specify

- "Such applications provide intrinsic discovery for the
support of group commands and announce this capability through the
assigned application ID.”

This is confusing. I think you mean support for groups is implied by the announcement of support for the application that explicitly supports it.But it can be read to mean a separate explicit announcement of group support.

§4.2:
- "It is left to the application to
determine the policy of session grouping.”
Does “application” mean Diameter application, or just “implementation”? Also, this is vague; I think this still talks about limits to the number of groups a  session belongs to, which is much more precise than “the policy of session grouping”.

- The second paragraph seems redundant with §3.3.

The phrase “single or multiple” would be easier to read as “one or more”. (This pattern repeats throughout the draft, along with some instances of “one or multiple”)

- “A list of all known session groups should be locally maintained on each
node, each group pointing to individual sessions being assigned to
the group."

s/should be/is

§4.2.1:

- “… the server MUST assign the new session to each of the one
or multiple identified session groups when present in …”

- "If the Diameter server receives a command request from a Diameter
client and the command comprises at least one Session-Group-Info AVP”

s/comprises/includes  (“comprises” means “made up of”, which would suggest that the request contains only Session-Group-Info AVPs).  (This occurs several times throughout the draft.)

What does “when” mean in context? Would “...session groups present in…” mean the same thing?

- "In case one or multiple identified session groups
are not already stored by the server”

“In case” usually refers to planning for a contingency (For example, “I have a fire extinguisher in case of fire”). I suggest “In the case where…” or even better, “If…”  (Variations of this pattern occur several times.)

- "the server MUST store the new
identified group(s)”
s/new/newly

- "The server sends the response to the client and
MAY include as information to the client only those Session-Group-
Info AVPs for which the group assignment failed.”

Hard to parse.

- "session. When the Diameter client is
confident that the Diameter server supports session grouping…”

Since this should always be true before the client sends _any_ group operation, why restate it here?

§4.4.1:

- "Either Diameter node (client or server) can request the recipient of
a request to process an associated command for all sessions being
assigned to one or multiple groups by identifying these groups in the
request.”

s/sessions being assigned/sessions assigned

- Please expand “CCF” on first mention.

- sentence starting with "When a server sends, as example, a Re-Authorization Request
(RAR) or a service-specific server-initiated request…”

The sentence is hard to parse.

- "If the sender sends a request including the Group-Response-Action AVP
set to ALL_GROUPS (1) or PER_GROUP (2), it MUST expect some delay…”

“expect” is vague for use in a MUST requirement. Please state this in terms of concrete actions or state it descriptively.

§A.1, first paragraph: Please don’t use normative keywords to describe requirements defined in other documents. Doing so introduces a high chance of error if either document is updated in the future.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards Track, which is indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The Diameter base protocol commands operate on a single session so some
  deployment cases could result in many thousands of command exchanges to
  enforce the same operation on each session in the group.  Specifying a mechanisms
  for bulk operations on a number of session  managed by a Diameter node using a
  single or a few command exchanges would significantly reduce signalling.  This
  document specifies the Diameter protocol extensions to achieve this signalling
  optimisation.

Working Group Summary

  There is a consensus behind the document. It just took a long time
  to complete the work.

Document Quality

  There are no known implementation of this protocol yet.
  There are plans expressed that the solution will be contributed
  into FreeDiameter.

  There is no need for MIB Doctor, Media Type or Expert
  review in this document.

Personnel

  Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd.
  Ben Campbell is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  Shepherd has reviewed the document as part of the proto write-up
  process. The document (-11) was re-reviewed again Dec 2019.

  There are places for improvement, which are not fatal, though. For
  example "AVP" is used before expanding the acronym.

  In Section 4.1.2 it is not clear whether it is possible for a Diameter node
  to withdraw its announcement for group operation support. The current
  text says on lines 301-304 to log and remember node's support.

  Section 6 is currently worded in a way that a group support has to use
  existing commands. It should be possible to create new commands for
  group support alone with a new Application ID. Although this is not
  explicit, it would be the case anyway.

  Section 7.4. "Group-Response-Action AVP" defines how the node should
  follow up with exchanges in response to a command which impacts multiple
  sessions. The shepherd chose not to ask for an IANA registry for this AVP.
  If one is seen beneficial during the IESG review shepherd's recommendation
  for assignment is "Standards Action" policy. However, the shepherd thinks
  there are no foreseen new actions without changing the current protocol.
 
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. The document has been lingering the DIME WG for a long time
  and the people who are interested in this work have already said
  their comments.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No issues. However, the security considerations refer to possible
  end to end security work in DIME / Diameter that may or may not take
  place. Only RFC7966 for requirements exist.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes. There are no IPR concerns.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  Solid consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  No IDnits found that would not be corrected with a freshly generated
  txt file from the XML or that are not editorial.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No need.

(13) Have all references within this document been identified as
either normative or informative?

  Yes. However, there are only Normative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document requests for 5 new AVP code points.

  The document creates two new registries:
  1) Session-Group-Control-Vector AVP registry for capability bits
        with two initial assignments.

        The future registration assignment policy is "Specification Required".

  2) Session-Group-Capability-Vector AVP with one initial assignment.
        Changes to this registry is "Standards Action" policy.
 
  The AVP names work as the registry names.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

1) Session-Group-Control-Vector AVP registry. The future registration
      assignment policy is "Specification Required".

Existing "AVP Codes" experts listed in IANA for Diameter should suffice.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None. AVPs were hand checked.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards Track, which is indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The Diameter base protocol commands operate on a single session so some
  deployment cases could result in many thousands of command exchanges to
  enforce the same operation on each session in the group.  Specifying a mechanisms
  for bulk operations on a number of session  managed by a Diameter node using a
  single or a few command exchanges would significantly reduce signalling.  This
  document specifies the Diameter protocol extensions to achieve this signalling
  optimisation.

Working Group Summary

  There is a consensus behind the document. It just took a long time
  to complete the work.

Document Quality

  There are no known implementation of this protocol yet.
  There are plans expressed that the solution will be contributed
  into FreeDiameter.

  There is no need for MIB Doctor, Media Type or Expert
  review in this document.

Personnel

  Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd.
  Ben Campbell is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  Shepherd has reviewed the document as part of the proto write-up
  process. The document (-11) was re-reviewed again Dec 2019.

  There are places for improvement, which are not fatal, though. For
  example "AVP" is used before expanding the acronym.

  In Section 4.1.2 it is not clear whether it is possible for a Diameter node
  to withdraw its announcement for group operation support. The current
  text says on lines 301-304 to log and remember node's support.

  Section 6 is currently worded in a way that a group support has to use
  existing commands. It should be possible to create new commands for
  group support alone with a new Application ID. Although this is not
  explicit, it would be the case anyway.

  Section 7.4. "Group-Response-Action AVP" defines how the node should
  follow up with exchanges in response to a command which impacts multiple
  sessions. The shepherd chose not to ask for an IANA registry for this AVP.
  If one is seen beneficial during the IESG review shepherd's recommendation
  for assignment is "Standards Action" policy. However, the shepherd thinks
  there are no foreseen new actions without changing the current protocol.
 
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. The document has been lingering the DIME WG for a long time
  and the people who are interested in this work have already said
  their comments.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No issues. However, the security considerations refer to possible
  end to end security work in DIME / Diameter that may or may not take
  place. Only RFC7966 for requirements exist.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes. There are no IPR concerns.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  Solid consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  No IDnits found that would not be corrected with a freshly generated
  txt file from the XML or that are not editorial.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No need.

(13) Have all references within this document been identified as
either normative or informative?

  Yes. However, there are only Normative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document requests for 5 new AVP code points.

  The document creates two new registries:
  1) Session-Group-Control-Vector AVP registry for capability bits
        with two initial assignments.

        The future registration assignment policy is "Specification Required".

  2) Session-Group-Capability-Vector AVP with one initial assignment.
        Changes to this registry is "Standards Action" policy.
 
  The AVP names work as the registry names.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

1) Session-Group-Control-Vector AVP registry. The future registration
      assignment policy is "Specification Required".

Existing "AVP Codes" experts listed in IANA for Diameter should suffice.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None. AVPs were hand checked.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards Track, which is indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The Diameter base protocol commands operate on a single session so some
  deployment cases could result in many thousands of command exchanges to
  enforce the same operation on each session in the group.  Specifying a mechanisms
  for bulk operations on a number of session  managed by a Diameter node using a
  single or a few command exchanges would significantly reduce signalling.  This
  document specifies the Diameter protocol extensions to achieve this signalling
  optimisation.

Working Group Summary

  There is a consensus behind the document. It just took a long time
  to complete the work.

Document Quality

  There are no known implementation of this protocol yet.
  There are plans expressed that the solution will be contributed
  into FreeDiameter.

  There is no need for MIB Doctor, Media Type or Expert
  review in this document.

Personnel

  Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd.
  Eric Rescola is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  Shepherd has reviewed the document as part of the proto write-up
  process. The document (-11) was re-reviewed again Dec 2019.

  There are places for improvement, which are not fatal, though. For
  example "AVP" is used before expanding the acronym.

  In Section 4.1.2 it is not clear whether it is possible for a Diameter node
  to withdraw its announcement for group operation support. The current
  text says on lines 301-304 to log and remember node's support.

  Section 6 is currently worded in a way that a group support has to use
  existing commands. It should be possible to create new commands for
  group support alone with a new Application ID. Although this is not
  explicit, it would be the case anyway.

  Section 7.4. "Group-Response-Action AVP" defines how the node should
  follow up with exchanges in response to a command which impacts multiple
  sessions. The shepherd chose not to ask for an IANA registry for this AVP.
  If one is seen beneficial during the IESG review shepherd's recommendation
  for assignment is "Standards Action" policy. However, the shepherd thinks
  there are no foreseen new actions without changing the current protocol.
 
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. The document has been lingering the DIME WG for a long time
  and the people who are interested in this work have already said
  their comments.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No issues. However, the security considerations refer to possible
  end to end security work in DIME / Diameter that may or may not take
  place. Only RFC7966 for requirements exist.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes. There are no IPR concerns.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  Solid consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  No IDnits found that would not be corrected with a freshly generated
  txt file from the XML or that are not editorial.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No need.

(13) Have all references within this document been identified as
either normative or informative?

  Yes. However, there are only Normative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document requests for 5 new AVP code points.

  The document creates two new registries:
  1) Session-Group-Control-Vector AVP registry for capability bits
        with two initial assignments.

        The future registration assignment policy is "Specification Required".

  2) Session-Group-Capability-Vector AVP with one initial assignment.
        Changes to this registry is "Standards Action" policy.
 
  The AVP names work as the registry names.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

1) Session-Group-Control-Vector AVP registry. The future registration
      assignment policy is "Specification Required".

Existing "AVP Codes" experts listed in IANA for Diameter should suffice.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None. AVPs were hand checked.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards Track, which is indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The Diameter base protocol commands operate on a single session so some
  deployment cases could result in many thousands of command exchanges to
  enforce the same operation on each session in the group.  Specifying a mechanisms
  for bulk operations on a number of session  managed by a Diameter node using a
  single or a few command exchanges would significantly reduce signalling.  This
  document specifies the Diameter protocol extensions to achieve this signalling
  optimisation.

Working Group Summary

  There is a consensus behind the document. It just took a long time
  to complete the work.

Document Quality

  There are no known implementation of this protocol yet.
  There are plans expressed that the solution will be contributed
  into FreeDiameter.

  There is no need for MIB Doctor, Media Type or Expert
  review in this document.

Personnel

  Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd.
  Eric Rescola is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  Shepherd has reviewed the document as part of the proto write-up
  process. The document (-11) was re-reviewed again Dec 2019.

  There are places for improvement, which are not fatal, though. For
  example "AVP" is used before expanding the acronym.

  In Section 4.1.2 it is not clear whether it is possible for a Diameter node
  to withdraw its announcement for group operation support. The current
  text says on lines 301-304 to log and remember node's support.

  Section 6 is currently worded in a way that a group support has to use
  existing commands. It should be possible to create new commands for
  group support alone with a new Application ID. Although this is not
  explicit, it would be the case anyway.
 
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. The document has been lingering the DIME WG for a long time
  and the people who are interested in this work have already said
  their comments.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No issues. However, the security considerations refer to possible
  end to end security work in DIME / Diameter that may or may not take
  place. Only RFC7966 for requirements exist.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes. There are no IPR concerns.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  Solid consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  No IDnits found that would not be corrected with a freshly generated
  txt file from the XML or that are not editorial.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No need.

(13) Have all references within this document been identified as
either normative or informative?

  Yes. However, there are only Normative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document requests for 5 new AVP code points.

  The document creates two new registries:
  1) Session-Group-Control-Vector AVP registry for capability bits
        with two initial assignments.

        The future registration assignment policy is "Specification Required".

  2) Session-Group-Capability-Vector AVP with one initial assignment.
        Changes to this registry is "Standards Action" policy.
 
  The AVP names work as the registry names.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None. AVPs were hand checked.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards Track, which is indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The Diameter base protocol commands operate on a single session so some
  deployment cases could result in many thousands of command exchanges to
  enforce the same operation on each session in the group.  Specifying a mechanisms
  for bulk operations on a number of session  managed by a Diameter node using a
  single or a few command exchanges would significantly reduce signalling.  This
  document specifies the Diameter protocol extensions to achieve this signalling
  optimisation.

Working Group Summary

  There is a consensus behind the document. It just took a long time
  to complete the work.

Document Quality

  There are no known implementation of this protocol yet.
  There are plans expressed that the solution will be contributed
  into FreeDiameter.

  There is no need for MIB Doctor, Media Type or Expert
  review in this document.

Personnel

  Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd.
  Eric Rescola is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  Shepherd has reviewed the document as part of the proto write-up
  process. The document (-11) was re-reviewed again Dec 2019.

  There are places for improvement, which are not fatal, though. For
  example "AVP" is used before expanding the acronym.

  In Section 4.1.2 it is not clear whether it is possible for a Diameter node
  to withdraw its announcement for group operation support. The current
  text says on lines 301-304 to log and remember node's support.

  Section 6 is currently worded in a way that a group support has to use
  existing commands. It should be possible to create new commands for
  group support alone with a new Application ID. Although this is not
  explicit, it would be the case anyway.
 
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. The document has been lingering the DIME WG for a long time
  and the people who are interested in this work have already said
  their comments.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No issues. However, the security considerations refer to possible
  end to end security work in DIME / Diameter that may or may not take
  place. Only RFC7966 for requirements exist.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes. There are no IPR concerns.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  Solid consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  No IDnits found that would not be corrected with a freshly generated
  txt file from the XML or that are not editorial.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No need.

(13) Have all references within this document been identified as
either normative or informative?

  Yes. However, there are only Normative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document requests for 5 new AVP code points.

  The document creates two new registries, however, there are
  clearly two new registries are created:
  1) Session-Group-Control-Vector AVP registry for capability bits
        with two initial assignments.

        The future registration assignment policy is "Specification Required".

  2) Session-Group-Capability-Vector AVP with one initial assignment.
        Changes to this registry is "Standards Action" policy.
 
  The AVP names work as the registry names.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None. AVPs were hand checked.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards Track, which is indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The Diameter base protocol commands operate on a single session so some
  deployment cases could result in many thousands of command exchanges to
  enforce the same operation on each session in the group.  Specifying a mechanisms
  for bulk operations on a number of session  managed by a Diameter node using a
  single or a few command exchanges would significantly reduce signalling.  This
  document specifies the Diameter protocol extensions to achieve this signalling
  optimisation.

Working Group Summary

  There is a consensus behind the document. It just took a long time
  to complete the work.

Document Quality

  There are no known implementation of this protocol yet.
  There are plans expressed that the solution will be contributed
  into FreeDiameter.

  There is no need for MIB Doctor, Media Type or Expert
  review in this document.

Personnel

  Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd.
  Eric Rescola is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  Shepherd has reviewed the document (-11) as part of the proto write-up
  process. The document was re-reviewed again Dec 2019.

  There are places for improvement, which are not fatal, though. For
  example "AVP" is used before expanding the acronym.

  In Section 4.1.2 it is not clear whether it is possible for a Diameter node
  to withdraw its announcement for group operation support. The current
  text says on lines 301-304 to log and remember node's support.

  Section 6 is currently worded in a way that a group support has to use
  existing commands. It should be possible to create new commands for
  group support alone with a new Application ID.
 

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. The document has been lingering the DIME WG for a long time
  and the people who are interested in this work have already said
  their comments.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No issues. However, the security considerations refer to possible
  end to end security work in DIME / Diameter that may or may not take
  place.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes. There are no IPR concerns.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  Solid consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  No IDnits found that would not be corrected with a freshly generated
  txt file from the XML or that are not editorial.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No need.

(13) Have all references within this document been identified as
either normative or informative?

  Yes. However, there are only Normative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document requests for 5 new AVP code points.

  The document does not request new registries, however, there are
  clearly two new registries are created:
  1) Session-Group-Control-Vector AVP registry for capability bits
        with two initial assignments.

        The future registration assignment policy is not described.
        The shepherd suggests "Specification Required" required.

  2) Session-Group-Capability-Vector AVP with one initial assignment.
        Changes to this registry would most likely change the group
        session management "overlay" protocol, the shepherd proposes
        "Standards Action" policy.
 
  The AVP names work as the registry names.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None. AVPs were hand checked.