Subject: [Geopriv] draft-winterbottom-geopriv-lis2lis-req-00.txt

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 17 Jun 2007 22:30:12 -0500

Hi All,

At the IETF meeting in Prague a decision was made to remove the LIS to
LIS protocol requirements from the L7 LCP requirements document and put
them in their own separate draft. Steve Norreys and I took the action to
come up with a draft to address these requirements.

http://www.ietf.org/internet-drafts/draft-winterbottom-geopriv-lis2lis-r
eq-00.txt

Comments welcome.

Cheers

James

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 18 Jun 2007 18:59:30 -0700

I was reading req 7

    7: Where location signing is requested by the end-point, this  
request
       MUST be forwarded to regional access LIS using the LIS to LIS
       protocol

Can you fill me (and others) in with a bit background around this one  
- the issues were not obvious to me one way or the other.

Thanks,

Cullen <with my individual hat on>

On Jun 17, 2007, at 8:30 PM, Winterbottom, James wrote:

> Hi All,
>
>
>
> At the IETF meeting in Prague a decision was made to remove the LIS  
> to LIS protocol requirements from the L7 LCP requirements document  
> and put them in their own separate draft. Steve Norreys and I took  
> the action to come up with a draft to address these requirements.
>
>
>
> http://www.ietf.org/internet-drafts/draft-winterbottom-geopriv- 
> lis2lis-req-00.txt
>
>
>
>
>
> Comments welcome.
>
>
>
> Cheers
>
> James
>
>
>
>
>
>

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Tue, 19 Jun 2007 11:45:09 -0600

James -

I do not any comments or issues with the document. 

However, I was wondering: At the Where 2.0 Conference there were several companies present that have as a business focus providing location based on WiFi. One such company is Skyhook. I wanted to make sure that I understand where such an application fits into the scheme as presented in this document. Perhaps this is not germane as Skyhook is not a network provider nor are they dealing with cable based broadband . But they are a provider and link into the broadband network and I would guess that they would be considered a service provider.

Just wondering

Thanks!

Carl

  ----- Original Message ----- 
  From: Winterbottom, James 
  To: GEOPRIV 
  Sent: Sunday, June 17, 2007 9:30 PM
  Subject: [Geopriv] draft-winterbottom-geopriv-lis2lis-req-00.txt

  Hi All,

  At the IETF meeting in Prague a decision was made to remove the LIS to LIS protocol requirements from the L7 LCP requirements document and put them in their own separate draft. Steve Norreys and I took the action to come up with a draft to address these requirements.

  http://www.ietf.org/internet-drafts/draft-winterbottom-geopriv-lis2lis-req-00.txt

  Comments welcome.

  Cheers

  James

------------------------------------------------------------------------------

---

From: "Stuard, Doug" <[email-masked]>
Date: Tue, 19 Jun 2007 14:32:10 -0400

James,

In the referenced document it is stated:
 
    5: The method used by the regional access LIS to determine the
      location of the end-point MUST be provided to the ISP LIS along

      with the determined location. 

I assume this is intended to be similar to the possource parameter in
wireless.  Are there standard codes for the various methods?

Doug 

	----- Original Message ----- 

	From: Winterbottom, James <mailto:[email-masked]>

	To: GEOPRIV <mailto:[email-masked]>  

	Hi All,

	At the IETF meeting in Prague a decision was made to remove the
LIS to LIS protocol requirements from the L7 LCP requirements document
and put them in their own separate draft. Steve Norreys and I took the
action to come up with a draft to address these requirements.

	 

	Comments welcome.

	Cheers

	James

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

________________________________

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 19 Jun 2007 14:23:15 -0500

Hi Doug,

Please take a look at the IANA registry.

http://www.iana.org/assignments/method-tokens

The existence of this repository is indicated in RFC4119.

Cheers

James

From: Stuard, Doug 
Sent: Wednesday, 20 June 2007 4:32 AM
To: Winterbottom, James; GEOPRIV
Subject: RE: [Geopriv] draft-winterbottom-geopriv-lis2lis-req-00.txt

James,

Doug 

	----- Original Message ----- 

	Hi All,

	

	Comments welcome.

	Cheers

	James

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 19 Jun 2007 18:45:55 -0500

Hi Cullen,

Thanks for the query.
The need for MUST versus SHOULD/MAY is not cut and dry. I think that
there is a need for the MUST in that the protocol needs to support it,
how it is configured is a different story.

In the types of network where these requirements are applicable the
access is provided by at least 2 organizations; an ISP providing layer
3, and a Regional Access Network Provider that provides layer 2 and
physical infrastructure. Ultimately, only the latter can provide the
final location. The issue therefore comes down to who, assuming that
location signing moves forward, is able to sign for location. In some
cases it may well be the ISP, in which case this requirement need not be
configured into the deployment, in others though the infrastructure
provider may insist on, or be legislated to performing the signing. In
this latter case the protocol needs to be capable of supporting the use
case.

I hope this clears things up a bit.

Cheers
James

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Tuesday, 19 June 2007 12:00 PM
> To: Winterbottom, James
> Cc: GEOPRIV
> Subject: Re: [Geopriv] draft-winterbottom-geopriv-lis2lis-req-00.txt
> 
> 
> I was reading req 7
> 
----------------------------------------------------------------------
> > --------------------------
----------------------------------------------------------------------
> > --------------------------
> > [mf2]

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 19 Jun 2007 18:52:07 -0500

Hi Carl,

It depends a little on view of the world, but I see Skyhook as a
location determination technology so it doesn't really fit into this
document.

Digressing out of GeoPriv terminology for a minute, I see Skyhook as
providing a location determination function (LDF) to a LIS. Currently
Geopriv specifically excludes location determination from their charter.

If you want to have an offline discussion in this area I would be happy
to do so.

Cheers

James

From: Carl Reed OGC Account [mailto:[email-masked]] 
Sent: Wednesday, 20 June 2007 3:45 AM
To: Winterbottom, James; GEOPRIV
Subject: Re: [Geopriv] draft-winterbottom-geopriv-lis2lis-req-00.txt

James -

However, I was wondering: At the Where 2.0 Conference there were several
companies present that have as a business focus providing location based
on WiFi. One such company is Skyhook. I wanted to make sure that I
understand where such an application fits into the scheme as presented
in this document. Perhaps this is not germane as Skyhook is not a
network provider nor are they dealing with cable based broadband . But
they are a provider and link into the broadband network and I would
guess that they would be considered a service provider.

Just wondering

Thanks!

Carl

	----- Original Message ----- 

	Hi All,

	

	Comments welcome.

	Cheers

	James

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 20 Jun 2007 10:05:09 -0700

That helps a bit - it sort of seem to be assuming a certain solution  
for the signing.  It might be better to try and list the requirements  
more along the lines of your email below where you try and say who  
need to be able to sign what, who needs to be able to check a  
signature, who needs to be able to get someone else to sign something  
on their behalf, and what the signatures attest to when something is  
signed. I imagine that the requirement you have here would fall out  
of those.