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"