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

Stefan Winter <> Mon, 24 March 2014 14:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 49AEA1A0218 for <>; Mon, 24 Mar 2014 07:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.791
X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5AlL-4ibPjJq for <>; Mon, 24 Mar 2014 07:23:27 -0700 (PDT)
Received: from ( [IPv6:2001:a18:1::62]) by (Postfix) with ESMTP id 5F62B1A01F9 for <>; Mon, 24 Mar 2014 07:23:27 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 8AC7310584 for <>; Mon, 24 Mar 2014 15:23:25 +0100 (CET)
Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by (Postfix) with ESMTPS id 7F0401057E for <>; Mon, 24 Mar 2014 15:23:25 +0100 (CET)
Message-ID: <>
Date: Mon, 24 Mar 2014 15:22:42 +0100
From: Stefan Winter <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
References: <> <035801cf42d2$99464b80$cbd2e280$> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
OpenPGP: id=8A39DC66; url=
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qQR61IUgFTixCbduq0G3aLkUaDVd7v69g"
X-Virus-Scanned: ClamAV
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: Mon, 24 Mar 2014 14:23:30 -0000


with my shiny new chair hat on:

>> 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 hope we're all smart enough to remember that the bit is allocated.
> If we're not... the WG should be shut down.

I believe it's a bad idea to rely on collective memory or a mailing list

So, regardless of what the consensus will be: try an "Updates" or not;
create an IANA registry or not - the fact that a loosely-knit
relationship to RFC6929 exists, and where the pitfalls are, should be
reflected inside the draft itself.

As for where - I think it helps to keep in mind that that there will be
numerous rounds of reviewing going on after the document has cleared WGLC.

In particular, the Operations Area will conduct an ops-dir review as
part of the IETF LC. There are very specific questions in the ops-dir
review template, one of which is:

"Are there any coexistence issues?"

The probability that an ops-dir reviewer will pick up the T-Bit
allocation coexistence issue during his reading are very high
(especially if the proto write-up mentions this as one of the
contentious points :-) ); so if that issue is not explicitly documented,
it will probably surface at that point, and we'll need to deal with it.

We can of course wait for that to happen, but I'd rather preempt such a
useless extra round and fix the issue in the draft right now.

Another question in the ops-dir review is

"Is an operational considerations and/or manageability section part of
the document?"

I believe the best way forward is to add such a section to the draft (it
could be a sub-section of Introduction, or be a section of its own). The
section would document what was argued on the mailing list, where the
pitfalls are, and that an "Updates" would be a reasonable possiblity to
avoid them if allowed by process.

With that text in the document, the WG can then try to use Updates or
not - and the reason for doing so can then be found in the document
itself. If the actual Updates relationship later doesn't fly, the text
highlighting the issue will at least still be in there - and not in
someone's brain or deep down in the ML archives. I realise that the text
then wouldn't necessarily be found by someone implementing a follow-up
spec to RFC6929 due to lack of an Updated-By, but chances are at least
way better.

(And as an individual: if we have an Operations/Manageability section
anyway at that point - wouldn't it be a good idea to move the "formal
violation of RFC2865" into that section as well? )


Stefan Winter

>> I believe that this update relationship needs to be retained.
>   It may be useful, but IETF process may forbid it.
>   Alan DeKok.
> _______________________________________________
> radext mailing list

Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me