From nobody Mon Apr 11 16:23:18 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D65112F622 for ; Mon, 11 Apr 2016 16:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=KZoi3WDs; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=T/tuMrYS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZ8O_vWb8zdk for ; Mon, 11 Apr 2016 16:23:15 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E1112F623 for ; Mon, 11 Apr 2016 16:23:15 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 02D5021B2B for ; Mon, 11 Apr 2016 19:23:14 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Mon, 11 Apr 2016 19:23:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=iY5yjWqkV+6LZNSheaBKxc9ZoKY=; b=KZoi3W DsI53i5pqiL6WN4/sx4lcwcPij8XeJ+u1K9wEFdZE8yEIWS+Tmn+ImQxTQx9iMsD Q7zqAAe0NXFKi+xg5IIgL/umce3OT9UsaHbIhUdWBo00zbR374R9RWBuVQMBpLE1 2o7ZehhtmVn/ZyvJrEKk9/ohS8o9Tx33aLjO8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=iY5yjWqkV+6LZNS heaBKxc9ZoKY=; b=T/tuMrYS9+Y2oOXuqzyGK565tUfSZ5Bi8GWYx/g+hgCuQR/ sj2tggfMWomM0EiQopI9PQc+9ScDuJF7CQ317d0lIwxz4JK56kTADLaTnry/shJU cojz96qYDtR3SU0fa47YbX43LbxHVC0pVHAFm9KeF0ZSmOnKgc1Xmo5ryzM0= X-Sasl-enc: /w++OsG0lAFwdRCs83/3BL1TFK79W6ELAd+8xFCUFLmJ 1460416993 Received: from dhcp-171-68-20-149.cisco.com (dhcp-171-68-20-149.cisco.com [171.68.20.149]) by mail.messagingengine.com (Postfix) with ESMTPA id 4B9DFC00014; Mon, 11 Apr 2016 19:23:13 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <78D5A005-8364-4DD1-974D-6689C8F9205E@unina.it> Date: Mon, 11 Apr 2016 16:23:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <142C7249-4732-4066-8A58-F28DD5C25A05@cooperw.in> References: <09019183-3B33-4BF5-8646-207F000E6B17@cooperw.in> <78D5A005-8364-4DD1-974D-6689C8F9205E@unina.it> To: Simon Pietro Romano X-Mailer: Apple Mail (2.3112) Archived-At: Cc: clue@ietf.org Subject: Re: [clue] AD review: draft-ietf-clue-data-model-schema-12 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 23:23:17 -0000 Hi Simon, Thanks. I=E2=80=99ve reviewed the -13. Some responses below. > On Mar 7, 2016, at 11:42 AM, Simon Pietro Romano = wrote: >=20 >> (3) I think the explanation of each of the extensibility points in = the document needs to be clearer. Some of the elements are extensible = when I wouldn=E2=80=99t have expected them to be, and the document often = doesn=E2=80=99t explain why the model=E2=80=99s extensibility is being = specified as it is. For example, it=E2=80=99s not clear to me why the = content type or the capture scene type are extensible, and there=E2=80=99s= no explanation provided. For other types I can intuit why they are = extensible, but it would help to make it explicit.=20 >=20 > We wanted to offer people enough flexibility as to define custom (and = perhaps currently unforeseen) extensions to the schema, without losing = compliance with the standard. We did this by leveraging = elemenrts and attributes, which is a common approach = with schemas, still matching the UPA (Unique Particle Attribution) = Constraint. The "XML Schema extensibility=E2=80=9D section was meant to = illustrate the mentioned approach. >=20 >> (4) Furthermore, this data model seems to err way on the side of = extensibility, leaving me to wonder just how much it will really = facilitate interoperability. I think the trade-offs the WG is making = here need to be thoroughly justified in the text.=20 >=20 > See my answer above to your comment number (3). What would you suggest = to improve the way we deal with extensibility? I think it would help to state in Section 14 that extensibility was = purposefully favored as much as possible based on expectations about = custom implementations.=20 >=20 >=20 >> =3D Section 3 =3D >>=20 >> CLUE consists of a small number of tightly coordinated specs. Why is = this spec not using the definition of "CLUE Participant=E2=80=9D from = the Framework doc? What was the point of defining it the way it=E2=80=99s = defined in the framework doc if it can=E2=80=99t be used in the schema?=20= >=20 > The CLUE Framework doc does not actually include a definition of the = "CLUE Participant=E2=80=9D. It rather introduces the =E2=80=9CCLUE = Endpoint=E2=80=9D, consisting of =E2=80=9C...of one or more physical = devices...and exactly one [RFC4353] Participant (which, in turn, = includes exactly one SIP User Agent)=E2=80=9D. What we needed in the = data model doc was a definition as simple as =E2=80=9C...a generic = entity (either an Endpoint or a MCU) making use of the CLUE protocol=E2=80= =9D. Such a definition does not match the =E2=80=9CCLUE Endpoint=E2=80=9D = of the framework and cannot even be replaced by the RFC4353 definition. = Indeed, in the most general case, a CLUE Participant might even not use = SIP at all. That=E2=80=99s why we took a freedom to put this (and only = this) new definition in the data model document. Ok. >=20 >> And why is it stated differently than how it=E2=80=99s stated in the = protocol doc? >=20 > They are (or at least should be) indeed identical. I checked version = -06 of the protocol and version -12 of the data model and found the = following: >=20 > - Protocol: >=20 > CLUE Participant (CP): An entity able to use the CLUE protocol within = a telepresence session. It can be an endpoint or an MCU able to use the = CLUE protocol. >=20 > - Data Model: >=20 > This term is not imported from the framework terminology. A CLUE = Participant identifies a generic entity (either an Endpoint or a MCU) = making use of the CLUE protocol. >=20 > If we decide that such a definition can survive, we might proceed as = follows: (i) introduce it in the protocol draft; (ii) point to it in the = data model draft. What=E2=80=99s your feeling about that? Good idea. >=20 >>=20 >> =3D Section 11.2 =3D >>=20 >> "Common values are "audio", "video", >> "text". Other values can be provided. It is assumed that >> implementations agree on the interpretation of those other values.=E2=80= =9D >>=20 >> This seems like an interop problem waiting to happen, since there is = no registry specified for these values. Why not create one so that = independent implementers can at least know what other values may be = supported by other implementations? >=20 > I=E2=80=99m not sure I understand this point correctly. The idea here = was to be as generic as possible. That=E2=80=99s why: (i) the basic = media capture type is an abstract one; (ii) =E2=80=9Cconcrete=E2=80=9D = definitions for audio, video and text capture types have been specified; Referencing the registry as Roni suggested would help. > (iii) a 100% generic =E2=80=9CotherCaptureType=E2=80=9D type has been = defined; (iv) the =E2=80=9CmediaType=E2=80=9D attribute has been = generically defined as a string, with no particular template. >=20 > That=E2=80=99s why we assume that if one chooses to rely on a brand = new media type and wants to interoperate with others, an = (application-level) agreement is needed on how to interpret such = information. If I=E2=80=99m an implementer and I want to start using some new media = type, it would be helpful for me to know if there are already other = implementations out there using that media type name before I decide = whether I want to risk collisions with however the attribute is already = being interpreted, or whether I want to name mine something different = and go negotiate what its interpretation should be. Not a huge deal and = we can see if anyone else raises this in IETF LC or IESG review, but = just an example where it seems like there could be a significant barrier = to achieving interop if people decide to use this extension point. >=20 >=20 >> (2) >> Same comment as section 11.2. >>=20 >> =3D Section 11.18 and 11.19 =3D >>=20 >> The text says =E2=80=9CThe current possible values are =E2=80=A6=E2=80=9D= =E2=80=94 is there a plan to add more values? (I note this is different = from the personType definition, which doesn=E2=80=99t say = =E2=80=9Ccurrent.=E2=80=9D) >=20 > These are actually consistent, respectively, with section 7.1.1.7. = (Presentation) and section 7.1.1.8. (View) of the framework document. Ok. >=20 >=20 >> =3D Section 11.23 =3D >>=20 >> "When defining new media capture types that are going to be described >> by means of the element, spatial properties of >> such new media capture types SHOULD be defined (e.g., whether or not >> they are spatially definable, whether or not they should be >> associated with an area of capture, etc.).=E2=80=9D >>=20 >> Are there other spatial properties that should be defined besides the = two that are listed? If this is going to be a normative requirement, the = list should be precise. >=20 > What we wanted to state here is that a new media capture might require = the definition of spatial properties. In such a case, the = element would be present and would contain (at = least) either the capture origin, or the capture area, or both. The list = is not exhaustive, since, like all other pieces of information in the = schema, further elements and attributes can be added if needed = (extensibility). Ok, I think you need something like s/etc./or other properties that may be defined/ >=20 >> =3D Section 11.27.2 =3D >>=20 >> Why is the media type attribute optional? >=20 > If the simultaneous set contains references to media captures, than = you don=E2=80=99t need to specify the media type, since it is a = mandatory attribute for each (referenced) media capture. On the other = hand, as the last part of the paragraph explains, if you only use = capture scene identifiers, than you=E2=80=99ll necessarily need to = indicate the media type associated with the media captures belonging to = the set in question and which can be sent simultaneously. Ok, Mark=E2=80=99s explanation helped with this. >=20 >> =3D Section 15 =3D >>=20 >> (1) What does =E2=80=9Cfull-optional=E2=80=9D mean? >=20 > Nothing meaningful, indeed :-). We meant something like = "full-fledged=E2=80=9D, =E2=80=9Cthoroughly specified=E2=80=9D, or = similar. What would you suggest here? Either of those would work. >=20 >=20 >> (2) "Data model information carried within CLUE messages SHOULD be = accessed only by authenticated endpoints.=E2=80=9D The exception cases = to this recommendation should be described. >=20 > We tried to highlight the fact that authenticated access is strongly = advisable, especially if you convey information about individuals = () and/or scenes (). There might be more = exceptions, depending on the level of criticality that is associated = with the setup and configuration of a specific session. In principle, = one might even decide that no protection at all is needed for a = particular session; that=E2=80=99s why we did not make this a MUST. Ok, please add some text to explain what you explain above. Thanks, Alissa >=20 >=20 >>=20 >> =3D Section 29 =3D >>=20 >> The references are not split between normative and informative. It = seems to me that only RFC 3550, RFC 3688, RFC 4353, and RFC 7667 should = be informative references. The rest should be normative. >=20 > Agreed. >=20 >> Nits: >>=20 >> =3D General =3D >>=20 >> (1) For the ID elements, I think it would help to specify the scope = within which the IDs are expected to be unique (e.g., within the = advertisement, or more narrowly). >=20 > XML ID elements are defined in W3C terms, which means that: (i) the = value is unique within the XML document; (ii) each element has at most = one single unique identifier. When we wanted to relax such a constraint, = we defined the =E2=80=9CiD=E2=80=9D as a string. >=20 >> =3D Section 11.1 =3D >>=20 >> s/(e.g., simultaneous sets, capture encodings, and others)/(e.g., = simultaneous sets, capture encodings, and others via ) >=20 > Done. >=20 >> =3D Section 11.7 =3D >>=20 >> s/last ones/latter ones/ >=20 > Done. >=20 >> =3D Section 11.29.1.2 =3D >>=20 >> I think this section should point to Appendix A in the ecrit = document. >=20 > Done. >=20 > Thanks again for your feedback and comments! >=20 > Simon >=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >=20 From nobody Tue Apr 19 11:07:45 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580E812D6E1 for ; Tue, 19 Apr 2016 11:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KW1Y20inP9fL for ; Tue, 19 Apr 2016 11:07:41 -0700 (PDT) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1E312DD27 for ; Tue, 19 Apr 2016 11:07:40 -0700 (PDT) X-AuditID: 1207440e-f07ff700000008c5-b3-571673ebf2f5 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id 35.63.02245.BE376175; Tue, 19 Apr 2016 14:07:39 -0400 (EDT) Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u3JI7dto012556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 19 Apr 2016 14:07:39 -0400 From: Paul Kyzivat To: CLUE Message-ID: <571673E9.4050005@alum.mit.edu> Date: Tue, 19 Apr 2016 14:07:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPIsWRmVeSWpSXmKPExsUixO6iqPumWCzc4O8cTov9py4zOzB6LFny kymAMYrbJimxpCw4Mz1P3y6BO+Pwsw1MBTO5Kv6ufcHYwDiVo4uRk0NCwETi3okOli5GLg4h ga2MEj8a7rBBOD+ZJL6+/M8IUsUmoCUx59B/FhBbWMBK4uKpx2wgtoiAhMSpU3fBangFtCUm /NnEDmKzCKhKLNp5BKxGVCBN4lvPQhaIGkGJkzOfgNnMAmYS8zY/ZIaw5SW2v53DPIGRZxaS sllIymYhKVvAyLyKUS4xpzRXNzcxM6c4NVm3ODkxLy+1SNdYLzezRC81pXQTIyRw+HYwtq+X OcQowMGoxMMbUCAaLsSaWFZcmXuIUZKDSUmU1woYdkJ8SfkplRmJxRnxRaU5qcWHGCU4mJVE eFVBcrwpiZVVqUX5MClpDhYlcV61Jep+QgLpiSWp2ampBalFMFkZDg4lCV5fkEbBotT01Iq0 zJwShDQTByfIcC4pkeLUvJTUosTSkox4UCzFFwOjCSTFA7RXHWxvcUFiLlAUovUUo6KUOG9M EVBCACSRUZoHNxaWDl4xigN9KcxrAtLOA0wlcN2vgAYzAQ3mvysKMrgkESEl1cA4aV/mr9o6 l+7EFyJqycohf+YUHZzxuGbzX/HVkfpMkWltL1etiyyfwVvfH9tx7PzmxBqOMNlLwSdFPbOP +vJ9WiD++8KZzzaRt85uDJRsMlB6/d1rKu+zbuPEZZ6nLzzWZdU/nHe4LDcw/feTxa7sCbkn dj9NXrx/8ePde3c957rIu/yB6bdPSizFGYmGWsxFxYkA1S7n/uICAAA= Archived-At: Subject: [clue] Finishing up Security Considerations for protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 18:07:43 -0000 The protocol needs to have a Security Considerations section before it can progress. That is the main gating item at this point. This should be pretty simple. The following are my thoughts about what should be in it: - it should reference the security considerations in the framework. They cover many important issues and those probably don't need to be restated as long as they are referenced. - it should reference the security considerations in the data model. That document has most of the critical data to be concerned with. - a reference to the security considerations in the clue-datachannel draft will cover the protection of the content of the protocol messages. - There probably should be a brief discussion of the extra data in the protocol (not in the data model) that exposes information that might be of concern. I think this is primarily in the options negotiation: exposing all the versions and options supported could conceivably leak a bit of info about the specific software. In theory an implementation could choose not to announce all the versions it supports if it wants to avoid such leakage, though it would reduce interoperability. And of course it will only be relevant when there are multiple versions and options. Thanks, Paul From nobody Wed Apr 27 23:04:20 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7706112D0D9; Wed, 27 Apr 2016 23:04:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160428060418.25233.12037.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2016 23:04:18 -0700 Archived-At: Cc: clue@ietf.org, clue-chairs@ietf.org Subject: [clue] clue - Not having a session at IETF 96 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 06:04:18 -0000 Roni Even, a chair of the clue working group, indicated that the clue working group does not plan to hold a session at IETF 96. This message was generated and sent by the IETF Meeting Session Request Tool.