Subject: [Geopriv] Comments on draft-ietf-geopriv-http-location-delivery-10

From: Cullen Jennings <[email-masked]>
Date: Tue, 4 Nov 2008 15:48:41 -0700

Looks good - few comments ...

Unclear to me if this is just HTTPS or if HTTP is allowed too. Might  
need to update the requirement in section 5.1

Section 6.2 has: "If the LIS believes that the Device is mobile, that  
is, its location may change over relatively short periods of time  
(i.e., several minutes), it SHOULD return a location URI." But to  
implement this, one need to know the information that is in some of  
the lbyr drafts which would make them normative references. I would  
prefer to break this dependency by having this specification not  
require implementation of any of the stuff that is currently in the  
informative references.

Not a problem for this draft but down the road where we are defining  
the details of stuff that goes in locationUriSet and just  
hypothetically suppose held was one of the protocols that could be  
used. If we find a URL in there with  a http scheme, how would we know  
to use held. In the previous version one knew by the scheme to use  
this but now we will need another way. I can imagine many ways to skin  
this cat and don't see it as a big problem to leave the doc like it is  
but wanted to point this out.

Section 6.5.2 where we have a SHOULD linked to "several minutes". Can  
we just put some exact number of minutes. Putting anything else just  
seems like it will lead to interoperability problems.

I am not a fan of two ways to do the same thing. We have the POST  
approach which is well defined, easy and clearly the preferred  
approach. Then we say, and you can also do a broken GET approach. I  
don't see the need for the GET stuff. The correct POST is just as easy  
to implement.

The comment about doing the 3704 stuff make no sense to me at all. See  
previous emails.

At one point in time, the certificate used for the HELD TLS needed to  
match the input domain used in LIS discovery. I'm not sure what the  
consensus was on removing that or not - I'll admit I'm lost but I  
can't figure out what happened reading the list. Do we want this, did  
we need it, was it determined useless. I've just lost track of what is  
needed here.

All of this sent with my individual contributor hat on,
Cullen
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 17 Nov 2008 10:57:43 -0600

Hi Cullen,

Thanks for the feedback - responses are embedded below [MB].  Sorry for
the delay - I had to go dig through previous versions to figure out when
certain things were added to ensure we're not flip/flopping. Also, I do
need WG feedback for some of the comments, as indicated below.

Mary. 

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Tuesday, November 04, 2008 4:49 PM
To: GEOPRIV
Cc: Barnes, Mary (RICH2:AR00)
Subject: Comments on draft-ietf-geopriv-http-location-delivery-10

Unclear to me if this is just HTTPS or if HTTP is allowed too. Might
need to update the requirement in section 5.1
[MB] Would changing the last bullet in section 5.3 from REQUIRES to
RECOMMENDED. More detail on the case where one doesn't use HTTPS are
provided in section 9.2. Do we need more text?  [/MB]

Section 6.2 has: "If the LIS believes that the Device is mobile, that
is, its location may change over relatively short periods of time (i.e.,
several minutes), it SHOULD return a location URI." But to implement
this, one need to know the information that is in some of the lbyr
drafts which would make them normative references. I would prefer to
break this dependency by having this specification not require
implementation of any of the stuff that is currently in the informative
references.

[MB] I do see your point. We do have the necessary scoping/restrictions
for the locationURI described in section 4.3.  Perhaps, we should
re-iterate that in section 6.2 and 6.5.1 really OR just point back to
4.3?  [/MB]

Not a problem for this draft but down the road where we are defining the
details of stuff that goes in locationUriSet and just hypothetically
suppose held was one of the protocols that could be used. If we find a
URL in there with  a http scheme, how would we know to use held. In the
previous version one knew by the scheme to use this but now we will need
another way. I can imagine many ways to skin this cat and don't see it
as a big problem to leave the doc like it is but wanted to point this
out.

Section 6.5.2 where we have a SHOULD linked to "several minutes". Can we
just put some exact number of minutes. Putting anything else just seems
like it will lead to interoperability problems.

[MB] Your suggestion is reasonable - does anyone have a good number?  I
would suggest nothing less than 2 or 3 and nothing more than 10, but
Martin and James W might have more relevant data.  Also, note we have
another instance of "several minutes" in section 6.2
"locationType".[/MB]

I am not a fan of two ways to do the same thing. We have the POST
approach which is well defined, easy and clearly the preferred approach.
Then we say, and you can also do a broken GET approach. I don't see the
need for the GET stuff. The correct POST is just as easy to implement.
[MB] It's not a problem to me to remove the GET -it's been in there from
day 1, so I'm hoping Martin or James W. can highlight why both were
documented - i.e., which have you all used in your prototype? [/MB]

The comment about doing the 3704 stuff make no sense to me at all. See
previous emails.
[MB] RFC 3704 is recommended to protect against IP address spoofing.
This was part of the original security text that Richard provided - it's
not a root LCP PS requirement, so perhaps we can drop. Richard, do you
have some feedback on this one? [/MB]

At one point in time, the certificate used for the HELD TLS needed to
match the input domain used in LIS discovery. I'm not sure what the
consensus was on removing that or not - I'll admit I'm lost but I can't
figure out what happened reading the list. Do we want this, did we need
it, was it determined useless. I've just lost track of what is needed
here. 
[MB] I thought this was adequately addressed in section 9.1 (second
sentence) and section 4 refers to section 9.[/MB]  

All of this sent with my individual contributor hat on, Cullen
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv