Subject: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23

From: Ben Campbell <[email-masked]>
Date: Fri, 4 Mar 2011 16:45:44 -0600

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-xcon-common-data-model-23
Reviewer: Ben Campbell
Review Date: 2011-03-04
IETF LC End Date: 2011-03-04
IESG Telechat date: (if known)

Summary: This draft is almost ready for publication as a proposed standard. I have a few minor comments that should be considered prior to publication.

Note: This draft makes extensive and fairly complex use of XML. I have not attempted to verify the schema, examples, etc. Hopefully these have been mechanically verified. I have been given to understand that this draft will undergo (or has undergone) an XML expert review--I concur that this is a good idea.

Major issues:

None

Minor issues:

-- section 3.3.1: "XCON-URI can not be resolved to addresses and/or ports."

Then why does it include a port in the ABNF? Also,  can "host" be an IP address? If so, does that change the comparison rules? (i.e. 192.168.0.1 vs 192.168.000.001, suppression of zeros in an IPv6 address, etc?) 

-- 4.6.2, 1st paragraph:

Are two users with the same signaling protocol allowed to have different authn mechanisms?

-- 4.6.3, 1st paragraph:

What if the user is using a protocol that doesn't use URIs?

-- 4.6.5.3: "The real information about the user is still stored in the data model."

This could use some elaboration. Does this mean that clients subscribing to the event package will get the real data, but be expected to conceal it from the user? Or that the data is only stored internally by the focus and not sent to subscribers? 

"’semi-private’ value specifies that this user is anonymous to all users with equal or lesser permissions (determined by local policy) in the conference."

This also needs elaboration, even if the way permission systems work is out of scope.

--4.6.5.3: 

I'm having trouble imagining what a role of "none" might mean.

-- 8, general:

It seems like some comments on protecting anonymity of anonymous users would be worth a mention here.

-- 8, paragraph 6: "The confidentiality of the database SHOULD be unauthorized users, given that the data model sensitive elements (e.g., passwords)."

Confidentiality of a database containing passwords only rates a SHOULD?

"Administrators of conferencing systems SHOULD also avoid disclosing information to unauthorized parties when a conference is being cloned or when a sidebar is being created."

This could use elaboration. Why is creating a sidebar more dangerous than other operations not mentioned here?

Nits/editorial comments:

-- general:  Please put vertical white space between bullet list entries. Otherwise, the resulting walls of text become very hard to track visually.

-- Section 1: 

It might be nice to have a paragraph defining what you mean by "conference" before jumping into conference attributes.

-- section 1, 2nd paragraph: "follow the XML format"

Odd choice of words. Do you mean "use" or "are incoded in" the format?

-- section 3.3, first paragraph after the diagram:

is XCON-URI intended to be an acronym? If so, you describe it as a "unique conference object identifier", but never actually expand the acronym itself.

-- section 4.2.1: "This element is not enforcing..."

... does not enforce...

-- 4.2.13, 6th bullet:  "It is expected..."

Who expects it?

"it is recommended that an extension to the data model be used."

Is that intended as a normative RECOMMENDED?

-- 4.6, 1st paragraph: "...because this attribute only applies to notifications mechanism."

Plural mismatch

-- 4.6.2, last paragraph: "In all other cases, the appearance of an <allowed-users-list> and <deny-users-list> MUST be ignored."

What other cases? I assume you don't mean to say that any extensions are prohibited from using allowed-user-list or deny-user-list--but one can read it to mean that.

-- 4.6.3:

Note that allowed-users-list and deny-user-list have inconsistent tense (allowed vs deny)

-- 5, 2nd paragraph: "the [RFC5239]" (2 occurrences)

Superfluous "the"

---

From: Oscar Novo <[email-masked]>
Date: Mon, 7 Mar 2011 13:07:16 +0100

Hello Ben,

Thanks for your comments. Answers to your comments inline.

Oscar

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: 5. maaliskuuta 2011 0:46
To: [email-masked]
Cc: General Area Review Team; The IETF
Subject: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23

[ON] The XML and examples has been verified by other reviewers.  

Major issues:

None

Minor issues:

Then why does it include a port in the ABNF? 

[ON] Note that URIs can not be resolved to addresses and then to ports. That's why we state it very clear in the document that this isn't the case. Besides that, an XCON-URI can be viewed as a key to access a specific conference object. So, having a direct mapping to a URL can be useful some times for some conferences.

Also,  can "host" be an IP address? If so, does that change the comparison rules? (i.e. 192.168.0.1 vs 192.168.000.001, suppression of zeros in an IPv6 address, etc?) 

[ON]I'm not an URI expert. Ted Hardie was the person in charge to review and verify the URIs of the document. For your question I would recommend you to read  RFC3986 section 6.1. 

-- 4.6.2, 1st paragraph:

[ON] Answering that question is out of the scope of this document. The Conference Control Protocol and/or RFC5239 (for instance section 11.1) should answer this question. 

-- 4.6.3, 1st paragraph:

[ON] This section talks about the SIP URI or the xcon-userid URI defined in Section 4.6.5. The xcon-userid contains a unique conference user identifier (XCON-USERID) within the scope of the conference. This URI will always exist within the scope of the conference.

[ON] The data model specifies a set of elements for different use cases in every conference system. That doesn't imply all the elements has to be defined in every conference, only those elements needed for every conference system. RFC5239 section 11.2 explains a bit about the privacy concept in a conference.

"'semi-private' value specifies that this user is anonymous to all users with equal or lesser permissions (determined by local policy) in the conference."

[ON] what information you think is missing in this sentence? Note that the WG agree on not defining the local policy (roles semantic, permissions...) in this document.

--4.6.5.3: 

[ON]A role of "none" indicates that any role is assigned; It was a WG resolution: 

	http://www.ietf.org/mail-archive/web/xcon/current/msg02102.html

-- 8, general:

[ON] The data model is part of the RFC5239 and this RFC is already handling quite well anonymity. We rather want to repeat information in the data model.  

[ON] It might be the case in some particular scenarios where the confidentiality can be ignored. For this reason, we decided not to impose confidentiality (using SHOULD instead of MUST) in the document and to leave that decision to the administrator of the conference.

[ON] Sidebars manipulation are described in RFC5239, section 9.4

Nits/editorial comments:

[ON] vertical whitespace? What do you mean? I'm already using spaces between every bullet and the text. Do you mean to leave spaces between the bullets?

-- Section 1: 

[ON] The definition of conference is already defined in RFC5239 section 4.

[ON] Right, I'll change it to "use"

[ON] XCON-URI is not an acronym 

... does not enforce...

[ON] Right

Who expects it?

[ON] Shall I rephrase it to:

[ON]"It is expected that these controls are sufficient for the majority of the basic conferences."

[ON] Right, I can change that to a normative RECOMMENDED.

Plural mismatch

[ON] true

[ON] That paragraph was an AD review proposal:

	http://www.ietf.org/mail-archive/web/xcon/current/msg02495.html

-- 4.6.3:

[ON] yes

Superfluous "the" 

[ON] right

---

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Mar 2011 15:13:38 -0600

Hi, thanks for the quick response. More comments inline. I've deleted any sections on which I think we are in agreement.

> Summary: This draft is almost ready for publication as a proposed standard. I have a few minor comments that should be considered prior to publication.

[...]

> [ON] Note that URIs can not be resolved to addresses and then to ports. That's why we state it very clear in the document that this isn't the case. Besides that, an XCON-URI can be viewed as a key…

I understand that it doesn't map to a port. But I don't understand why you would include a "port" construction in a URI that can't map to a port. Actually, to generalize, I don't understand why one would use "host" either, since that construction is designed to carry addressing material, either in the form of a DNS name or an IPv4 or v6 address.

What do you mean by "direct mapping to a URL?" Do you expect to contruct an XCON URI from, say, a SIP URI?

> [ON]I'm not an URI expert. Ted Hardie was the person in charge to review and verify the URIs of the document. For your question I would recommend you to read  RFC3986 section 6.1. 

3986 says "string comparison, perhaps augmented by reference to additional rules
   provided by URI scheme definitions."

My point is that if you are really using the host and port constructions, they need some of those additional rules.  Certainly, 2 host:port constructions that match character for character are equivilent--but there's a number of ways host:port can be equivalent when it _doesn't_ match character for character. And that's not even counting aliasing--I'm talking about strict syntactic equivalence.

Wouldn't it better to just use some sort of string contruction (perhaps "unreserved") that would allow you to put something in it that looks like host:port, but without the meaning usually associated with those?

Was this concern discussed in Ted's review? If so, do you have a pointer to it?

> [ON] Answering that question is out of the scope of this document. The Conference Control Protocol and/or RFC5239 (for instance section 11.1) should answer this question. 

My question is whether the data model allows it. Why wouldn't that be in scope? 

I'm concerned that <user-admission-policy> is a child of <users>, not <user>, so it looks like all the <user> elements with the same <users> parent must share the same admission policy. Am I misreading that? If not, how would you render multiple policies in the same conference?

> [ON] This section talks about the SIP URI or the xcon-userid URI defined in Section 4.6.5. The xcon-userid contains a unique conference user identifier (XCON-USERID) within the scope of the confere…

It lists SIP URIs and XCON-USERID URIs as examples. Are you limited to those schemes? What if someone is using XMPP for their signaling protocol--are they excluded since XMPP does not use URIs?

> [ON] The data model specifies a set of elements for different use cases in every conference system. That doesn't imply all the elements has to be defined in every conference, only those elements ne…

My question wasn't whether they are used for a particular conference. It's more about how the data is protected when it is used by a conference. In particular, the text says this affects the way the data is provided to other participants. _How_ it effects it needs more detail.

I think that you mean that the focus should not provide the data to participating clients. _Not_ that said clients can be expected to conceal it from their users. This should be explicit either here or in the security considerations.

If you think RFC 5239 explains this, then a reference to it would be in order. I think it helps a bit, but I think you could use some stronger and more explicit language here.

> [ON] what information you think is missing in this sentence? Note that the WG agree on not defining the local policy (roles semantic, permissions...) in this document.

What do you mean, in abstract, by "equal or lesser" permissions? That implies some assumptions about how permissions work, even though they are explicitly out of scope. Equal or lesser to what? Why assume permissions are hierarchical in the first place? Is it simply that the information should only be provided to users who have permission to see it? (a much simpler statement with fewer assumptions about how permissions work)

A comment to that effect in the text would be helpful.

> [ON] The data model is part of the RFC5239 and this RFC is already handling quite well anonymity. We rather want to repeat information in the data model.  

See my previous comment above. I think you need more _somewhere_.  At least, some explicit references to specific passages in 5239 that are relevant to anonymity.

I push on this, because anonymity is an area often gotten wrong by implementors and protocol designers. It warrants careful attention.

> [ON] It might be the case in some particular scenarios where the confidentiality can be ignored. For this reason, we decided not to impose confidentiality (using SHOULD instead of MUST) in the docu…

Really? Can you give an example where it's safe to ignore confidentiality of _passwords_?

> [ON] Sidebars manipulation are described in RFC5239, section 9.4

If you think that answers the question, then a reference would be in order. But on a quick scan, I don't see where that section explicitly discusses security risks in creating sidebars. 

> [ON] vertical whitespace? What do you mean? I'm already using spaces between every bullet and the text. Do you mean to leave spaces between the bullets?

You have _horizontal_ white space between a bullet and the text within a particular list entry. You do not have _vertical_ white space (i.e. blank lines) between entries.

See http://www.rfc-editor.org/rfc-style-guide/rfc-style section 3.1.

> [ON] The definition of conference is already defined in RFC5239 section 4.

Sure, but it would be reader friendly to have a sentence describing it here. I'm not talking about a detailed description.

[...]

> [ON] XCON-URI is not an acronym 

Hmm. It doesn't  stand for "Centralized Conferencing - Universal Resource Identifier"?

[...]

> [ON]"It is expected that these controls are sufficient for the majority of the basic conferences."

Still, "It is expected" by whom?

Maybe just say "These controls are sufficient for the majority of basic conferences."?

[...]

> 	http://www.ietf.org/mail-archive/web/xcon/current/msg02495.html

With all due respect to Robert, I think the current text is unclear. I interpret "All other cases" to mean "All cases except for those enumerated above". That is, all cases other than the one it's talked about so far.  The text goes on to say some things about future extensions--which seems to contradict the first sentence. I think you mean to say that, except in the case where a future specification gives guidance otherwise, all other cases MUST be ignored.

One simple fix would be to move the first sentence to the end of the paragraph. Something to the effect of:

"Future specifications using the <allowed-users-list> and <deny-users-list>  lists must provide clear guidance... .  In all other cases, the appearance of an <allowed-users-list> and <deny-users-list> MUST be ignored."

Another approach would be to say "All other cases... MUST be ignored, except as stated otherwise in a future specification describing..."

[...]

---

From: Oscar Novo <[email-masked]>
Date: Wed, 9 Mar 2011 13:01:23 +0100

Hi Ben,

 More comments inline as [ON1]. :)

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: 8. maaliskuuta 2011 23:14
To: Oscar Novo
Cc: [email-masked]; General Area Review Team; The IETF
Subject: Re: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23

[...]

[ON1] Ben, I think the XCON-URI identifier is unclear to you. I recommend you to read section 3.3 of my document. A XCON-URI identifier is created by the conference system and maintains a relationship between all the conference object identifiers in the conference. Figure 2 of my document shows an example and, in that case, the XCON-URI is a host identifier: xcon:[email-masked]. A XCON-URI can be anything. However, I can remove the port if it's unclear.

>
>
> Also,  can "host" be an IP address? If so, does that change the
> comparison rules? (i.e. 192.168.0.1 vs 192.168.000.001, suppression of
> zeros in an IPv6 address, etc?)
>

[ON1] From RFC3986 section 6.1: "comparison methods are designed to minimize false negatives while strictly avoiding false positives."
Ted's agreed on the text mention in the document. He's an URI expert.

[ON1] From section 4.6.2 of the document: " Since a variety of signaling protocols are possible, a variety of authentication mechanism - determined by every individual conference servers - may need to be mapped from the different protocols. The specific types of authentication mechanism are beyond the scope of this document."

[ON1] You render multiple policies using the <allowed-users-list> and <deny-users-list> elements. The <user-admission-policy> only lets the organizer to choose the policy of the whole conference: closedAuthentication, openAuthentication...

[ON1] A XCON-USERID is a unique conference user identifier assigned by the conference system. It's explained in the section 4.6.5 of the document. If there is an XMPP signaling protocol, such XMPP identifier will be mapped to the XCON-USERID.

[ON1]  What about modifying the text from:

"This element only affects the way the user information is provided to the other participants. The real information about the user is still stored in the data model."

To:

"This element only affects the way the user information is provided to the other participants. The real user information is stored in the data model but is not provide to the other participants of the conference."

[ON1] So, what I meant with the "equal or lesser" is something like: "a semi-private value implies a root role is anonymous to a user role". Since the WG decided not to include the different roles and policies in this document, we have to leave it as an abstract concept and every local policy will define it as they think its appropriate.

[ON1] I can add it to the document.

[ON1] I can add the RFC5239, section 11.2 reference in this part of the text.

[ON1] There are conference which don't define any password and any sensitive information. Providing confidentiality at a conference may seem strange or counterproductive sometimes, especially these days where event sessions are routinely streamed and videoed for anyone who wants to watch.

[ON1] For instance, RFC5239, section 9.4.2 is talking about the external sidebars. In those sidebars, users -which are external to the conference - are *joining* the conference. Disclosing information to those unauthorized users is essential. That's just an example.
The data model describes the data of the conference objects which are described in RFC5239. So, the data model is *complementing* RFC5239. The aim of the data model is not to repeat the information already written in RFC5239 rather than defining the missing information.

[ON1] got it. I can add vertical white spaces between bullets.

[...]

[ON1] The terminology part of the document states:

"This document uses the terminology defined in the Centralized
   Conferencing Framework [RFC5239], the SIPPING conferencing framework
   [RFC4353] and the BFCP (Binary Floor Control Protocol) specification
   [RFC4582].  Readers of this document should be familiar with the
   terminology used in those documents."

[...]

[ON1] XCON-URI is a conference object Identifier.

[...]

[ON1] Right, I'll add it to the document.

[...]

[ON1] I recommend you to talk with Robert about your proposed change. If he accepts this change I'll modify my document. Otherwise, I will stick to the AD proposal.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 9 Mar 2011 13:38:45 -0600

> [ON1] Ben, I think the XCON-URI identifier is unclear to you. I recommend you to read section 3.3 of my document. A XCON-URI identifier is created by the conference system and maintains a relations…

I think it would be best to remove "port" unless you have a concrete reason to include it. I assume there must have been one at one time, but it's not apparent to me from the text, or the discussion so far.

> [ON1] From RFC3986 section 6.1: "comparison methods are designed to minimize false negatives while strictly avoiding false positives."

3986 does not mandate that all URI schemes use a character by character comparison. It lists that as a minimum choice. It also suggests that each scheme will have it's own additional rules.

My issue with "host" is that there's a lot of implied baggage there. Host can be an literal IP address  (IPv6, IPv4, IPvFuture, a name, etc.) For some of these, a character comparison may not yield the results that an implementor would intuitively expect. "Host" can include internationalized domain names--and that _really_ throws a kink into comparisons. Furthermore, implementors are likely to already have libraries that they think "just do the right thing" with the "host" syntax--but that right thing may be exactly the wrong thing for XCON-URIs

I don't think that necessarily means you shouldn't use "host". But it would probably be worth adding a non-normative note (perhaps as an indented parenthetical note) pointing out that the character comparison rule may not always match the the usual comparison expectations for certain kinds of content, and giving an example or two. (For example, 192.168.0.1 vs 192.168.000.001).

OTOH, a simpler alternative (from the reader's perspective) would be to just define some sort of string-token construction that uses the correct characters, but doesn't that the "address semantics" baggage of "host".

> Ted's agreed on the text mention in the document. He's an URI expert.

I certainly can't dispute Ted's expertise here, but did he offer a rationale for his agreement?

> [ON1] You render multiple policies using the <allowed-users-list> and <deny-users-list> elements. The <user-admission-policy> only lets the organizer to choose the policy of the whole conference: c…

So you would never have "closedAuthenticated" for one set of users and "openAutenticated" for another set for the same conference, right? If so, then I think the text is okay here.

> [ON1] A XCON-USERID is a unique conference user identifier assigned by the conference system. It's explained in the section 4.6.5 of the document. If there is an XMPP signaling protocol, such XMPP…

The first paragraph in 4.6.3 says "The <allowed-users-list> child element contains a list of user URIs (e.g.  SIP URI, xcon-userid...)

This led me to believe you meant to allow signaling protocol URIs, since SIP was mentioned. Did you mean that to really be limited to XCON URIs? When I read further down, I see the <user> child element seems to be limited to using XCON-USERID, so this seems to be the case. If that is correct, then simply removing the reference to SIP URIs in 1st paragraph of 4.6.3 would seem to fix things.

> "This element only affects the way the user information is provided to the other participants. The real user information is stored in the data model but is not provide to the other participants of…

My concern was what is meant by "is not provided" at a protocol level. But on reflection, that probably doesn't belong here. OTOH, should that be a normative "SHOULD not be provided"?

> [ON1] So, what I meant with the "equal or lesser" is something like: "a semi-private value implies a root role is anonymous to a user role". Since the WG decided not to include the different roles…

Not all systems use "root" and "user" as the permissions model. So how about removing the whole idea of "greater" and "lesser", and say something to the effect of "... anonymous to all users who have not been granted permission to see it"

[...]
> [ON1] There are conference which don't define any password and any sensitive information. Providing confidentiality at a conference may seem strange or counterproductive sometimes, especially these…

Okay.

> The data model describes the data of the conference objects which are described in RFC5239. So, the data model is *complementing* RFC5239. The aim of the data model is not to repeat the information…

I'm not suggesting you recreate the definition of sidebars here. I'm suggesting you explain the security consideration that you already mention. For example, an additional sentence to the effect of "For example, an external sidebar as defined in [RFC5239], section 9.4.2, may include participants who were not authorized for the parent conference."

[...]

>   terminology used in those documents."

While I expect a reader has to be familiar with 5239 to get much use of this draft, it would still be more friendly to the reader if they can at least get a sense of what this document is about prior to digging into the references. All I am asking for is a sentence to the effect of the following: 

 "[RFC5239] defines the idea of a centralized conference as an association of participants with a central focus. The state of a conference is represented by a conference object. This document describes the data model to be used for conference objects."

> [ON1] XCON-URI is a conference object Identifier.

That's the definition, not the expansion. But I think we've spent too much effort on this one already. I'd leave it to the RFC editor at this point.

[...]

> [ON1] I recommend you to talk with Robert about your proposed change. If he accepts this change I'll modify my document. Otherwise, I will stick to the AD proposal.

I talked to Robert offline. We came to the conclusion that my second example above is the best choice. Here's a complete example:

"In all other cases, the appearance of an <allowed-users-list> and <deny-users-list> MUST be ignored, except as otherwise described in a future specification.   Future specifications describing the use of these lists must provide clear guidance on how to process the lists when they occur concurrently, especially when both lists contain the same user."

---

From: Oscar Novo <[email-masked]>
Date: Thu, 10 Mar 2011 10:23:51 +0100

Comments inline as [ON2].

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: 9. maaliskuuta 2011 21:39
To: Oscar Novo
Cc: [email-masked]; General Area Review Team; The IETF
Subject: Re: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23

[ON2] I can remove port from the XCON-URI

>> comparison rules? (i.e. 192.168.0.1 vs 192.168.000.001, suppression
>> of zeros in an IPv6 address, etc?)
>>

[ON2] I'm not an URI expertise. So, I suggest you to talk with Ted Hardie about this issue. Please, come back to me with the outcome of that discussion.

[ON2] OK

[ON2] OK

[ON2] OK

> What do you mean, in abstract, by "equal or lesser" permissions? That
> implies some assumptions about how permissions work, even though they
> are explicitly out of scope. Equal or lesser to what? Why assume
> permissions are hierarchical in the first place? Is it simply that the
> information should only be provided to users who have permission to
> see it? (a much simpler statement with fewer assumptions about how
> permissions work)
>

[ON2] I know not all systems use root or users. That was just an example to explain you the use of equal or lesser. I'll add your text to the document anyway.

[...]

Okay.

[ON2] OK
[...]

[ON2] OK

[...]

[ON2] OK

[ON2] OK