Re: [dhcwg] Re: Two companion IDs for consideration

John Schnizlein <> Tue, 12 November 2002 19:40 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id OAA11597 for <>; Tue, 12 Nov 2002 14:40:22 -0500 (EST)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id gACJgTF24627 for; Tue, 12 Nov 2002 14:42:29 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id gACJgTv24624 for <>; Tue, 12 Nov 2002 14:42:29 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA11591 for <>; Tue, 12 Nov 2002 14:39:51 -0500 (EST)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id gACJe7v24564; Tue, 12 Nov 2002 14:40:07 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id gACJdev24511 for <>; Tue, 12 Nov 2002 14:39:40 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA11517 for <>; Tue, 12 Nov 2002 14:37:01 -0500 (EST)
Received: from ( []) by (8.12.2/8.12.2) with ESMTP id gACJdYIX026374; Tue, 12 Nov 2002 11:39:34 -0800 (PST)
Received: from (localhost []) by (8.12.2/8.12.2) with ESMTP id gACJdWHe016120; Tue, 12 Nov 2002 11:39:33 -0800 (PST)
Received: from ( []) by (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA10217; Tue, 12 Nov 2002 11:39:31 -0800 (PST)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 12 Nov 2002 14:39:29 -0500
From: John Schnizlein <>
Subject: Re: [dhcwg] Re: Two companion IDs for consideration
Cc:,, "James M. Polk" <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

I agree that this mechanism depends on a RAIO like Circuit-ID.
We may have a chicken-or-egg situation with widespread support for
this sub-option depending on useful features that get built depending
on it. It is part of the process of building components of mechanism
that their value is not realized until a useful combination of them
delivers what people want. 

The approach here is to enable the phone end-point, or any host, to
learn its geographic location from the network. Then it is up to some
other application to use this information in a way that its user values.
In that sense, the value of the mechanism also depends on the applications.

Building valuable features out of standard components is the best way
to encourage the implementation of standard components. The specification
of the standard components is just a germ for the potential tree.


At 02:06 PM 11/12/2002, wrote:

>I believe the approach described in the afore-mentioned Internet Drafts is
>dependent upon both LAN switch and DHCP server support of Circuit-ID RAIO
>defined (as SubOpt 1) in RFC 3046, Patrick M., "DHCP Relay Agent
>Information Option",  January2001.  Does anyone have any idea how widely
>supported these functions are by LAN switches and by DHCP servers?
>Nadine Abbott
>Telcordia Technologies
>A few of us have written two companion Drafts for consideration into 2 WGs
>The first ID (into the DHC WG) is at:
>and defines a Location Object format that satisfies (we hope) the basic
>required elements to represent  a Target as well as the requirement for
>granular resolution. This ID in no way affects the GEOPRIV Protocol and
>it's goal for security or user control (ie rules for actively responding to
>a Location request). It provides a mechanism for getting the location
>information to an (wired) IP device which can then use the eventual GEOPRIV
>Protocol as that WG specifies. There are no semantics written into the DHC
>ID, and leaves some questions as to why the authors made certain choices.
>Hence the reason for the second ID.
>The second ID (into the GEOPRIV WG) is the semantics ID for the DHC ID.
>It's at:
>and shows (with many examples) why the meaning of "resolution" is better
>suited to meet the requirement of granular (im)precision than "accuracy".
>The examples of how the location Target device can simply alter the
>resolution presented to a location request from within 3.11mm x 2.62mm to
>as much as 1/6th that of the earth. Neither ID talks about the
>circumstances of these choices - the authors believe this normative text
>should reside elsewhere in GEOPRIV efforts with whatever rules that WG
>places on its Protocol efforts and output.
>Questions and comments have already been raised on the IEPREP WG list in
>the Transport Area, so this combined effort looks like it will have
>multiple lists with comments on them regarding these two IDs.
>Comments are encouraged

dhcwg mailing list