RE: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23
Comments inline as [ON2]. -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: 9. maaliskuuta 2011 21:39 To: Oscar Novo Cc: draft-ietf-xcon-common-data-model@tools.ietf.org; General Area Review Team; The IETF Subject: Re: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23 On Mar 9, 2011, at 6:01 AM, Oscar Novo wrote: Hi Ben, More comments inline as [ON1]. :) -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: 8. maaliskuuta 2011 23:14 To: Oscar Novo Cc: draft-ietf-xcon-common-data-model@tools.ietf.org; General Area Review Team; The IETF Subject: Re: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23 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:b...@estacado.net] Sent: 5. maaliskuuta 2011 0:46 To: draft-ietf-xcon-common-data-model@tools.ietf.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? [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:ji0...@example.com. A XCON-URI can be anything. However, I can remove the port if it's unclear. 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. [ON2] I can remove port from the XCON-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? [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
RE: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23
Hi Ben, More comments inline as [ON1]. :) -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: 8. maaliskuuta 2011 23:14 To: Oscar Novo Cc: draft-ietf-xcon-common-data-model@tools.ietf.org; General Area Review Team; The IETF Subject: Re: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23 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:b...@estacado.net] Sent: 5. maaliskuuta 2011 0:46 To: draft-ietf-xcon-common-data-model@tools.ietf.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? [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:ji0...@example.com. 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?) [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? [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. -- 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? [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. I'm concerned that user-admission-policy is a child of users, not user
RE: Gen-ART LC Review of draft-ietf-xcon-common-data-model-23
Hello Ben, Thanks for your comments. Answers to your comments inline. Oscar -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: 5. maaliskuuta 2011 0:46 To: draft-ietf-xcon-common-data-model@tools.ietf.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
