Minutes IETF99: radext
minutes-99-radext-00

RADEXT WG IETF 99 Agenda
========================
Chairs:
Stefan Winter <stefan.winter at restena.lu>
Lionel Morand <lionel.morand@orange.com>

Jabber room: radext at jabber.ietf.org (Please join)
Time and Day: Wednesday 19 Jul 2017, 1330-1500 CEST

Place: Karlin III

There were 7 people in the room, including the chairs and the AD.
None of the authors having a presentation was in the room or in remote participation.
At least a clear indication that a F2F meeting is not needed!

Preliminaries (10 min)
----------------------
Audio/Video & Remote Presentation Debugging
Note Well
Note Takers
Jabber scribe
Agenda bash
Document Status

Working group draft discussion (5 min)
--------------------------------------
   * Dynamic Authorization Proxying in Remote
     Authorization Dial-In User Service Protocol
     (RADIUS)
     - draft-ietf-radext-coa-proxy -
                                            :  5 min

This document has completed the WGLC and S. Winter has started Write-Up as document
shepherd. For the shepherd, the content is indeed mostly okay. But it must have
escaped the WGLC scrutiny as there was an entire section with the sole content "Stuff".
Can we really rely on WG scrutiny if an empty section is not detected? With so few
active participants, processes are hard to keep up.

Authors have to produce a new revision of the document.

Individual Drafts (20 min)
--------------------------

The two following documents are competitive solutions to solve the same problem:

   * Getting beyond the 256 packets-in-flight
     limit and other header changes - various
     approaches

    - draft-chen-radext-identifier-attr -

Presented by Stefan as the author was not there.

This document defines a new 32-bit "Extended Identifier" attribute that is to be used
together with the Identifier field to match outstanding requests and replies. Capability
support is discovered using Status-Server messages.

Comments:
Brian Weis (Cisco): Simple approach and backward compatible with exiting implementation.
Ok with this proposal. People in the room share the same understanding.

     - draft-dekok-radext-request-authenticator -
                                            : 15 min

Presented by Stefan as the author was not there.

This document proposes to use the Request Authenticator to be used as an additional
field for identifying packets. It relies on the under specification of the use of the
Request Authenticator and define a new behavior that can be beneficial to solve the 256
packets-in-flight limitation issue.

The approach outlined in this specification is largely similar to the "extended ID"
approach, except that it leverages a pre-existing field as an identifier, instead of
creating a new one. A new one is still needed to echo the Request-Authenticator back
in replies, so that the sending client can identify which reply is for which request.

Comments:
Both approaches are very similar and workable and it is a kind of beauty contest.
For people in the room, the approach of defining a specific attribute to carry the new
functionality appears as the more explicit method - every request carries an explicit
evidence that extended IDs are in use - , compared to the semantic re-use of the Request
Authenticator in which the extensibility is only implicit and has to be inferred by
maintaining state of preceeding Status-Server exchanges or by inspecting the replies).

It is proposed to push forward the draft-chen-radext-identifier-attr. This will be
discussed on the mailing list.


Wrap-up (20 minutes)
--------------------
Open mic: the future of radext

The future of the group was discussed at the end of the session.

It has been decided to finish the ongoing work, including the non-WG document on
Extended ID and then close the WG. When the working group will be closed, the mailing
list will be left open.
New proposed works on RADIUS will be discussed on the mailing list and then be candidate
for AD sponsoring, or can be taken to the opsawg group.

Chairs and AD wil see how to move the Experimental RFC on RADIUS/TLS to Standards track
RFC. A closer look is required, especially regarding the work on TLS 1.3. The feeling in
the room was that a simple re-labeling of RFC6614 is a good short-term measure, with any
fixes or TLS version considerations deferred to a new document updating RFC6614 (which
would likely happen in opsawg then).

It was likely the last RADEXT meeting at the IETF.

The meeting was adjourned after 40-45 minutes.