RE: [Geopriv] Last Call: draft-ietf-geopriv-radius-lo(CarryingLocation Objects in RADIUS and Diameter) to Pr

"David B. Nelson" <d.b.nelson@comcast.net> Tue, 06 May 2008 13:49 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A40728C21D; Tue, 6 May 2008 06:49:13 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC1A828C21D for <ietf@core3.amsl.com>; Tue, 6 May 2008 06:49:08 -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=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6DvfAzIUEb9 for <ietf@core3.amsl.com>; Tue, 6 May 2008 06:49:07 -0700 (PDT)
Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id BB2A43A7046 for <ietf@ietf.org>; Tue, 6 May 2008 06:48:44 -0700 (PDT)
Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA01.westchester.pa.mail.comcast.net with comcast id NAfj1Z0010vyq2s5109W00; Tue, 06 May 2008 13:48:42 +0000
Received: from NEWTON603 ([24.61.11.96]) by OMTA05.westchester.pa.mail.comcast.net with comcast id NDoh1Z00D24Kx1C3R00000; Tue, 06 May 2008 13:48:42 +0000
X-Authority-Analysis: v=1.0 c=1 a=yOcCyQUPuZIA:10 a=0DA5qP-qZL4A:10 a=s8t9BGMcWLXV7Pgi-7UA:9 a=mT4aKCBzsZpOh7qPEvbZMS3EEfgA:4 a=tqucuuI3bnEA:10
From: "David B. Nelson" <d.b.nelson@comcast.net>
To: 'Glen Zorn' <gzorn@arubanetworks.com>
References: <A3DA4C2546E1614D8ACC896746CDCF2901249CAC@aruba-mx1.arubanetworks.com><BLU137-W504C7EE5B7CD7AE55E1B1093DE0@phx.gbl><002401c8aa14$79b3e640$3d01f00a@arubanetworks.com><01dc01c8aa20$cbdc31a0$5d1216ac@xpsuperdvd2> <A3DA4C2546E1614D8ACC896746CDCF29012D9259@aruba-mx1.arubanetworks.com>
Subject: RE: [Geopriv] Last Call: draft-ietf-geopriv-radius-lo(CarryingLocation Objects in RADIUS and Diameter) to Pr
Date: Tue, 06 May 2008 09:48:46 -0400
Message-ID: <003301c8af7f$e82b7a50$6401a8c0@NEWTON603>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
In-reply-to: <A3DA4C2546E1614D8ACC896746CDCF29012D9259@aruba-mx1.arubanetworks.com>
Thread-Index: AcipUnEZvxg2xJNKQf6kQqsb361hXgAfn0JQABKeVeABMyDScAAlhLGg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Cc: geopriv@ietf.org, ietf@ietf.org, radiusext@ops.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Glen Zorn writes...

> There's just one big difference: EAP is, in fact, a separate protocol,
> distinct from RADIUS.

We're talking about EAP messages tunneled in RADIUS Attributes.  That's what
qualifies for the "opaque blob" exception.

> We're talking about RADIUS attributes here, and the document states that
> the RADIUS server bases a decision upon these attributes.

Yes, I tend to agree with you.  The consensus position, as I understand it,
is that these are "semi-opaque blobs" because the contents are derived from
a separate protocol (a DHCP option, I think, but I may be mistaken).

> There isn't anything I can find in the draft that even suggests the
> existence of some "plug-in".

Nor would I expect you to.  That would be one of those infamous
"implementation specific details".

> Very little about the operation of a RADIUS server has to do with the
> on-the-wire protocol.

Eh?

> This "all a matter of implementation" stuff is just a cop-out: this
> document needs to clearly specify all the entities involved, however
> skeletal that specification may be: if the RADIUS server gets the
> location information from another server which subsequently validates
> the response, that's fine.  If the RADIUS server does it, that's fine; I
> don't really care but 'fuzziness' has no place in standards, IMHO.

The "fuzziness" I was talking about was the applicability of the "opaque
blob" exception in the RADIUS Attribute Design Guidelines. It is claimed to
apply in this case, and I, like you, don't quite buy it.  However, the
consensus position of the GEOPRIV and RADEXT WGs (from WGLC) is that it does
apply.

> So are you saying that good design practices aren't good design
> practices until they have an RFC number?

No.  I'm simply saying that two dissenting opinions do not a rough consensus
break.  :-)


_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf