Subject: RE: Q&C regarding geopriv-reqs-02

From: Cuellar Jorge <[email-masked]>
Date: Thu, 20 Feb 2003 18:54:21 +0100

Hi James,

We are making progress here, thanks!

Cheers,

Jorge

----------

> > > > > 1. Jorge will add some text

> Couldn't this be accomplished with a NOTIFY message
> pertaining to the Target Identifier, and not an LO. I
> guess I'm just not understanding the multi-use of an
> LO. If an LO is the combination of LI, PI and SI elements,
> how are any of these used by that AP in France to inform
> the LS in your example above?

I guess you mean SI for security information and PI for
privacy information (= policy rules).

The LO contains more than LI, PI, SI, it contains
identifiers for the target and recipient, credentials,
etc. (See Req. 2). 

!We should make this clear in the text earlier than in 
Req 2.

You can easily build up a message with those fields intended
to mean "recipient x has obtained LI for target y in such
accuracy".  That is basically what you need to construct a
notify message.

> > > > > 2. + 3. fixed

> > > > > 4.  Jorge will provide some text

> > > > > This doesn't account for the possibility of
> > > > > any domain based policies (and mechanisms) that
> > > > > might override a user's policies.

> > > I can see a clear case where an enterprise/government
> > > provider does NOT want devices providing too precise a
> > > location, and having a set policy to configure all
> > > Target and Location Servers to this mandatory maximum
> > > precision.

> > I do not really understand the case. Is this "set policy
> > to configure all Target and Location Servers to this
> > mandatory maximum precision" a user policy? And an
> > enterprise, where this user happens to be, does not want
> > the user to send the information that he is there? Or is
> > the device a fixed device, and the enterprise does not
> > want to disclose its exact position?  But how does the
> > user have the rights to write the privacy polices in
> > that case?

> This is a case where the user has certain right to set the
> policy of the target, as does the domain the device is
> in. For example, there are certain countries in the world
> that don't want GPS location information derived to within
> a certain precision. If that maximum precision is 1000 ft
> x 1000 ft square, this might violate the 100 ft x 100 ft
> square precision the user sets for their device. Who wins
> here? Likely the jurisdictional authority by the threat of
> jail time for the owner of the location device.

> As such, Geopriv could become a quite accurate mapping
> mechanism for other people's or corporations or
> organization's property lines (and structures with those
> property lines. If the corporation or organization is the
> Access provider as well, they should be able to set
> artificial limits on the precision measurable (thus
> conveyable by Geopriv Targets). This would be part of the
> contract the user has with the service or access provider.

> Just like laws in most countries, if you're on someone
> else's land, they have certain rights that you have to
> obey.

Agree! I will add some text and you check it!

> > > > > 5. Do you suggest adding some text here?

> > > > > 6. fixed (?)

> > > Privacy yes, but the amount of privacy could change
> > > (be more or less) based on the amount of LI
> > > given. This is the foundation for the Resolution
> > > Fields; in other words, if device X gives location
> > > precision that is down to the millimeter, that Geopriv
> > > message should be considered for higher privacy
> > > controls than if device X merely gave the location
> > > precision of 1/6th that of the Earth (for where it
> > > is). Then there might not be very much (or no) privacy
> > > controls.

> > In both cases there is privacy control.  And it is
> > exactly the same privacy control check, base on exactly
> > the same policy rule. In one case the privacy compliance
> > check may say ok in the other it may say not ok.

> Oh... so this is a binary choice and not multi-leveled? I
> thought we would have a situation where there was
> something like a template for users to generally adhere to
> (by their choice), of basic categories of how to fashion a
> response to a Location Request. Something like:

> 1. fail the request
> 2. pass the request, give which hemisphere you are in
> 3. pass the request, give the time zone you're in
> 4. pass the request, give the country/province you're in
> 5. pass the request, give the province/state you're in
> 6. pass the request, give the city you're in
> 7. pass the request, give the city quadrant you're in
> 8. pass the request, give the street you're on
> 9. pass the request, give the street address you're at
> 10. pass the request, give the floor of the building you're on
> 11. pass the request, give the office/cube # you're in

I see what you're saying.  This to me looks like an
implementation choice and not logically any different than
what I am saying.  But I would say that the LS is checking
the authorization against one rule and choosing the
precision or resolution to be used.  I call the 11 steps of
your implementation design *one* privacy control.

> This list is a generic template, and a user moves people
> (Location Requesters) in and out of each category. A more
> complex situation or end device might have time of day
> adjustment of what type of reply they get to an authorized
> query.

I see.

> Obviously this is a 'civil' template example, but it is
> the easiest to visualize.

Yes.

> In this template example of categories, it isn't just a
> case of a location reply being authorized or not, it's who
> was authorized, what time they were authorized - and based
> on a rules engine on the Location Server for that Target,
> a the appropriate reply is generated.

> This might make for a whole bunch of a long list of
> rules. I like to look at this from a time of date routing
> perspective from IP Telephony. I'll wait for your (and
> other feedback) on this template category proposal I've
> suggested above before going further.

> > > > > 7. James will provide some text

> > > > > 8. James will provide some text (on 2 different
             topics/places?)

> > > > > 9. fixed

> > > > > 10. Jorge will use the text and defs sent by James

> > > > > 11. fixed (?) (was: Why would LI be optional?)

> This is rooting in our general disagreement in how the LO
> is used. If the PI and SI is all relative to the LI, then
> the absence of LI should negate the use of the LO. 

Not necessarily. The PI are the policy rules, and they are
logically attached to the target.  For instance I could say:
" to all other people, send only the time zone I am" is a
policy (PI) without a LI.  And there are many other examples.

> All other messages should be of another form and not use and
> LO to transmit or request information (like UPDATE and
> NOTIFY messages would intuitively accomplish)

> > "LO" is the generic geopriv object, that should be used
> > also for notifications (if they are geopriv messages).
> > This is another possible use of LO without LI.

> Why would a Notify message described above need the PI and
> SI of a target?

No but it would use other fields of Req 2.

> I'm having a hard time not believing you consider an LO to
> be a generic term for any and all Geopriv messages... I
> must be misunderstanding something still

No, this is right: the LO is the one and only one Object in
geopriv.  At least until now.  The idea is to use the LO in
any geopriv exchange.  geopriv may be defined as the set of
rules that govern the use of the LO.  If we have
notifications, or alerts or geopriv requests they are done
with the LO.

It is probably unfortunate to use the word LO for this
"geopriv object", but that decision was taken quite a time
ago and very explicitly.

> But you answered one of my confusions with your answer
> above - I now understand that where I believe that there
> are only 3 pieces that make up the LO, you consider
> everything Geopriv to be an LO. I can't say which one of
> us is right, I just understand what the difference is now.

Yes.  It is only a convention.

> > (See for instance: "Filtered Location Information: Then
> > the Location Server sends the location information to
> > the Location Recipient.  The information may be filtered
> > in the sense that in general a less precise or a
> > computed version of the information is being delivered.
> > + Location Server rules for receiving, filtering and
> > distributing Location Objects")

> I don't remember your use of the word "filter" as you have
> it above. If this is properly defined as to its direct
> impact or effect on the precision given, then this is
> either something I missed, or is a good improvement of
> what I remember reading.

That was a quote from the draft.

> > > > > There should be cases where maximum resolution is
> > > > > provided (emergencies or just by policy
> > > > > configuration for certain requesters). This isn't
> > > > > mentioned as being available.

> > > > A particular case of filtering is using no filter,
> > > > or a particular case of sending "in general a less
> > > > precise or a computed version of the information is
> > > > being delivered" is sending full resolution.

> > Suggested text and a place to insert it?

> I need to re-read this area of the ID to make sure I
> didn't miss a concept you were trying to convey before I
> suggest a rewrite. 

Fair!

> > Explicit negotiation was in the first versions of the
> > draft, but was rejected.

> hmmmm..... I think I remember something about this, but I
> think the group wasn't talking about this exact
> mechanism. I believe we must reopen this capability to
> accomplish what we'll have asked of us. I can wait for
> other comments regarding this. I might pose an individual
> question to the list about this one, framing it to suggest
> alternatives for how we solve requesting optional LI
> fields be returned.

Fine.

> > > Maybe I'm thinking down the road about having these
> > > multiple packet formats too much within my questions
> > > when I refer to asking why LI would be optional. If
> > > there is only ever one Geopriv packet format, the LI
> > > will be optional. I'd like to hope that we create a
> > > few packet formats/messages (Location Request,
> > > Location Reply, Location Reject, Notify, Location
> > > Update, etc)

> > May be, but all are one LO subformats.  Can we leave
> > this for later?

> I just hope the train isn't heading down the tracks
> without any brakes on this one

Keep an eye on it. Up to now, for me it is only a
convention, that we call the geopriv object LO.

> > > > > 12. James will provide some text

> > > > > 13. James will provide some text

> > > > > 14. some clarifying text could be appropriate

> > Is there a text that would resolve the confusion?

> I can now live with what you wrote

> This is similar to how we two look at this whole effort. I
> understand that the LO will have to have all of its fields
> defined, yet not have to include most of them in any one
> message. I just don't use the term LO as generically as
> you.

Yes, but some clarifying text could be appropriate. You were
not the only one confused here.

> > > > > 15. fixed, or do you wish some clarification text?

> > > > > 16.  fixed (?)

> > Actually, in some cases, like for instance when the data
> > is publicly know, there is no need to have a security
> > relation to exchange LO.

> but once the SA is up and running, then all private into
> can be exchanged without regard to any other
> constraints. This is what I was looking for.

> > > > > 17. fixed (?)

> > > > > 18. fixed (?)

> > No, a target may be also a person or almost anything.
> > But a target may be a device.  And a target usually has
> > one or several devices.

> Ok, so you're taking the opposite definition of
> inheritance that I have, I'll bow to your definition if
> you put text in the ID stating a Target can be a person
> (or something non-IP based, or even non-electronic)

I read the text as saying that (?)

> > > > > 19. Jorge will provide some text

> > > > >       "Rule Maker: The individual or entity that
> > > > >       has the authorization to set the applicable
> > > > >       privacy policies and rules."

> > > > > This definition explicitly states that there is
> > > > > "one" controller of rules or policies. A user
> > > > > should have control over their target(s), yet
> > > > > there could easily be a situation where a domain
> > > > > (perhaps a company's internal policy) might also
> > > > > have overriding control over part of the LI
> > > > > (perhaps overriding the maximum resolution a
> > > > > Target gives in a Location Request).

> > > > Actually I do agree.  But there has to be some proof
> > > > the user agrees too on that.

> > > I agree with your comment as well. This can be done
> > > within an employment or service contract, for example.

Yes!

> > Should I include some additional text? Suggestion?

> This might revolve around who is able to set the
> rules/policies for a Target (or device). If it is a
> combination of the owner of a device and the Access
> Provider, then there are two controllers. I think the text
> should state something to this affect and that there are
> jurisdictional issues that might force what a owner of a
> Device to adjust the precision of LI to be more exact or
> less exact, depending on local circumstances

Yes. Let me try to write something here.

> > > > > 20. James will make probably further suggestions

> > Because an ULR needs different policy information than
> > another recipient, which may pass this information
> > further.

> Why can't the ULR just disregard what doesn't pertain to
> it in this instance (which will always be a superset of
> what it receives)?

Yes, this is one mechanism.

> > > > > 21. fixed

> > Even if it is not using IP, the ULR is not permitted to
> > pass this information any further.  This rule for the
> > URL is like a "copyright statement" if you wish. It says
> > "this data may not be disclosed further, in any form
> > whatsoever."  We may not be able to enforce it, but we
> > want to express such a restriction.

> I think it's out of scope once it leaves the IP world, but
> will relent if you want it that much

Yes, I do.  Meanwhile I am thinking like a lawyer.

> > > > > 22. fixed

> > > > > 23. Conclusion: Replace IAP by AP. done

> > > > The IAP can also be a WLAN provider (not necessarily
> > > > the internet provider) or a corporate network, or
> > > > something else.

> > > Then any or all IP networks can be IAP. This seems
> > > like a hard group to define and I don't understand the
> > > purpose of this except for when lawyers get involved
> > > (no offense John).

> > Suggestion?

> You used the term Access Provider earlier in this email -
> and I think this term fits what you intend, and is fairly
> easy to understand and remember.  Maybe just a switch out?

Fine

> > > I'm not sure how privacy concerns here are in scope of
> > > the IETF if they are not IP based

> > Oh yes, they are! We are defining, in IP, a language to
> > express the rules that govern the use of certain data,
> > in IP or not! It is like copyright.

> Written like a lawyer..... ha ha.

> I guess I don't have a problem with this explanation if
> used to explain the location gathering methods

The rules apply not only to the location gathering phase, or
the "IP-geopriv phase", but also to what may come after it
(writing the data in some database or in textual form).

> > > > > 24. fixed (?)

> > > > Yes, I see something like "this data must be kept
> > > > secret (or even encrypted) as part of the
> > > > policy. But we have not reached consensus here. All
> > > > those questions have been moved to the
> > > > "core-policies" draft.

> > > Then maybe that ID should be referenced here?

> > I don't think that a draft in last call shall reference
> > a draft that is not supposed to become an rfc.

> oh... you're right - but it does explain the situation
> that this ID won't unless something is referenced or
> included...

> > > > > 25. Jorge will try to use the words correctly in
              the new version of the draft and James will
              check it.

> > > > >    "..."my location can only be disclosed to the
> > > > >    owner of such credentials and in such
> > > > >    accuracy"..."

> > > > > This is a misuse of the word "accuracy" and its
> > > > > meaning. Resolution and (more likely only)
> > > > > precision are the coupled meanings that should be
> > > > > here in the quote.

> > > > Fine.

> > > Thanks

> > When should we use resolution and when precision (text
> > suggestions?)

> The usages are subtly different and sometimes
> interchangeable (unfortunately).

> Precise (is an adjective)
> how precise something is

> Precision ( is a noun)
> level of precision

> Resolution (is a noun)
> Use Resolution when referring to boundaries (like Lat or Long)
> Use resolution when referring to the topic

> Resolve (is a verb)
> To resolve to a certain degree

> Key:
>          Precision and Resolution can be interchanged, but
>          Precise and Resolve are independent words

> > > > > 26. fixed (?)

> > > > > Identifiers, Authentication and Authorization
> > > > > "...Unlinkability ...

> > > > > If you don't know that it is me requesting your
> > > > > location, because of this unlinkability, then how
> > > > > would you bind a rule or policy to my pseudonym
> > > > > and grant me the ability you would have given me
> > > > > (had you known it was me asking)?

> > I would say: the person who presents a token of this or
> > that type is allowed to obtain my location.

> But this would mean that I would have to identify myself
> to your authenticator/authorizer in order to obtain the
> appropriate token... I think this would compromise my
> anonymity in ways that is inconsistent with our goals -
> yet I don't have a solution ( this topic gets my noodle
> all wrapped up)

Yes, this is strange.  Of course, you will authenticate end
identify sometime to somebody, but there is technology
around to create credentials that, like money, show that you
have some authorization status without telling who you are.
Of course, you have to identify yourself to the bank and to
the employer, but they do not know what you are doing with
your money.  The paradigm is similar here.  Much of the
business of privacy is how to do access control without
identification.  See for instance www.ra-pid.org, look for
identity management and PETs in infrastructures (section on
authorization privacy).

> Now how do we accomplish this without you or I reveling
> ourselves in the packets, yet knowing each is who we say
> we are in people time?

For instance, using electronic tokens, like e-cash. But
there are other methods.

Do you see there explicitly some incongruence in the reqs
related to Authorization and Identity Management? (Req
12. and 13.)

> > > > > 27. fixed (?)

> > > > > "Authorization

> > > But how do you determine who is who if pseudonyms are
> > > used?

> > For instance (although this is not the best solution, it
> > is easy to explain) you can give your friends a codeword
> > to access your location.

> But my friends will know it's from me because I gave it to
> them out of band (from Geopriv).

Sure!

> You are putting the
> burden on me to distribute my codeword(s) to all who can
> ask for my location. 

The codeword solution was only one example. Actually it
can be done quite efficiently, but it is a burden. There are
better solutions.

> Since they have to have it in order
> for Geopriv to work at all, this codeword distribution
> must be done some other way. I have a belief that this
> makes the process less efficient

> I want to put the type of person (wife, son, boss,
> co-worker, friend, etc as URIs) into and out of categories
> in a user friendly template that has established
> rules/policies, then adjust from there the specifics. Let
> these people authenticate to some service I trust, and
> their URI in the request will determine the type of
> response they receive.

Sure!  I can tell the trusted server: give Alice a token
stating that she is a friend of mine, and give Bob one
saying that he is a co-worker.  Then they use those e-tokens
at the LS to obtain the LI without disclosing who they are
to the LS.  This is another possible solution.

> This puts the burden on them just
> like I have to learn your email address in order to email
> you, or your phone number in order to call you. But I can
> always input or push that trust up to my provider to state
> that I will trust a request from this or these URIs
> (perhaps to only some lesser degree that usual, but much
> more than a failure)

> > > > > 28.  James will provide some text

> > Sure! Can you provide the text and a place to insert it?

> By this point in the email, I knew you were going to ask
> for it. I'll get it to you soon.

:)))))

> > > > > Additionally, any GPS communications is logical
> > > > > and shouldn't be mentioned as a Geopriv scenario
> > > > > (there's no IP involved). Cell Towers aren't IP
> > > > > based, therefore they too aren't under Geopriv's
> > > > > charter.

> > > > > Once some Server that has gathered enough
> > > > > information about these cellular devices, that
> > > > > Server might use Geopriv to communicate to other
> > > > > Location Servers (this scenario could fall under
> > > > > Geopriv, or SOAP).

> > Suggested concrete changes?

> I've already caved into these being viable examples that
> should be pointed out for clarity

Let us discuss the details over the phone

> > > > > 29. fixed (?)

> At least we both should understand more about what the
> other is referring to when communicating points of view
> ;-)

:)))

> > > > > 30. phone discussion?

> > Like in Mobile-IP or gsm or
> > umts or many others, the visited nw will contact the
> > home network and ask for some kind of authorization and
> > authentication data.

> based on what message? The target doesn't generate
> anything except a response. If the Target is now in
> another Access Provider's network (coverage), there is no
> pinging like there is in gsm or utms, there's no broadcast
> saying "here I am, track me over here now".

There are many possibilities. Some:

- you turn on your notebook, which has mobile-ip. The
notebook will obtain his location via gps and send it via
geopriv to where he wants.

- you turn on your notebook, which has mobile-ip. The
notebook will obtain connection to the access provider using
the mobile ip exchanges, During this process the AP contacts
the home nw to obtain keys, challenge-response material,
etc. The towers of the AP are able to calculate where this
device is, to link this information to the corresponding CoA
(mobile ip care of address) and they send this information
to a LS in the visited nw.  The LS has to ask the home nw
which policies to use and where to send this information.
Etc.

- you turn on your notebook, which has mobile-ip. The
environment has some active beacons offering data that a LS
will decipher as providing LI. Your computer sends this
beacons to the LS, etc.

- you are in fact using umts or another 3g+ technology.

> > The visited nw or isp will perform a challenge response
> > or another check and authenticate or authorize the
> > mobile device or user.

> How will AP 2 know the Target one left its home domain?

This is solved in mobile ip using the NAI

> Does the home domain track the target's motions until it
> realizes the target is leaving it's area of control into
> another (known) AP and then contact that AP on some
> control channel to start tracking this Target?

Not necessarily.

> I think you'll have a failure to communicate because of
> this lack of broadcast

Then mobile ip and other solutions will also fail

> If this is to be in addition to or take advantage of
> cellular communications such as 3GPP, the Geopriv
> client(device) software needs to know in its code to
> periodically announce itself like a gsm device does.  

I don't think

> The
> movement from AP zones will not be graceful always (like
> getting off a plane in another country and being turned
> on).

True

> > This is usually not referred to as registration.

> No, but it is a form of broadcast beckoning that Geopriv
> Targets/devices likely don't have in mind currently. Or
> can you point me to the text hinting at this requirement
> for all implementations?

> > > Shouldn't there be something like a roaming
> > > registration of cellular systems in our architecture?
> > > This would likely involve some form of registration
> > > with the new Service Provider, I would think.

> > AAA, not registration.

> I'm using the wrong word here (registration) - and I sit
> corrected. But you need to solve the active outbound
> beckoning issue for Targets for me then (as mentioned
> above)....

> > > > > Further, it would seem that the Target would be
> > > > > doing the Registration to a Location Service, and
> > > > > within that Registration would be a pointer to an
> > > > > existing Rule Maker (the Target and Rule Maker
> > > > > should be the owners of the policy for that
> > > > > Target) and an existing Rule Maker Policy Profile
> > > > > for that Target. The text here has this process
> > > > > turned around.

> > > > Say, the target is a car of an infant. The owner of
> > > > the car or the parent of the child, the rule maker,
> > > > would be doing the Registration, not the target. I
> > > > do not think the text is reversed.

> > > Once that car or the infant crosses jurisdictional
> > > boundaries (county, province, state, country, etc) and
> > > leaves its home Location Service Provider's network,
> > > how does that car communicate via Geopriv in any
> > > direction?

> > As in mobile-ip or whatever.

> here I'm getting back to the issue of a broadcast
> capability that this Reqs ID doesn't have that I'm seeing
> (until someone points this out where I've missed).

> > > How does any Location Request get an appropriate
> > > response (remember - there would be no Sighter in this
> > > "other" jurisdiction)? The new LSP won't recognize it
> > > because there is no contract. It can't sent out a
> > > Location Update or determine where it is... nothing.

> > If there is no contract and no way of
> > sending/information, what has to do this with geopriv?
> > If there is, like in mobile-ip, then the visited nw will
> > recognize it

> in Geopriv code?

will recognize the IP address (CoA and Home Address), will
ask the home LS where to get the rules from this HoA (only
the home nw will generally know who the user is, but this is
enough), and the LS of the visited domain will send the
information based on this dynamic CoA.

> > and send the information, say, to the home nw.  To know
> > exactly what to do the visited domain has probably to
> > contact the home nw to know who the rule maker is or
> > where the policies (rules) can be found.

> Once this visited nw becomes aware of the target, what you
> state above is appropriate

Oh, ok.  So your problem seems only to be the paging.  You
are right: if you are not connected to the nw, and there is
no paging mechanism for your idle target, you will not be
recognized.

> see above, we can explore this further if you still don't
> understand my position (figuratively), or a proposed
> solution if you realize something is indeed missing that
> I've discovered.

> > > > > 31. fixed (?)

> ... oh, I've had that read into my brain this evening
> going through this email....

sorry! I didn't mean to be to nagging.

> > > The Sighter or Generator doesn't have policy contained
> > > within it, so it should be mandatory to have that
> > > device send the complete, most precise LI for all
> > > potential Geopriv Targets it is the Sighter for. The
> > > LS then applies the Policy to all inbound requests.

> > I understand this requirement, but I do not see why this
> > is a MUST.

> Because it should not be up to the Generator which fields
> to send - this should be exclusively where the policies
> are applied to determine how to manipulate any if not all
> fields from their respective maximum
> levels/values/whatever.

> >  Suppose the generator contacts the LS and ask him which
> > LI granularity he wants, and thereafter only sends this
> > required information.

> this is suggesting a PDP/PEP relationship - which is new

Yes.  One of the problems in geopriv is that it has to work
in all kinds of scenarios that you haven't thought before!

>  > > > > 1.2) Some fields within the Location Object MAY
> be > > > present, or MAY not.

> > > > >     1.2a) All Geopriv entities MUST not fail a
> > > > > transaction if one or more fields are not present,
> > > > > or not understood, if the Geopriv message is
> > > > > acceptable under the Policy and Security rules for
> > > > > that Target.

> > > > I don't understand the requirement.  But if the
> > > > Geopriv message is not acceptable under the Policy
> > > > and Security rules for that Target, then it should
> > > > not use it.

> What I state is the opposite, if the message does pass the
> PI and SI, and is also missing one or more LI fields the
> Location Seeker wants, this shouldn't be a candidate for
> failure by the Seeker, the Seeker should accept the LO as
> is. Lacking one or more fields might be by choice of the
> Rule Maker for that Target's presentation of location

Sure.  

> > > If a Location Seeker doesn't understand a particular
> > > field
>Including policy rules?

no, aside from Policy or Security rules only - we're talking about LI 
Fields only

> > > that is included within the reply, it shouldn't fail
> > > the transaction. If a Location Server doesn't
> > > understand a Location field, it shouldn't fail the
> > > transaction.  This requirement is for the cases of
> > > extensibility when one side of the Geopriv process in
> > > any direction provides more information than the
> > > receiver understands.

> > Suggested text?  Is this a requirement in the scope of
> > the draft as stated in #3, 
that is, as I wrote in my answer to #3:
>Let us agree that the scope of the draft is the privacy
>requirements of the LO (plus any other needed thing in
>order to discuss privacy properly) and not on general
>requirements on the LO format or the geopriv transactions.

I would have problems with such a req. although it sounds
quite plausible.  One problem is that it is way out of our
scope in this draft.  Another is that we have never decided
what the LI fields are going to be (I have some idea of what
the LO fields are, but you are referring here to missing
LI fields) or we do not know what the using protocol will
want to do with them.  Perhaps, from the point of view of
the using protocol transaction, the transaction indeed
fails.  I do not know what is a geopriv transaction.

> > > > > 32. From Requirement 2.5 Location Field.

> > > > >    "Each Location Field may contain one or more
> > > > >    Location Representations, which can be also in
> > > > >    different formats."

> > > > > This text seems to indicate the necessity of
> > > > > another ID defining all the potential Location
> > > > > Information Fields (to ensure
> > > > > interoperability). Why was this left so open?

> > Suggestion for our draft?

> none if another ID should be written...

> But I think what you call "Location Representations" here
> is what you call "Data Types" elsewhere

I do not think.

> > > > > 33. should we move 2.7 to 2.5.1?? Would you accept
              that as a solution?

> > > > > From Requirement 2.7 Motion and direction
> > > > > vectors

> > > > > This text should be under Req 2.5 - or this
> > > > > separate ID defining the LO, or at least the LI
> > > > > and its mandatory and optional fields

> > > > > 34. fixed (?)

> > > Ah, then you believe some notion of a Location Request
> > > containing the LI Fields it wants to receive? 

I do not know what the LI fields are. I know what you mean
by them, but I would use a very different terminology.  I
would say: a Location Request contains the Data Types and
Precision it wants to receive. I think this is possible with
the current reqs, so I do not see need for starting an
action here.

> > > I think
> > > this is necessary, and we don't need much detail, but
> > > a little text should be added to this ID mentioning
> > > this (it is a FW ID as well).

> This is the details of a "negotiation" you said we killed
> the idea of. Now I remember that discussion - and it was
> something to the of not wanting there to be too many round
> trips before deciding on the location answer.  But I
> believe if we define a default set of LI fields that are
> appropriate for all Location Replies (meaning what's
> returned to the Location Seeker after passing policy and
> security rules) - then we can have the Seeker merely
> include in its Location Request the additional fields
> (that are defined somewhere) that it happens to
> want. Obviously the Rule maker is the decider of what is
> in the reply

> > Also, perhaps the request does not contain the LI fields
> > it want to receive, but only information on the data
> > type and perhaps also on the precision or resolution
> > that it would expect.

> This is absolutely allowable in a request as I envision it

> > > > > 35. James will discuss this with Henning and try
              to come with a better solution to the one in
              the draft. (Topic: delta format reduces the
              packet size?)

> > > > > 36. fixed

> > > > > 37. Jorge will try to change the wording in 3.1.3
              as not to suggest that this weakens Req 4

> > > > >       "Req. 4.  The using protocol has to obey the
> > > > >       privacy and security instructions coded in
> > > > >       the Location Object and in the corresponding
> > > > >       Policy Rules regarding the transmission and
> > > > >       storage of the LO."

> > > > > This is written as a MUST, where other text in
> > > > > other parts of the ID state this is optional or
> > > > > preferred only;

> > > > No this is a MUST.  In other part it is said: there
> > > > are many ways of securing a LO.  We prefer the
> > > > LO-security itself, not just transporting the LO
> > > > securely.  This is like preferring IPsec to TLS or
> > > > preferring xml-security than securing SOAP with TLS.

> > Text suggestion?

> This is a MUST above, but if you look at the examples I've
> included, you have the words that pull back on that
> emphasis.

> > > > > 38. James will provide this open ended pointer (that
              the IESG will accept)?

> > > > >    "The protocol SHOULD allow a bypass if
> > > > >    authentication fails in an emergency call.

> > > I believe the text should state "full resolution" (as
> > > you stated with your reply).

> > I agree, but I do not think that this requirement would
> > be in the scope of our draft.  I imagine that the type
> > of resolution required by emergency services is not for
> > us to decide, but by NENA or whoever.  Perhaps they
> > request a special format which is not "full resolution".
> > I would rather leave this point open here.

> Then maybe place a open ended pointer to a future document
> on this known to exist topic (that could be for each
> country or generically for all countries - which I doubt
> could happen)

> > > > > 39. fixed

> > > > > 40. James come up with some text

> > > > > 41. fixed!

> > > > > 42. fixed

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 20 Feb 2003 13:58:21 -0600

>We are making progress here, thanks!

Yes - we're making progress, this is good

I still have comments though inline

>Jorge

yes

>identifiers for the target and recipient, credentials,

what you mention I believe is what I would consider part of the 
construction of the Geopriv envelope (including a Geopriv version #) which 
has as it's main payload the LO

>!We should make this clear in the text earlier than in

OK - I'm not trying to design this already, just want to point out the 
elements we know will have to be included in the protocol within this doc

>Agree! I will add some text and you check it!

OK

> > > > > > 5. Do you suggest adding some text here?

I need to review this again before answering - I don't have everything in 
one place here

>what I am saying.

I know it's more of an implementation choice in appearance, but we can make 
all implementations easier in our design. The above is on way of 
implementing the rules behind the rule maker interface - and should be a 
very popular way of doing it.

>But I would say that the LS is checking
>precision or resolution to be used.

So, if what you're referring to "...checking against one rule..." is my 
separation from step 1 and step 2, then I can understand your explanation. 
But it might present a problem:

Are we going to limit all successful location queries to only those people 
we have shares our passwords with?

Or do we go down the 2 step (or more) process of allowing a location query 
to be successful by most requests, but just limit the template resolution 
of the reply to be based next (step) on who's asking for our location, with 
a much less precise LI for my Target those I don't want to know where I am 
other than my timezone of hemisphere (for example)?

I know we want to prevent a location version of telemarketers, but we can 
be more open than only allowing 10 or 100 Location Seekers access to my 
location (which it sounds more like the implementation you are possibly 
proposing).

>I call the 11 steps of

Yes, one of *privacy* control - but if you severely limit the potential for 
a successful query, you won't need to worry too much about privacy control, 
you'll know all 10 people you've given your password to.

>policy (PI) without a LI.

I this quoted above, if taken alone, is a UPDATE message to an LS that has 
a  preexisting relationship (or configuration) with that Target.

If the quote above is within the initial configuration or rules to follow 
(by the LS) for that Target, then this is more of a Registration/log-on 
transaction.

The latter example might have the LO included in the message, but the 
former is quite possibly a change request between the rule maker and the LS 
with regard to a specific Target, and I an LO has already been sent previously.

>And there are many other examples.
>

Right... then there could be another packet format that's tailored for the 
purposes of something like a Notify or Update or Log-on or Register. I 
don't believe it should be more complicated that these examples

>geopriv.  At least until now.

I have to say I'm not in agreement, but I might be the only one who doesn't 
agree at this point - and will bow to group consensus if there is one

>The idea is to use the LO in
>any geopriv exchange.

>geopriv may be defined as the set of
>rules that govern the use of the LO.

>If we have

>That was a quote from the draft.

I'll re-read that section. I was perhaps so focused on a lateral topic in 
this area of the ID, I missed this term and meaning. Forgive...

> > alternatives for how we solve requesting optional LI

Will send this out soon

>not the only one confused here.

That's a relief....  :-/

> > constraints. This is what I was looking for.

I need to review this topic again to be sure

>I read the text as saying that (?)

I don't remember the text saying the equivalent of Target = person (as one 
of its possibilities

>Yes. Let me try to write something here.

OK

>Yes, this is one mechanism.

Then if this is true, we can expand the definition of the Location Seeker 
and do away with ULR, no?

>Yes, I do.  Meanwhile I am thinking like a lawyer.

no comment - although many come to mind  ;-)

> > > > > > 23. Conclusion: Replace IAP by AP. done

Good!

> >          Precise and Resolve are independent words

I might even think these 4 terms should be included in the ID to make sure 
others aren't confused in their usages - including the "Key" somewhere in 
the text

>For instance, using electronic tokens, like e-cash. But

But how do you set up a rule allowing me (who doesn't reveal my identity) 
to access your location?

And then, how do you determine which level of precision you choose to 
provide in your response to me?

> > them out of band (from Geopriv).

yes, but this is quite limiting in who you will even accept a location 
query from

>to the LS.  This is another possible solution.

I must be tired or something else - because I believe you just contradicted 
yourself.

>- you are in fact using umts or another 3g+ technology.

I don't read in one of your examples how the Geopriv protocol will 
formulate a "push" packet on its own. Upon turning on a notebook, it could 
have a program that sends something like an Update packet to its home LS. 
But how will the LS know which AP it's in? The AP servers don't inspect the 
Geopriv packets and incorporate something like a SIP VIA header showing a 
path back.

The reqs ID doesn't cover this instance at all IMO. Nor does it cover the 
case in which you and in your car and you drive outside of your AP's home 
domain. It should then loose contact with you (and your device). there was 
no power-up sequence to cause a Update or Register packet to be sent (each 
of which aren't yet defined or mentioned yet BTW).

>This is solved in mobile ip using the NAI

But Geopriv has to have a "push" mechanism to perform this - and if you 
agree, then it needs to be mentioned within this ID so it can be created in 
future work.

> > periodically announce itself like a gsm device does.

we need to discuss this then

>information based on this dynamic CoA.

I think you're assuming the remote network become aware of this new roaming 
Geopriv device through Mobile IP, and I believe this should be a Geopriv 
transaction (or action). And I don't believe this is addressed yet

>no paging mechanism for your idle target, you will not be

This is what I'm referring to - how do we solve this? I think this should 
be a requirement now for the WG, and I don't think the charter prevents us 
from addressing it. This could be the subject on a completely separate 
solution ID (one I'm not going to write, mind you!). I believe by putting 
this into our reqs ID now, we expect someone to step up and solve it 
sometime down the road (it doesn't have to be today). Leaving this topic 
dangling or unaddressed, means it remains lingering until someone puts it 
in another requirements ID.

>sorry! I didn't mean to be to nagging.

No worries.... It was late when I got this that email done (almost 3 hours 
spent writing it   ugh!)

>in all kinds of scenarios that you haven't thought before!

I still don't like decisions like this being made by 
devices/entities/servers that have no knowledge of the PI and SI of a 
Target (which is its home LS). We're begging for gaps in our delivery if we 
allow this to continue

> > Rule Maker for that Target's presentation of location

Thank you

>no, aside from Policy or Security rules only - we're talking about LI

OK

>fails.

>I do not know what is a geopriv transaction.

A "Request/Response" (pass or fail),

A Notify/Response

An Update/Response

A Register/Response

A Sighting (sent to the LS)/Acknowledgement back

A Rules look-up/Acknowledgement back

These are all what I consider Geopriv transactions (ie point to point "push 
and acknowledgement" or "pull and answer")

> > is what you call "Data Types" elsewhere

Then "Location Representations" needs to be defined somewhere

>I do not know what the LI fields are.

fair - they haven't been agreed upon yet

>I know what you mean
>by them,

then their concept can be referenced

>but I would use a very different terminology.  I
>Precision it wants to receive.

Date Types shouldn't include all the possible optional LI Fields, having 
each possible sequence of them called a unique number or name. I believe 
the LI fields can/will be individually named and can therefore be 
individually called out.

>I think this is possible with

This is like relative position. We all want it. But the Target or device 
shouldn't have to calculate it, IMO. If it can, then all the better.

> > > > > > 38. James will provide this open ended pointer (that

no burden here - thanks for the challenge

> > > > > > 40. James come up with some text

cheers,
James

               *************************************
"People generally demand more respect for their own rights than
                          they are willing to allow for others"