headers
Cuellar Jorge | 4 Nov 2002 12:25
Picon

2 revised drafts

Hello,

We have submitted the next revision of the requirements draft
(WG Item) and of the Scenarios draft (Private Submission):

You will also find a copy of the drafts at following URL:

http://www.ersue.de/nsis/draft-ietf-geopriv-reqs-01.txt
http://www.ersue.de/nsis/draft-cuellar-geopriv-scenarios-02.txt

I wanted to ask for feedback and discussion on the referenced I-Ds,
particularly on the first one.  

The second one, the scenarios draft, is very much a work in progress and 
will need more effort.

Any comments and questions would be welcome.

--Jorge

-----Original Message-----
From: Cuellar Jorge 
Sent: Monday, November 04, 2002 10:47 AM
To: 'internet-drafts <at> ietf.org'
Subject: Version -01 of Draft for Geopriv Requirements

Dear editor,

we would like to submit a version -01 Internet Draft related to the work in 
the Geopriv Working Group. This is a new version of
(Continue reading)

Permalink | Reply | 0 comments |
headers
nabbott | 12 Nov 2002 20:06
Favicon

Re: Two companion IDs for consideration


All,
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?
Thanks,
Nadine Abbott
Telcordia Technologies

                                                                                                
                    "James M.                                                                   
                    Polk"                To:     geopriv <at> mail.apps.ietf.org                     
                    <jmpolk <at> cisco        cc:     dhcwg <at> ietf.org, (bcc: Nadine B.                
                    .com>                Abbott/Telcordia)                                      
                                         Subject:     Two companion IDs for consideration       
                    10/30/2002                                                                  
                    03:44 PM                                                                    

All

A few of us have written two companion Drafts for consideration into 2 WGs
(GEOPRIV and DHC).

The first ID (into the DHC WG) is at:
http://www.ietf.org/internet-drafts/draft-polk-dhcp-geo-loc-option-00.txt
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Schnizlein | 12 Nov 2002 20:39
Picon
Favicon

Re: Re: Two companion IDs for consideration

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.

John

At 02:06 PM 11/12/2002, nabbott <at> telcordia.com wrote:

>All,
>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?
>Thanks,
>Nadine Abbott
>Telcordia Technologies
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Allison Mankin | 14 Nov 2002 13:27

IETF 55: Geopriv WG Agenda

Hi, Folks,

We meet on Monday evening in Atlanta.  

There will be no walkthrough of the drafts.  Time allotted is for
discussion of issues, and the speakers will up there with issues only.

It'll be early in IETF week, so we hope for everyone to have the
drafts booted in their brains.  Thanks!

* Agenda bashing

* draft-cuellar-geopriv-scenarios-01.txt
      (Morris or Cuellar) (15 minutes)
      Key questions:  - problems, issues with draft?
                      - other important scenarios needed in the draft?
                      - adopt as WG draft (with edits)?

* draft-ietf-geopriv-reqs-01.txt
      (Cuellar) (30 minutes)
      Key questions:  - open issues that are not *protocol* open issues
                      - any requirements missing from draft?
                      - ready for WGLC?

* draft-morris-geopriv-core-00.txt
      (Morris) (20 minutes)
      Key questions:  - resolution on Location Object carrying with it
                        the basic instruction set on privacy

* draft-danley-geopriv-threat-analysis-00.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ricardo Cuellar | 18 Nov 2002 21:48
Picon

IETF 55: Geopriv Requirements Issues

All,

This is the current list of issues identified in the draft
<draft-ietf-geopriv-reqs-01.txt>.

The goal of this list is to identify the changes required to further
advance this document. Please submit comments to the presented issues,
or send more issues to the mailing list.  Please refer to the text in
the draft that relates to the issue. If possible, supply also the
suggested text that you would like to see.

Regards,

Jorge

################################################

Current Issues:
Nov 18, 2002

Issue 8b: "Accuracy flag": Closed

  It is not useful to provide an accuracy attribute in
  object, i.e., a flag saying "I'm not telling you the whole
  truth."

  But: if the LO is used for requesting a position, an
  accuracy level may be requested.

  This is an open *protocol issue*: outside of the scope of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Barr Hibbs | 26 Nov 2002 07:30

RE: [dhcwg] Two companion IDs for consideration


-----Original Message-----
From: dhcwg-admin <at> ietf.org [mailto:dhcwg-admin <at> ietf.org]On Behalf Of
James M. Polk
Sent: Wednesday, October 30, 2002 15:44

A few of us have written two companion Drafts for consideration into 2
WGs (GEOPRIV and DHC).

The first ID (into the DHC WG) is at:
http://www.ietf.org/internet-drafts/draft-polk-dhcp-geo-loc-option-00.tx
t
and defines a Location Object format...

The second ID (into the GEOPRIV WG) is the semantics ID for the DHC ID.
It's at:
http://www.ietf.org/internet-drafts/draft-polk-geopriv-loc-object-semant
ics-00.txt
and shows why the meaning of "resolution" is better suited to meet the
requirement of granular (im)precision than "accuracy".

...comments about the two drafts follow.

--Barr

draft-polk-dhcp-geo-loc-option-00:

--editorial matters

as you never repeat the acronym "RAIO" in the document, please spell it
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Linsner | 27 Nov 2002 18:30
Picon
Favicon

RE:Two companion IDs for consideration

see in-line

> --content matters
>
> 1.  the first sentence of the first paragraph of section 1.0
> "Introduction" clearly limits the scope of this option to be data
> provided BY the server TO the client.  This seems applicable to both
> wire-connected clients and some wireless clients (a specific access
> point might identify location with sufficient precision), but can you
> imagine a future scenario where a wireless or roaming client supplies
> the location information TO the server?  If so, perhaps this sentence
> needs to be generalized, or a specific exclusion be included that
> prevents client to server notification (I'm not clear on how or why a
> DHCP server might use this information as it seems more
> application-oriented than network-oriented.)

I envision a 'service' that may be the receiver of the location object, but
can't imagine why the DHC server would want it after the client is
initialized.  I don't think we want to change the role of the DHC server.

>
> 2.  section 1.2, "Motivation," provides some of the background for this
> option that I asked about above, but I see the use of the location
> information as application data, not entirely appropriate for DHCP.  If
> I could see a clear motivation for needing location information at this
> point in the initialization process (likely to be before higher-layer
> protocols, such as IP telephony, are loaded and activated) I wouldn't
> question the need.  I can think of other uses for this information
> besides E911 over IPtel (operations, management, and troubleshooting
> come to mind) but all are really applications-layer functions.
(Continue reading)

Permalink | Reply | 3 comments |
headers
James M. Polk | 27 Nov 2002 18:33
Picon
Favicon

RE: [dhcwg] Two companion IDs for consideration

Barr

Interesting comments, I've provided some replies in-line below

At 10:30 PM 11/25/2002 -0800, Barr Hibbs wrote:
>
>-----Original Message-----
>From: dhcwg-admin <at> ietf.org [mailto:dhcwg-admin <at> ietf.org]On Behalf Of
>James M. Polk
>Sent: Wednesday, October 30, 2002 15:44
>
>A few of us have written two companion Drafts for consideration into 2
>WGs (GEOPRIV and DHC).
>
>The first ID (into the DHC WG) is at:
>http://www.ietf.org/internet-drafts/draft-polk-dhcp-geo-loc-option-00.tx
>t
>and defines a Location Object format...
>
>The second ID (into the GEOPRIV WG) is the semantics ID for the DHC ID.
>It's at:
>http://www.ietf.org/internet-drafts/draft-polk-geopriv-loc-object-semant
>ics-00.txt
>and shows why the meaning of "resolution" is better suited to meet the
>requirement of granular (im)precision than "accuracy".
>
>...comments about the two drafts follow.
>
>--Barr
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Barr Hibbs | 27 Nov 2002 20:52

RE: Two companion IDs for consideration


comments in-line

--Barr

-----Original Message-----
From: Marc Linsner [mailto:mlinsner <at> cisco.com]
Sent: Wednesday, November 27, 2002 09:31

> --content matters
>
> ... perhaps this sentence needs to be generalized, or a specific
> exclusion be included that prevents client to server notification
> (I'm not clear on how or why a DHCP server might use this information
> as it seems more application-oriented than network-oriented.)

I envision a 'service' that may be the receiver of the location object,
but can't imagine why the DHC server would want it after the client is
initialized.  I don't think we want to change the role of the DHC
server.

...after reflecting on this for a few days (while fighting off a cold) I
slightly regret the way I phrased that statement:  the physical location
of a network host is a very useful and practical bit of information for
several purposes including operations and management.  For example, an
application service might recognize that communication is lost with the
host, and open a trouble ticket that includes the location of the host
for dispatching a technician.  But, the location really is a piece of
application-layer information.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane