Re: [radext] Fwd: New Version Notification for draft-ietf-radext-radius-fragmentation-05.txt

Alejandro Perez Mendez <alex@um.es> Wed, 19 March 2014 10:07 UTC

Return-Path: <alex@um.es>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEB91A06CA for <radext@ietfa.amsl.com>; Wed, 19 Mar 2014 03:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level:
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLCIfnSy6A2A for <radext@ietfa.amsl.com>; Wed, 19 Mar 2014 03:07:29 -0700 (PDT)
Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDC61A06C8 for <radext@ietf.org>; Wed, 19 Mar 2014 03:07:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id DBBB532D7; Wed, 19 Mar 2014 11:07:19 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon23.um.es
Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XkG3PNbIsvuQ; Wed, 19 Mar 2014 11:07:19 +0100 (CET)
Received: from [10.42.0.19] (84.124.131.72.dyn.user.ono.com [84.124.131.72]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon23.um.es (Postfix) with ESMTPSA id 35905268A; Wed, 19 Mar 2014 11:07:17 +0100 (CET)
Message-ID: <53296C54.7030907@um.es>
Date: Wed, 19 Mar 2014 11:07:16 +0100
From: Alejandro Perez Mendez <alex@um.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Alan DeKok <aland@deployingradius.com>
References: <20140307075126.8756.14600.idtracker@ietfa.amsl.com> <53197B56.10303@um.es> <53281E36.2020708@cisco.com> <53282898.9050504@um.es> <532849D2.3040504@deployingradius.com>
In-Reply-To: <532849D2.3040504@deployingradius.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/I6eUEEh1Znq1HN9xKTK5qIFhi1A
Cc: radext@ietf.org
Subject: Re: [radext] Fwd: New Version Notification for draft-ietf-radext-radius-fragmentation-05.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Mar 2014 10:07:32 -0000

El 18/03/14 14:27, Alan DeKok escribió:
> Alejandro Perez Mendez wrote:
>> we could extend that line to something like:
>>
>> The
>>    authors acknowledge this is formally violating [RFC2865], but no
>>    operational issues are expected as no known implementation 
>>    perform that verification when proxying Access-Requests, since doing so would
>>    preclude them to support future extensions. 
>   Perhaps this (word-smithing)
>
> The authors acknowledge that this specification violates the "MUST"
> requirement of [RFC2865] Section 4.1.  We note that a proxy which
> enforces that requirement would be unable to support future RADIUS
> authentication extensions.  Extensions to the protocol would therefore
> be impossible to deploy.
>
> All known implementations have chosen the philosophy of "be liberal in
> what you accept".  That is, they accept traffic which violates the
> requirement of [RFC2865] Section 4.1.  We therefore expect to see no
> operational issues with this specification.  After we gain more
> operational experience with this specification, it can be re-issued as a
> standards track document, and update [RFC2865].

Thanks for the improved text. I will use it.

>
>   Alan DeKok.