Re: [radext] Update RFC 6929 in draft-ietf-radext-radius-fragmentation

"Jim Schaad" <ietf@augustcellars.com> Tue, 18 March 2014 17:52 UTC

Return-Path: <ietf@augustcellars.com>
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 4DEAC1A073C for <radext@ietfa.amsl.com>; Tue, 18 Mar 2014 10:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 XrxSOPjHFo9b for <radext@ietfa.amsl.com>; Tue, 18 Mar 2014 10:52:45 -0700 (PDT)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id D1EC91A0740 for <radext@ietf.org>; Tue, 18 Mar 2014 10:52:45 -0700 (PDT)
Received: from Philemon (68-116-62-210.static.mdfd.or.charter.com [68.116.62.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 650CC38EEF; Tue, 18 Mar 2014 10:52:37 -0700 (PDT)
From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Benoit Claise'" <bclaise@cisco.com>, <draft-ietf-radext-radius-fragmentation@tools.ietf.org>
References: <53285DE2.9040802@cisco.com>
In-Reply-To: <53285DE2.9040802@cisco.com>
Date: Tue, 18 Mar 2014 10:50:49 -0700
Message-ID: <035801cf42d2$99464b80$cbd2e280$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0359_01CF4297.ECE8FA20"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHG4DswLDcHlHX0C+rPNIfO2Yg3wJr35FDw
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/3tweX935KaqFFhD492OC8hJouXo
Cc: radext@ietf.org, lionel.morand@orange.com
Subject: Re: [radext] Update RFC 6929 in 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, 18 Mar 2014 17:52:49 -0000

While it is true that an implementer of 6929 does not need to see this
document, it is also true that this document is effectively allocating a bit
from a structure that is in that document.  If this document does not update
6929, then it is possible that the next document to update that structure
will fail to notice this and allocate the same bit for a different purpose.

 

I believe that this update relationship needs to be retained.

 

Jim

 

 

From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Tuesday, March 18, 2014 7:53 AM
To: draft-ietf-radext-radius-fragmentation@tools.ietf.org
Cc: radext@ietf.org; <lionel.morand@orange.com>
Subject: [radext] Update RFC 6929 in draft-ietf-radext-radius-fragmentation

 

Dear all,

Following Lionel's question during the RADEXT meeting regarding the "update
RFC 6929" in draft-ietf-radext-radius-fragmentation-04, I was asked to look
into this question. 

RFC 3967 and RFC 4897 are about the reverse, i.e. normative downref, so no
problem here. 
The question is: does it even make sense for an experimental RFC to update
another RFC? 

Checking with one fellow IESG member, we don't think this the draft Updates
6929. Nobody implementing 6929 has to look at this document. And we think an
Experimental document updating a standards track document is bad form, even
if not specifically forbidden. There's a normative reference to 6929;
Updates is not needed.

Regards, Benoit