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

From: [email-masked]
Date: Fri, 20 Feb 2004 14:20:58 +0200

I read through this draft and I did not find anything controversial. I do have a few nits though:

- The name of the document is too abstract, Something like the following will do: Common Authorization Policy Framework for Application Date.

- The use of the acronym PS is confusing to us people working in SIMPLE. PS for us stands for Presence Server. May I suggest APS: Authorization Policy Server?

-In Section 2: It says that the WR is requests access to data item. Then it goes on to state that those access operations might be read or write. The question is: Do we really envision that there will be requests for write access by the WR? If not, the I suggest removing that operation from the list of possible operations.

- Section 3 first paragraph. The following sentence should be re-structured, for clarity, from: 

  "The using protocol provides
   the identity of the requestor (or more precisely the authentication
   protocol),"

to

The using protocol (or more precisely the authentication protocol) provides the identity of the requestor ,

- Section 3.2 give the example of SIP INVITE. I'm lost by that example. When can that happen?

- Section 7.1 and 10 talk about attribute. This is confusing since there is a term clash with XML attributes. I get confused when I read "The <sphere> attribute". Perhaps you can use the term characteristic or something like that.

- Section 7.1: It says the <domain> element contains a list of <except> elements. Looking at the schema and examples, the <except> element is not really contained by the <domain> element. The schema needs changing. This change will also cause less errors by using the schema to disallow the <except> element appearing with a <uri> element. I suggest:

  <domain>
     <domain-name>example.com</domain-name>
     <except>[email-masked]</except>
  </domain>

You also need to state that the URI appearing in an <except> element must have a domain part that is the same as the domain in <domain-name>

- Section 7 defines conditions: Identity is referring to the WR while sphere is referring to the PT. When put together under <conditions>, it is a little confusing to figure out which is for the WR and which is for the PT. May I suggest <WR-Identity> and <PT-sphere>, for clarity.

- Section 7.3 defines the validity. Who does the garbage collection when a rule has expired? Do they stay or the server for ever? cleaned by the client? by the server?

Regards,
Hisham

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 22 Feb 2004 01:40:04 -0500

Some further thoughts inline:

[email-masked] wrote:

> - Section 7.1: It says the <domain> element contains a list of
> <except> elements. Looking at the schema and examples, the <except>
> element is not really contained by the <domain> element. The schema
> needs changing. This change will also cause less errors by using the
> schema to disallow the <except> element appearing with a <uri>
> element. I suggest:
> 
> <domain> <domain-name>example.com</domain-name> 
> <except>[email-masked]</except> </domain>
> 
> You also need to state that the URI appearing in an <except> element
> must have a domain part that is the same as the domain in
> <domain-name>

You can actually enforce that with the schema, if you define it like this:

<domain>
   <domain-name>example.com</domain-name>
   <except-user>joe</except-user>
</domain>

That is, the <except-user> element only contains a user part within the 
specified domain. This way, you don't even need to do a check - there is 
no way to specify exceptions outside of a domain.

> - Section 7.3 defines the validity. Who does the garbage collection
> when a rule has expired? Do they stay or the server for ever? cleaned
> by the client? by the server?

My understanding is that there is actually no garbage collection in the 
normal sense; that is, the server would not remove the rule. If the 
validity has expired, the rule would simply never match any requests. A 
client would still need to clean it up. I think thats important. I dont 
want the server to remove them, since the client may wish to 
re-instantiate the rule for a different time period by just modifying 
the validility element.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 22 Feb 2004 01:40:04 -0500

<domain>

-Jonathan R.