* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Radext Status Pages

RADIUS 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

Minutes

minutes-99-radext-00 minute



          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.
          
          



Generated from PyHt script /wg/radext/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -