Hi, thanks for the quick response. More comments inline. I've deleted any
sections on which I think we are in agreement.
On Mar 7, 2011, at 6:07 AM, Oscar Novo wrote:
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.
[...]
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.
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?
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.
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?
-- 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.
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?
-- 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.
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?
-- 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.
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.
"'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.
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)
--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
A comment to that effect in the text would be helpful.
-- 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.
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.
-- 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.
Really? Can you give an example where it's safe to ignore confidentiality of
_passwords_?
"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
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.
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?
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.
-- 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.
Sure, but it would be reader friendly to have a sentence describing it here.
I'm not talking about a detailed description.
[...]
-- 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
Hmm. It doesn't stand for "Centralized Conferencing - Universal Resource
Identifier"?
[...]
-- 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."
Still, "It is expected" by whom?
Maybe just say "These controls are sufficient for the majority of basic
conferences."?
[...]
-- 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
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..."
[...]
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf