RADIUS EXTensions
charter-ietf-radext-07

[Ballot block]
I support approval of this charter with the defined text, and it is my intent to ballot YES.  Per Section 2.2 of RFC2418, this charter still requires formal milestones (i.e., "Enumerates a set of milestones together with time frames for their completion.") before approval.

[Ballot comment]
# GEN AD review of charter-ietf-radext-06-03

CC @larseggert

## 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

#### "RADIUS.", paragraph 0
```
- RADIUS. Any non-backwards compatibility changes with existing RADIUS
-                          ^        - ^^^
+ RADIUS. Any non-backwards-compatible changes with existing RADIUS
+                          ^        ^
```

#### Section 5080, paragraph 0
```
- be compatible with RFC 3539, with any non-backwards compatibility changes
-                                                    ^        - ^^^
+ be compatible with RFC 3539, with any non-backwards-compatible changes
+                                                    ^        ^
```

#### Section 5080, paragraph 1
```
- The WG will review its existing RFCs' document track categories and
- where necessary or useful change document tracks, with minor changes in
-                                ^^^^^^^^^  ^^^^
+ The WG will review the standards levels of existing RFCs and,
+ where necessary or useful, propose changes to those levels, with minor changes in
+                          +++++++++      ^  ^^^^^^^^^^^^^
```

#### Section 5080, paragraph 5
```
- - Bring RFC 6614 (RADIUS/TLS), and RFC 7360 (RADIUS/DTLS) to
+ - Bring RFC 6614 (RADIUS/TLS), and RFC 7360 (RADIUS/DTLS) to the
+                                                            ++++
```

#### Section 5080, paragraph 8
```
- - Improve operations for multi-hop RADIUS networks: e.g. loop detection
-                                                  ^
- and prevention, a multi-hop Status-Server equivalent with ability to
-              ^ ^
+ - Improve operations for multi-hop RADIUS networks, e.g., loop detection
+                                                  ^    +
+ and prevention. A multi-hop Status-Server equivalent with ability to
+              ^ ^
```

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Ignoring the way that the charter has been written, which others have already commented on, then I broadly agree with the scope/aims for this WG.  Further, if the WG has a tight timeline for completing the bulk of the work then I think that it would probably also be helpful to ensure that they can make good progress - i.e., that they are able to meet in IETF 116.

One point that wasn't entirely clear to me is whether this WG is chartered to work on other things beyond the listed items without a recharter or whether they are restricted to those items only.  Potentially making this clear in the charter text would be helpful.

[Ballot block]
While I like the goals of the re-chartering, I am afraid that the use of "if possible" is meaningless in a charter. Suggest to change it to something like "all incompatibilities with existing RFC must be justified and explained".

Hope this helps to crystallise the charter

Regards

-éric

[Ballot comment]
Like other IESG member wrote, please remove all the text related to AD's discretion, we are not kings ;-)

Unsure about the added timeline pressure added by Wi-Fi 8 (BTW should there be a reference to Wi-Fi 8 ?)

[Ballot comment]
This seems like a sensible and well-scoped effort, but I had a hard time
reading the proposed charter. In the end I think it comes down to, it had a
lot of extra words that to my eye, are not needed. Rather than call out
individual criticisms, I just took 01 of the charter and edited it, the
edited version is below. The bullet items are untouched, I edited only the
pre- and postamble. Feel free to use it, amend it, or not, as you prefer.

My intention with these proposed changes is that semantically it's the same
as the 01 charter. The one substantive change is that I took out the bits
about things the AD has to approve, because those go without saying anyway.

I also thought Erik had a good point that some of the work items, for
example "define best practices..." seem like OPS territory so it might be
good to call out ops in the introductory text. However I haven't proposed
any change in that regard.

$0.02.

--

The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol. To ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
all documents produced must specify means of interoperation with legacy
RADIUS and, if possible, be backward compatible with existing RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675,
5080, 5090, 5176 and 6158. Transport profiles should, if possible, be
compatible with RFC 3539.

The WG will review its existing RFCs' document track categories and
where necessary or useful change document tracks, with minor changes in
the documents if needed.

Work Items

The immediate goals of the RADEXT working group are:

- Deprecating the use of insecure transports outside of secure
networks. This work updates RFC 6421 where possible.

- Bring RFC 6614 (RADIUS/TLS), and RFC 7360 (RADIUS/DTLS) to
Standards track.

- Define best practices for using TLS-PSK with TLS-based transport.

- Define best practices for RADIUS roaming, and roaming consortia
based on experience with RADIUS/TLS.

- Improve operations for multi-hop RADIUS networks: e.g. loop detection
and prevention, a multi-hop Status-Server equivalent with ability to
Trace the proxy steps a RADIUS message will follow.

- Extend the 8-bit RADIUS ID space to allow more than 256 "in flight"
packets across one connection.

- Allow for CoA / Disconnect packets to be sent in "reverse" down a
RADIUS/TLS or RADIUS/DTLS connection. This functionality assists with
transit of NATs.

- Defining Application-Layer Protocol Negotiation (ALPN) extensions  for RADIUS/TLS and RADIUS/TLS
which allow the use of those transports in a FIPS-140 compliant environment.

Timeline:

Much of this work should be completed by 2024 in order to be part of
the Wi-Fi 8 release, with products in 2026.

[Ballot comment]
# GEN AD review of charter-ietf-radext-06-01

CC @larseggert

## Comments

### "RADIUS", paragraph 0
```
  The RADIUS Extensions Working Group will focus on extensions to the
  RADIUS protocol pending approval of the new work from the Area Director
  and clarify its usage and definition.
```
It's a bit odd to start with this and not the actual list of work items that are
in scope...

### Section 5080, paragraph 4
```
  The immediate goals of the RADEXT working group are to address the
  following issues:
```
Only a few of these are issues. Most are just deliverables.

### Section 5080, paragraph 6
```
  - Define best practices for using TLS-PSK with TLS-based transport.
```
Are "best practices" a BCP? In general, would be good to indicate intended RFC
levels here.

### Section 5080, paragraph 13
```
  Much of this work should be completed by 2024 in order to be part of
  the WiFi 8 release, with products in 2026.
```
That is IMO very ambitious, but hey.

## 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.

### Grammar/style

#### Section 5080, paragraph 16
```
d by 2024 in order to be part of the WiFi 8 release, with products in 2026. T
                                    ^^^^
```
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
# Internet AD comments for charter-ietf-radext-06-01
CC @ekline

## Comments

* At a high level it might be possible to try to recharter for both "focus
  on [RADIUS] extensions" and "focus on [RADIUS] operations", as much of this
  seems like operational advice?  As long as OPS ADs weren't too territorial
  about "all things ops" it might turn this exercise into a simpler update
  of the milestones.

[Ballot comment]
This text is garbled:

    When a
NAS is simply performs an exact copy of an EAP-Identity into a User-Name,
invalid packets might be produced.
   
In this text:
   
- Data Types. RFC 2865 defines a number of data types, but later
  documents do not use those types in a consistent way.  This work item
      will define data types, and update the IANA RADIUS Attribute Type
  registry so that each attribute has a data type.  Where necessary, it
  will correct issues with previous specifications.  This will be a
  standards track document.
     
I'm not understanding if there are are constraints about backward compatibility between data types from this work and RFC 2865. If that's unknown, or obvious, that's fine, of course.

In this text:

Larger Packets. Support RADIUS packets greater than 4096-octets over
RADIUS transports with this capability.

Is this doing anything that would benefit from TSVWG review? I'm guessing not, but wanted to ask.

[Ballot comment]
Question. Will NASes be running a normalisation process for EAP identities, and if, so, do they need any context information, or is all information that they need in the EAP packets?

[Ballot comment]
I agree with Benoît's suggestion about the intended status of the documents.

"Verbatimly"?  I suppose we can make up adverbs on the fly, but you might consider just deleting that (non-)word as unnecessary.

[Ballot comment]
I agree with Benoît's suggestion about the intended status of the documents.

"Verbatimly"?  I suppose we can make up adverbs on the fly, but you might consider just deleted that (non-)word as unnecessary.

[Ballot comment]
Editorial improvement: Remove "Furthermore" in the second paragraph.

Instead of duplicating the RFC type ( "This will be a standards track document.") in the charter and the milestones , consider mentioning it only in the milestones ("Nov 2016 - Data Types as Informational RFC")
advantage #1: strong AD advice, it can still be changed if the WG has got a good reason
advantage #2: it avoids discrepancies between the charter text and the milestones. Look at the data types document :-)

[Ballot comment]
I have no objection.

Looking at the milestones, I am curious  about the large number of documents slated to complete in the next four weeks.

Two new entries:
- Update and clarification of Network Access Identifiers (RFC4282)
- Fragmentation of RADIUS packets to support exchanges exceeding the existing 4KB limit imposed by RFC 2865