Radext Status PagesRADIUS EXTensions (Active WG)
Ops Area: Benoit Claise, Warren Kumari | 2004-Jul-14 —Chairs:
IETF-99 radext minutes
Session 2017-07-19 1330-1500: Karlin III - Audio stream - radext chatroom
RADEXT WG IETF 99 Agenda ======================== Chairs: Stefan Winter Lionel Morand 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.