RADIUS EXTensions
charter-ietf-radext-07-03

[Ballot comment]

Just a couple of easy suggestions:

Para 2:  Spell out WBA, and remove 'as needed to support the work of those organizations'.

Para 3: I think the sentence that starts, 'Any non-backwards compatibility...' could be streamlined by removing the long list of RFCs, leaving 'Any non-backwards compatibility changes with existing RADIUS RFCs, including the RadSec RFC (when published) must be justified.'

Work items:  Some of these could be turned into milestones.

I have no earthly idea what a 'roaming consortia' is, hopefully the working group knows.

[Ballot block]
I support Roman's block here for the reasons he states.

The statement "support the work of those organizations":

- Inverts the normal relationship between the IETF and external bodies
(the IETF produces standards; others may choose to adopt them)

- Could be used to justify work items that lack genuine IETF community
consensus by claiming external demand

- Is inconsistent with RFC 2026 and BCP 9 principles of individual participation

Secondly, none of the work items specifies an intended publication type
(PS, BCP, Informational, or Experimental). Eric noted he was about to
block on this issue. You could say I am enabling that.

Finally, the four multi-hop work items, the roaming best-practices document, and the minor extensions
work all require different tracks (likely PS for protocol extensions, BCP for best practices).

[Ballot comment]
Paragraph 1
> 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. Any non-backwards compatibility changes
> with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,
> 4675, 5080, 5090, 5176, 6158, 6929, 8044 and the RadSec RFC (when published) must be justified.

The existing RADIUS/TLS RFC (RFC 6614) and RADIUS/DTLS RFC (RFC 7360) are absent from the backward-compatibility
list — if the bis supersedes them, the list should be updated to reflect that.

[Ballot block]
** Working on behalf of other organizations.  The charter says:

“The radext WG will publish minor RADIUS extensions,
best-practices documents and clarifications, as needed to support the work of those organizations.”

“Define and publish minor extensions to RADIUS, such as new attribute definitions, needed by external organizations or other IETF WGs.”

I’m not sure what the inclusion of these statements is intended to do regarding scope or process, but it was unexpected and seems to suggest an alternative to the current standards process of consensus and participation as individuals.

-- The introductory text says that this WG will focus on maintenance of RADIUS.  The above text caveats working on extensions on behalf of others in the first clause.  Is this suggesting that WG couldn’t self-initiate extension work?

-- How is the standards process guiding the WG changed at all by the fact that an outside group needs an extension? 

-- How are these organizations given standing to ask for extension (e.g., who gets to ask since this is a scope criteria)?  Typically, a decision to do work (e.g., an extension) and publish is done via WG (and then later IETF) consensus.  What’s the alternative being proposed here?  Even if the request came from another IETF WG, the same procedures would apply (i.e., there would need to be consensus in RADEXT to do the work).

Could the intended scope of work be written as follows:

OLD
“The radext WG will publish minor RADIUS extensions,
best-practices documents and clarifications, as needed to support the work of those organizations.”

NEW
The radext WG will publish minor RADIUS extensions,
best-practices documents and clarifications.

OLD
“Define and publish minor extensions to RADIUS, such as new attribute definitions, needed by external organizations or other IETF WGs.”

NEW
Define and publish minor extensions to RADIUS.

[Ballot comment]
* In what way is this text providing scoping: “Information from operators shows that anywhere from 20% to 90% of authentications are for accounts which are always rejected.”?  Is this a target that the future solution from need to improve upon directly written into the charter text?  What, if anything, would be lost if it was removed?

* Significant new scope has been added.  What are the associated milestones?

[Ballot comment]
Hi all,

Thanks for the charter refresh to keep maintenance of this important technology for many operations.

Please find some few comments below:

# Not all RADIUS attributes are/will be defined in RADEXT

CURRENT:
  Define and publish minor extensions to RADIUS, such as new attribute definitions,
  needed by external organizations or other IETF WGs.

I think that we need some text that says (and which actually reflects the practice so far), that RADIUS attributes can be defined in the WGs that own the technololgy. RADEXT will be responsible for reviewing those.

# (nit) As this is a long-life maintenance, I would make this change:

OLD:
  The immediate goals of the RADEXT working group are to:

NEW:
  The goals of the RADEXT working group are to:

For example, defining new attributes defines that there is actually a need for it. Which is not "immediate".

# (nit) The formatting of sub-bullet is broken.

# Not sure I would keep the following in the charter

CURRENT:
  Information from operators shows
  that anywhere from 20% to 90% of authentications are for accounts which are always rejected.

Cheers,
Med

[Ballot comment]
Thanks for doing the rechartering as RADIUS is important.

Some minor comment though:
- introduce the WG acronym at the beginning
- expand WBA (and provide a reference ?)
- the 2nd level bullet list is wrongly formatted as it appears as first level
- s/The immediate goals of the RADEXT working group/The goals of the WG/
- unsure whether `Information from operators shows that anywhere from 20% to 90% of authentications are for accounts which are always rejected.` belongs to a charter rather than in a draft introduction/justification

*I am trusting the responsible AD to formally state the intended publication status of all work items (I was about to BLOCK on this issue).*

[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