Skip to main content

Admin Interface for the OSCORE Group Manager
draft-ietf-ace-oscore-gm-admin-17

Yes

(Paul Wouters)

No Objection

Andy Newton
Gunter Van de Velde
Jim Guichard
Ketan Talaulikar
(Erik Kline)
(Orie Steele)

Note: This ballot was opened for revision 14 and is now closed.

Andy Newton
No Objection
Éric Vyncke
No Objection
Comment (2026-02-26 for -15) Not sent
Due to the very specific nature of this I-D, I only quickly browsed through it and found nothing related to the INT area.
Gunter Van de Velde
No Objection
Jim Guichard
No Objection
Ketan Talaulikar
No Objection
Mike Bishop
No Objection
Comment (2026-03-02 for -15) Sent
# IESG review of draft-ietf-ace-oscore-gm-admin-15

CC @MikeBishop

## Comments

### Section 3, paragraph 31-32
```
     When using the scope format as defined in this section, the
     permission set ("Tperm") of each admin scope entry MUST include the
     "List" permission.  It follows that, when expressing permissions for
     Administrators of OSCORE groups as defined in this document, an admin
     scope entry has the least significant bit of "Tperm" always set to 1.
```
What happens when a permission set that doesn't allow Listing is encountered? Is
this an error? Invalid according to the scope format? If it's possible to express,
then rules for handling it should be outlined.

```
     earlier in this section, respectively.  The two types of scope
     entries can be unambiguously distinguished by means of the least
     significant bit of their permission set "Tperm", which has value 0
     for the user scope entries and 1 for the admin scope entries.
```
If the LSB is going to be used to differentiate these types, omitting the required
permission would result in confusion about which type the entry expresses and therefore
potential misinterpretation of the remaining bits.

Consider fixing the LSB to 1 in the format rather than requiring the
presence of a permission at that bit. (The List permission can be implicit from
the existence of a scope, leaving the resulting format unchanged.)

### Section 6, paragraph 2
```
     For each operation, it is defined whether that operation is required
     or optional to support for an Administrator and for the Group
     Manager.  If an Administrator supports an operation, then the
     Administrator is able to produce and send the request associated with
     that operation.  If the Group Manager supports an operation, then the
```
It's unclear how the Administrator can be REQUIRED to implement a request that
it initiates. If it doesn't implement it, it simply won't happen. Perhaps better
to state where information retrieved by one operation is a prerequisite to other
operations the Administrator might wish to perform?

### Section 10.3, paragraph 6
```
        (see Section 6.4 and Section 6.5).  Also aligned with what is
        allowed by the granted authorization, the Administrator could
        ultimately delete the group configuration in question by deleting
        the corresponding group-configuration resource (see Section 6.8)
        and then create a new group configuration (see Section 6.3).
```
Does this suggest an attack vector where an attacker could corrupt a URI and induce
an authorized Administrator to delete a group the attacker could not itself
delete?

### Section 11, paragraph 2

Please add links to the relevant registries.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 10.2, paragraph 1
```
-    compromised Group Manager would allow an adversary to also monitor
-                                                          -----
```

#### Section 10.2, paragraph 3
```
-    responsible for, after having experienced a reboot.
-                   -
```

#### Section 10.3, paragraph 2
```
-    'joining_uri' parameter, if the URI does not point to the Group
-                           -
```

#### Section 10.3, paragraph 4
```
-    sent by the Group Manager points to the same Group Manager, by
-                                                              -
```

### Grammar/style

#### Section 3, paragraph 29
```
erns, the encoded scope can be compact in size while allowing the Administrat
                               ^^^^^^^^^^^^^^^
```
This wording could be more concise.

#### Section 8, paragraph 6
```
fferent groups. For a given group, oldest log entries are expected to be tho
                                   ^^^^^^
```
A determiner may be missing.
Mohamed Boucadair
No Objection
Comment (2026-03-02 for -15) Sent
Hi Marco, Rikard, Peter, and Francesca, 

Thank you for the effort put into this well-written document. Special thanks for the detailed operational considerations and the discusson about various management actions, and  partiuclalry the handling of default values.

I only have very few edits/nits that I will sent in a PR for authors convenience. 

Cheers,
Med
Roman Danyliw
No Objection
Comment (2026-03-03 for -15) Not sent
Section 11.4
   *  Value: The numeric identifier for this permission.  Integer values
      greater than 65535 are marked as "Private Use".  All other values
      use the registration policy "Expert Review" (see Section 4.5 of
      [RFC8126]).

Consider adding a citation for “Private Use" with Section 4.1 of RFC8126.
Paul Wouters Former IESG member
Yes
Yes (for -14) Unknown

                            
Erik Kline Former IESG member
No Objection
No Objection (for -14) Not sent

                            
Orie Steele Former IESG member
No Objection
No Objection (for -15) Not sent