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

<> Tue, 18 March 2014 15:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8EA281A0404 for <>; Tue, 18 Mar 2014 08:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v5NwecO4Dpae for <>; Tue, 18 Mar 2014 08:27:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9EB541A0147 for <>; Tue, 18 Mar 2014 08:27:27 -0700 (PDT)
Received: from (unknown [xx.xx.xx.200]) by (ESMTP service) with ESMTP id BE39C1B81BD; Tue, 18 Mar 2014 16:27:18 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 98684158084; Tue, 18 Mar 2014 16:27:18 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 18 Mar 2014 16:27:18 +0100
From: <>
To: Alan DeKok <>, Benoit Claise <>
Thread-Topic: [radext] Update RFC 6929 in draft-ietf-radext-radius-fragmentation
Thread-Index: AQHPQrnP4HnMZIGi4keQHwd+/AH7M5rm3mAAgAADA4CAABZBag==
Date: Tue, 18 Mar 2014 15:27:17 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2014.3.18.134216
Cc: "" <>, "" <>
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 15:27:29 -0000

On the same line, it should be highlighted for information that the field assigned for "T" in this document was available at the time of publication but it could conflict in the future with a normative document that would reuse the same field with another meaning.



Envoyé depuis mon Sony Xperia SP d'Orange

Benoit Claise <> a écrit :

> Benoit Claise wrote:
>> The question is: does it even make sense for an experimental RFC to
>> update another RFC?
>    Only if the other one is also experimental.
Good point.
I checked the last 100 published experimental RFCs, and when an "Update"
was used, it was always updating an experimental RFC.

Regards, Benoit
>> 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.
>    That sounds good to me.
>    Alan DeKok.
> .


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.