This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

As I am not very familiar with this topic, most of my comments are editorial except a few.
My comments are only suggestions to improve the text and I'd happy to discuss them if needed.


COMMENTS:
Section 1.1 : “NODENAME: the invariant once established text string used in URIs to identify a member a group.”
Typo at the end of the sentence. 

OLD: to identify a member a group.
NEW: to identify a member of a group.


Section 2: “Client (C): node that wants to join a group and take part in group communication with other group memebrs.”
Typo in the last word- members.

Section 2: “Examples of a Dispatcher are:”
Does this need to include anycast addresses?

Section 3.3.1:”in the groups indicated by the transferred acces token as per its 'scope' claim”
Typo in the word - access.

Section 4.1:
For all the resources defined, can authors double check if “Clients may be authorized to access this resource even without being group members” is mentioned for all applicable resources.

Section 4.1.2: “If the request includes unknown or non-expected fields, the handler MUST silently ignore them and continue processing the request.”
Is this safe to silently ignore such requests? Please double check.

Section 4.2.1.1. “In case the joining node only knows the group identifier of the group it wishes to join or about which it wishes to get update information from the KDC”

Did you mean to say “.. to get updated information..”?

Section 4.4.1.1.
Is it possible to include an example of authentication credential request-response for more than 1 group members?

Section 5: 

OLD: “…if it acts as repository of authentication credentials for group members.”
NEW: “…if it acts as a repository of authentication credentials for group members.”

Similar text “KDC acts as repository” is present elsewhere and can be updated like above.

Section 6.1: “This approach consists in the KDC sending one individual rekeying message to each target group member.”
The beginning of this sentence doesn’t seem right. Can you double check?

Section 6.2.1: 
OLD: “The used encryption algorithm which SHOULD be the same one used to protect communications in the group.”
NEW: “The used encryption algorithm SHOULD be the same one used to protect communications in the group.”

Section 6.3: Paragraph starting with “In the second case, the sender protects a message using the new group keying material, but the recipient receives that message before having received the new group keying material.”

Another suggestion to deal with this case: The recipient can store a message that it can’t decrypt temporarily for a limited time so that if it receives new group keying material shortly after, it can then decrypt those stored messages.

Section 10.
DDOS attack possibilities - I can see some possibilities for DDOS where Clients can overwhelm KDC by sending unexpected or unknown fields. There might be more - can authors provide some possible DDOS attack vectors?



Thanks,
Vidhi