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

"Jim Schaad" <> Tue, 18 March 2014 17:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4DEAC1A073C for <>; Tue, 18 Mar 2014 10:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XrxSOPjHFo9b for <>; Tue, 18 Mar 2014 10:52:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D1EC91A0740 for <>; Tue, 18 Mar 2014 10:52:45 -0700 (PDT)
Received: from Philemon ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 650CC38EEF; Tue, 18 Mar 2014 10:52:37 -0700 (PDT)
From: "Jim Schaad" <>
To: "'Benoit Claise'" <>, <>
References: <>
In-Reply-To: <>
Date: Tue, 18 Mar 2014 10:50:49 -0700
Message-ID: <035801cf42d2$99464b80$cbd2e280$>
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
Subject: Re: [radext] Update RFC 6929 in draft-ietf-radext-radius-fragmentation
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: 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.





From: radext [] On Behalf Of Benoit Claise
Sent: Tuesday, March 18, 2014 7:53 AM
Cc:; <>
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