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
- [radext] Update RFC 6929 in draft-ietf-radext-rad… Benoit Claise
- Re: [radext] Update RFC 6929 in draft-ietf-radext… Alan DeKok
- Re: [radext] Update RFC 6929 in draft-ietf-radext… Benoit Claise
- Re: [radext] Update RFC 6929 in draft-ietf-radext… lionel.morand
- Re: [radext] Update RFC 6929 in draft-ietf-radext… Jim Schaad
- Re: [radext] Update RFC 6929 in draft-ietf-radext… Alan DeKok
- Re: [radext] Update RFC 6929 in draft-ietf-radext… Alejandro Perez Mendez
- Re: [radext] Update RFC 6929 in draft-ietf-radext… Michael Richardson
- Re: [radext] Update RFC 6929 in draft-ietf-radext… Alan DeKok
- Re: [radext] Update RFC 6929 in draft-ietf-radext… Sam Hartman
- Re: [radext] Update RFC 6929 in draft-ietf-radext… Michael Richardson
- Re: [radext] Update RFC 6929 in draft-ietf-radext… Alan DeKok
- Re: [radext] Update RFC 6929 in draft-ietf-radext… Stefan Winter
- Re: [radext] Update RFC 6929 in draft-ietf-radext… Alejandro Perez Mendez
- Re: [radext] Update RFC 6929 in draft-ietf-radext… Stefan Winter
- Re: [radext] Update RFC 6929 in draft-ietf-radext… Alan DeKok
- Re: [radext] Update RFC 6929 in draft-ietf-radext… Jim Schaad