Subject: [Geopriv] Q1 about draft-ietf-geopriv-lbyr-requirements-01

From: "James M. Polk" <[email-masked]>
Date: Fri, 15 Feb 2008 18:12:57 -0600

This document states clearly that it only covers LCPs and Dereference 
protocols (which seems to leave out conveyance protocols, BTW).

In that context, I don't understand requirement C7 (in section 5.1), 
since this requirement is clearly discussing a clients ability to 
dereference location, yet it appears in the LCP requirements 
section.  Why is C7 where it is? And why is C7 not in the next 
section (section 5.2) that discusses dereference protocols?

James

_______________________________________________
Geopriv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/geopriv

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 17 Feb 2008 12:45:46 +0100

Hi James, 

These are good questions. 

Here are my thoughts: 
 
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von ext James M. Polk
> Gesendet: Samstag, 16. Februar 2008 02:13
> An: [email-masked]
> Betreff: [Geopriv] Q1 about draft-ietf-geopriv-lbyr-requirements-01
> 

   C7. Location timestamp:  There SHOULD be a way to allow a client to
      determine whether the dereferenced location information refers to
      the location of the Target at the time when the location URI was
      created or when it was dereferenced.

      Motivation: It is important to distinguish between an original and
      an updated location.

I believe that this relates to the LCP since it would be helpful to let the Target know how long the reference is valid and to allow the client to express his/her preference about the lifetime of the reference. 

There is a separate aspect to let the entity performing the derefencing step to know how long the reference is expected to be valid. 

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 17 Feb 2008 19:00:32 -0600

>These are good questions.

comments in-line

>I believe that this relates to the LCP since it 
>would be helpful to let the Target know how long 
>the reference is valid and to allow the client 
>to express his/her preference about the lifetime of the reference.

Are you familiar with RFC 4833 
(ftp://ftp.rfc-editor.org/in-notes/rfc4833.txt) 
which is a DHCP Timestamp, but this Option does 
not give an answer in "time to consider valid 
for", but in an absolute time (i.e., something 
more complex than "1700 GMT, Feb 18, 2008").

The two representations are clearly different, 
yet the definition (and name) of this ID's 
version is conflicting with the usage within RFC 4833.

Now that

         draft-ietf-geopriv-dhcp-lbyr-uri-option-00

will become a WG item today or tomorrow, there 
shouldn't be mixed meanings within implementors 
of DHCP.  First, I suggest this ID's C7 title get 
renamed to "Location Valid-for", to have an answer in seconds (and not a time).

I think the motivation text is there incorrect, 
since the updated location would merely overwrite 
the old location URI (perhaps otherwise still 
valid interval when the original location 
remained good) and reset the valid-for value (in seconds).

>There is a separate aspect to let the entity 
>performing the derefencing step to know how long 
>the reference is expected to be valid.
>
>Ciao
>Hannes
>
> >
> > James
> >

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Feb 2008 10:59:38 +0200

Hi James,

> renamed to "Location Valid-for", to have an answer in seconds (and not a time).
I now understand your issue. It sounds good to me to rename the 
corresponding section in draft-ietf-geopriv-lbyr-requirements-01.
Sounds good to me.

> remained good) and reset the valid-for value (in seconds).

I agree.

Ciao
Hannes

---

From: "Roger Marshall" <[email-masked]>
Date: Sun, 24 Feb 2008 22:30:24 -0800

James:
See my couple of comments in-line.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James M. Polk
> Sent: Sunday, February 17, 2008 5:01 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
> Subject: Re: [Geopriv] Q1 about 
> draft-ietf-geopriv-lbyr-requirements-01
> 
> > > This document states clearly that it only covers LCPs and 
> > > Dereference protocols (which seems to leave out 
> conveyance protocols, BTW).

James - (reaching back) it sounds like you are in favor of including conveyance also within the scope of this doc.  Is that true?

> >I believe that this relates to the LCP since it would be 
> helpful to let 
> >the Target know how long the reference is valid and to allow 
> the client 
> which is a DHCP Timestamp, but this Option does not give an 
> answer in "time to consider valid for", but in an absolute 
> time (i.e., something more complex than "1700 GMT, Feb 18, 2008").
> 
> The two representations are clearly different, yet the 
> definition (and name) of this ID's version is conflicting 
> with the usage within RFC 4833.
> 
> Now that
> 
> will become a WG item today or tomorrow, there shouldn't be 
> mixed meanings within implementors of DHCP.  First, I suggest 
> this ID's C7 title get renamed to "Location Valid-for", to 
> have an answer in seconds (and not a time).
> 
> I think the motivation text is there incorrect, since the 
> updated location would merely overwrite the old location URI 
> (perhaps otherwise still valid interval when the original 
> location remained good) and reset the valid-for value (in seconds).

RSM - I've changed the title and requirement's text relating to C7 in the next iteration of the requirements doc (-02), something that also assumes an implied start time (e.g., epoch), no?

...also, I've included this same new defn into the deref req's section.

thanks,

-roger marshall.

> 
> 
> >There is a separate aspect to let the entity performing the 
> derefencing 
> >step to know how long the reference is expected to be valid.
> >
> >Ciao
> >Hannes
> >
> > >
> > > James
> > >

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 25 Feb 2008 17:09:33 -0600

Roger

comments in-line

At 12:30 AM 2/25/2008, Roger Marshall wrote:
>James - (reaching back) it sounds like you are 
>in favor of including conveyance also within the 
>scope of this doc.  Is that true?

I don't believe this at all, since the conveyance 
protocol(s) will only do with what they 
have...  I just wanted to make it clear this ID 
really wasn't targeting SIP Location Conveyance - 
which isn't clear based on a few comments on the list.

>RSM - I've changed the title and requirement's 
>text relating to C7 in the next iteration of the 
>requirements doc (-02), something that also 
>assumes an implied start time (e.g., epoch), no?

we need to come to an agreement on what any 
"valid-for" (in seconds) parameter means, or when 
it's considered to have started its timer.

I believe this is from the moment, for example with

of the LIS reply (via the DHCP server).  In other 
words, it's the time remaining before this LbyR 
needs to be refreshed by the endpoint/client.

>CONFIDENTIALITY NOTICE: The information 
>contained in this message may be privileged 
>and/or confidential. If you are not the intended 
>recipient, or responsible for delivering this 
>message to the intended recipient, any review, 
>forwarding, dissemination, distribution or 
>copying of this communication or any 
>attachment(s) is strictly prohibited. If you 
>have received this message in error, please 
>notify the sender immediately, and delete it and 
>all attachments from your computer and network.

---

From: "Roger Marshall" <[email-masked]>
Date: Mon, 25 Feb 2008 15:35:57 -0800

Hey there James.  Please see my responses in-line. 

> From: James M. Polk [mailto:[email-masked]] 
> Sent: Monday, February 25, 2008 3:10 PM
> To: Roger Marshall; Tschofenig, Hannes (NSN - FI/Espoo); 
> [email-masked]
> Subject: RE: [Geopriv] Q1 about 
> >James - (reaching back) it sounds like you are in favor of including 
> >conveyance also within the scope of this doc.  Is that true?
> 
> protocol(s) will only do with what they have...  I just 
> wanted to make it clear this ID really wasn't targeting SIP 
> Location Conveyance - which isn't clear based on a few 
> comments on the list.

-rsm, ok - makes sense, (you had me go'in there for a second).  The draft does explicitly make the statement of conveyance being out of scope below figure 1., in step (2).

> > > > > since this requirement is clearly discussing a 
> clients ability 
> > > > > to dereference location, yet it appears in the LCP 
> requirements 
> > > which is a DHCP Timestamp, but this Option does not give 
> an answer 
> > > in "time to consider valid for", but in an absolute time (i.e., 
> > > something more complex than "1700 GMT, Feb 18, 2008").
> > >
> > > The two representations are clearly different, yet the definition 
> > > (and name) of this ID's version is conflicting with the 
> usage within 
> > > RFC 4833.
> > >
> > > Now that
> > >
> > > will become a WG item today or tomorrow, there shouldn't be mixed 
> > > meanings within implementors of DHCP.  First, I suggest 
> this ID's C7 
> > > title get renamed to "Location Valid-for", to have an answer in 
> > > seconds (and not a time).
> > >
> > > I think the motivation text is there incorrect, since the updated 
> > > location would merely overwrite the old location URI (perhaps 
> > > otherwise still valid interval when the original location 
> remained 
> > > good) and reset the valid-for value (in seconds).
> >
> >RSM - I've changed the title and requirement's text relating 
> to C7 in 
> >the next iteration of the requirements doc (-02), something 
> that also 
> we need to come to an agreement on what any "valid-for" (in 
> seconds) parameter means, or when it's considered to have 
> started its timer.
> 
> of the LIS reply (via the DHCP server).  In other words, it's 
> the time remaining before this LbyR needs to be refreshed by 
> the endpoint/client.

-rsm, true, we need to agree on something.  A couple of proposals:
a. valid until some time t, in seconds, measured from a baseline time t0, (e.g., UTC), or
b. valid until some time t, in seconds, measured from "now", which would be a relative UTC timestamp - now must be included as a new baseline reference.

> >CONFIDENTIALITY NOTICE: The information contained in this 
> message may 
> >be privileged and/or confidential. If you are not the intended 
> >recipient, or responsible for delivering this message to the 
> intended 
> >recipient, any review, forwarding, dissemination, distribution or 
> >attachment(s) is strictly prohibited. If you have received 
> this message 
> >in error, please notify the sender immediately, and delete 
> it and all 
> >attachments from your computer and network.
> 
>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 Feb 2008 14:09:23 -0600

Roger

see in-line

At 05:35 PM 2/25/2008, Roger Marshall wrote:
>-rsm, ok - makes sense, (you had me go'in there 
>for a second).  The draft does explicitly make 
>the statement of conveyance being out of scope below figure 1., in step (2).

in all the fun (of the reqs), I missed that line. sorry

>b. valid until some time t, in seconds, measured 
>from "now", which would be a relative

I strongly prefer option 'b' here

>  UTC timestamp - now must be included as a new baseline reference.

this necessitates a format change in at least

which actually came from James W., so I suspect 
this format change is true for HELD as well (without looking this up)