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

Peter Deacon <> Mon, 24 March 2014 16:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BAE361A0236 for <>; Mon, 24 Mar 2014 09:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.789
X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pPnkS0TBpcyc for <>; Mon, 24 Mar 2014 09:43:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2654B1A025C for <>; Mon, 24 Mar 2014 09:43:09 -0700 (PDT)
Received: from (unverified []) by (Rockliffe SMTPRA 7.0.6) with ESMTP id <>; Mon, 24 Mar 2014 09:43:07 -0700
Date: Mon, 24 Mar 2014 09:43:23 -0700 (Pacific Daylight Time)
From: Peter Deacon <>
To: Jouni Korhonen <>
In-Reply-To: <>
Message-ID: <alpine.WNT.2.11.1403240855250.12912@SMURF>
References: <>
User-Agent: Alpine 2.11 (WNT 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "" <>, "" <>
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 16:43:11 -0000

On Tue, 18 Mar 2014, Jouni Korhonen wrote:

> We had good support to adopt draft-hartman-radext-bigger-packets I-D as a WG
> item during the London WG meeting. However, we need to confirm the adoption
> in the mailing list. This mail starts a one week adoption call for the I-D.

> If you are against the adoption, voice your opinion and why. Silence is
> counted as an acceptance. The call ends 25th March.

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.

Would like to see a solution whether it's bigger packets, extended request 
or something else offer full coverage yet enable implementors to support 
any subset they see value in supporting.

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