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

Alejandro Perez Mendez <> Tue, 25 March 2014 08:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 562F11A0369 for <>; Tue, 25 Mar 2014 01:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aQ9CFO0-TWUt for <>; Tue, 25 Mar 2014 01:29:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B09681A013B for <>; Tue, 25 Mar 2014 01:29:43 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A52B43FAB6 for <>; Tue, 25 Mar 2014 09:29:41 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id imUGlFjwy8to for <>; Tue, 25 Mar 2014 09:29:41 +0100 (CET)
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by (Postfix) with ESMTPSA id 5FA363F84B for <>; Tue, 25 Mar 2014 09:29:40 +0100 (CET)
Message-ID: <>
Date: Tue, 25 Mar 2014 09:29:39 +0100
From: Alejandro Perez Mendez <>
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
Content-Type: multipart/alternative; boundary="------------040604070403080604030700"
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, 25 Mar 2014 08:29:47 -0000

El 24/03/14 15:22, Stefan Winter escribió:
> Hello,
> 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
> archive.
> 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? )

I think it is a good idea to have such a section, specially is you think
it will be requested by ops-dir reviewers if not present. I would place
it as section 10, right before "Security considerations" section,
instead of in the Introduction section, to avoid basing the explanations
on something that has not been described yet.

I also think that the "formal violation..." discussion should be moved
here. We could also include the "proxying based on User-Name"
restriction too.

> Greetings,
> 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
> _______________________________________________
> radext mailing list