Re: [radext] Adoption call for draft-hartman-radext-bigger-packets

Peter Deacon <> Mon, 24 March 2014 17:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 35FA51A0254 for <>; Mon, 24 Mar 2014 10:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X4h-0TozY4Ke for <>; Mon, 24 Mar 2014 10:09:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D5B3A1A024C for <>; Mon, 24 Mar 2014 10:09:10 -0700 (PDT)
Received: from (unverified []) by (Rockliffe SMTPRA 7.0.6) with ESMTP id <>; Mon, 24 Mar 2014 10:09:09 -0700
Date: Mon, 24 Mar 2014 10:09:25 -0700 (Pacific Daylight Time)
From: Peter Deacon <>
To: Alan DeKok <>
In-Reply-To: <>
Message-ID: <alpine.WNT.2.11.1403240955120.12912@SMURF>
References: <> <alpine.WNT.2.11.1403240855250.12912@SMURF> <>
User-Agent: Alpine 2.11 (WNT 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "" <>, Jouni Korhonen <>, "" <>
Subject: Re: [radext] Adoption call for draft-hartman-radext-bigger-packets
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Mar 2014 17:09:13 -0000

On Mon, 24 Mar 2014, Alan DeKok wrote:

> Peter Deacon wrote:
>> I do not support adoption at this time.  Seeing value in continuing to
>> support UDP/DTLS no bridge is available for CoA and Accounting.  Noting
>> also did not support rational in Alex's draft for ignoring this issue
>> for reasons explained in detail earlier on this list.

>  That is unnecessary, for reasons explained in detail earlier on this list.

There is no defined mechanism for coalescing accounting sessions. 
Multi-Session-Id is inter-session rather than intra-session.

Binding CoA to authorization is not something we can support seeing value 
in maintaining autonomy to manage admitted sessions separately from 

>> If systems are to start transmitting more than max size I prefer a less
>> permissive environment where some indication of support is required up
>> front prior to transmitting larger messages.  It can be a manual setting
>> or an automatic "discovery" yet would prefer something "MUST" be indicated.

>  The draft discusses negotiation of large packets, which seems to 
> address the above concerns.

A list of optional procedures are defined.  What I don't see is where it 
says one of them must be followed or an implementation must not assume 
support for larger packets.