Hello Ben,
Thanks for your comments. Answers to your comments inline.
Oscar
-----Original Message-----
From: Ben Campbell [mailto:ben(_at_)estacado(_dot_)net]
Sent: 5. maaliskuuta 2011 0:46
To: draft-ietf-xcon-common-data-model(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: General Area Review Team; The IETF
Subject: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23
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.
[ON] The XML and examples has been verified by other reviewers.
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?
[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:
Are two users with the same signaling protocol allowed to have different authn
mechanisms?
[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:
What if the user is using a protocol that doesn't use URIs?
[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.
-- 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?
[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."
This also needs elaboration, even if the way permission systems work is out of
scope.
[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:
I'm having trouble imagining what a role of "none" might mean.
[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:
It seems like some comments on protecting anonymity of anonymous users would be
worth a mention here.
[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.
-- 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?
[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.
"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?
[ON] Sidebars manipulation are described in RFC5239, section 9.4
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.
[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:
It might be nice to have a paragraph defining what you mean by "conference"
before jumping into conference attributes.
[ON] The definition of conference is already defined in RFC5239 section 4.
-- section 1, 2nd paragraph: "follow the XML format"
Odd choice of words. Do you mean "use" or "are incoded in" the format?
[ON] Right, I'll change it to "use"
-- 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.
[ON] XCON-URI is not an acronym
-- section 4.2.1: "This element is not enforcing..."
... does not enforce...
[ON] Right
-- 4.2.13, 6th bullet: "It is expected..."
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."
"it is recommended that an extension to the data model be used."
Is that intended as a normative RECOMMENDED?
[ON] Right, I can change that to a normative RECOMMENDED.
-- 4.6, 1st paragraph: "...because this attribute only applies to notifications
mechanism."
Plural mismatch
[ON] true
-- 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.
[ON] That paragraph was an AD review proposal:
http://www.ietf.org/mail-archive/web/xcon/current/msg02495.html
-- 4.6.3:
Note that allowed-users-list and deny-user-list have inconsistent tense
(allowed vs deny)
[ON] yes
-- 5, 2nd paragraph: "the [RFC5239]" (2 occurrences)
Superfluous "the"
[ON] right
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf