RE: Mobile nodes etc.

Dear Kenji,

Thank you very much for your remarks! Sorry for the late reply,
I was out of town.

> In my opinion, the draft does not make it clear which parts are
requirements
> or not. I think that the sentences starting with "Req" are requirements
and
> the rest is just background information. But the background information
> sometimes sounds like requirements and is confusing. For example,
>
> I am not sure if basic location information types are requirements or not.
> If it is, I have a comment on the descrete format along with Dante. At
> least,
> in China and Japan, we do not use "street address". Also the format
should
> handle international languages (e.g. UTF16, UTF32). Anyway I think the
> format
> definition should be out of scope.

We agree completely.

> In 3.2, what is "correct" abstraction is written with example of DT1 and
> DT2. I do not think this is neccessary in the draft. Rather, the draft
may
> say what is "correct" abstraction is out of scope. The protocol should not
> assure the semantical correctness of the data. It just sends back and
forth
> location relevant data between authenticated/authorized parties.

Maybe. There is one advantage about "correct abstractions":
  if the policy says:
  the location information disclosed will be only the time zone
    (or for that sake any other location data type),
  then there is only one correct translation (as long as the
    existing location information is finer than that).
Otherwise, if any incorrect abstraction is allowed, either
the particuar translation must be specified in the policy
(which in general is expensive) or the location server may
just state that you are in GMT time zone, idependently of your
current position.

> The Pol flow does not just send a policy but should let the owners view
and
> modify current policies stored in the repository.

Yes, we agree.

> The section 3.3 discusses identities and authentication/authorization.
But
> I am not sure how the discussions are related to Req 15 and 16. I think
it
> is more important to determine who authenticate/authorize whom in figure
1.

Yes. Who authenticates himself to whom is described in Req. 14: The protocol
must allow the message flows LI, Pol, LIF, LRequest, and PolI to be
mutually authenticated as required by policies (default or dynamic) or by
further requirements to be discussed. I guess that most policies will
indeed require all this data flows to be authenticated, but in some
cases, the

> I wonder if the policy repository (or part of it) could be at the target
> side.

Yes. The repository may also be distributed.

> This allows the owners to control policies at will. If the whole
> repository is at the target side, the location server becomes a kind of
> directory server. It relays LRequests to the target from clients and the
> target decide if the location information should be relaesed. In this
way,
> the owners can decide the disclosure per request - e.g. "Now I am at home
> and the request is from my family, so I am going to disclose my location
> information." If this is too tedius, the owners may store filtering
> policies at the server side and only handle important requests. I think
it
> is important to give owners last-minute decision to disclose.

> I do not understand Req11 very well. I thought policy conditions would
be,
> for examples:
> - When to disclose location information (e.g. To my boss, I only disclose
my
> location from 9am to 5pm)
> - Where to disclose location information (e.g. If I am in US, I disclose
my
> location to local police).

Yes, both examples should be possible to express in policies.
Req. 11 just says that in order to identify who your boss is, a syntactic
criteria will be given on the identifier or credential that he will present.
(For instance his name is "..." or his certificate has a certain value
on a given field). The idea is that with one syntactic criteria you
may identify several bosses, or all members of your company or your
department, say using regular expressions.

Morover, the credentials of the client are perhaps also used to agree
on prices, or other parameters of the service. Those parameters are
perfectly opaque to the geopriv protocol, but the policy may be used
to specify conditions that may be interpreted as "if the printer
service costs less than 10 cents per page". This may be done in the
following way: The target and the client agree (say, using the
"Service" data flow) on the meaning of some parts of the identifiers
or credentials as providing information about the value of the
parameters. For instance a credential containing the string
"10centsperpage" (in the correct context) is interpreted as
stating that the printing service in question costs 10 cents per page.
This use (or mis-use) of identifiers or credentials for passing
parameters does not need to be standarized, and may be left out
of scope of geopriv.

What is intended is that not _any_ condition on the identifier
or credential will be a valid condition to be checked.
Only matching (say, at the level of regular expressions) is allowed.
This is what is ment by "syntactical condition". For instance
it sould be impossible to express something like: if you translate
the string to a number using this-encoding, then the resulting
number is a root of that-equation or even more complicated things
that may be too costly. This would be very difficult to specify
and would allow DoS attacks.

What is missing in 3.4 is a discussion of what the types of conditions are
ment at the end of the the sentence:
"3.4. Policies
   A location privacy policy is an assertion that a certain amount of
   information (identity or identifier plus location) may be released to
   a certain entity (or group of entities) under a certain set of
   conditions."

As in your examples, we think the following must be included:
 time conditions (from 9am to 5pm),
 location conditions (if I am in the US).
It is possible to think of others, but we are not sure about
how to standarize them.

Thus "atomic" conditions would be regular expressions (or something
of the like) on credentials or identifiers, and time constraints
and location conditions of very simple restricted forms.
The general conditions are simply boolean combinations of atomic ones.

> Can the protocol handle mutlicast?

I understand your question as asking if the data flows LI, POL, etc.
may be multicast flows. I guess in principle yes, but this can be
somewhat to early to decide: first we would need to figure out exactly
what the message exchanges are. There could be something dynamical
about them (some negotiation for instance). Also the whole issue of
authentication/authorization is more difficult in the multicast setting.

Is there any special data flow that you think SHOULD be multicast?
(LI, Pol or LRequest to several Location Servers or FLI to several
Clients?)

As for the LI, Pol and LRequest flows one alternative would be that the
Location Server Agent distributes this information to other
Location Server Agents. This may be done since the Location server
is seen as distributed.

> Does this protocol allow owners to disclose their location information in
an
> anonymous manner? I guess it does using pseudonyms. But I think we need
a
> requirement that explicitly says so.

Yes, this is true.

> On Page 6, the definition of the Client says "one or more Mobile Nodes....
".
> The protocol should not limit its applicability only to mobile nodes. It
> should also support fixed (and wired) nodes (for example, equipment in the
> field).

You are right!

> Also there are a few minor editorial errors:
>
> On Page 6, the paragraph just before Section 3.2, "In that case if
> SHOULD..." -> "In that case it SHOULD..."
>
> On Page 7, the second last paragraph, "In general, if DT1 has more
> information than DT2, then there is one a..." -> "In general, if DT1 has
> more information than DT2, then there is one...".

We agree here too. Thanks!

Regards, Jorge
Received on Mon Nov 26 06:39:27 2001