[Geopriv] RE: comments to <draft-ietf-xcon-cpcp-xcap-01.txt>

From: hisham.khartabil@nokia.com
Date: Mon Jul 26 2004 - 07:54:09 EDT


Many thanks for taking the time in reviewing the draft. Responses inline...

> -----Original Message-----
> From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@siemens.com]
> Sent: 26.July.2004 11:27
> To: Niemi Aki (Nokia-M/Espoo); Koskelainen Petri (Nokia-NRC/Tampere);
> Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: geopriv@ietf.org; xcon@ietf.org
> Subject: comments to <draft-ietf-xcon-cpcp-xcap-01.txt>
> hi aki,
> hi hisham,
> hi petri,
> i went through your document and i like it. it improves the
> utility of the
> authorization policies defined in the geopriv wg.
> there are a few things which i like to point out.
> - the name of this draft is misleading. you are not defining
> a protocol. you
> define authorization policies.

Part of the document defines authorisation policy. Other parts define the rest of the conference policy. Combining it with a transport protocol like XCAP gives you a full solution that an be named the conference policy control protocol.

> furthermore, the filename is also misleading. these protocols
> have nothing
> todo with xcap itself.
> i know that this is a historical left-over from jonathan's
> draft naming.

Actually I removed the word xcap from the filename, but the WG chairs insisted that it goes back in.

> - would it be useful to separate the policies from the xcap usage?
> actually, i have the same impression about jonathan's
> <draft-ietf-simple-presence-rules-00.txt> draft.

It is separated. The current draft has less than a page on XCAP, just to satisfy the XCAP base document mandatory sections.

> - i took a brief look at the xml schema and noticed that you
> do not derive
> it from the common-policy schema in the same fashion as, for
> example, the
> geopriv-policy draft. why this?

There were a couple of reasons:

- the <identity> definition did not allow us to add <any> element
- the <validity> element was not needed in CPCP

For the latter, we can probably add text saying that CPCP clients and servers should ignore, but the <any> element needs to be there. This will depend on the answer to the question I ask few comments below about the <identity> element not being there.

> - i wasn't quite sure about the structure of the policies. in
> section 4.2
> you list a few xml elements which build the conference policy
> document (such
> as <setting>, <info>, <time>, <authorization>,....). i got
> the impression
> that this document describes more than just authz. policies
> which have the
> typical characteristic of (condition, action [and
> transformation]). maybe we
> should discuss some aspects in more detail next week (in san
> diego) - if you
> want.

Sure, we can set up a time.

XCON is scheduled for Monday morning and I would like to have the discussion before then. Is Sunday afternoon good for you?

> i asked myself, for example, the following questions:
> * why isn't the <time>, <conference-uri> or the
> <max-participant-count>
> part of the conditions element?
> * why isn't the <allow-sidebars> element part of the
> actions element?
> the info element is interesting. i wonder whether such an
> element would be
> relevant for other authz usage domains.
> - <security-control> element:
> we also discussed such an element in the geopriv area (we called it
> <encrypt>).
> you only talk about the signalling traffic and the
> differentiation between
> tls and s-mime (as a means to say e2e vs. hop-by-hop security).
> you do not talk about the actual data traffic (something like
> 'confidentiality of data traffic between the conferencing
> participants must
> be enabled if element X is set to true.)

Every media stream might have a different protocol for security. Allowing one to be defined as a common data traffic security protocol seemed limiting.

I thought to leave this up to the media protocols and local policy of conference servers. But I'm open to ideas.

> - section talks about the identity element. the
> section says:
> "
> However, the rules for interpreting the identities in
> <id> elements are left for each application to define separately.
> This document, however, does not define the rules for interpreting
> identities in <id> elements in conferencing applications
> since those
> interpretation rules are signalling protocol specific.
> "
> you might want to take a look at 3.1.1 of
> <draft-ietf-simple-presence-rules-00.txt>.

I originally had text in there, but I received comments saying that in XCON, we don't limit our selves to any particular signalling protocol and therefore will not add any text to a specific protocol such as sip and leave others out. Therefore it was decided to leave all text out. Do you think that this is not the right thing to do?

> - section talks about the <any> element to match
> any identity.
> you don't need this element since you can simply omit the
> identity field and
> achieve the same behavior.

But the <any> element refers to any identity, not any condition. Does leaving the <identity> element out imply any identity?

> - section talks about the <unauthenticated> element.
> why do you need to use this field? if

Some conferences need to allow unauthenticated users into the conference, or block them. The difference between unauthenticated and anonymous is that in the former, the conference focus does not know who they are. In the latter, the conference focus has authenticated the user, but the user requested anonymity from the conference.

> - section talks about 'Matching AnonymousIdentities'
> i would not place this element into the conditions section.
> this is rather
> an element for the transformation section. in geopriv we have
> something
> similar but for location information. here you would change
> the display of
> the identity to others in a conference.

You misunderstood this one. As stated above, this is needed to allow or block users from joining the conference depending on if they are anonymous or not.

We leave what you talk about to the signalling protocol. For example, in sip, a user can set the From-header field to anomymous@invalid or whatever.

> a confusion might be created with the <anonymous> element
> defined in 3.1.2
> of <draft-ietf-simple-presence-rules-00.txt> which has a
> different meaning.

Oh well :) I guess they are different documents.

> btw, i do not think that the behavior defined in 3.1.2 of
> <draft-ietf-simple-presence-rules-00.txt> is particularly useful.
> - section talks about the pin codes. i would
> suggest to move
> this functionality into the common-policy document.

I'll keep an eye out for a conclusion on this issue in geopriv.

> - section talks about 'Matching Passwords'.
> i would remove this element since it assumes that sip can
> carry username and
> password elements or you define your own authentication
> algorithm here. if a
> sip-based authentication algorithm with (username/password)
> is used then you
> can just match the authenticated identity.

We use password here much like the PIN above. For example, if a user knows the password, then he is allowed to join. His identity is irrelevant.

> - section talks about 'Authenticating a User'
> (<authenticate>
> element).
> we also discussed the inclusion of such an element in the
> geopriv area and
> finally dropped it due to the lack usefulness. the same was
> true for the
> presence authz document. it is really difficult to say
> something about a
> security level and it has very little benefit for an ordinary
> user. you can
> take a look at our discussions, if you want.

We need this since we have a requirement that a conference creator can decide the type of authentication needed for a user. You are right thought that the average user does not know. I'll bring it up during my presentation.

> - section to section talks about modifying some
> specific issues.
> i am not sure about the applicability of a meta-policy in the policy
> document. for example, section talks about 'Modifying
> Authorization rules' which is basically a meta - policy to
> modify the authz
> policies defined in the document.
> such a behavior should be specified in a separate document since it is
> generic to all authz policies: 'is an entity A allowed to modify the
> authorization policies of entity B?' for most cases it might
> be sufficient
> to say that the owner is authorized to modify its own document.

We have discussed this before. The conference policy needs to define who is allowed to make changes to the document. It was also agreed that the way this is defined is semantically and within the same document. Do you believe it is completely wrong to do it this way?

It is not viewed a entity A modifying entity B's document. It is viewed as entity A is modifying the conference policy, irrespective of who is the owner of the document in the directory.

> - a few things need to be fixed due to the change in the common-policy
> document.

Can you be more specific here? I haven't kept track of what changes were made to common-policy (besides the <uri> to <id> change.


> additionally i think it is necessary to investigate
> the combining
> permissions algorithm a little bit more.
> ciao
> hannes

Geopriv mailing list
Received on Mon, 26 Jul 2004 14:54:09 +0300

This archive was generated by hypermail 2.1.8 : Mon Jul 26 2004 - 07:58:29 EDT