Subject: [Geopriv] Comments on draft-ietf-geopriv-policy-00

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 28 Oct 2003 14:26:15 -0500

Substance:
Has there been discussion of wildcards in the URI of the requestor?
It would seem this would be pretty important, as in most cases, you
will specify a rule to a class of recipients, and wildcarded uri's
are the easiest way to classify. "[email-masked]" is a pretty useful
URI for a requester, while enumerating all the uri's in example.com
might be quite difficult.  Regexps would seem to be appropriate for
a string match.

In the same vein, it would be very helpful to be able to have
more than one URI in the <applies-to> which would be an inclusive OR
of any of the specified targets.  You might like to get fancy with
other conditions, but I suspect that is too complicated.  A single
list of URIs is pretty simple.  The same could reasonably be
applied to the other conditions, with somewhat less usefulness.
Sphere is an example where it would be more useful, civil slightly
less so.

Why can you have a parameter to a "Retention Time", but not a URI
list to "Distribute"?

Nits:

Goals and Assumptions, Permit only has a sentence fragment
"However, to avoid complex conflict resolution with these rules 
only 'permit'."  Probably should add "is specified" or something
similar.

Goals and Assumptions, Additive Permissions has a misplaced comma:
"If several rules fire then, the location recipient obtains the
permissions of all rules."  Probably should be "..fire, then..."

The word "action" is overloaded, or at least confusing in the text
"Since only one type of action i.e. 'permit' is 
allowed it does not need to be represented. 
... Actions cause the location server to take a certain action, 
such as adding a subscription." 
One cannot have "one only one kind of action" and "certain action, 
such as".  I'm actually not sure what was intended.  Perhaps
other actions are possible, each of which also assumes 'permit'.

In 4.1, the caution is somewhat misleading, or at least confusing.
It may right itself when we actually produce a document describing
a civil LO.  Until then, you could revise the wording to make it
clear that you are including this definition solely for the purpose
of naming the fields, which are referenced in later sections in 
rules.

The text twice states "street level precision", but actually it
goes to floor, and has the LOC field for Room.

BTW, I would really like to see a better definition of LOC
when we get to it.

Brian

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Oct 2003 14:37:52 -0500

> might be quite difficult.  Regexps would seem to be appropriate for

While the discussion isn't reflected in depth, the authors discussed 
this in some detail. This also came up at the interim meeting.

I have two concerns with allowing wildcards:

- I have not seen a convincing use case. For all but the tiniest domain, 
you wouldn't give access to everybody in that domain, e.g., in your 
company or everybody within AOL. If the number of people is small, you 
might as well enumerate them. Would you really have a rule for all of 
marconi.com, interns, cleaning staff and your boss included?

- Efficiency: the auth format is designed to be evaluated very 
efficiently for large sets of rules. As soon as you add regexp, you need 
to do a linear search and evaluation, rather than a simple 
indexed/hashed search and probably decrease efficiency by an order of 
magnitude.

> Sphere is an example where it would be more useful, civil slightly

This is an optimization that adds no fundamental capability, as the same 
effect can be achieved by having multiple rows which differ in the 
<applies-to> element only. However, as soon as you allow multiple 
values, the matching algorithm breaks and, for example, a database-like 
matching mechanism does not work any more.

I've tried very hard to keep this in canonical relational database form, 
as this is easy to reason about in terms of matching and there are 
known, large-scale implementations with a wealth of performance 
optimizations.

Indeed, as is, one implementation of this is extremely trivial: convert 
XML one-to-one into database records, apply SELECT. (Naturally, this is 
not required, but it certainly beats the model of searching through 
thousands of records sequentially, evaluating each one.)

Also, the more variation in rules, the harder it is to render this. One 
name is easy to ask for on a web form, multiple names gets tricky to do, 
as you'll always have some kind of upper limit on the count. Thus, from 
a UI perspective, having a single value per field simplifies the 
implementation.

> Why can you have a parameter to a "Retention Time", but not a URI

I'm not sure what you mean by the latter.

> Nits:

I'll fold those into the next version.

> BTW, I would really like to see a better definition of LOC

Agreed. Thanks for the comments.