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: <geopriv-bounces@ietf.org>
X-Original-To: geopriv-archive@megatron.ietf.org
Delivered-To: ietfarch-geopriv-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA0128C36D; Tue, 6 May 2008 06:49:14 -0700 (PDT)
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA783A6BAE for <geopriv@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 d8guQ3-YVJWn for <geopriv@core3.amsl.com>; Tue, 6 May 2008 06:49:07 -0700 (PDT)
Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 73D643A7045 for <geopriv@ietf.org>; Tue, 6 May 2008 06:48:44 -0700 (PDT)
Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA08.westchester.pa.mail.comcast.net with comcast id NCW71Z0030vyq2s5803k00; Tue, 06 May 2008 13:48:31 +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>
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
Subject: Re: [Geopriv] Last Call: draft-ietf-geopriv-radius-lo(CarryingLocation Objects in RADIUS and Diameter) to Pr
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: geopriv-bounces@ietf.org
Errors-To: geopriv-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.  :-)


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