Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 ???

["James M. Polk" <[e-mail]>]

Roger

thanks for doing this

At 01:24 PM 4/1/2008, Roger Marshall wrote:
>The following summarizes the first of the three original subj:
>questions, Q1,Q2,Q3:
>
>Q1:
>
>...about draft-ietf-geopriv-lbyr-requirements-01, Fr: James M. Polk
>Sent: Friday, February 15, 2008 4:13 PM
> >
> > 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?
>
>... Some List discussion...
>
>My response to the list on 2/25/08...
>
>[
>-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.
>/]
>
>PROPOSAL:
>I now think that neither of the above suggestions would work well.
>Rather, the best way is a  third option, c., which reuses the 'expires'
>attribute approach from LoST, containing values
>'dateTime','NO-EXPIRATION', and 'NO-CACHE'.  This makes timing explicit,
>and avoids subjectiveness due to potential transport delay, and avoids
>unnecessary recalculations.

Since DHCP should incorporate what is in this doc as best as it can, 
and is a BINARY protocol, the above would not work easily since it is 
written for text based protocols (i.e., with variable length fields the norm).

I'm not exactly suggesting we reverse engineer this into
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-00.txt
to make it work, but I also don't yet see how this requirement can be 
met in the URI Option ID.  the 'dateTime' indication needs a format 
if conveyed in binary *AND* we need to agree what the value 
indicates. I assume you suggest this dateTime value in the URI Option 
ID means when the URI is no longer considered for use, but want to 
get this clearly agreed upon.

If the 'dateTime','NO-EXPIRATION', and 'NO-CACHE' choices are a new 
DHCP field, how long is the field? 1 byte?

This will necessitate a matrix be built for each of the 3 indicates, 
is there a value in the old "valid-for" field that likely becomes an 
"expiry-Time" field. AS an example, if there is a 'NO-EXPIRATION' 
indication, yet there is a value in the "expiry-Time" field, what 
happens (i.e., what does this mean)? Does a 'NO-EXPIRATION' 
indication mean there cannot be a value in the "expiry-Time" field, 
or does it mean the "expiry-Time" field is ignored?

Regardless, this makes the URI Option ID a little more complicated.


>CHANGE FROM:
>Current C7 requirement (-02) reads:
>C7. Location URI Valid-for:  A location URI validity interval, if
>used, MUST include the validity time, in seconds, as an indication
>of how long the client can consider a location URI to be valid.
>
>CHANGE TO:
>Proposed C7 requirement would read:
>C7*. Location URI expiration:  An expiration indicator MUST be included
>with
>the location URI to indicate the URI validity interval.  This indicator
>utilizes
>any of the following parameter values, 'dateTime','NO-EXPIRATION', and
>'NO-CACHE',
>where dateTime is a timezoned XML type dateTime, in canonical
>representation,
>NO-EXPIRATION is indicator that the location URI never expires, and
>NO-CACHE
>means that it is valid now, but should not be reused, and if needed
>again, it MUST
>be requeried for.

How exactly can a binary protocol satisfy the above requirement as written?
or
Do binary LCPs merely ignore this requirement?

You have a MUST above, but this is clearly tailored for text based 
protocols, at the expense of binary protocols.  This isn't fair, and 
I therefore don't support this as written.


>Questions Q2 & Q3 will be sent as separate threads.
>
>-roger marshall.
>
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of James M. Polk
> > Sent: Monday, March 31, 2008 1:19 PM
> > To: Hannes Tschofenig
> > Cc: GEOPRIV
> > Subject: Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 ???
> >
> > At 07:53 AM 3/30/2008, Hannes Tschofenig wrote:
> > >It seems that you are saying that Roger has to keep things going.
> >
> > All I'm saying is that there was never a post articulating
> > what the consensus reached answers were to each of the 3
> > questions I asked on the list.  I don't believe that is
> > asking a lot. Do you think this is asking too much?
> >
> > Each of the 3 questions had ~ 5 to 75 responses, so there
> > were a lot of folks interested in the questions, and
> > obviously the first response didn't answer any of the 3 Qs right away.
> >
> >
> > >Roger, could you post a description of the outstanding issues with a
> > >suggestions on how to address them?
> > >
> > >Ciao
> > >Hannes
> > >
> > >James M. Polk wrote:
> > > > At 12:40 PM 3/29/2008, Hannes Tschofenig wrote:
> > > >> Given the status of HELD this document should have been
> > finished a
> > > >> while ago.
> > > >> I am not even sure whether I have seen a WGLC for it.
> > > >>
> > > >> What are the next steps for it?
> > > >> Why isn't it done already?
> > > >
> > > > weeeeelllll....
> > > >
> > > > There were 3 fairly substantiative questions posted
> > against -01 of
> > > > the ID just before the -0X deadline, and there needs to
> > be time for
> > > > proper review of -02 to see if this version answers at
> > least these 3 questions.
> > > >
> > > > I think 1 has been answered
> > > >
> > > > I think another has not reached consensus
> > > >
> > > > and the last wasn't answered at all
> > > >
> > > > but this is memory (which may or may not be reliable)
> > > >
> > > >
> > > >> _______________________________________________
> > > >> Geopriv mailing list
> > > >> [e-mail]
> > > >> https://www.ietf.org/mailman/listinfo/geopriv
> > >
> > >_______________________________________________
> > >Geopriv mailing list
> > >[e-mail]
> > >https://www.ietf.org/mailman/listinfo/geopriv
> >
> > _______________________________________________
> > Geopriv mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/geopriv
> >
>
>
>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.

_______________________________________________
Geopriv mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv