Re: [radext] AD review: draft-ietf-radext-radius-fragmentation
Alejandro Perez Mendez <alex@um.es> Tue, 02 December 2014 07:39 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 E7ECB1A0154 for <radext@ietfa.amsl.com>; Mon, 1 Dec 2014 23:39:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 CVeEp_dd77Zm for <radext@ietfa.amsl.com>; Mon, 1 Dec 2014 23:39:44 -0800 (PST)
Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id CF1C51A0151 for <radext@ietf.org>; Mon, 1 Dec 2014 23:39:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id B907BADF for <radext@ietf.org>; Tue, 2 Dec 2014 08:39:40 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon24.um.es
Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5-wcHwpUM+e1 for <radext@ietf.org>; Tue, 2 Dec 2014 08:39:40 +0100 (CET)
Received: from [10.42.0.18] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon24.um.es (Postfix) with ESMTPSA id 81BA94CB for <radext@ietf.org>; Tue, 2 Dec 2014 08:39:39 +0100 (CET)
Message-ID: <547D6CBB.40908@um.es>
Date: Tue, 02 Dec 2014 08:39:39 +0100
From: Alejandro Perez Mendez <alex@um.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: radext@ietf.org
References: <54779834.9030205@cisco.com>
In-Reply-To: <54779834.9030205@cisco.com>
Content-Type: multipart/alternative; boundary="------------010503060806080203090809"
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/CZjV28SA3MXeaO1CVNhdFXig6ZY
Subject: Re: [radext] AD review: draft-ietf-radext-radius-fragmentation
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: Tue, 02 Dec 2014 07:39:48 -0000
Dear Benoit, thanks for the review. We will prepare a new revision considering your comments. Best regards, Alejandro El 27/11/14 a las 22:31, Benoit Claise escribió: > Dear all, > > Here is the AD review. > Note that I initiated a discussion with the IESG on the topic of an > experimental doc updating a Standard Track doc. More on this pretty > soon (hopefully). > > 1. > Since this is an experimental future RFC, the experiment should be > better explained. And if/when the experiment is successful, what's the > next step. > As an example, > http://tools.ietf.org/html/draft-ietf-radext-dtls-13#section-1.3 was > appreciated by the IESG. > Coming back to this draft, if the experiment is success, the Standard > Track version will update RFC 2865? > > 2. > Open question: Does this draft update RFC 6158? > The Length field in the RADIUS packet header is defined in[RFC2865] > Section 3 <http://tools.ietf.org/html/rfc2865#section-3>. It is noted there that the maximum length of a RADIUS > packet is 4096 octets. As a result, attribute designers SHOULD NOT > assume that a RADIUS implementation can successfully process RADIUS > packets larger than 4096 octets. > Or maybe this is taken care of by: > No such > exchange is possible for accounting or authorization data.[RFC6158] > Section 3.1 <http://tools.ietf.org/html/rfc6158#section-3.1> suggests that exchanging large amounts authorization data > is unnecessary in RADIUS. > > Or, maybe, if this experiment is successful, then the Standard Track > version will update RFC 6158? > > > _Editorial:_ > - > Your first sentence in the introduction speaks about "Authentication > Server (AS)", but some other parts of the document speak about "server" > Example: > In some cases, however, the > authorization data sent by the server is large and highly dynamic. > In other cases, the NAS needs to send large amounts of authorization > data to the server. > Btw, RFC 6158 speaks of RADIUS Server, which I believe is the right term. > Please be consistent regarding terminology: server, AS, RADIUS server > Same remark for client, RADIUS client. > > - > OLD > [RFC6158] recommends three approaches for the transmission of large > amount of data within RADIUS. However, they are not applicable to > the problem statement of this document for the following reasons: > > NEW: > [RFC6158] section 3.1 recommends three approaches for the transmission of large > amount of data within RADIUS. However, they are not applicable to > the problem statement of this document for the following reasons: > > - > OLD > o The first approach does not talk about large ... > > o The second approach is not usable either, ... > > o PMTU discovery does not solve the problem, as it does not allow to > send data larger than the minimum of (PMTU or 4096) octets. > > NEW: > o The first approach (Utilization of a sequence of packets) does not talk about large ... > > o The second approach (Utilization of names rather than values) is not usable either, ... > > o PMTU discovery does not solve the problem, as it does not allow to > send data larger than the minimum of (PMTU or 4096) octets. > > - > Similarly, there is no need to fragment CoA packets. > > A reference, or at least expanding the acronym would help > > - > This limit is the minimum of 4096 octets, and the current PMTU. > I guess you want to say > This limit is the minimum of 4096 octets and the current PMTU. > > - > It is strongly RECOMMENDED that servers include a State attribute > > So strongly RECOMMENDED is between RECOMMENDED and MUST? :-) > Let's not invent new RFC 2119 semantics. > NEW: It is RECOMMENDED that servers include a State attribute > > - Section 4.2 > OLD: Compliant clients receiving this packet will see the Frag-Status > attribute, wand suspend all authorization and authentication handling > until all of the chunks have been received. > > NEW: Compliant clients receiving this packet will see the Frag-Status > attribute,_and_suspend all authorization and authentication handling > until all of the chunks have been received. > > Regarding this sentence, we are in the "post-authorization section". > So shouldn't be: > > NEW: Compliant clients receiving this packet will see the Frag-Status > attribute,_and_suspend all authorization handling > until all of the chunks have been received. > > - Section 11.2 > > The authors acknowledge that this specification violates the "MUST" > requirement of[RFC2865] Section 4.1 <http://tools.ietf.org/html/rfc2865#section-4.1>. > > Be specific on which MUST requirements in [RFC2865] Section 4.1 > <http://tools.ietf.org/html/rfc2865#section-4.1>. you refer to > > While you revise the document, you might want to take care of > http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-radext-radius-fragmentation-08.txt > > Regards, Benoit > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext
- [radext] AD review: draft-ietf-radext-radius-frag… Benoit Claise
- Re: [radext] AD review: draft-ietf-radext-radius-… Alejandro Perez Mendez