From nobody Tue Mar 1 08:45:47 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EB41A8841 for ; Tue, 1 Mar 2016 08:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 tgU1yWs1ctDW for ; Tue, 1 Mar 2016 08:45:44 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F85F1B2F2B for ; Tue, 1 Mar 2016 08:45:44 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-12v.sys.comcast.net with comcast id Qgl11s0022GyhjZ01glj5C; Tue, 01 Mar 2016 16:45:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with comcast id Qglj1s00D3KdFy101gljwT; Tue, 01 Mar 2016 16:45:43 +0000 To: clue@ietf.org References: <56D46616.1060105@alum.mit.edu> <56D4E26C.6040907@nteczone.com> From: Paul Kyzivat Message-ID: <56D5C736.7060301@alum.mit.edu> Date: Tue, 1 Mar 2016 11:45:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D4E26C.6040907@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456850743; bh=FbQEXa7R7e4w4PYf2dU81/TdFFlwQ+z3WGXKtoutqck=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=kCm6F3TzQXrabkJ6Le7TAQQRD4XDrerVdYsZz/dczJLi2Lm5P2ebuZpQt/bD/NxAI HwsQOEU7oz7c6+qEw5gZDFYlesicdkvXWZ2VMulg7M0owEPxqPWpGsu8OtjUgHYYvt Mn5aKd0vbyAZtmivrHUsznTjqW7Vsh2pjlcrY7zWdhVoh/DdL3DHKU4ZZ5PQ4ZVNga 9LxC5Cvwa51gb5TCYkqT1bmacY4s+RqzdLmnIfFw0q7ATZNqE91zkKkS0YsqMAjuJv hTwZHONit51lwFeXrmlk37dH4F0pDg7Vc1HO0rKJ38YmYouw/EPcPpf3eoOg1vsKCN 6htfhafBFo6pQ== Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-datachannel-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 Mar 2016 16:45:46 -0000 On 2/29/16 7:29 PM, Christian Groves wrote: > Hello Paul, > > It looks ok to me. A couple of minor reference updates: > ietf-mmusic-data-channel-sdpneg -> now v8 > ietf-mmusic-sctp-sdp-> now v16 > > There hasn't been much change since the last WGLC on this. Thanks for looking. We did have a prior WGLC, but it was almost a year ago, and on -08. So it is good to check. Thanks, Paul > Regards, Christian > > On 1/03/2016 2:39 AM, Paul Kyzivat wrote: >> This message announces the start of a two week WGLC for >> draft-ietf-clue-datachannel-11. The last call will end at midnight on >> Monday 14-mar-2016. >> >> I request all those who have worked on or are interested in CLUE to >> make an effort to review this document and submit comments. If you >> have no specific comments to make then please send a note indicating >> you have reviewed it an agree it is ready to advance. >> >> Thanks, >> Paul Kyzivat >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Mar 1 09:09:51 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509051B2FF2 for ; Tue, 1 Mar 2016 09:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham 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 km3nCcw86CGl for ; Tue, 1 Mar 2016 09:09:48 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7941B2FF7 for ; Tue, 1 Mar 2016 09:09:44 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 30BBF203CD for ; Tue, 1 Mar 2016 12:09:43 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Tue, 01 Mar 2016 12:09:43 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= 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=zUSYt7+cNudpDv/RXst8arRWhUQ=; b=uvyFVp tMKOQ/YhP+OMayolcZR/whWDnG3AjWpGoLAdC34nft5kKqw2iKCyntAM1QwCe+8a kv+ELFAfMNVYXeU/keN+P9UR2Fs1mLGAeOoDdFbC1EDp3oFtHuAA8V01I+CfmLct rz6vuyMh05HV4VFs76Cfy2U4pl/6uc/YXDrh4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=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=zUSYt7+cNudpDv/ RXst8arRWhUQ=; b=J9JjAhl1SUEhc8zA0dGGZ1aPJ0JjknxNpEvKvaM99VaeYsq 1bVwL9pDb9Y5RZ9J4Q1fxmqm5g6/loudBKw09OMtXJgWvHf9P5Var80xWTZcxQZw 55Ng8Bj4sCSc5GmaMD2jTBlgMpo7A4dcMEXrQmp1aR5IKDWh3tZiE0AjnjhQ= X-Sasl-enc: YjjrfUe7OeTlhtzpx7af4swzrvBys074WWKydK4MWjDE 1456852182 Received: from [192.168.1.82] (c-24-6-61-198.hsd1.ca.comcast.net [24.6.61.198]) by mail.messagingengine.com (Postfix) with ESMTPA id 81FC3C00013 for ; Tue, 1 Mar 2016 12:09:42 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <09019183-3B33-4BF5-8646-207F000E6B17@cooperw.in> Date: Tue, 1 Mar 2016 09:09:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <63C83070-5357-4C6B-AFA2-1EA68C70A7E9@cooperw.in> References: <09019183-3B33-4BF5-8646-207F000E6B17@cooperw.in> To: CLUE X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [clue] AD review: draft-ietf-clue-data-model-schema-12 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 Mar 2016 17:09:50 -0000 Is there an estimate of when these comments will be addressed? Thanks, Alissa > On Feb 23, 2016, at 2:31 PM, Alissa Cooper wrote: >=20 > I have reviewed this document in preparation for IETF last call. I = have some substantive comments and questions that need to be resolved = before going to last call, along with some nits that should be resolved = as well. >=20 >=20 > Substantive comments: >=20 > =3D General =3D >=20 > (1) The use of normative language appears inconsistent in the = document. There are normative uses of MUST and also non-normative uses = of =E2=80=9Cmust,=E2=80=9D =E2=80=9Coptional,=E2=80=9D and = =E2=80=9Cmandatory.=E2=80=9D I would recommend a careful pass through to = establish consistency. >=20 > (2) The definition of the simultaneous set type uses = while the definitions for content and capture ID = list use . Same goes for encoding ID, which is sometimes = called =E2=80=9CencID=E2=80=9D and sometimes called =E2=80=9CencodingID.=E2= =80=9D If the difference in name is not meaningful, the same names = should be reused throughout. >=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 > (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 > =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? = And why is it stated differently than how it=E2=80=99s stated in the = protocol doc? >=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 > =3D Section 11.10 =3D >=20 > (1) > "It indicates the criteria applied to build the > multiple content capture using the media captures referenced in > .=E2=80=9D >=20 > is not defined anywhere. Did you mean = ? >=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 > =3D Section 11.22 =3D >=20 > Why is this a SHOULD rather than a MUST? >=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 > =3D Section 11.27.2 =3D >=20 > Why is the media type attribute optional? >=20 > =3D Section 15 =3D >=20 > (1) What does =E2=80=9Cfull-optional=E2=80=9D mean? >=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 > =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 >=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 >=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 >=20 > =3D Section 11.7 =3D >=20 > s/last ones/latter ones/ >=20 > =3D Section 11.29.1.2 =3D >=20 > I think this section should point to Appendix A in the ecrit document. >=20 >=20 >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Mar 1 09:21:33 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D301B3012 for ; Tue, 1 Mar 2016 09:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.026 X-Spam-Level: X-Spam-Status: No, score=-0.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 xKcFyVb1j94U for ; Tue, 1 Mar 2016 09:21:23 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3581B300F for ; Tue, 1 Mar 2016 09:21:21 -0800 (PST) X-ASG-Debug-ID: 1456852878-05f27540f63d2df40001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id zaBg3a78HrjUDDAg (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Tue, 01 Mar 2016 18:21:18 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [143.225.28.169] ([143.225.28.169]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u21HLHtT005209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Mar 2016 18:21:18 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_7AD843AE-6F28-468D-96FF-FD08AC8C09E6" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] AD review: draft-ietf-clue-data-model-schema-12 In-Reply-To: <63C83070-5357-4C6B-AFA2-1EA68C70A7E9@cooperw.in> Date: Tue, 1 Mar 2016 18:21:29 +0100 Message-Id: <27E977FE-3BF4-4604-9FD5-5C94C1EED3CC@unina.it> References: <09019183-3B33-4BF5-8646-207F000E6B17@cooperw.in> <63C83070-5357-4C6B-AFA2-1EA68C70A7E9@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.1993) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1456852878 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.82 X-Barracuda-Spam-Status: No, SCORE=0.82 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE, MIME_QP_LONG_LINE, MIME_QP_LONG_LINE_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.27471 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.82 MIME_QP_LONG_LINE_2 RAW: Quoted-printable line longer than 76 chars Archived-At: Cc: CLUE Subject: Re: [clue] AD review: draft-ietf-clue-data-model-schema-12 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 Mar 2016 17:21:26 -0000 --Apple-Mail=_7AD843AE-6F28-468D-96FF-FD08AC8C09E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Alissa, we=E2=80=99re working on them right now. We=E2=80=99ll send back our = comments/modifications by the end of this week. Thank you for your useful feedback, by the way! Simon > On 01/mar/2016, at 18:09, Alissa Cooper wrote: >=20 > Is there an estimate of when these comments will be addressed? >=20 > Thanks, > Alissa >=20 >> On Feb 23, 2016, at 2:31 PM, Alissa Cooper wrote: >>=20 >> I have reviewed this document in preparation for IETF last call. I = have some substantive comments and questions that need to be resolved = before going to last call, along with some nits that should be resolved = as well. >>=20 >>=20 >> Substantive comments: >>=20 >> =3D General =3D >>=20 >> (1) The use of normative language appears inconsistent in the = document. There are normative uses of MUST and also non-normative uses = of =E2=80=9Cmust,=E2=80=9D =E2=80=9Coptional,=E2=80=9D and = =E2=80=9Cmandatory.=E2=80=9D I would recommend a careful pass through to = establish consistency. >>=20 >> (2) The definition of the simultaneous set type uses = while the definitions for content and capture ID = list use . Same goes for encoding ID, which is sometimes = called =E2=80=9CencID=E2=80=9D and sometimes called =E2=80=9CencodingID.=E2= =80=9D If the difference in name is not meaningful, the same names = should be reused throughout. >>=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 >> (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 >> =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? = And why is it stated differently than how it=E2=80=99s stated in the = protocol doc? >>=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 >> =3D Section 11.10 =3D >>=20 >> (1) >> "It indicates the criteria applied to build the >> multiple content capture using the media captures referenced in >> .=E2=80=9D >>=20 >> is not defined anywhere. Did you mean = ? >>=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 >> =3D Section 11.22 =3D >>=20 >> Why is this a SHOULD rather than a MUST? >>=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 >> =3D Section 11.27.2 =3D >>=20 >> Why is the media type attribute optional? >>=20 >> =3D Section 15 =3D >>=20 >> (1) What does =E2=80=9Cfull-optional=E2=80=9D mean? >>=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 >> =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 >>=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 >>=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 >>=20 >> =3D Section 11.7 =3D >>=20 >> s/last ones/latter ones/ >>=20 >> =3D Section 11.29.1.2 =3D >>=20 >> I think this section should point to Appendix A in the ecrit = document. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_7AD843AE-6F28-468D-96FF-FD08AC8C09E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello Alissa,

we=E2=80=99re working on them right now. We=E2=80=99ll send = back our comments/modifications by the end of this week.

Thank you for your = useful feedback, by the way!

Simon


On 01/mar/2016, at 18:09, = Alissa Cooper <alissa@cooperw.in> wrote:

Is there an estimate = of when these comments will be addressed?

Thanks,
Alissa

On Feb 23, 2016, at 2:31 = PM, Alissa Cooper <alissa@cooperw.in> wrote:

I= have reviewed this document in preparation for IETF last call. I have = some substantive comments and questions that need to be resolved before = going to last call, along with some nits that should be resolved as = well.


Substantive = comments:

=3D General =3D

(1) The use of normative language appears inconsistent in the = document. There are normative uses of MUST and also non-normative uses = of =E2=80=9Cmust,=E2=80=9D =E2=80=9Coptional,=E2=80=9D and = =E2=80=9Cmandatory.=E2=80=9D I would recommend a careful pass through to = establish consistency.

(2) The definition = of the simultaneous set type uses <mediaCaptureIDREF> while the = definitions for content and capture ID list use <captureIDREF>. = Same goes for encoding ID, which is sometimes called =E2=80=9CencID=E2=80=9D= and sometimes called =E2=80=9CencodingID.=E2=80=9D If the difference in = name is not meaningful, the same names should be reused throughout.

(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.

(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.

=3D Section 3 =3D

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? And why is it stated differently than how it=E2=80=99s stated in = the protocol doc?

=3D Section 11.2 =3D

"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

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?

=3D = Section 11.10 =3D

(1)
"It = indicates the criteria applied to build the
=  multiple content capture using the media captures referenced in
 <contentCaptureIDs>.=E2=80=9D

<contentCaptureIDs> is not defined anywhere. Did you = mean <captureIDREFs>?

(2)
Same comment as section 11.2.

=3D = Section 11.18 and 11.19 =3D

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= )

=3D Section 11.22 =3D

Why is this a SHOULD rather than a MUST?

=3D Section 11.23 =3D

"When = defining new media capture types that are going to be described
 by means of the <otherMediaCapture> 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

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.

=3D Section 11.27.2 =3D

Why is = the media type attribute optional?

=3D = Section 15 =3D

(1) What does = =E2=80=9Cfull-optional=E2=80=9D mean?

(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.

=3D = Section 29 =3D

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.


Nits:

=3D General =3D

(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).


=3D Section 11.1 =3D

s/(e.g., simultaneous sets, capture encodings, and = others)/(e.g., simultaneous sets, capture encodings, and others via = <captureIDREF>)


=3D = Section 11.7 =3D

s/last ones/latter = ones/

=3D Section 11.29.1.2 =3D

I think this section should point to Appendix = A in the ecrit document.




_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

  =                   =   =        = _\\|//_
            =                 =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                =      = Simon Pietro Romano
      =          Universita' di Napoli = Federico II
          =            =  Computer Engineering Department 
  =            Phone: +39 081 7683823 -- Fax: = +39 081 7683816
          =                     =              e-mail: spromano@unina.it

    = <<Molti mi dicono che lo scoraggiamento =C3=A8 l'alibi = degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
           =      =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~( =   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   )
=                 =                   \_) =          ) /
    =                     =                     =                     =        (_/






= --Apple-Mail=_7AD843AE-6F28-468D-96FF-FD08AC8C09E6-- From nobody Tue Mar 1 09:54:07 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2601B30F5 for ; Tue, 1 Mar 2016 09:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 L-RFAWCq3aS8 for ; Tue, 1 Mar 2016 09:54:03 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B171B30EA for ; Tue, 1 Mar 2016 09:54:03 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id F17CC21185 for ; Tue, 1 Mar 2016 12:54:02 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 01 Mar 2016 12:54:02 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=PRGKV 52iG6LdHYDmhvcOQ19wfIQ=; b=qOU2B9CN+/h7M6oX3TDAzCZVlKelwfB3jEJln 7rfeecXLjtK+BD+V9r80AQ9K5cWcGFVwwNB6SsoBHrYL2cYFCBOShU28CtrRmo63 Dv7XZlZI55+16p3Y1NpgIq8BG00kXlSP+7vag66f2CilJEkRg7hA1DmuCZ7NFBh1 PdQ/5s= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=PRGKV52iG6LdHYDmhvcOQ19wfIQ=; b=Y79Uc suabjz7FgiUwVZ2HGGITZOD94s/OI3bzW3kiug5RJn5Q1XA1hWh+GeVln7hFVDNW Rn0G9CqOqrV6g+9fRakP0Ea6lsyJ7PJT/Zj1ldcuG7yVHSgrPoBsKiHkeERbTgzg es7gJlQtvIQ9ekxAuBVqgitIyBpCJ5ruloqW4I= X-Sasl-enc: 4U/b1Pyg40r5bsBoafNHNR3W10FE94O20wmNxBXvhKGg 1456854842 Received: from [192.168.1.82] (c-24-6-61-198.hsd1.ca.comcast.net [24.6.61.198]) by mail.messagingengine.com (Postfix) with ESMTPA id 43A45C00014; Tue, 1 Mar 2016 12:54:02 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4D92A996-30FD-496F-A470-C3B6E112628D" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <27E977FE-3BF4-4604-9FD5-5C94C1EED3CC@unina.it> Date: Tue, 1 Mar 2016 09:54:00 -0800 Message-Id: References: <09019183-3B33-4BF5-8646-207F000E6B17@cooperw.in> <63C83070-5357-4C6B-AFA2-1EA68C70A7E9@cooperw.in> <27E977FE-3BF4-4604-9FD5-5C94C1EED3CC@unina.it> To: Simon Pietro Romano X-Mailer: Apple Mail (2.3112) Archived-At: Cc: CLUE Subject: Re: [clue] AD review: draft-ietf-clue-data-model-schema-12 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 Mar 2016 17:54:06 -0000 --Apple-Mail=_4D92A996-30FD-496F-A470-C3B6E112628D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Great, thanks. > On Mar 1, 2016, at 9:21 AM, Simon Pietro Romano = wrote: >=20 > Hello Alissa, >=20 > we=E2=80=99re working on them right now. We=E2=80=99ll send back our = comments/modifications by the end of this week. >=20 > Thank you for your useful feedback, by the way! >=20 > Simon >=20 >=20 >> On 01/mar/2016, at 18:09, Alissa Cooper > wrote: >>=20 >> Is there an estimate of when these comments will be addressed? >>=20 >> Thanks, >> Alissa >>=20 >>> On Feb 23, 2016, at 2:31 PM, Alissa Cooper > wrote: >>>=20 >>> I have reviewed this document in preparation for IETF last call. I = have some substantive comments and questions that need to be resolved = before going to last call, along with some nits that should be resolved = as well. >>>=20 >>>=20 >>> Substantive comments: >>>=20 >>> =3D General =3D >>>=20 >>> (1) The use of normative language appears inconsistent in the = document. There are normative uses of MUST and also non-normative uses = of =E2=80=9Cmust,=E2=80=9D =E2=80=9Coptional,=E2=80=9D and = =E2=80=9Cmandatory.=E2=80=9D I would recommend a careful pass through to = establish consistency. >>>=20 >>> (2) The definition of the simultaneous set type uses = while the definitions for content and capture ID = list use . Same goes for encoding ID, which is sometimes = called =E2=80=9CencID=E2=80=9D and sometimes called =E2=80=9CencodingID.=E2= =80=9D If the difference in name is not meaningful, the same names = should be reused throughout. >>>=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 >>> (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 >>> =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? = And why is it stated differently than how it=E2=80=99s stated in the = protocol doc? >>>=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 >>> =3D Section 11.10 =3D >>>=20 >>> (1) >>> "It indicates the criteria applied to build the >>> multiple content capture using the media captures referenced in >>> .=E2=80=9D >>>=20 >>> is not defined anywhere. Did you mean = ? >>>=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 >>> =3D Section 11.22 =3D >>>=20 >>> Why is this a SHOULD rather than a MUST? >>>=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 >>> =3D Section 11.27.2 =3D >>>=20 >>> Why is the media type attribute optional? >>>=20 >>> =3D Section 15 =3D >>>=20 >>> (1) What does =E2=80=9Cfull-optional=E2=80=9D mean? >>>=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 >>> =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 >>>=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 >>>=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 >>>=20 >>> =3D Section 11.7 =3D >>>=20 >>> s/last ones/latter ones/ >>>=20 >>> =3D Section 11.29.1.2 =3D >>>=20 >>> I think this section should point to Appendix A in the ecrit = document. >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >=20 > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico = II > Computer Engineering Department=20 > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it = >=20 > < idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( = ( ) > \_) ) = / > = (_/ >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_4D92A996-30FD-496F-A470-C3B6E112628D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Great, thanks.

On = Mar 1, 2016, at 9:21 AM, Simon Pietro Romano <spromano@unina.it> = wrote:

Hello = Alissa,

we=E2=80=99re = working on them right now. We=E2=80=99ll send back our = comments/modifications by the end of this week.

Thank you for your useful feedback, by = the way!

Simon


On 01/mar/2016, at 18:09, Alissa Cooper = <alissa@cooperw.in> wrote:

Is there an estimate = of when these comments will be addressed?

Thanks,
Alissa

On Feb 23, 2016, at 2:31 = PM, Alissa Cooper <alissa@cooperw.in> wrote:

I= have reviewed this document in preparation for IETF last call. I have = some substantive comments and questions that need to be resolved before = going to last call, along with some nits that should be resolved as = well.


Substantive = comments:

=3D General =3D

(1) The use of normative language appears inconsistent in the = document. There are normative uses of MUST and also non-normative uses = of =E2=80=9Cmust,=E2=80=9D =E2=80=9Coptional,=E2=80=9D and = =E2=80=9Cmandatory.=E2=80=9D I would recommend a careful pass through to = establish consistency.

(2) The definition = of the simultaneous set type uses <mediaCaptureIDREF> while the = definitions for content and capture ID list use <captureIDREF>. = Same goes for encoding ID, which is sometimes called =E2=80=9CencID=E2=80=9D= and sometimes called =E2=80=9CencodingID.=E2=80=9D If the difference in = name is not meaningful, the same names should be reused throughout.

(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.

(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.

=3D Section 3 =3D

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? And why is it stated differently than how it=E2=80=99s stated in = the protocol doc?

=3D Section 11.2 =3D

"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

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?

=3D = Section 11.10 =3D

(1)
"It = indicates the criteria applied to build the
=  multiple content capture using the media captures referenced in
 <contentCaptureIDs>.=E2=80=9D

<contentCaptureIDs> is not defined anywhere. Did you = mean <captureIDREFs>?

(2)
Same comment as section 11.2.

=3D = Section 11.18 and 11.19 =3D

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= )

=3D Section 11.22 =3D

Why is this a SHOULD rather than a MUST?

=3D Section 11.23 =3D

"When = defining new media capture types that are going to be described
 by means of the <otherMediaCapture> 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

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.

=3D Section 11.27.2 =3D

Why is = the media type attribute optional?

=3D = Section 15 =3D

(1) What does = =E2=80=9Cfull-optional=E2=80=9D mean?

(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.

=3D = Section 29 =3D

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.


Nits:

=3D General =3D

(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).


=3D Section 11.1 =3D

s/(e.g., simultaneous sets, capture encodings, and = others)/(e.g., simultaneous sets, capture encodings, and others via = <captureIDREF>)


=3D = Section 11.7 =3D

s/last ones/latter = ones/

=3D Section 11.29.1.2 =3D

I think this section should point to Appendix = A in the ecrit document.




_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

        =               =    =     _\\|//_
        =                   =   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                =      = Simon Pietro Romano
      =          Universita' di Napoli = Federico II
          =            =  Computer Engineering Department 
  =            Phone: +39 081 7683823 -- Fax: = +39 081 7683816
          =                     =              e-mail: spromano@unina.it

    = <<Molti mi dicono che lo scoraggiamento =C3=A8 l'alibi = degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
           =      =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~( =   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   )
=                 =                   \_) =          ) /
    =                     =                     =                     =        (_/







= --Apple-Mail=_4D92A996-30FD-496F-A470-C3B6E112628D-- From nobody Tue Mar 1 10:53:03 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49F91B3FC8 for ; Tue, 1 Mar 2016 10:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 uRXKPPK-1w0E for ; Tue, 1 Mar 2016 10:52:57 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301D61B3FC6 for ; Tue, 1 Mar 2016 10:52:55 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id l68so48965190wml.0 for ; Tue, 01 Mar 2016 10:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=Prdw7Xz4wMkSdP9i+jwTUO8/3JEWUDxKoRgV6SJcMQE=; b=ne1wGeGT0/rLJNrlX2Vz9ebLnZg2LtoRm3GZxyVw69K7Vo2nrCMlzJVdFNcFf0Phk2 axFx0ErfixPdDzCa6EwRd/QMGtyiMOKZFOjlxuBHzO/f+f+xqhnfWF5k8PNqU+Azz08f s2XPlVI2fxvXb+AcW4nbYC69As7DRusF1xSC/qbtU7jJYPOSXRXHQQCWmcAAVebjK/6H g8rCesA987LOVDV4O9sKbPMGHttB8CWt0GnvfWV7D+4z9KYKdcKbX8GfiBDY6YDpO+UD fJWlZUIO2nZ005Al1eW4gTAJ7IqL8egyzMZ4J8ZDZxUyXpE+ckCWqb60aEoeXc8Jy9k5 u2eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Prdw7Xz4wMkSdP9i+jwTUO8/3JEWUDxKoRgV6SJcMQE=; b=WZkoUUTJKvW+iohvWwTPXo6yQsZHA4u6L6XtCZo76FjhRlOOqOpinK9wfJrVlAw+Vc YBQFpnfo1UeB/BUvpQSZpwxY50mGJMH2G3KFF0oEW0AHA98DNLVzgOLBmAlsBeIoeccK cCsRDsKo3Iav+6KLEYnfFz7a33aq3+jP+8CEu6Paa0wAT2j3TzKUKKzyNoIb7DCo8/b4 YZ8D4Htg2F71wINEs0ww0Y+IYGmudX2bKKJKrY/yHnbnHv4poCLYS0wbH8H9MXR27t98 cd5pvq6SPIOCKjMPGUpDhnufY9h1MBEvbT0sHzQDSRkT0bkLxoAuTCKb9GV+U3VT/2mG /IaQ== X-Gm-Message-State: AD7BkJJkz4p+leWdJLyHXdc+DHPl+zNwjVS4tB0CUaR76RGfYtmaIMKN5C6nO6j4/cjCAA== X-Received: by 10.194.187.240 with SMTP id fv16mr26547304wjc.53.1456858373705; Tue, 01 Mar 2016 10:52:53 -0800 (PST) Received: from RoniPC (bzq-79-177-19-17.red.bezeqint.net. [79.177.19.17]) by smtp.gmail.com with ESMTPSA id jo6sm32291371wjb.48.2016.03.01.10.52.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2016 10:52:52 -0800 (PST) From: "Roni Even" To: "'Alissa Cooper'" , "'CLUE'" References: <09019183-3B33-4BF5-8646-207F000E6B17@cooperw.in> In-Reply-To: <09019183-3B33-4BF5-8646-207F000E6B17@cooperw.in> Date: Tue, 1 Mar 2016 20:52:39 +0200 Message-ID: <0d1c01d173eb$8828f770$987ae650$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRTsqkoIQGtZFYL3JnPMYGMPaReqBFMorQ Content-Language: he Archived-At: Subject: Re: [clue] AD review: draft-ietf-clue-data-model-schema-12 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 Mar 2016 18:52:59 -0000 Hi Alissa, Thanks for the review, I will try to answer some of the comments and cut = the rest for clarity Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Alissa Cooper > Sent: Wednesday, February 24, 2016 12:32 AM > To: CLUE > Subject: [clue] AD review: draft-ietf-clue-data-model-schema-12 >=20 > I have reviewed this document in preparation for IETF last call. I = have some > substantive comments and questions that need to be resolved before = going > to last call, along with some nits that should be resolved as well. >=20 >=20 > Substantive comments: >=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? [Roni Even] I think that the meaning was to allow the media types from = the IANA registry = http://www.iana.org/assignments/media-types/media-types.xhtml . The = issue will be about the usage of other media types in the CLUE = environment and not about the values themselves. Need to clarify >=20 > =3D Section 11.10 =3D >=20 > (1) > "It indicates the criteria applied to build the > multiple content capture using the media captures referenced in > .=E2=80=9D >=20 > is not defined anywhere. Did you mean > ? >=20 > (2) > Same comment as section 11.2. [Roni Even] This one is more complicated, I think we need to have a = normative language requiring a document that describes the policy for = interoperability. On the other hand I think that the WG thought that it = should not be strict for an IETF document but can be specified by = industry forums or any other means. This is an optional parameter and my = view is that the policy will be handled by application level protocol = (e.g. XCON) >=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) [Roni Even] I think we can take out the "current". Still there may be = other values, we tried to list the commonly known ones. >=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 [Roni Even] I think it is discussed in section 11.5 > precise. >=20 > =3D Section 11.27.2 =3D >=20 > Why is the media type attribute optional? [Roni Even] I think the second part of the section explains it. >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Mar 2 09:09:21 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2201B2CAF for ; Wed, 2 Mar 2016 09:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 khI4azqJTzVm for ; Wed, 2 Mar 2016 09:09:17 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877921B2CAA for ; Wed, 2 Mar 2016 09:09:17 -0800 (PST) Received: from [216.82.251.38] by server-3.bemta-12.messagelabs.com id C0/C7-03296-D3E17D65; Wed, 02 Mar 2016 17:09:17 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-14.tower-163.messagelabs.com!1456938556!34704140!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 115991 invoked from network); 2 Mar 2016 17:09:16 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-14.tower-163.messagelabs.com with AES128-SHA encrypted SMTP; 2 Mar 2016 17:09:16 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Wed, 2 Mar 2016 09:09:16 -0800 From: "Duckworth, Mark" To: Paul Kyzivat Date: Wed, 2 Mar 2016 09:09:13 -0800 Thread-Topic: [clue] WGLC for draft-ietf-clue-datachannel-11 Thread-Index: AdFzB2EVw+laKkcXRNmO9aWu9v5n6gBnsFXA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52FC1902F8CD3@CRPMBOXPRD08.polycom.com> References: <56D46616.1060105@alum.mit.edu> In-Reply-To: <56D46616.1060105@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0C0B_01D1747C.55F3C1E0" MIME-Version: 1.0 Archived-At: Cc: CLUE Subject: Re: [clue] WGLC for draft-ietf-clue-datachannel-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 17:09:19 -0000 ------=_NextPart_000_0C0B_01D1747C.55F3C1E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I reviewed the document and agree it is ready to advance. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, February 29, 2016 10:39 AM > To: CLUE > Subject: [clue] WGLC for draft-ietf-clue-datachannel-11 > > This message announces the start of a two week WGLC for > draft-ietf-clue-datachannel-11. The last call will end at midnight on > Monday 14-mar-2016. > > I request all those who have worked on or are interested in CLUE to make > an effort to review this document and submit comments. If you have no > specific comments to make then please send a note indicating you have > reviewed it an agree it is ready to advance. > > Thanks, > Paul Kyzivat > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue ------=_NextPart_000_0C0B_01D1747C.55F3C1E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUEjCCBQ0w ggL1oAMCAQICEBrVY02YeFKcQ+zVfznU/o4wDQYJKoZIhvcNAQEFBQAwGTEXMBUGA1UEAxMOUG9s eWNvbS1Sb290Q0EwHhcNMTMxMTA0MTg1NzA2WhcNMjMxMTA0MTkwNjU4WjAZMRcwFQYDVQQDEw5Q b2x5Y29tLVJvb3RDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMzj+6krY3OF7mtq +O2/yC5heUML7DFZn2cp0Mkp/vos7TDrysGdPDdEIK+zYvZQZs6TrGzPh0XXnEpMcHE7V4nD5zN3 VX0+Zg46w0wCHdkgq/GV3EKlyg0AsX8LgooGlUMeuUNpe+sT0WBl3mXB97TUw7mnRLY1m/IAlyFv 4XO8LfQ1L03vfLBRAVft7xc9Okm6DbHrPxFx9VKpgIkSIUvIx/BK0zXBa/0arWW3tfimfY9t5KdJ Wqb68E8Nb0bD8S0Ve0O76TCR4dVE/HmVj6YrauGcUGfvB4yT+bOOCGlsOw3NoHW2G9PZJF9B9PvV cWzv9Jw3AlzGU2sQMbVD1ZiiRgkG47bvqvi/tg38vWEDMj1lzSpMp/FhC8YrSaGb4YwjM52w9MXM DNypbOFZ/0WjrykwuGB1P9Ga38nRlaMkMJ3lE7P1pQMgxElO5uE+1TI5kTJ9mIGgQtQb57w4vkkJ kHNKjmqzOo3IFkhEIUS3ARPkYG4HWzP7xtmcYBoEx4QwpbxYQKKcxN9h/zuv9LYc79WvnF+i+aj0 1YJKoldsPnIXhG3HullYVQb+v19q8cqm0OGUEq7e2wY72H6JiT6YFc5kZitpZ65L5d1OGVLyFO6b iC79ARA9eBE5L3g9zF/du+U1k9L6LWW3VaHr3ZDCECU8ZX5QeBrqv2aTb0VNAgMBAAGjUTBPMAsG A1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSMD03mpjCj/UgRICWESaXA53z3 0TAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAAOCAgEAs02vFW5Je6895ZBWadxy5vxR z2imWk97qU2sMFSMnmf9QeqPwdawGO33zWr1sSQr8d67AHQc+3ihZuoAaeQAAC6Lww9r17Q3vVqg 7Qge86101Xw1fjXqTFUnWTxBK0S7re7pMqWlqaFgFQOHBMLnrM9z+NQIyDh7st9JjA+bRfFwErQ9 5CziXu+o/4q7eDBP1WaI0yKkEcOQ2LyPuCCE4hcshcJABiSYPax8nW71foHb+bv92IYvYXu2Wpa6 VgnxYqdi2k0Yk8CDiYalVsc+7QH0euQ1YIcovPbpZ02AirLqiiy6XB9i8OKfuapKSftsdfjLKqwI L7lKqz/4uAheETQsORVEh4IT0P8RRaIgHBOBVz/DOW+/IiiYagOJIYqbwGIFImQ7uOLNCoP5qY4y PLUZhmHFnnr7xtz4gv455KP9cwtPYcAarc/IB7WkTmEhFYa19k4jXlZ19AZIO/SPhvV7qz50zqB+ pCReRB5fXnf3qhRSw2WpRD4xr/q8OrWTfQRdXaooTJ14tRziqjEWLz4nPQKbE45aAjgwO0Rp6k5J tWGPhCxmuru/iqVES98VbjuAoo2qYZk7eNrqcnMuSxgqU0bgyie/R/FfMcbsw6rAh7T+qfBSxVIQ tpiqPwtZR5kdi6af3vf4w9q1PvEGrNipAjKEN2HW73558qGfPMowggZ5MIIEYaADAgECAhNuAAAA AgUmZh85ZflDAAAAAAACMA0GCSqGSIb3DQEBBQUAMBkxFzAVBgNVBAMTDlBvbHljb20tUm9vdENB MB4XDTEzMTEwNDE5MTM1MFoXDTIzMTEwNDE5MDY1OFowSDETMBEGCgmSJomT8ixkARkWA2NvbTEX MBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAOZhKwn7h/qKsHx8zQQPT356Og5GOOJ26SKfzS6dIZaD NjFIhS/5QRd3HZ9I1qFD8faDfpIHL+NzC0xqYJUZsEKntD+cCj99nx33t9D6GCmsEEngeLV0FO/u DlDcCXVJNJWS65E05vKyWFPlIRegDs+E73mNh3dHZ53mgrsCFd8PnX5Zm6zm+dAinDTUreXzSuzT si5yuZ10jHdEoin3bQyYQfAe4nR7BiqcQzYnD+JgU+NrZZ555xMdwVtRhjIFuFHwCN1BgWL8+cmI PTmW3bS/irYkbUn/IYFXGJIdgeZTzsp22+OPChBkCBiy86d9RaM6qvOV/ZLmq0bj4souN1cNBg0g ZnYIgTypQY/5Ew99FJJDor4TH1R5YNtqgwxBiSZSc0WSKy8WBrcUpBM+FP1gETY2sqZh2ApFkhU1 7BBLXcEwu6dnSO9Y5u0zJfOTKPesVaeGTfvzTEcm6A8xKO6V+ai/zhu3egbv4SmlPGiMENMPsWRy cG0c73xz/w9RwpWpImjIcE3+XA9rPhIdNj2KN4sbMJvvN5/ZLJHRScE5F3pltq2sFLyPSqhukYVY NRVXmdJ14FCArDqlrREeWLA2tP4ir0WeFeX6KgU+QrmWvdw1hJZ9/lPkiqDvuBWvDVyON0u/Dvi3 p6RJmWJlC5F8ajRegnM+BAYfokRZkvOHAgMBAAGjggGJMIIBhTAQBgkrBgEEAYI3FQEEAwIBADAd BgNVHQ4EFgQUcIfA57S89xZAbs9iT83FhcVNeekwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEw CwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUjA9N5qYwo/1IESAlhEml wOd899EwbwYDVR0fBGgwZjBkoGKgYIYuaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtpL1BvbHlj b20tUm9vdENBLmNybIYuaHR0cDovL2NkcDIucG9seWNvbS5jb20vcGtpL1BvbHljb20tUm9vdENB LmNybDCBhgYIKwYBBQUHAQEEejB4MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMS5wb2x5Y29tLmNv bS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMi5wb2x5Y29t LmNvbS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQDAITSF89YEDKMA zqteWVdg8IqzdMHSHIJGybNrbe1UJj6trSldu42wcgjYLgJrTIDEUEX2Qp1xywpv+zpVAE1bVoek 6ot846XEIiOTofJYnwACZNnCLJ3ijG2iuBCSJjPc6FzwCF/2DMR0erdh8PNhEnl3xDRNyqVOy+DC mlLssSjPgej1UxM4yaDZZUCBrkv1dB3a4qkTbMPFBj5CkC5gPnyKTRW7iUFMKr0pXvByGPHCtRbu ShXAcoSdVH2f8cLUfJ8raVMWu1ynjOMcvlagDaZAcbzLSc8hzhxJNC6Wel9U1uFyEaYGodJTMxzv e5zRU5wZod5kPaEThCKq12Fr9Sz/dYYp4Rup/SymTS4A46qMIrOi6i3icxa3SYAhsCeALdcrgCH4 +cCtKiEE1UpqIfJq8P/+FE6cnfHyGaXD+wn4BTA5BrUBg900HNVNf1Y6BDMqaXDeAPKbiSb5FDot PjAW0v7GLoshHMr+951EdhaFNSUyOV8CoSx9b9BjlYpjJV+QtiaqJLn9UlNOa987Fg9dIY4vrfqH q9kCVr+sVpQsZ6DC17bE7etrHPevRny/EcLmuJY1RD56gPAyePHFs1GEhmKVW9ZlLWtNs79G6wSf ZRnr3vRAtr7v0zWyjfvn52HWM4kbXedjCa/q9boJMVqK+8DJawhrrn38Liw7oDCCCIAwggZooAMC AQICE2sAANv9iRUGFNx/sYkAAAAA2/0wDQYJKoZIhvcNAQELBQAwSDETMBEGCgmSJomT8ixkARkW A2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTAe Fw0xNjAyMTYxNzI1NTlaFw0xNzAyMTUxNzI1NTlaMIGnMRMwEQYKCZImiZPyLGQBGRYDY29tMRcw FQYKCZImiZPyLGQBGRYHcG9seWNvbTEPMA0GA1UECxMGUGVvcGxlMRIwEAYDVQQLEwlFbXBsb3ll ZXMxDTALBgNVBAsTBE5BTEExGDAWBgNVBAMTD0R1Y2t3b3J0aCwgTWFyazEpMCcGCSqGSIb3DQEJ ARYaTWFyay5EdWNrd29ydGhAcG9seWNvbS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDUKfyJTxXkwEsUnHz/9m3k1jNMh31VSjpcboNOXMLE7ERqwC+KdVON0NLHp5ctN4kWewuu YDOuS+Qhp/Pm/+T2acQ0cqw+oY3nvKl7erYfC5Ul0EATlD3aUTGz34L2iKttOm9YID2GylBH9670 PHQ7n3YqC5sh1C7l2S4CznZz5c4ATRw1VtAzWskinzwYWKeiJV2ybr4JU9EM5QAGqM84jFXV2kN2 3CGKmAWlo6GIXstg82hfTkfubmgW9BQ+iyHEfwP1DIvdLh4tsyrgHoz+qomNaXmG+jUiP5CktXDF KueQLciDeg9HyxGh7AgtTvdMtI3KZUFCDyKDN4k0ux/5AgMBAAGjggQBMIID/TA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiGpOVThtjlcoO1gRiEnaYag+m7OimFw9RYg9ngHQIBZAIBBzApBgNV HSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwCwYDVR0PBAQDAgWgMDUGCSsG AQQBgjcVCgQoMCYwCgYIKwYBBQUHAwIwCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDBDBEBgkqhkiG 9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZI hvcNAwcwHQYDVR0OBBYEFBENjiHBionI5U/bTdJlzr9d3XeNMB8GA1UdIwQYMBaAFHCHwOe0vPcW QG7PYk/NxYXFTXnpMIIBOgYDVR0fBIIBMTCCAS0wggEpoIIBJaCCASGGgbxsZGFwOi8vL0NOPVBv bHljb20tU1VCQ0EwMSxDTj12d2NvbG9zdWJjYTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXBvbHljb20sREM9Y29tP2Nl cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludIYvaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtpL1BvbHljb20tU1VCQ0EwMS5jcmyGL2h0 dHA6Ly9jZHAyLnBvbHljb20uY29tL3BraS9Qb2x5Y29tLVNVQkNBMDEuY3JsMIIBPQYIKwYBBQUH AQEEggEvMIIBKzCBrgYIKwYBBQUHMAKGgaFsZGFwOi8vL0NOPVBvbHljb20tU1VCQ0EwMSxDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz1wb2x5Y29tLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTA7BggrBgEFBQcwAoYvaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtp L1BvbHljb20tU1VCQ0EwMS5jcnQwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZHAyLnBvbHljb20uY29t L3BraS9Qb2x5Y29tLVNVQkNBMDEuY3J0MEgGA1UdEQRBMD+gIQYKKwYBBAGCNxQCA6ATDBFtYXJr ZEBwb2x5Y29tLmNvbYEaTWFyay5EdWNrd29ydGhAcG9seWNvbS5jb20wDQYJKoZIhvcNAQELBQAD ggIBAHSlqpzE3JJ6cwdt2ve4eLY7IBfvrGjyFRQRfUgHg7SpxJVjB1jIZY7xXeGcBozQDSO6nQF6 KN3s+Mhy1GgH0tRMZBqefwZaT0taRdMHH/bXxDE4Qf8BRMXNIPZPb+2CV4ldFakuT1VZwmg1Gdtc ZU41o/zXYUBkzjPRX4DaEBWDsxI8Z3OX0lz3Kps3CocagYE+sjTaPIEFF3Gztyw5I8fS/nMnrSq3 G91bqqWE0teuGfBdt6tKqavJ0qHobkOQRV2bQi6OPzLZg8a1IaSZMviUDgzj/VASvw7phEUScEVf VqAvoru/7TWREyoc/lSvsd+PTpMeOjLUDre/FAbRGpN9Sx8FuBgvvb3wYdIMg/R8tIaQ8tqaAG/3 dSa9IeRfWOrcAOuc8TUieSDsTqugStWtKVsO8dCcZtdaPpL0deSjjEF+Ep9ZfqufhibQyFGNTjRK VwgxCQc+owwJx69vo2oDlzwWYhASQmwXVW9eiSWnvvMhvAny5dftCFaV47mSyQimkQ3k/rsX2Cg9 qbeuI0dSSD5c5pgE6z3jkF8ISL/1WitwCtG5Yqqp7Q8G2a35smlSVRzc1WTAiy6jZHSPZsbnRu5Y 9BnsB/TOcmKt9kAn6VUAC4j+Rq7MokZJzmj0sKNMH4qz3bo6ZMImkGS3xCLyvsK4iilg1Me67dlz bbJ1MYIDdzCCA3MCAQEwXzBIMRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYH cG9seWNvbTEYMBYGA1UEAxMPUG9seWNvbS1TVUJDQTAxAhNrAADb/YkVBhTcf7GJAAAAANv9MAkG BSsOAwIaBQCgggHtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MDMwMjE3MDkxM1owIwYJKoZIhvcNAQkEMRYEFH/rGnn6ceZQ/rsi7wutnNOIfV4uMG4GCSsGAQQB gjcQBDFhMF8wSDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20x GDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMQITawAA2/2JFQYU3H+xiQAAAADb/TBwBgsqhkiG9w0B CRACCzFhoF8wSDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20x GDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMQITawAA2/2JFQYU3H+xiQAAAADb/TCBqwYJKoZIhvcN AQkPMYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG 9w0BAQEFAASCAQDRxJ3PSZbpuBabt72DJ3OThq099jPrAZktcxLsLwqD5paZ7Wsgl7vRHOfyNqCj ykQI/3tEDvMq/+qG6/zycMxlF+uK+IA9l+5pZU7RtOno9x/0xiHS+sSbPVbi5g4e+xJAj/YXSiN9 hkBPQUIIRRP2T6HopeuQqpqWP8WNRpW7D9cP9yjUdJ8uEkI2V8bq196gj6YU3lhILHy+XSp/4+Q5 FzAoG4qf47MXiQp/6ubzAJQmptD3/0qICo+7xorSCi+oVs6wwNJBjrtG4mDLD5iLfSi8jEBhvGmN NYrUuvWF0NDtj5nnUknk7CUg4ts7gEQaFNuZFEykR3ypw07wCLyyAAAAAAAA ------=_NextPart_000_0C0B_01D1747C.55F3C1E0-- From nobody Fri Mar 4 11:49:17 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAC11A88F9 for ; Fri, 4 Mar 2016 11:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham 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 9U42-KckKYZR for ; Fri, 4 Mar 2016 11:49:13 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6161A88E9 for ; Fri, 4 Mar 2016 11:49:13 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id F04A52095E for ; Fri, 4 Mar 2016 14:49:12 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 04 Mar 2016 14:49:12 -0500 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=YtsJQnCTgxIC79znmrfL2cdsRIc=; b=4hQg7L SNWVTDlqo80x9ppo2pagqYLuoPqllmHjOebnSJ2tO/Lw2So/S3gVe2N2GCuUZTxU 9Gjpj+MOYCb7rEZySKmvJSaQQ4zMTwy2gICay/jWA3UU1sPoERQmpGjYBY0hnUKs n0vr6DSbwhyCnsHwymzGT9ZmwF3EMc5lNIrwA= 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=YtsJQnCTgxIC79z nmrfL2cdsRIc=; b=l+C+Jopp8/M6eIoBFLUJDkLdhqxsDLVDwI4Kw9QL5zs90Ft N2iAK1pag1dJxkO2YGtWfnOj3yLMZFCVGfm+Uj3+9OcXlrL2RZbGLCRrV63Zn3f+ 1O/nGo28MN9mBQe/qH49/QlnjH0jZ8dTMTwY6gWvPqs4EzrlG9YN04yaIERI= X-Sasl-enc: 2Yr2+yUGjYQCwciiSvk9IhoA8qEzp5U2i7raIIJ/QRsj 1457120952 Received: from dhcp-171-68-20-44.cisco.com (dhcp-171-68-20-44.cisco.com [171.68.20.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 799DFC00016; Fri, 4 Mar 2016 14:49:12 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <0d1c01d173eb$8828f770$987ae650$@gmail.com> Date: Fri, 4 Mar 2016 11:49:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2D5158E5-826E-4CE2-98D6-336D8A2CE422@cooperw.in> References: <09019183-3B33-4BF5-8646-207F000E6B17@cooperw.in> <0d1c01d173eb$8828f770$987ae650$@gmail.com> To: Roni Even X-Mailer: Apple Mail (2.3112) Archived-At: Cc: CLUE Subject: Re: [clue] AD review: draft-ietf-clue-data-model-schema-12 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 19:49:15 -0000 Hi Roni, > On Mar 1, 2016, at 10:52 AM, Roni Even wrote: >>=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 >=20 >=20 > [Roni Even] I think it is discussed in section 11.5 If the properties are limited to those discussed in 11.5 then the text = in 11.23 should say that. >=20 >> precise. >>=20 >> =3D Section 11.27.2 =3D >>=20 >> Why is the media type attribute optional? > [Roni Even] I think the second part of the section explains it. I don=E2=80=99t think it does. A simultaneous set is defined as a set of = captures that all have the same type. So why would you send a set = without indicating the media type? Alissa >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >=20 From nobody Mon Mar 7 06:03:20 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70091B416F for ; Mon, 7 Mar 2016 06:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 6ptZGzmD-7iO for ; Mon, 7 Mar 2016 06:03:18 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4821B4164 for ; Mon, 7 Mar 2016 06:03:17 -0800 (PST) Received: from [216.82.251.38] by server-12.bemta-12.messagelabs.com id 2B/D1-02990-42A8DD65; Mon, 07 Mar 2016 14:03:16 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-13.tower-163.messagelabs.com!1457359395!36022085!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 124223 invoked from network); 7 Mar 2016 14:03:15 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-13.tower-163.messagelabs.com with AES128-SHA encrypted SMTP; 7 Mar 2016 14:03:15 -0000 Received: from SACWPHUBCAS01V.polycom.com (10.236.3.231) by crpehubprd02.polycom.com (10.236.0.154) with Microsoft SMTP Server (TLS) id 8.3.389.2; Mon, 7 Mar 2016 06:03:15 -0800 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by SACWPHUBCAS01V.polycom.com ([fe80::8028:c1d3:87ca:98e%12]) with mapi; Mon, 7 Mar 2016 06:03:14 -0800 From: "Duckworth, Mark" To: Alissa Cooper , Roni Even Date: Mon, 7 Mar 2016 06:03:12 -0800 Thread-Topic: [clue] AD review: draft-ietf-clue-data-model-schema-12 Thread-Index: AdF2TxWFoAFG5bIaRHaj9Rzk1QiimACJofkw Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52FC1902F8FC7@CRPMBOXPRD08.polycom.com> References: <09019183-3B33-4BF5-8646-207F000E6B17@cooperw.in> <0d1c01d173eb$8828f770$987ae650$@gmail.com> <2D5158E5-826E-4CE2-98D6-336D8A2CE422@cooperw.in> In-Reply-To: <2D5158E5-826E-4CE2-98D6-336D8A2CE422@cooperw.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0030_01D17850.2D4C7FC0" MIME-Version: 1.0 Archived-At: Cc: CLUE Subject: Re: [clue] AD review: draft-ietf-clue-data-model-schema-12 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Mar 2016 14:03:20 -0000 ------=_NextPart_000_0030_01D17850.2D4C7FC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Alissa and Roni, > >> =3D Section 11.27.2 =3D > >> > >> Why is the media type attribute optional? > > [Roni Even] I think the second part of the section explains it. >=20 > I don=E2=80=99t think it does. A simultaneous set is defined as a set = of captures that all > have the same type. So why would you send a set without indicating the > media type? There is some history to this. Originally, the simultaneous set was a = sequence of media captures or scene views. Since both of those things = already include a specific media type, there was no need to specify the = type again in the simultaneous set itself. Then later we added ability = to include an entire capture scene. Since a capture scene could contain = multiple media types, it now becomes necessary to specify which media = type applies to the simultaneous set. That is why we added the optional = media type attribute. Mark ------=_NextPart_000_0030_01D17850.2D4C7FC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUEjCCBQ0w ggL1oAMCAQICEBrVY02YeFKcQ+zVfznU/o4wDQYJKoZIhvcNAQEFBQAwGTEXMBUGA1UEAxMOUG9s eWNvbS1Sb290Q0EwHhcNMTMxMTA0MTg1NzA2WhcNMjMxMTA0MTkwNjU4WjAZMRcwFQYDVQQDEw5Q b2x5Y29tLVJvb3RDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMzj+6krY3OF7mtq +O2/yC5heUML7DFZn2cp0Mkp/vos7TDrysGdPDdEIK+zYvZQZs6TrGzPh0XXnEpMcHE7V4nD5zN3 VX0+Zg46w0wCHdkgq/GV3EKlyg0AsX8LgooGlUMeuUNpe+sT0WBl3mXB97TUw7mnRLY1m/IAlyFv 4XO8LfQ1L03vfLBRAVft7xc9Okm6DbHrPxFx9VKpgIkSIUvIx/BK0zXBa/0arWW3tfimfY9t5KdJ Wqb68E8Nb0bD8S0Ve0O76TCR4dVE/HmVj6YrauGcUGfvB4yT+bOOCGlsOw3NoHW2G9PZJF9B9PvV cWzv9Jw3AlzGU2sQMbVD1ZiiRgkG47bvqvi/tg38vWEDMj1lzSpMp/FhC8YrSaGb4YwjM52w9MXM DNypbOFZ/0WjrykwuGB1P9Ga38nRlaMkMJ3lE7P1pQMgxElO5uE+1TI5kTJ9mIGgQtQb57w4vkkJ kHNKjmqzOo3IFkhEIUS3ARPkYG4HWzP7xtmcYBoEx4QwpbxYQKKcxN9h/zuv9LYc79WvnF+i+aj0 1YJKoldsPnIXhG3HullYVQb+v19q8cqm0OGUEq7e2wY72H6JiT6YFc5kZitpZ65L5d1OGVLyFO6b iC79ARA9eBE5L3g9zF/du+U1k9L6LWW3VaHr3ZDCECU8ZX5QeBrqv2aTb0VNAgMBAAGjUTBPMAsG A1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSMD03mpjCj/UgRICWESaXA53z3 0TAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAAOCAgEAs02vFW5Je6895ZBWadxy5vxR z2imWk97qU2sMFSMnmf9QeqPwdawGO33zWr1sSQr8d67AHQc+3ihZuoAaeQAAC6Lww9r17Q3vVqg 7Qge86101Xw1fjXqTFUnWTxBK0S7re7pMqWlqaFgFQOHBMLnrM9z+NQIyDh7st9JjA+bRfFwErQ9 5CziXu+o/4q7eDBP1WaI0yKkEcOQ2LyPuCCE4hcshcJABiSYPax8nW71foHb+bv92IYvYXu2Wpa6 VgnxYqdi2k0Yk8CDiYalVsc+7QH0euQ1YIcovPbpZ02AirLqiiy6XB9i8OKfuapKSftsdfjLKqwI L7lKqz/4uAheETQsORVEh4IT0P8RRaIgHBOBVz/DOW+/IiiYagOJIYqbwGIFImQ7uOLNCoP5qY4y PLUZhmHFnnr7xtz4gv455KP9cwtPYcAarc/IB7WkTmEhFYa19k4jXlZ19AZIO/SPhvV7qz50zqB+ pCReRB5fXnf3qhRSw2WpRD4xr/q8OrWTfQRdXaooTJ14tRziqjEWLz4nPQKbE45aAjgwO0Rp6k5J tWGPhCxmuru/iqVES98VbjuAoo2qYZk7eNrqcnMuSxgqU0bgyie/R/FfMcbsw6rAh7T+qfBSxVIQ tpiqPwtZR5kdi6af3vf4w9q1PvEGrNipAjKEN2HW73558qGfPMowggZ5MIIEYaADAgECAhNuAAAA AgUmZh85ZflDAAAAAAACMA0GCSqGSIb3DQEBBQUAMBkxFzAVBgNVBAMTDlBvbHljb20tUm9vdENB MB4XDTEzMTEwNDE5MTM1MFoXDTIzMTEwNDE5MDY1OFowSDETMBEGCgmSJomT8ixkARkWA2NvbTEX MBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAOZhKwn7h/qKsHx8zQQPT356Og5GOOJ26SKfzS6dIZaD NjFIhS/5QRd3HZ9I1qFD8faDfpIHL+NzC0xqYJUZsEKntD+cCj99nx33t9D6GCmsEEngeLV0FO/u DlDcCXVJNJWS65E05vKyWFPlIRegDs+E73mNh3dHZ53mgrsCFd8PnX5Zm6zm+dAinDTUreXzSuzT si5yuZ10jHdEoin3bQyYQfAe4nR7BiqcQzYnD+JgU+NrZZ555xMdwVtRhjIFuFHwCN1BgWL8+cmI PTmW3bS/irYkbUn/IYFXGJIdgeZTzsp22+OPChBkCBiy86d9RaM6qvOV/ZLmq0bj4souN1cNBg0g ZnYIgTypQY/5Ew99FJJDor4TH1R5YNtqgwxBiSZSc0WSKy8WBrcUpBM+FP1gETY2sqZh2ApFkhU1 7BBLXcEwu6dnSO9Y5u0zJfOTKPesVaeGTfvzTEcm6A8xKO6V+ai/zhu3egbv4SmlPGiMENMPsWRy cG0c73xz/w9RwpWpImjIcE3+XA9rPhIdNj2KN4sbMJvvN5/ZLJHRScE5F3pltq2sFLyPSqhukYVY NRVXmdJ14FCArDqlrREeWLA2tP4ir0WeFeX6KgU+QrmWvdw1hJZ9/lPkiqDvuBWvDVyON0u/Dvi3 p6RJmWJlC5F8ajRegnM+BAYfokRZkvOHAgMBAAGjggGJMIIBhTAQBgkrBgEEAYI3FQEEAwIBADAd BgNVHQ4EFgQUcIfA57S89xZAbs9iT83FhcVNeekwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEw CwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUjA9N5qYwo/1IESAlhEml wOd899EwbwYDVR0fBGgwZjBkoGKgYIYuaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtpL1BvbHlj b20tUm9vdENBLmNybIYuaHR0cDovL2NkcDIucG9seWNvbS5jb20vcGtpL1BvbHljb20tUm9vdENB LmNybDCBhgYIKwYBBQUHAQEEejB4MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMS5wb2x5Y29tLmNv bS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMi5wb2x5Y29t LmNvbS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQDAITSF89YEDKMA zqteWVdg8IqzdMHSHIJGybNrbe1UJj6trSldu42wcgjYLgJrTIDEUEX2Qp1xywpv+zpVAE1bVoek 6ot846XEIiOTofJYnwACZNnCLJ3ijG2iuBCSJjPc6FzwCF/2DMR0erdh8PNhEnl3xDRNyqVOy+DC mlLssSjPgej1UxM4yaDZZUCBrkv1dB3a4qkTbMPFBj5CkC5gPnyKTRW7iUFMKr0pXvByGPHCtRbu ShXAcoSdVH2f8cLUfJ8raVMWu1ynjOMcvlagDaZAcbzLSc8hzhxJNC6Wel9U1uFyEaYGodJTMxzv e5zRU5wZod5kPaEThCKq12Fr9Sz/dYYp4Rup/SymTS4A46qMIrOi6i3icxa3SYAhsCeALdcrgCH4 +cCtKiEE1UpqIfJq8P/+FE6cnfHyGaXD+wn4BTA5BrUBg900HNVNf1Y6BDMqaXDeAPKbiSb5FDot PjAW0v7GLoshHMr+951EdhaFNSUyOV8CoSx9b9BjlYpjJV+QtiaqJLn9UlNOa987Fg9dIY4vrfqH q9kCVr+sVpQsZ6DC17bE7etrHPevRny/EcLmuJY1RD56gPAyePHFs1GEhmKVW9ZlLWtNs79G6wSf ZRnr3vRAtr7v0zWyjfvn52HWM4kbXedjCa/q9boJMVqK+8DJawhrrn38Liw7oDCCCIAwggZooAMC AQICE2sAANv9iRUGFNx/sYkAAAAA2/0wDQYJKoZIhvcNAQELBQAwSDETMBEGCgmSJomT8ixkARkW A2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTAe Fw0xNjAyMTYxNzI1NTlaFw0xNzAyMTUxNzI1NTlaMIGnMRMwEQYKCZImiZPyLGQBGRYDY29tMRcw FQYKCZImiZPyLGQBGRYHcG9seWNvbTEPMA0GA1UECxMGUGVvcGxlMRIwEAYDVQQLEwlFbXBsb3ll ZXMxDTALBgNVBAsTBE5BTEExGDAWBgNVBAMTD0R1Y2t3b3J0aCwgTWFyazEpMCcGCSqGSIb3DQEJ ARYaTWFyay5EdWNrd29ydGhAcG9seWNvbS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDUKfyJTxXkwEsUnHz/9m3k1jNMh31VSjpcboNOXMLE7ERqwC+KdVON0NLHp5ctN4kWewuu YDOuS+Qhp/Pm/+T2acQ0cqw+oY3nvKl7erYfC5Ul0EATlD3aUTGz34L2iKttOm9YID2GylBH9670 PHQ7n3YqC5sh1C7l2S4CznZz5c4ATRw1VtAzWskinzwYWKeiJV2ybr4JU9EM5QAGqM84jFXV2kN2 3CGKmAWlo6GIXstg82hfTkfubmgW9BQ+iyHEfwP1DIvdLh4tsyrgHoz+qomNaXmG+jUiP5CktXDF KueQLciDeg9HyxGh7AgtTvdMtI3KZUFCDyKDN4k0ux/5AgMBAAGjggQBMIID/TA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiGpOVThtjlcoO1gRiEnaYag+m7OimFw9RYg9ngHQIBZAIBBzApBgNV HSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwCwYDVR0PBAQDAgWgMDUGCSsG AQQBgjcVCgQoMCYwCgYIKwYBBQUHAwIwCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDBDBEBgkqhkiG 9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZI hvcNAwcwHQYDVR0OBBYEFBENjiHBionI5U/bTdJlzr9d3XeNMB8GA1UdIwQYMBaAFHCHwOe0vPcW QG7PYk/NxYXFTXnpMIIBOgYDVR0fBIIBMTCCAS0wggEpoIIBJaCCASGGgbxsZGFwOi8vL0NOPVBv bHljb20tU1VCQ0EwMSxDTj12d2NvbG9zdWJjYTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXBvbHljb20sREM9Y29tP2Nl cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludIYvaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtpL1BvbHljb20tU1VCQ0EwMS5jcmyGL2h0 dHA6Ly9jZHAyLnBvbHljb20uY29tL3BraS9Qb2x5Y29tLVNVQkNBMDEuY3JsMIIBPQYIKwYBBQUH AQEEggEvMIIBKzCBrgYIKwYBBQUHMAKGgaFsZGFwOi8vL0NOPVBvbHljb20tU1VCQ0EwMSxDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz1wb2x5Y29tLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTA7BggrBgEFBQcwAoYvaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtp L1BvbHljb20tU1VCQ0EwMS5jcnQwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZHAyLnBvbHljb20uY29t L3BraS9Qb2x5Y29tLVNVQkNBMDEuY3J0MEgGA1UdEQRBMD+gIQYKKwYBBAGCNxQCA6ATDBFtYXJr ZEBwb2x5Y29tLmNvbYEaTWFyay5EdWNrd29ydGhAcG9seWNvbS5jb20wDQYJKoZIhvcNAQELBQAD ggIBAHSlqpzE3JJ6cwdt2ve4eLY7IBfvrGjyFRQRfUgHg7SpxJVjB1jIZY7xXeGcBozQDSO6nQF6 KN3s+Mhy1GgH0tRMZBqefwZaT0taRdMHH/bXxDE4Qf8BRMXNIPZPb+2CV4ldFakuT1VZwmg1Gdtc ZU41o/zXYUBkzjPRX4DaEBWDsxI8Z3OX0lz3Kps3CocagYE+sjTaPIEFF3Gztyw5I8fS/nMnrSq3 G91bqqWE0teuGfBdt6tKqavJ0qHobkOQRV2bQi6OPzLZg8a1IaSZMviUDgzj/VASvw7phEUScEVf VqAvoru/7TWREyoc/lSvsd+PTpMeOjLUDre/FAbRGpN9Sx8FuBgvvb3wYdIMg/R8tIaQ8tqaAG/3 dSa9IeRfWOrcAOuc8TUieSDsTqugStWtKVsO8dCcZtdaPpL0deSjjEF+Ep9ZfqufhibQyFGNTjRK VwgxCQc+owwJx69vo2oDlzwWYhASQmwXVW9eiSWnvvMhvAny5dftCFaV47mSyQimkQ3k/rsX2Cg9 qbeuI0dSSD5c5pgE6z3jkF8ISL/1WitwCtG5Yqqp7Q8G2a35smlSVRzc1WTAiy6jZHSPZsbnRu5Y 9BnsB/TOcmKt9kAn6VUAC4j+Rq7MokZJzmj0sKNMH4qz3bo6ZMImkGS3xCLyvsK4iilg1Me67dlz bbJ1MYIDdzCCA3MCAQEwXzBIMRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYH cG9seWNvbTEYMBYGA1UEAxMPUG9seWNvbS1TVUJDQTAxAhNrAADb/YkVBhTcf7GJAAAAANv9MAkG BSsOAwIaBQCgggHtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MDMwNzE0MDMxMlowIwYJKoZIhvcNAQkEMRYEFP9v0Ot3mV46Qcef77KsPqsbJ32YMG4GCSsGAQQB gjcQBDFhMF8wSDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20x GDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMQITawAA2/2JFQYU3H+xiQAAAADb/TBwBgsqhkiG9w0B CRACCzFhoF8wSDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20x GDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMQITawAA2/2JFQYU3H+xiQAAAADb/TCBqwYJKoZIhvcN AQkPMYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG 9w0BAQEFAASCAQAuYCRhYebTRcj3jkHOoIzYz8WtJ+/D8HrYHJVKT3ghEC6lSnB0bSRaejYaAm7M KjLfuzD2fyBA5RxmPd3gKRajKl3XRNVu5MbaNFOKXxErPJPSKbmCkoZ7iKynwVcyXOZ8fLPJUbGW X0UASLfy13l2aWIF0Ch3bLFaupxkrgLW50vdA7krHp8zJyHmE09/E/Ljh3tNzXGcFfAkrKARm6u3 uxmKReFuf7kF2aQ/de/d/2PK2Pi+yytbzQzjVriAeDMQdo+p7W48MxnjhSEW+RAq75bztHZ4lM0Q ni8S7WcElGnnBN2lc2UDPrdwTEtL+327FM/J3sOVBDQwLEa98reGAAAAAAAA ------=_NextPart_000_0030_01D17850.2D4C7FC0-- From nobody Mon Mar 7 11:42:19 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfc.amsl.com Received: from ietfc.amsl.com (localhost [IPv6:::1]) by ietfc.amsl.com (Postfix) with ESMTP id A18451CD9FE; Mon, 7 Mar 2016 11:42:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160307194217.22676.70021.idtracker@ietfc.amsl.com> Date: Mon, 07 Mar 2016 11:42:17 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-data-model-schema-13.txt 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: Mon, 07 Mar 2016 19:42:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : An XML Schema for the CLUE data model Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-data-model-schema-13.txt Pages : 72 Date : 2016-03-07 Abstract: This document provides an XML schema file for the definition of CLUE data model types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 7 11:43:01 2016 Return-Path: X-Original-To: clue@ietfc.amsl.com Delivered-To: clue@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 098CB1CDA15 for ; Mon, 7 Mar 2016 11:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLl3c4U1O30m for ; Mon, 7 Mar 2016 11:42:56 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 5EF081CDA11 for ; Mon, 7 Mar 2016 11:42:56 -0800 (PST) X-ASG-Debug-ID: 1457379773-05f2752c7bcd9190001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id AFgfwR2UvWrUFURq (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Mon, 07 Mar 2016 20:42:53 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u27JgmQ7008283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Mar 2016 20:42:48 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] AD review: draft-ietf-clue-data-model-schema-12 In-Reply-To: <09019183-3B33-4BF5-8646-207F000E6B17@cooperw.in> Date: Mon, 7 Mar 2016 20:42:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <78D5A005-8364-4DD1-974D-6689C8F9205E@unina.it> References: <09019183-3B33-4BF5-8646-207F000E6B17@cooperw.in> To: alissa@cooperw.in X-Mailer: Apple Mail (2.2098) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1457379773 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.27649 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 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, 07 Mar 2016 19:43:00 -0000 Hello Alissa, thanks a lot for your review. Please find in-line my answers to your = comments and observations. > Substantive comments: >=20 > =3D General =3D >=20 > (1) The use of normative language appears inconsistent in the = document. There are normative uses of MUST and also non-normative uses = of =E2=80=9Cmust,=E2=80=9D =E2=80=9Coptional,=E2=80=9D and = =E2=80=9Cmandatory.=E2=80=9D I would recommend a careful pass through to = establish consistency. We tried to perform the consistency check. We found out that most = =E2=80=9Cmusts=E2=80=9D hat to be normative (i.e., =E2=80=9CMUST=E2=80=9D)= and replaced them accordingly. As to =E2=80=9Coptional=E2=80=9D we are = not actually using it with an RFC2119 meaning. Such a term is mostly = used throughout the draft to indicate =E2=80=9Coptional=E2=80=9D XML = schema elements. We are hence inclined to leave them lowercase. What=E2=80= =99s your feeling about this interpretation? The same holds for = =E2=80=9Cmandatory=E2=80=9D, by the way. > (2) The definition of the simultaneous set type uses = while the definitions for content and capture ID = list use . Good catch. We replaced =E2=80=9CcaptureIDREF=E2=80=9D with = =E2=80=9CmediaCaptureIDREF" > Same goes for encoding ID, which is sometimes called =E2=80=9CencID=E2=80= =9D and sometimes called =E2=80=9CencodingID.=E2=80=9D If the difference = in name is not meaningful, the same names should be reused throughout. Done. We replaced =E2=80=9CencID=E2=80=9D with =E2=80=9CencodingID=E2=80=9D= . > (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 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. > (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 See my answer above to your comment number (3). What would you suggest = to improve the way we deal with extensibility? > =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= 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. > And why is it stated differently than how it=E2=80=99s stated in the = protocol doc? 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: - Protocol: 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. - Data Model: 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. 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? >=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? 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; = (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. 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. >=20 >=20 > =3D Section 11.10 =3D >=20 > (1) > "It indicates the criteria applied to build the > multiple content capture using the media captures referenced in > .=E2=80=9D >=20 > is not defined anywhere. Did you mean = ? Yes. > (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) These are actually consistent, respectively, with section 7.1.1.7. = (Presentation) and section 7.1.1.8. (View) of the framework document. > =3D Section 11.22 =3D >=20 > Why is this a SHOULD rather than a MUST? I believe we had identified some scenarios in which you might actually = decide to "spatially define=E2=80=9D a text capture; but these scenarios = do not come to my mind right now. I=E2=80=99ll replace SHOULD with MUST, = unless someone else finds a counter-example. > =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. 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). > =3D Section 11.27.2 =3D >=20 > Why is the media type attribute optional? 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. > =3D Section 15 =3D >=20 > (1) What does =E2=80=9Cfull-optional=E2=80=9D mean? 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? > (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. 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. >=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. Agreed. > 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). 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. > =3D Section 11.1 =3D >=20 > s/(e.g., simultaneous sets, capture encodings, and others)/(e.g., = simultaneous sets, capture encodings, and others via ) Done. > =3D Section 11.7 =3D >=20 > s/last ones/latter ones/ Done. > =3D Section 11.29.1.2 =3D >=20 > I think this section should point to Appendix A in the ecrit document. Done. Thanks again for your feedback and comments! Simon >=20 >=20 >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Mar 7 11:46:41 2016 Return-Path: X-Original-To: clue@ietfc.amsl.com Delivered-To: clue@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 514E91CDA04 for ; Mon, 7 Mar 2016 11:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCE6-aSdmo5b for ; Mon, 7 Mar 2016 11:46:39 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 5986A1CD9FB for ; Mon, 7 Mar 2016 11:46:39 -0800 (PST) X-ASG-Debug-ID: 1457379997-05f2752c7bcd9400001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id gjN6ridbSGYEATa3 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 07 Mar 2016 20:46:37 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u27Jkajs008650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Mar 2016 20:46:37 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] I-D Action: draft-ietf-clue-data-model-schema-13.txt In-Reply-To: <20160307194217.22676.70021.idtracker@ietfc.amsl.com> Date: Mon, 7 Mar 2016 20:46:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <88E69334-3FD8-4FB8-8AAE-8D1567E48ABE@unina.it> References: <20160307194217.22676.70021.idtracker@ietfc.amsl.com> To: clue@ietf.org X-Mailer: Apple Mail (2.2098) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1457379997 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.27650 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-data-model-schema-13.txt 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, 07 Mar 2016 19:46:40 -0000 Just to warn you that this is a =E2=80=9Ctemporary=E2=80=9D new version = trying to address (most of) the comments we received last week. More = modifications are supposed to come as soon as we gather further feedback = from Alissa (and others). Cheers, Simon > On 07 Mar 2016, at 20:42, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the ControLling mUltiple streams for = tElepresence of the IETF. >=20 > Title : An XML Schema for the CLUE data model > Authors : Roberta Presta > Simon Pietro Romano > Filename : draft-ietf-clue-data-model-schema-13.txt > Pages : 72 > Date : 2016-03-07 >=20 > Abstract: > This document provides an XML schema file for the definition of CLUE > data model types. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-13 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-data-model-schema-13= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 From nobody Tue Mar 8 11:36:00 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 7623B12D89E for ; Tue, 8 Mar 2016 11:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsHT25gDs20S for ; Tue, 8 Mar 2016 11:35:52 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3AA12D721 for ; Tue, 8 Mar 2016 11:35:52 -0800 (PST) Received: by mail-ob0-x229.google.com with SMTP id m7so24252616obh.3 for ; Tue, 08 Mar 2016 11:35:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=woaktHTKfUSdiJ3XkI7+Ggwxf5+aFTEwcu7FEP1tRBU=; b=mLsnK5rxhYnz6ec5Teik/UJKBoDn5dXrYrzqFLRaJkKohRdtBamsjcq2VubP5FhQfG s28gIO9e5dfj21HsXlzl89/3oeic98rmFm9WJotbDD03tbMSXCw4YNasjOldEGsy738J /9YtNPKOLaPvBr9C06M9p1zhcpZMSsXGi0RxcGZFJ3ScuqyU9PvBoNvvkwY5VN7KIOGF JfPv6mDf7WuBHmBsuCwQXGszU+CMPUqI6oEgAkCGLGMD6G3Ny0Lac+7SGBYoEiyMpy45 8xFn3HTPZZvoMNc3/I5ou/CVTNcUnysEivf7muYC4yNmU8ZMVOguEkPzTBJTFlk2fuTB CqZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=woaktHTKfUSdiJ3XkI7+Ggwxf5+aFTEwcu7FEP1tRBU=; b=Ju/W8mqIiVBscOZYdarqLTXyzOXx4G6j8azPXB/0j//wZZUFdHmVXPtkyT2vBrdLto MxUplyLx+1ZKymw89d/Oxlwu9mmXMQ6JV2Lb7csx+6M+OxAEZB3d9a3I6vAXXKcoS67U K6FvyV8SGungyMfvu7l/ub9Is+/r0cN8gfsY8sfeZ8vnvAwdiRSY36R3ITf38ghre7lT WQQ9O/C6LsYw748nC+/6bgmGLVCaUBN6sdQuVFNbcyxRFPXCpmLHkcMBUc4EYBf3JOKQ IufwCsUN/RMNy+B/99Zs/TXV8tzxpqZTmTODZdXmHivUA+qT5OFbegBh+s61HkcXEIxY b7xQ== X-Gm-Message-State: AD7BkJKA4pbRz/zrOLaWwlh5VC3nKXjjluLNox/cLXLeLJj4V74i0FBc4Y4KrlPG1xDeOOygyzU+vif4264Gmg== MIME-Version: 1.0 X-Received: by 10.60.141.227 with SMTP id rr3mr17488027oeb.57.1457465752165; Tue, 08 Mar 2016 11:35:52 -0800 (PST) Received: by 10.202.85.12 with HTTP; Tue, 8 Mar 2016 11:35:52 -0800 (PST) Date: Tue, 8 Mar 2016 14:35:52 -0500 Message-ID: From: Daniel Burnett To: "clue@ietf.org" Content-Type: multipart/alternative; boundary=047d7b33957d6e27d5052d8eb009 Archived-At: Subject: [clue] WGLC for draft-ietf-clue-rtp-mapping-06 ends 18 March 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, 08 Mar 2016 19:35:56 -0000 --047d7b33957d6e27d5052d8eb009 Content-Type: text/plain; charset=UTF-8 This message announces the start of a 1.5 week WGLC for draft-ietf-clue -rtp-mapping. The last call will end at midnight on Friday, 18 March 2016 to allow time for a rev before the 21st. PLEASE REVIEW NOW. -- Dan (for the Chairs) --047d7b33957d6e27d5052d8eb009 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This message announces th= e start of a 1.5 week=C2=A0WGLC=C2=A0for draft-ietf-= clue-rtp-mapping. The last= call will end at=C2=A0midnight=C2=A0on=C2=A0Friday,=C2=A018 March 2016 to allow time f= or a rev before the 21st.

PLEASE REVIEW NO= W.

-- Dan (for the Chairs)

--047d7b33957d6e27d5052d8eb009-- From nobody Wed Mar 9 00:31:29 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 92B2112D50C for ; Wed, 9 Mar 2016 00:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsmv5bXjuNfj for ; Wed, 9 Mar 2016 00:31:26 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CDC12D517 for ; Wed, 9 Mar 2016 00:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=qkVx2RIsCelTHID3jz2RGUfgqC4zTln9F+KBML2UJUQ=; b=nhlxVUddH1hfGf1NXD54pduIEz pg0wEwfvhQIbh0uG/CBSykPGUjlI9J7rBEkLVhljAgtFCV0aSoXMhXqtos8hpqL1kB4zIFhTJKZQW Tf5m4YAKenJN0oukPPlXagfB4/RJZWcqOAuH6ueo9Wbi1U/Olekr+2+VxW/yVogdAvB+o8O0wEouV mK4hKmAs/XJBZCC3HKPNewOqUId65Ru3yjWr4xwZoya3GA25IEqsgWI9CZEeUESFlCAcMGygAITjm ys129GJ31o9ZeVnqoryhSKxYI4Ib85sAK8jV8MMnRKdu8pi8Xcv9rFlMC8PVH2rwa6d8ufPic8uQi 5PeAxHcw==; Received: from ppp118-209-64-163.lns20.mel4.internode.on.net ([118.209.64.163]:55865 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1adZWd-002QME-SW for clue@ietf.org; Wed, 09 Mar 2016 19:31:24 +1100 To: clue@ietf.org References: From: Christian Groves Message-ID: <56DFDF57.2020003@nteczone.com> Date: Wed, 9 Mar 2016 19:31:19 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-06 ends 18 March 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: Wed, 09 Mar 2016 08:31:28 -0000 Hello, I didn't see any major issues. Mostly all editorial. Here are my comments: General: The draft should settle on one form for "Media Capture" sometimes its "media Capture" sometimes "capture" etc. Clause 1 para 1: Add (MC) after first usage of Media Capture. Clause 1 para 3: Define MCU on first usage. Clause 1 para 3: "... RTP[RFC3550] media streams...", Should “media” be removed to align with “RTP Stream” from rfc7656#section-2.1.10? Clause 1 para 4: I think the draft should talk about "CLUE" architecture rather than "telepresence" architecture. Clause 1 para 5: CLUE supports audio, video AND "text". We should add "text" to the usages of "audio and video" in the draft. Clause 3 para 1: The clause introduces various RTP topologies, we should use the names as specified in RFC7667 with the same capitalisation etc., e.g. Media-Mixing Mixers. Later on in the draft it starts using the short names e.g. topo-mixer. Perhaps the draft should use the full name and short name on first usage and then use the sort name from then on? Clause 3 para 2: Add "... is point-to-point may nonetheless have RTP stream which..." Clause 3 para 3: Change "available" to "determined" in "....media and media-id (SSRC) can be using the conference..." Clause 4 para 2: Delete two words "...For example, main and slides video sources are separated into <> RTP sessions based on the content attribute [RFC4796]. This solution <> is straightforward if the multiplexing ..." Clause 4 para 3: I don't think CLUE "recommends" using BUNDLE. draft-ietf-clue-signaling-07#section-7.1 indicates CLUE “MAY” support BUNDLE. The paragraph should be reworded accordingly. e.g. /"Even though Session multiplexing is supported by CLUE, for scaling reasons, CLUE indicates that SSRC multiplexing in a single or multiple sessions using [I-D.ietf-mmusic-sdp-bundle-negotiation] may be used. When SSRC multiplexing is used, the mapping of RTP streams to Captures Encodings needs to be considered."/ Clause 4 2nd last para: Should clean up the use of MCU/Mixer, some places its MCU / Mixer other Mixer/MCU etc. Also TelePresence should be Telepresence. Clause 4.1 1st para: Delete word "This section provides an overview of the RFCs and drafts that <> can be used in a..." Clause 4.1 para 5: This needs some reword. "It" seems to refer to the image attribute offerring separate RTP sessions. Clause 4.1 last para: Is this paragraph needed? Sounds more like something you'd see in a contribution rather than a specification. Clause 4.4 para 1: Add "Dynamic mapping by tagging..." Clause 4.4 para 3: "However, the disadvantage in using a mid in the stream that it..." Clause 4.4 para 4: "In this case, may require up to an additional 12 bytes in the RTP header..." Clause 4.4 para 4: Whilst its true there's significant bandwidth increase for very low bandwidth audio codecs are these really candidates to be used for Telepresence/CLUE which would imply a higher quality codec. Clause 4.5: Add "s" to "CLUE endpoints" and delete leading "[" on the reference. Clause 5 para 1: Duplicated word "section Section". Clause 5: The section talks about "mid". Is this the "mid" used in the CLUE group or? E.g. a CLUE controlled m-line may also have a mid used for BUNDLE. Clause 6 para 1: I propose rewording slightly to clarify the use: /For MCCs which can represent multiple switched MCs there is a need to// // know which MC represents the current RTP stream<.> This requires a mapping// // from an RTP stream to an MC. In order to address this mapping this// // document defines an RTP header extension that includes the CaptureID// // in order to map to the original MC allowing the consumer to use the// // MC attributes like the spatial information. The media provider MUST// // send for MCC the captureID of the current MC in the RTP header and as// // a RTCP SDES message./ Clause 6.1 Header figure: The separator "|" for ID seems to be in the wrong place. It should be between the 7 and 8 not under 9. Also should we include a note for the RFC editor to replace the XXX? Clause 6.2 Header figure: The separator "|" for ID seems to be in the wrong place. It should be between the 7 and 8 not under 9. There's a similar issue for the next separator. Also "Len-1" I think can simply be "Length". The second instance of "CaptureId" could be deleted. Also should we add how the CaptureID (IDRef) is encoded, i.e. UTF-8 text? Clause 6.2: Missing letter " Packets tagged by the sender with the CapturId then contain a header extension as shown below..." Clause 7: The "composed" and "switched" attributes should be removed as they are no longer defined in the framework. I think this is also an issue for the protocol document. Clause 7: If understand the example "MaxCaptures" I think should be "3" to indicate switched and composition. Not "1" which indicates switching. Regards, Christian On 9/03/2016 6:35 AM, Daniel Burnett wrote: > This message announces the start of a 1.5 week WGLC for > draft-ietf-clue-rtp-mapping. The last call will end at > midnight on Friday, 18 March 2016 to allow time for a rev before the 21st. > > PLEASE REVIEW NOW. > > -- Dan (for the Chairs) > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Mar 9 14:43:34 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 370FF12DAAD for ; Wed, 9 Mar 2016 14:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 uyZNyscLPnEK for ; Wed, 9 Mar 2016 14:43:30 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C8612DAB6 for ; Wed, 9 Mar 2016 14:43:12 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-02v.sys.comcast.net with comcast id Tyj01s0012S2Q5R01yjCMP; Wed, 09 Mar 2016 22:43:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with comcast id TyjB1s00K3KdFy101yjBnT; Wed, 09 Mar 2016 22:43:12 +0000 To: clue@ietf.org References: From: Paul Kyzivat Message-ID: <56E0A6FF.1010306@alum.mit.edu> Date: Wed, 9 Mar 2016 17:43:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457563392; bh=zhP6VQ+Hy2+/ouRXqN8azzWMXT7hRxxwQPmTeKnGUj8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=gFrS5L8by4FAI/L3Yb0HtqKaCpFh80P4rWPwFViC4KBN1Txy5uHBQbmOxLZN74eef MDaliK6nKA3xZ1cUVmyBYhvA5kGfdJIvcIaCVmlAtS/tvpnT8QoEZi/OShMAsDDt6J BUeuRwDizqF34cxRowf8eyQBIicGoQwdH/yjgnPFX5AJAQIywGOivRsc1gK/SUfK8G Im6hTp6+gsqmaGZ1ODL7MOaO9/nVzXBeTjHQyuYpIQllSyIEfPfLfG6ZONaenMjk01 vZ+B+XVkqU/rv+ukyztPbS52s3SW2C4ZnicmNXsXK9KI/o3mk6I5Wr3yjZ/CsJIJPG 8ZFUsmjRN92dA== Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-06 ends 18 March 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: Wed, 09 Mar 2016 22:43:32 -0000 On 3/8/16 2:35 PM, Daniel Burnett wrote: > This message announces the start of a 1.5 week WGLC for > draft-ietf-clue-rtp-mapping. The last call will end at > midnight on Friday, 18 March 2016 to allow time for a rev before the 21st. > > PLEASE REVIEW NOW. In general I find this draft to be in good shape. I saw that Christian already offered a lot of editorial comments. I won't try to compete with that. I did find a few things: * General: There are assorted language problems with articles, plurals, etc. I didn't try to note them. * Section 4.1: There are a couple of instances of [I-D.ietf-mmusic-sdp-bundle-negotiation] and one instance of [bundle] that isn't linked. I expect they should all be the same. It would improve readability if you used mnemonic tags for the references (e.g. [bundle]) rather than the default. It seems this is logically a list of "tools". It would read better if it were formatted as a list. As it is, it isn't obvious which paragraphs start new list items. * Section 5: This can be done by a Selective Forwarding middlebox, but not by a Switching Mixer. The last requirement can be accomplished through an FIR message [RFC5104], though potentially a faster mechanism (not requiring a round-trip time from the receiver) would be preferable. I don't see how the final comment on a faster mechanism is helpful in the document at this point. I don't know how to take: For a Selective Forwarding middlebox, this may be a problem since an encoding can be used by a single MC, it will require using the same SDP label for multiple MC (example middle camera and active speaker MC) this can also be done for an environment with a hybrid of mixer topologies and static and dynamic captures. If using the same label for multiple MC is a solution, then why might there be a problem? OTOH, if that usage isn't defined, then why is it suggested? (I am unsure whether this usage is allowed.) Thanks, Paul From nobody Sat Mar 12 09:40:53 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 1B63912DDAD; Fri, 11 Mar 2016 15:05:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230531.15028.6511.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:31 -0800 Archived-At: X-Mailman-Approved-At: Sat, 12 Mar 2016 09:40:52 -0800 Cc: clue@ietf.org Subject: [clue] clue - Requested session has been scheduled for IETF 95 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: Fri, 11 Mar 2016 23:05:31 -0000 Dear Roni Even, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. clue Session 1 (1:00:00) Friday, Afternoon Session I 1220-1320 Room Name: Atlantico B size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: ControLling mUltiple streams for tElepresence Area Name: Applications and Real-Time Area Session Requester: Roni Even Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 40 Conflicts to Avoid: First Priority: rmcat avtcore avtext mmusic payload rtcweb xrblock dispatch netvc perc Special Requests: --------------------------------------------------------- From nobody Mon Mar 14 21:20:22 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 A0D9312D596; Mon, 14 Mar 2016 21:20:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160315042018.23861.50476.idtracker@ietfa.amsl.com> Date: Mon, 14 Mar 2016 21:20:18 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-signaling-08.txt 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: Tue, 15 Mar 2016 04:20:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : CLUE Signaling Authors : Paul Kyzivat Lennard Xiao Christian Groves Robert Hansen Filename : draft-ietf-clue-signaling-08.txt Pages : 37 Date : 2016-03-14 Abstract: This document specifies how CLUE-specific signaling such as the CLUE protocol [I-D.ietf-clue-protocol] and the CLUE data channel [I-D.ietf-clue-datachannel] are used with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-signaling-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 14 21:22:41 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 D35CB12D773 for ; Mon, 14 Mar 2016 21:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 WqPK0vWVMW41 for ; Mon, 14 Mar 2016 21:22:37 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9482912D6BF for ; Mon, 14 Mar 2016 21:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5944; q=dns/txt; s=iport; t=1458015757; x=1459225357; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=NjbPSAStiaV7u2j03y0y48Rh0mR3Njc4G+MNVK3JhLA=; b=N7Y9rVER8josv+SfUJc8Cug19Yg9UIL0GhjcrEgXH2DIjHdtmFHi7TWZ ESQFY5Ab8Kf/GQj1EB83o9QTQbLsk+JEI4KT2gs/XdIjtIxccgj5lxzBs jaa9KHIz7YvX4N2eXX3xMNsyYOecR7NG0C0RV+BbKbOZIrEBTOcviFzEQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A8AgDJjOdW/5RdJa1dg0ZSbQa6RgENg?= =?us-ascii?q?XAXCoVsAoEwOBQBAQEBAQEBZCeEQQEBAQQBAQE3NBcEAgEIEQQBAQEeCQcnCxQ?= =?us-ascii?q?JCAIEARIIiB0OvCoBAQEBAQEBAQEBAQEBAQEBAQEBAQEVilyIdQWXSwGFbYJyh?= =?us-ascii?q?RmBbEuDfohXhgqIdAEeAQFCggMZgUlqiWV+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,337,1454976000"; d="scan'208";a="248577441" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2016 04:22:36 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u2F4MaFZ021619 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 04:22:36 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 14 Mar 2016 23:22:35 -0500 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1104.009; Mon, 14 Mar 2016 23:22:35 -0500 From: "Rob Hansen (rohanse2)" To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] I-D Action: draft-ietf-clue-signaling-07.txt Thread-Index: AQHRVGjyxUYCCMKKhk6gmj1X41hH5p8GlEeAgADNFoCAUtntMA== Date: Tue, 15 Mar 2016 04:22:35 +0000 Message-ID: <1dd8eb0fd9f84d92bf7c4766197bb386@XCH-RCD-016.cisco.com> References: <20160121162918.2158.51064.idtracker@ietfa.amsl.com> <56A10D0B.2020509@cisco.com> <56A1B915.6040800@nteczone.com> In-Reply-To: <56A1B915.6040800@nteczone.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.85.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt 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, 15 Mar 2016 04:22:40 -0000 Hi Christian, Have just uploaded a new draft, incorporating your suggestions - thank you = for providing them. On the section on disabling CLUE mid-call it is now exp= licit about the procedure for doing so. It also covers what to do if the fa= r end does so, and clarifies that if the data channel fails or is closed wi= thout a corresponding SDP negotiation to disable it CLUE-controlled media s= hould continue to flow. Rob -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves Sent: 22 January 2016 05:08 To: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt Hello Rob, Thanks for the update. A couple of comments: cl. 4.5.2.2 adds "lines for compatible encodings" - is compatible the right= term here? Isn't it more "accepted encodings"? cl. 4.5.4.3: I've made a comment a couple of times now about the need to me= ntion SCTP reset for disabling CLUE mid call but it appears to be missed. B= oth draft-ietf-clue-datachannel (cl.3.2.7) and draft-ietf-mmusic-data-chann= el-sdpneg (cl.5.2.4) both mention that an SCTP SSN reset has to be performe= d.=20 draft-ietf-mmusic-data-channel-sdpneg (cl.5.2.4) mentions that its protocol= specific whether this is announced by SDP. So I would propose to word the first paragraph of cl.4.5.4.3 differently: "If order to close a CLUE data channel in an ongoing CLUE-enabled call, an = endpoint shall follow the procedures for closing a data channel defined in = clause 5.2.4 [draft-ietf-mmusic-data-channel-sdpneg] by sending a new SDP o= ffer/answer exchange and subsequent SCTP SSN reset for the CLUE channel. In the event that this occurs, CLUE is no longer enabled and sending of=20 all CLUE-controlled media associated with the corresponding CLUE group=20 MUST stop. If the data channel is still present but not included in the CL= UE group semantic CLUE protocol messages MUST no longer be sent." Regards, Christian On 22/01/2016 3:53 AM, Robert Hansen wrote: > Hi all, apologies that this took longer than intended to revise and=20 > check. > > Thanks to all the reviewers - almost all suggestions were=20 > incorporated, usually as-is when suggested text was provided. > > * Removed the entire 'Media line directionality' section as a=20 > discussion of the pros/cons of using bidirectional vs unidirectional=20 > schemes wasn't suitable for a finalised version. The unidirectionality=20 > requirement is covered normatively in an earlier section. > > * BUNDLE no longer includes an address synchronisation step so the=20 > suggestion to wait until that done has been replaced with some general=20 > language about following any negotiated extensions. > > * Added OPTIONS negotiation to the example flow, and revised the flow=20 > to ensure it matched protocol document. > > * Section on not sending CLUE control media until CLUE negotiation=20 > completes narrowed to notify that only RTP should not be sent until=20 > negotiation completes and add RTCP to the list of things that should=20 > be sent as normal, in line with a=3Dinactive. > > * Make explicit that m=3Drecvonly lines don't need to have a label, as=20 > only m=3Dsendonly lines are referenced by CLUE protocol messages. > > * Fix formatting of IANA sections. Improve syntax of feature tag=20 > section in line with Paul's suggestions. Definition of feature tag=20 > narrowed to be multiple media lines 'negotiated via CLUE protocol' > rather than more generic 'multiple media lines'. > > One thing that Paul brought up was that in 5.1 "Later there are=20 > references to named states and transitions in the clue protocol. These=20 > don't seem to be consistent with the current state machine=20 > definitions" - I've checked and to me they seem to be consistent with=20 > the state machines in the protocol document. > > Rob > > On 21/01/16 16:29, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >> This draft is a work item of the ControLling mUltiple streams for=20 >> tElepresence Working Group of the IETF. >> >> Title : CLUE Signaling >> Authors : Paul Kyzivat >> Lennard Xiao >> Christian Groves >> Robert Hansen >> Filename : draft-ietf-clue-signaling-07.txt >> Pages : 36 >> Date : 2016-01-21 >> >> Abstract: >> This document specifies how CLUE-specific signaling such as the CLUE >> protocol [I-D.ietf-clue-protocol] and the CLUE data channel >> [I-D.ietf-clue-datachannel] are used with each other and with >> existing signaling mechanisms such as SIP and SDP to produce a >> telepresence call. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-clue-signaling-07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-signaling-07 >> >> >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at=20 >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Mon Mar 14 21:34:47 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 4D90212D5D9 for ; Mon, 14 Mar 2016 21:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 76UWtiA6BBLD for ; Mon, 14 Mar 2016 21:34:43 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763BF12D8B4 for ; Mon, 14 Mar 2016 21:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8046; q=dns/txt; s=iport; t=1458016481; x=1459226081; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=bDASSV2Ab88Y0oZ/nFw6tVUSJ/u1BxoMviaqa8NkQrI=; b=SSblG7UE2gSi2eWB0olZg4U4pJpglpPk/6QdjdnrMyj0wYHs/jp09n1F rq+CvV06BDBw+7Un25zSmWLn4+eQBBp8rHFqrpfPNm/zTrIkEo/gv7+gN m6oqIqpns18nxkTmgNh3m6Q6kElEXPOeRR35cgWd+zJfIsRlDrsyKI+AL 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A8AgB8kOdW/4UNJK1dDoM4Um0GukYBD?= =?us-ascii?q?YFwFwqFbAKBMDgUAQEBAQEBAWQnhEEBAQEDAQEBATc0BAwHBAIBCA4DBAEBAR4?= =?us-ascii?q?JBycLFAkIAgQBEgiIFQgOA7wmAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYpchAsRA?= =?us-ascii?q?YRYBYVWgguLIoRIAYVthVuCMIFsS4N+iFeGCoh0AR4BAUKCAxmBDjtqiSgGAxc?= =?us-ascii?q?dfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,337,1454976000"; d="scan'208";a="249371266" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2016 04:34:40 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u2F4Ye51005962 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 04:34:40 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 14 Mar 2016 23:34:39 -0500 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1104.009; Mon, 14 Mar 2016 23:34:39 -0500 From: "Rob Hansen (rohanse2)" To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] I-D Action: draft-ietf-clue-signaling-07.txt Thread-Index: AQHRVGjyxUYCCMKKhk6gmj1X41hH5p8GlEeAgAaJXgCATR4wQA== Date: Tue, 15 Mar 2016 04:34:39 +0000 Message-ID: <786b15336ce74c29a8d9833c55e26db7@XCH-RCD-016.cisco.com> References: <20160121162918.2158.51064.idtracker@ietfa.amsl.com> <56A10D0B.2020509@cisco.com> <56A688C4.3010906@alum.mit.edu> In-Reply-To: <56A688C4.3010906@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.85.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt 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, 15 Mar 2016 04:34:45 -0000 Hi Paul, have just uploaded a new draft incorporating your review - thank y= ou for the attention to detail. I did indeed manage to miss your section 8 comments on the previous revisio= n - apologies for that. I worked on the revision offline and pulled what I = thought was all the relevant emails with review comments but missed that on= e, so only included the basilar comments that were discussed further in a s= ubsequent email.=20 > About the flow: The call flow shows INVITE 2 followed by a clue=20 configure and response followed by 200 ok. This certainly encourages the=20 inference that there is a dependency on doing the configure before=20 sending the invite response. That is contrary to protocol requirements.=20 (And the same holds for INVITE 3.) Agreed - have rearranged messages and changed text to make clear that ther= e should be no such dependency and that the SIP 200 OK should be send indep= endently of the CLUE Configure message. > Also, there should be responses for the Advertisements. Added. > This shows Alice's advertisement going first, and Bob's advertisement=20 being sent after receiving Alice's. This is of course possible, but it=20 may suggest that there is a cause/effect relationship. It would be good=20 to at least mention that the decisions are independent. It might make=20 sense to show the messages crossing on the wire, making it clear that=20 they are independent. Have added text to the effect that both sides send their messages independe= ntly, and adding the ACKs after both are sent helps clarify this. > you get to the point where Alice sends INVITE 2. At this point,=20 both Alice and Bob need to update the SDP. There is potential for a race=20 condition for who goes first. Why is it that Alice goes first, and Bob=20 doesn't try before receiving Alice's reINVITE? It would be good to=20 explain this. (Or simply state that this just of of several ways this=20 might play out depending on timing.) Have kept Alice sending her INVITE first in the example to reduce complexit= y but have added a paragraph pointing out that this isn't the only way to d= o it and that often both sides will send their INVITEs and resolve this via= glare resolution. > I think it would be good to show the 200 for INVITE 2 prior to sending=20 the Configure. This will make clear that the sip signaling not be=20 delayed. Or just mention that they are both sent nearly concurrently. I've kept the Configure message first as we do earlier say to do CLUE befor= e SDP, but have made clear in the text that they are sent independently and= at pretty much the same time; both are shown as sent before the far end se= nds an ACK or CONFIGURE RESPONSE > Finally, there should probably be another O/A at the end to completely=20 disable the non-clue media. (Maybe it would be interesting to show that=20 one end keeps the non-clue media until the clue media is flowing, while=20 the other end stops receiving the non-clue media as soon as it confirms=20 this will be a clue call.) The SIP OK 3 from Alice disables the non-clue media so I don't think there'= s a need for an additional O/A.=20 Thanks both for the original review and pointing out I'd missed making some= of the revisions. Rob -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 25 January 2016 20:43 To: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt On 1/21/16 11:53 AM, Robert Hansen wrote: > Hi all, apologies that this took longer than intended to revise and check= . > > Thanks to all the reviewers - almost all suggestions were=20 > incorporated, usually as-is when suggested text was provided. This generally looks good. I found a few nits while reading: * Section 4.5.3.1: s/"m=3D" line to send or receive/"m=3D" lines to send or receive/ * Section 4.5.4.3: s/distinct to/distinct from/ (This isn't new, I missed it previously.) As written I think it means the o= pposite of what it intends. * Section 8: Did you attempt to address my comments in: http://mailarchive.ietf.org/arch/msg/clue/gYAy7v42JN8uxFz53qxBVki7OBY I see a few of the editorial ones addressed, but not the substantial ones. = For the most part the meaty ones still apply. Thanks, Paul > * Removed the entire 'Media line directionality' section as a=20 > discussion of the pros/cons of using bidirectional vs unidirectional=20 > schemes wasn't suitable for a finalised version. The unidirectionality=20 > requirement is covered normatively in an earlier section. > > * BUNDLE no longer includes an address synchronisation step so the=20 > suggestion to wait until that done has been replaced with some general=20 > language about following any negotiated extensions. > > * Added OPTIONS negotiation to the example flow, and revised the flow=20 > to ensure it matched protocol document. > > * Section on not sending CLUE control media until CLUE negotiation=20 > completes narrowed to notify that only RTP should not be sent until=20 > negotiation completes and add RTCP to the list of things that should=20 > be sent as normal, in line with a=3Dinactive. > > * Make explicit that m=3Drecvonly lines don't need to have a label, as=20 > only m=3Dsendonly lines are referenced by CLUE protocol messages. > > * Fix formatting of IANA sections. Improve syntax of feature tag=20 > section in line with Paul's suggestions. Definition of feature tag=20 > narrowed to be multiple media lines 'negotiated via CLUE protocol' > rather than more generic 'multiple media lines'. > > One thing that Paul brought up was that in 5.1 "Later there are=20 > references to named states and transitions in the clue protocol. These=20 > don't seem to be consistent with the current state machine definitions" > - I've checked and to me they seem to be consistent with the state=20 > machines in the protocol document. > > Rob > > On 21/01/16 16:29, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >> This draft is a work item of the ControLling mUltiple streams for=20 >> tElepresence Working Group of the IETF. >> >> Title : CLUE Signaling >> Authors : Paul Kyzivat >> Lennard Xiao >> Christian Groves >> Robert Hansen >> Filename : draft-ietf-clue-signaling-07.txt >> Pages : 36 >> Date : 2016-01-21 >> >> Abstract: >> This document specifies how CLUE-specific signaling such as the CLUE >> protocol [I-D.ietf-clue-protocol] and the CLUE data channel >> [I-D.ietf-clue-datachannel] are used with each other and with >> existing signaling mechanisms such as SIP and SDP to produce a >> telepresence call. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-clue-signaling-07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-signaling-07 >> >> >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at=20 >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Tue Mar 15 08:17:43 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 8531712DCAB for ; Tue, 15 Mar 2016 08:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 ZQgONWsJohWn for ; Tue, 15 Mar 2016 08:17:38 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A5D12DB62 for ; Tue, 15 Mar 2016 08:17:33 -0700 (PDT) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-06v.sys.comcast.net with comcast id WFEd1s0094s37d401FHZGd; Tue, 15 Mar 2016 15:17:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-01v.sys.comcast.net with comcast id WFHY1s00J3KdFy101FHYom; Tue, 15 Mar 2016 15:17:33 +0000 To: "Rob Hansen (rohanse2)" , "clue@ietf.org" References: <20160121162918.2158.51064.idtracker@ietfa.amsl.com> <56A10D0B.2020509@cisco.com> <56A688C4.3010906@alum.mit.edu> <786b15336ce74c29a8d9833c55e26db7@XCH-RCD-016.cisco.com> From: Paul Kyzivat Message-ID: <56E8278A.9070107@alum.mit.edu> Date: Tue, 15 Mar 2016 11:17:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <786b15336ce74c29a8d9833c55e26db7@XCH-RCD-016.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458055053; bh=rjgqxJb3HTqjPGOog/trbZdZEf1M2uJ5uxKBva9ejlU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=qSKs2sI0MBK8An5u55FvLzg+azf81yNOpftbi4BV3kXAs+nkQ56jvFeP9UBi0TAvZ IhLNbhfBcYykp8O876ACSgsvFJTntrAQbdTe9KUTqkiZr0t7xlBpju6bNR+4T2Z4fk rUv22/pkQdJWcTHbEgXzmh4D2JLv02zn2vp4fu49HK0y8ShWBa5SsvD/MDfLz2tZzF +S0z33ECxb2L1nc2hCNoFYTEdN1lhe8WwhsAy2xLP+Ov2ontpA0VrQey9lorM+TnBO dgGMLb5dSwCEeKKSb9pE+oWrK87BJOc+P3vHN6Lpbh/llpGtRA4iquCY8LQdLWvCPB 3obLXy7AQ7MAQ== Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt 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, 15 Mar 2016 15:17:42 -0000 On 3/15/16 12:34 AM, Rob Hansen (rohanse2) wrote: > Hi Paul, have just uploaded a new draft incorporating your review - thank you for the attention to detail. Based on a review of the diffs, this seems good to me. Thanks, Paul > I did indeed manage to miss your section 8 comments on the previous revision - apologies for that. I worked on the revision offline and pulled what I thought was all the relevant emails with review comments but missed that one, so only included the basilar comments that were discussed further in a subsequent email. > >> About the flow: The call flow shows INVITE 2 followed by a clue > configure and response followed by 200 ok. This certainly encourages the > inference that there is a dependency on doing the configure before > sending the invite response. That is contrary to protocol requirements. > (And the same holds for INVITE 3.) > > Agreed - have rearranged messages and changed text to make clear that there should be no such dependency and that the SIP 200 OK should be send independently of the CLUE Configure message. > >> Also, there should be responses for the Advertisements. > > Added. > >> This shows Alice's advertisement going first, and Bob's advertisement > being sent after receiving Alice's. This is of course possible, but it > may suggest that there is a cause/effect relationship. It would be good > to at least mention that the decisions are independent. It might make > sense to show the messages crossing on the wire, making it clear that > they are independent. > > Have added text to the effect that both sides send their messages independently, and adding the ACKs after both are sent helps clarify this. > >> you get to the point where Alice sends INVITE 2. At this point, > both Alice and Bob need to update the SDP. There is potential for a race > condition for who goes first. Why is it that Alice goes first, and Bob > doesn't try before receiving Alice's reINVITE? It would be good to > explain this. (Or simply state that this just of of several ways this > might play out depending on timing.) > > Have kept Alice sending her INVITE first in the example to reduce complexity but have added a paragraph pointing out that this isn't the only way to do it and that often both sides will send their INVITEs and resolve this via glare resolution. > >> I think it would be good to show the 200 for INVITE 2 prior to sending > the Configure. This will make clear that the sip signaling not be > delayed. Or just mention that they are both sent nearly concurrently. > > I've kept the Configure message first as we do earlier say to do CLUE before SDP, but have made clear in the text that they are sent independently and at pretty much the same time; both are shown as sent before the far end sends an ACK or CONFIGURE RESPONSE > >> Finally, there should probably be another O/A at the end to completely > disable the non-clue media. (Maybe it would be interesting to show that > one end keeps the non-clue media until the clue media is flowing, while > the other end stops receiving the non-clue media as soon as it confirms > this will be a clue call.) > > The SIP OK 3 from Alice disables the non-clue media so I don't think there's a need for an additional O/A. > > Thanks both for the original review and pointing out I'd missed making some of the revisions. > > Rob > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 25 January 2016 20:43 > To: clue@ietf.org > Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt > > On 1/21/16 11:53 AM, Robert Hansen wrote: >> Hi all, apologies that this took longer than intended to revise and check. >> >> Thanks to all the reviewers - almost all suggestions were >> incorporated, usually as-is when suggested text was provided. > > This generally looks good. I found a few nits while reading: > > * Section 4.5.3.1: > > s/"m=" line to send or receive/"m=" lines to send or receive/ > > * Section 4.5.4.3: > > s/distinct to/distinct from/ > > (This isn't new, I missed it previously.) As written I think it means the opposite of what it intends. > > * Section 8: > > Did you attempt to address my comments in: > > http://mailarchive.ietf.org/arch/msg/clue/gYAy7v42JN8uxFz53qxBVki7OBY > > I see a few of the editorial ones addressed, but not the substantial ones. For the most part the meaty ones still apply. > > Thanks, > Paul > > >> * Removed the entire 'Media line directionality' section as a >> discussion of the pros/cons of using bidirectional vs unidirectional >> schemes wasn't suitable for a finalised version. The unidirectionality >> requirement is covered normatively in an earlier section. >> >> * BUNDLE no longer includes an address synchronisation step so the >> suggestion to wait until that done has been replaced with some general >> language about following any negotiated extensions. >> >> * Added OPTIONS negotiation to the example flow, and revised the flow >> to ensure it matched protocol document. >> >> * Section on not sending CLUE control media until CLUE negotiation >> completes narrowed to notify that only RTP should not be sent until >> negotiation completes and add RTCP to the list of things that should >> be sent as normal, in line with a=inactive. >> >> * Make explicit that m=recvonly lines don't need to have a label, as >> only m=sendonly lines are referenced by CLUE protocol messages. >> >> * Fix formatting of IANA sections. Improve syntax of feature tag >> section in line with Paul's suggestions. Definition of feature tag >> narrowed to be multiple media lines 'negotiated via CLUE protocol' >> rather than more generic 'multiple media lines'. >> >> One thing that Paul brought up was that in 5.1 "Later there are >> references to named states and transitions in the clue protocol. These >> don't seem to be consistent with the current state machine definitions" >> - I've checked and to me they seem to be consistent with the state >> machines in the protocol document. >> >> Rob >> >> On 21/01/16 16:29, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the ControLling mUltiple streams for >>> tElepresence Working Group of the IETF. >>> >>> Title : CLUE Signaling >>> Authors : Paul Kyzivat >>> Lennard Xiao >>> Christian Groves >>> Robert Hansen >>> Filename : draft-ietf-clue-signaling-07.txt >>> Pages : 36 >>> Date : 2016-01-21 >>> >>> Abstract: >>> This document specifies how CLUE-specific signaling such as the CLUE >>> protocol [I-D.ietf-clue-protocol] and the CLUE data channel >>> [I-D.ietf-clue-datachannel] are used with each other and with >>> existing signaling mechanisms such as SIP and SDP to produce a >>> telepresence call. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-clue-signaling-07 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-07 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at >>> tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Mar 15 08:21:19 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 C7C5F12DCAE for ; Tue, 15 Mar 2016 08:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 k4Tt2aysrA3P for ; Tue, 15 Mar 2016 08:21:15 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2BF312DB09 for ; Tue, 15 Mar 2016 08:20:04 -0700 (PDT) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-06v.sys.comcast.net with comcast id WFKm1s00B4vw8ds01FL4vY; Tue, 15 Mar 2016 15:20:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-04v.sys.comcast.net with comcast id WFL31s00M3KdFy101FL33R; Tue, 15 Mar 2016 15:20:04 +0000 To: clue@ietf.org References: <20160121162918.2158.51064.idtracker@ietfa.amsl.com> <56A10D0B.2020509@cisco.com> <56A1B915.6040800@nteczone.com> <1dd8eb0fd9f84d92bf7c4766197bb386@XCH-RCD-016.cisco.com> From: Paul Kyzivat Message-ID: <56E82822.8090301@alum.mit.edu> Date: Tue, 15 Mar 2016 11:20:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1dd8eb0fd9f84d92bf7c4766197bb386@XCH-RCD-016.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458055204; bh=VPmb0Xd4EHAKiEhF6kNx9xiwf1kyykLGYZHlk0YSxWA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=mrepCE4NIF1+WIZUoxjnEsFmu9zDAgOTxL12uIP6vw25XUavGIBZ9Om5u0VAbSAaz 8mVX/+r2sgLbA9MbUjliQNsCg1WvGl5qg5s6pRbUDl3X9aakySG3jneishmkhUwfcf z0jpKWHgEqNwgch/dR3xe0qgC6R94vGuxx7MGRUDCu5DG/xsH2pN95X7QLAKkw8jVL lw4ZUXgX00Pb6HB5zbZErbxmG3nie7lwGheycg4T/1EjrxY8H3xdk5JrQqeXR/ym/k rAIh2vb9E6mXIBdE48GJr+y7A4NbFJ5UnZ2fk70uHGBX7M7wmegUbGVHjV+iFicoeR YPIPps3XZePXw== Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt 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, 15 Mar 2016 15:21:18 -0000 On 3/15/16 12:22 AM, Rob Hansen (rohanse2) wrote: > Hi Christian, > > Have just uploaded a new draft, incorporating your suggestions - thank you for providing them. On the section on disabling CLUE mid-call it is now explicit about the procedure for doing so. It also covers what to do if the far end does so, and clarifies that if the data channel fails or is closed without a corresponding SDP negotiation to disable it CLUE-controlled media should continue to flow. In section 4.5.5.3: If, during an ongoing CLUE-enabled call a device wishes to disable CLUE, it can do so by following the procedures for closing a data channel defined in Section 5.2.4 of [I-D.ietf-mmusic-data-channel-sdpneg]: sending a new SDP offer/answer exchange and subsequent SCTP SSN reset for the CLUE channel. It MUST also remove the "mid" for the data channel from the CLUE group. Shouldn't the entire clue group be removed??? Otherwise this seems good. Thanks, Paul > Rob > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: 22 January 2016 05:08 > To: clue@ietf.org > Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt > > > Hello Rob, > > Thanks for the update. A couple of comments: > > cl. 4.5.2.2 adds "lines for compatible encodings" - is compatible the right term here? Isn't it more "accepted encodings"? > > cl. 4.5.4.3: I've made a comment a couple of times now about the need to mention SCTP reset for disabling CLUE mid call but it appears to be missed. Both draft-ietf-clue-datachannel (cl.3.2.7) and draft-ietf-mmusic-data-channel-sdpneg (cl.5.2.4) both mention that an SCTP SSN reset has to be performed. > draft-ietf-mmusic-data-channel-sdpneg (cl.5.2.4) mentions that its protocol specific whether this is announced by SDP. > > So I would propose to word the first paragraph of cl.4.5.4.3 differently: > > "If order to close a CLUE data channel in an ongoing CLUE-enabled call, an endpoint shall follow the procedures for closing a data channel defined in clause 5.2.4 [draft-ietf-mmusic-data-channel-sdpneg] by sending a new SDP offer/answer exchange and subsequent SCTP SSN reset for the CLUE channel. > > In the event that this occurs, CLUE is no longer enabled and sending of > all CLUE-controlled media associated with the corresponding CLUE group > MUST stop. If the data channel is still present but not included in the CLUE group semantic CLUE protocol messages MUST no longer be sent." > > Regards, Christian > > > > > > On 22/01/2016 3:53 AM, Robert Hansen wrote: >> Hi all, apologies that this took longer than intended to revise and >> check. >> >> Thanks to all the reviewers - almost all suggestions were >> incorporated, usually as-is when suggested text was provided. >> >> * Removed the entire 'Media line directionality' section as a >> discussion of the pros/cons of using bidirectional vs unidirectional >> schemes wasn't suitable for a finalised version. The unidirectionality >> requirement is covered normatively in an earlier section. >> >> * BUNDLE no longer includes an address synchronisation step so the >> suggestion to wait until that done has been replaced with some general >> language about following any negotiated extensions. >> >> * Added OPTIONS negotiation to the example flow, and revised the flow >> to ensure it matched protocol document. >> >> * Section on not sending CLUE control media until CLUE negotiation >> completes narrowed to notify that only RTP should not be sent until >> negotiation completes and add RTCP to the list of things that should >> be sent as normal, in line with a=inactive. >> >> * Make explicit that m=recvonly lines don't need to have a label, as >> only m=sendonly lines are referenced by CLUE protocol messages. >> >> * Fix formatting of IANA sections. Improve syntax of feature tag >> section in line with Paul's suggestions. Definition of feature tag >> narrowed to be multiple media lines 'negotiated via CLUE protocol' >> rather than more generic 'multiple media lines'. >> >> One thing that Paul brought up was that in 5.1 "Later there are >> references to named states and transitions in the clue protocol. These >> don't seem to be consistent with the current state machine >> definitions" - I've checked and to me they seem to be consistent with >> the state machines in the protocol document. >> >> Rob >> >> On 21/01/16 16:29, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the ControLling mUltiple streams for >>> tElepresence Working Group of the IETF. >>> >>> Title : CLUE Signaling >>> Authors : Paul Kyzivat >>> Lennard Xiao >>> Christian Groves >>> Robert Hansen >>> Filename : draft-ietf-clue-signaling-07.txt >>> Pages : 36 >>> Date : 2016-01-21 >>> >>> Abstract: >>> This document specifies how CLUE-specific signaling such as the CLUE >>> protocol [I-D.ietf-clue-protocol] and the CLUE data channel >>> [I-D.ietf-clue-datachannel] are used with each other and with >>> existing signaling mechanisms such as SIP and SDP to produce a >>> telepresence call. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-clue-signaling-07 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-07 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at >>> tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Mar 15 12:21:20 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 D2D7D12D701 for ; Tue, 15 Mar 2016 12:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 YyB_BPffh8zq for ; Tue, 15 Mar 2016 12:21:15 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D268B12D6F7 for ; Tue, 15 Mar 2016 12:21:15 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-03v.sys.comcast.net with comcast id WKLK1s0072VvR6D01KMEUE; Tue, 15 Mar 2016 19:21:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with comcast id WKME1s00J3KdFy101KMENU; Tue, 15 Mar 2016 19:21:14 +0000 From: Paul Kyzivat To: CLUE References: <56D46616.1060105@alum.mit.edu> Message-ID: <56E860A9.9030705@alum.mit.edu> Date: Tue, 15 Mar 2016 15:21:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56D46616.1060105@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458069674; bh=67Fng6CAyjtJx3aQbpbc2Da7Oe/fb+zg3dCK7T4RJJM=; h=Received:Received:From:Subject:To:Message-ID:Date:MIME-Version: Content-Type; b=WfeISCHOzjdqU3CWP5mxFl4TYNp8iafvSJzWyfRh4pwoJqrGTaHcSOudfKY19LgqN /W2gzhYDFfv7udU0qflWuuew09F0ZuzaSte8NyTaM1YhFvP+3Klboqya5/NeP8L7aM ssW+uU8pshLT+Xs9Z4GLyJwmHjfwekSWdcXp4R8JQub16zYK5TkdyUJs9Ckn5/0W6t 9ypAiWa5Zw0FbgXshlBahV9ZJPKcAHPARYb33WI2m2twkZ0VDsgspmOs3N5bUay1nm rzNrZnRTmSxheDYXwuJbGy1AAA9x8C7z06N1QG7HsT5awbdvzu4oy3FbWDGa+8mn3+ b2hjQmekvi0+A== Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-datachannel-11 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, 15 Mar 2016 19:21:18 -0000 Well, the WGLC cutoff date has passed. But we had only 2 responses! (Thanks to Christian and Mark.) If anybody has any objection to this document progressing, please say so now. I am going to begin action to progress this draft. Thanks, Paul On 2/29/16 10:39 AM, Paul Kyzivat wrote: > This message announces the start of a two week WGLC for > draft-ietf-clue-datachannel-11. The last call will end at midnight on > Monday 14-mar-2016. > > I request all those who have worked on or are interested in CLUE to make > an effort to review this document and submit comments. If you have no > specific comments to make then please send a note indicating you have > reviewed it an agree it is ready to advance. > > Thanks, > Paul Kyzivat > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Mar 16 04:10:46 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 1876C12D571 for ; Wed, 16 Mar 2016 04:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 aYHheKzpjQcs for ; Wed, 16 Mar 2016 04:10:42 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17F212D525 for ; Wed, 16 Mar 2016 04:10:40 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 98274B065BF30 for ; Wed, 16 Mar 2016 11:10:36 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2GBAcPU016801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 16 Mar 2016 11:10:38 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u2GBAW4O010349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 16 Mar 2016 12:10:36 +0100 Received: from [149.204.68.181] (135.239.27.39) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 16 Mar 2016 12:10:35 +0100 To: References: <56D46616.1060105@alum.mit.edu> <56E860A9.9030705@alum.mit.edu> From: Juergen Stoetzer-Bradler Message-ID: <56E93F2A.9090504@alcatel-lucent.com> Date: Wed, 16 Mar 2016 12:10:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E860A9.9030705@alum.mit.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070907050802010006030907" X-Originating-IP: [135.239.27.39] Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-datachannel-11 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: Wed, 16 Mar 2016 11:10:44 -0000 --------------ms070907050802010006030907 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Sorry for the late feedback. Have reviewed this draft with focus on consistency with most recent=20 draft-ietf-mmusic-data-channel-sdpneg-08 and have following comments/ques= tions. * Section 3.3.1.1, first paragraph after table 1, 4th line: There seems t= o be a redundant "the". * Section 5.1, IANA registration of subprotocol identifier "CLUE": The "W= ebSocket Subprotocol Name=20 Registry" has an additional column "Reference". Should its value also be = described in section 5.1=20 like e.g. "Reference: RFC-XXXX"? * Section 8.1, Normative references: Most recent version of draft-ietf-mm= usic-data-channel-sdpneg is 08. Thanks, Juergen On 15.03.2016 20:21, EXT Paul Kyzivat wrote: > Well, the WGLC cutoff date has passed. But we had only 2 responses! (Th= anks to Christian and Mark.) > > If anybody has any objection to this document progressing, please say s= o now. I am going to begin=20 > action to progress this draft. > > Thanks, > Paul > > On 2/29/16 10:39 AM, Paul Kyzivat wrote: >> This message announces the start of a two week WGLC for >> draft-ietf-clue-datachannel-11. The last call will end at midnight on >> Monday 14-mar-2016. >> >> I request all those who have worked on or are interested in CLUE to ma= ke >> an effort to review this document and submit comments. If you have no >> specific comments to make then please send a note indicating you have >> reviewed it an agree it is ready to advance. >> >> Thanks, >> Paul Kyzivat >> --------------ms070907050802010006030907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DF8wggTdMIIDxaADAgECAgoanQrOAAAAAAAGMA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoT DkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBSb290 IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcyOFowgYUxEzARBgoJkiaJk/IsZAEZ FgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcw FQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJu YWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2Ocmcli3LbVU6TRh +JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdfkyWAiGzVWeRI rYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38VbxMvQ+ygj Eyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+VdiUwDa ry1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUw AwEB/zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsG AQQBgjcVAQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAes slr2YYl8XHzr4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5z dXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5h bGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4Bggr BgEFBQcwAoYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQw OAYIKwYBBQUHMAKGLGh0dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0Eu Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQClGxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3 F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjbEhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx 4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6 rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwfRfPmwRetdnD6NC5x8aRkhr4ZNBjv YxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6/XpNOx2FyG18axeeASWtENgP vqEirM5MjwkCMIIHejCCBmKgAwIBAgIKYWH+JwAAAAFWdjANBgkqhkiG9w0BAQUFADCBhTET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVs IEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNTE4MTMwNzI0WhcNMTcwNTE3MTMwNzI0 WjBOMRAwDgYDVQQDEwdsaTYwNzYwMTowOAYJKoZIhvcNAQkBFitqdWVyZ2VuLnN0b2V0emVy LWJyYWRsZXJAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA3SjiDDt1yolL0cBi5MS+Bea3hhVDSdcJ/xtfzEbTtkxo05xnMgeRTy/kNJZuR4oY j/2TE+raQenSEgROQtLgxKjxtLh9/fGEuLCyFclz9SIeIYIkZBB1NSwZKmGlJHRU5jjqSinT Hmux9chaP+TUoidoDYbfdz/uFGdPW7RP21Gxjzg9v/VC+tfc0u0idNF9Vwnkh3VgdisMf1Jf JZNINpw0ZapFKRhLEhgtXVS7tkdxxTL0uc9XtviOTSSfxgBt2MPsj0qfhsNFFO4zUO1pJiBz SBPnLt7af96oS2ZHI4Xz7zNHShDoSMMIr+7l9xgopb5qN/KMCMP9BSxxNEfphwIDAQABo4IE IDCCBBwwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIhb3FWYPjsTmHpYEqhr/DQoWUmBmB C/nmTIT9tVoCAWQCAQUwHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQwCwYDVR0P BAQDAgWgMCkGCSsGAQQBgjcVCgQcMBowDAYKKwYBBAGCNwoDBDAKBggrBgEFBQcDBDBEBgkq hkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcw CgYIKoZIhvcNAwcwHQYDVR0OBBYEFEVmlcJSxtK5Cu7FZb5XUWWuKktKMB8GA1UdIwQYMBaA FNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXQYDVR0fBIIBVDCCAVAwggFMoIIBSKCCAUSGgdls ZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPXVz bmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vydmlj ZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2VydGlmaWNh dGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybIY4aHR0cDov L3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmwwggFh BggrBgEFBQcBAQSCAVMwggFPMIHMBggrBgEFBQcwAoaBv2xkYXA6Ly8vQ049QWxjYXRlbCUy MEx1Y2VudCUyMEludGVybmFsJTIwU3ViJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUy MFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNl bnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9u QXV0aG9yaXR5MDgGCCsGAQUFBzAChixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20v UEtJL3N1YkNBLmNydDBEBggrBgEFBQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxj YXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwNgYDVR0RBC8wLYEranVlcmdlbi5zdG9l dHplci1icmFkbGVyQGFsY2F0ZWwtbHVjZW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAMrtX ZAqm6NqOAYttJjvC6pL04tEKUusax1Dr6p6NfxVfUuW8ZoFXKoxHEDaYKQR9ldfnuILHN+x7 KdLeKg+NPUs7GFGwpBmJb7PRmxnIarFJbGHzpqZ9+Fhsde1uxi+y2VJcIOVaEh/JoRdHvSUQ nwT4+FcBmS6uRv68rnCkh+KeUm6A7+6dDo/9l/Zh2Hu1+HVWw5kEH/xmO170v9Xef7efxzxv BeQ644kvErDNG26LJDUtOqaKTdz9KKZXngw+2cAV/4Kc7C9xdT29Ugm8oOK/ecqBliMhBUen WphsEDjIbKJCd40RJLKb+v49EN/IJogNDd81vtehOxDw5Lus4zGCA+0wggPpAgEBMIGUMIGF MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZIm iZPyLGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0 ZWwgTHVjZW50IEludGVybmFsIFN1YiBDQQIKYWH+JwAAAAFWdjANBglghkgBZQMEAgEFAKCC AikwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMzE2MTEx MDM0WjAvBgkqhkiG9w0BCQQxIgQggc+Dh32eWLNgK9y0A8m7JrnKX//KLA7WukcjUwKXjtYw bAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCBpQYJKwYBBAGCNxAEMYGXMIGUMIGFMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZIm iZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRl bCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVybmFsIFN1YiBDQQIKYWH+ JwAAAAFWdjCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYUxEzARBgoJkiaJk/IsZAEZFgNjb20x FjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQK Ew5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgU3Vi IENBAgphYf4nAAAAAVZ2MA0GCSqGSIb3DQEBAQUABIIBAExx935J5WU7yYT2zNlEHz7OOlmW mLjHER4Vg3BBgl/y7dUXoDTGYq9jErn93dfrFvmj9AXRB+zi1gIA2g6sgE+vpDEWdPn/vnB7 ChwZxHuEHoiQPrZHDKyLJFlUF9SE0uGT1uegW7HwU2a/sF0+OV3PMAymjxjz9/3ZKIMBulG+ ZQTCAJj9JkW2tSiZ/oCzxfHEK7PxWzYRnlzjuxBrtzuTClB0sOwQiX8oIQ7I9l0tOSCp56ZR t+JqZf6enJaqEV9QHMF3PG35Pl6BFLlMDnmvYE2oEO0/kqyUpfGcDov5SJ1J9ODO+0PfDJp7 EBHUHtNR8y1IwDvPy7qD/JTGNO0AAAAAAAA= --------------ms070907050802010006030907-- From nobody Wed Mar 16 06:08:22 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 F1AA912D958 for ; Wed, 16 Mar 2016 06:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0jRwXcOLvTC1 for ; Wed, 16 Mar 2016 06:08:18 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE01712D945 for ; Wed, 16 Mar 2016 06:08:17 -0700 (PDT) X-AuditID: c1b4fb30-f79246d00000788a-ee-56e95ac09d5e Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 07.A0.30858.0CA59E65; Wed, 16 Mar 2016 14:08:16 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.122]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Wed, 16 Mar 2016 14:08:15 +0100 From: Christer Holmberg To: Juergen Stoetzer-Bradler , "clue@ietf.org" Thread-Topic: [clue] WGLC for draft-ietf-clue-datachannel-11 Thread-Index: AQHRcwdVtFg31v7910yitys0mzY2gJ9a6NqAgAEJPwCAADB2kA== Date: Wed, 16 Mar 2016 13:08:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37EB69EE@ESESSMB209.ericsson.se> References: <56D46616.1060105@alum.mit.edu> <56E860A9.9030705@alum.mit.edu> <56E93F2A.9090504@alcatel-lucent.com> In-Reply-To: <56E93F2A.9090504@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7uu6BqJdhBtN3iFvsP3WZ2eLskxWM DkweS5b8ZPK4e+sSUwBTFJdNSmpOZllqkb5dAlfGi2P72QtOCVXMbLrM2MDYI9TFyMkhIWAi MfPmJyYIW0ziwr31bF2MXBxCAocZJeb+f8YK4SxhlJi9ZgVQFQcHm4CFRPc/bZAGEYEUidkT V7OB2MIC1hJv905khojbSHT09LJB2E4S346cYAWxWQRUJb5f2swIYvMK+Eqs+nYXbLGQQLHE xlN9YHFOASOJDdPngMUZgQ76fmoNmM0sIC5x68l8qEMFJJbsOc8MYYtKvHz8jxXCVpJYsf0S I8iZzAKaEut36UO0KkpM6X7IDrFWUOLkzCcsExhFZyGZOguhYxaSjllIOhYwsqxiFC1OLU7K TTcy0kstykwuLs7P08tLLdnECIyRg1t+G+xgfPnc8RCjAAejEg/vh8kvwoRYE8uKK3MPMUpw MCuJ8ApEvgwT4k1JrKxKLcqPLyrNSS0+xCjNwaIkzsv66XKYkEB6YklqdmpqQWoRTJaJg1Oq gXHyCou2g9MmVHsrh7x3VvOqdnlhYfv2x+K97MKm/80+nKxY8GZ30bFFL4R/6HV7P9hZ3t3S ++06U7Gdycycp78mrLMOtcvamz15//1rbHzPtrV52W2Pkdw/eed34fz8F8lsPM8kZm6aL939 M/tx0SevJVJzzjYf7+H/P+HrjmfdNQbvZs/ZcLxLiaU4I9FQi7moOBEAJuKW340CAAA= Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-datachannel-11 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: Wed, 16 Mar 2016 13:08:21 -0000 SGkgSnVlcmdlbiwNCg0KPlNvcnJ5IGZvciB0aGUgbGF0ZSBmZWVkYmFjay4NCj5IYXZlIHJldmll d2VkIHRoaXMgZHJhZnQgd2l0aCBmb2N1cyBvbiBjb25zaXN0ZW5jeSB3aXRoIG1vc3QgcmVjZW50 DQo+ZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0wOCBhbmQgaGF2ZSBmb2xs b3dpbmcgY29tbWVudHMvcXVlc3Rpb25zLg0KPg0KPiogU2VjdGlvbiAzLjMuMS4xLCBmaXJzdCBw YXJhZ3JhcGggYWZ0ZXIgdGFibGUgMSwgNHRoIGxpbmU6IFRoZXJlIHNlZW1zIHRvIGJlIGEgcmVk dW5kYW50ICJ0aGUiLg0KDQpJJ2xsIGZpeCB0aGF0Lg0KDQo+KiBTZWN0aW9uIDUuMSwgSUFOQSBy ZWdpc3RyYXRpb24gb2Ygc3VicHJvdG9jb2wgaWRlbnRpZmllciAiQ0xVRSI6IFRoZSAiV2ViU29j a2V0IFN1YnByb3RvY29sIE5hbWUgUmVnaXN0cnkiIGhhcyBhbiBhZGRpdGlvbmFsIA0KPiBjb2x1 bW4gIlJlZmVyZW5jZSIuIFNob3VsZCBpdHMgdmFsdWUgYWxzbyBiZSBkZXNjcmliZWQgaW4gc2Vj dGlvbiA1LjEgbGlrZSBlLmcuICJSZWZlcmVuY2U6IFJGQy1YWFhYIj8NCg0KSSBndWVzcyBpdCBz aG91bGQuIEknbGwgbG9vayBpbnRvIHRoYXQuDQoNCj4qIFNlY3Rpb24gOC4xLCBOb3JtYXRpdmUg cmVmZXJlbmNlczogTW9zdCByZWNlbnQgdmVyc2lvbiBvZiBkcmFmdC1pZXRmLW1tdXNpYy1kYXRh LWNoYW5uZWwtc2RwbmVnIGlzIDA4Lg0KDQpJJ2xsIG1ha2Ugc3VyZSBhbGwgcmVmZXJlbmNlIHZl cnNpb25zIGFyZSB1cC10by1kYXRlLiAgDQoNCk9uY2UgdGhlIGNoYWlycyB0ZWxsIG1lIHRvIEkn bGwgc3VibWl0IGEgbmV3IHZlcnNpb24sIGJhc2VkIG9uIHRoZSBjb21tZW50cy4NCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KDQpPbiAxNS4wMy4yMDE2IDIwOjIxLCBFWFQgUGF1bCBLeXppdmF0 IHdyb3RlOg0KPiBXZWxsLCB0aGUgV0dMQyBjdXRvZmYgZGF0ZSBoYXMgcGFzc2VkLiBCdXQgd2Ug aGFkIG9ubHkgMiByZXNwb25zZXMhIA0KPiAoVGhhbmtzIHRvIENocmlzdGlhbiBhbmQgTWFyay4p DQo+DQo+IElmIGFueWJvZHkgaGFzIGFueSBvYmplY3Rpb24gdG8gdGhpcyBkb2N1bWVudCBwcm9n cmVzc2luZywgcGxlYXNlIHNheSANCj4gc28gbm93LiBJIGFtIGdvaW5nIHRvIGJlZ2luIGFjdGlv biB0byBwcm9ncmVzcyB0aGlzIGRyYWZ0Lg0KPg0KPiAgICAgVGhhbmtzLA0KPiAgICAgUGF1bA0K Pg0KPiBPbiAyLzI5LzE2IDEwOjM5IEFNLCBQYXVsIEt5eml2YXQgd3JvdGU6DQo+PiBUaGlzIG1l c3NhZ2UgYW5ub3VuY2VzIHRoZSBzdGFydCBvZiBhIHR3byB3ZWVrIFdHTEMgZm9yIA0KPj4gZHJh ZnQtaWV0Zi1jbHVlLWRhdGFjaGFubmVsLTExLiBUaGUgbGFzdCBjYWxsIHdpbGwgZW5kIGF0IG1p ZG5pZ2h0IG9uIA0KPj4gTW9uZGF5IDE0LW1hci0yMDE2Lg0KPj4NCj4+IEkgcmVxdWVzdCBhbGwg dGhvc2Ugd2hvIGhhdmUgd29ya2VkIG9uIG9yIGFyZSBpbnRlcmVzdGVkIGluIENMVUUgdG8gDQo+ PiBtYWtlIGFuIGVmZm9ydCB0byByZXZpZXcgdGhpcyBkb2N1bWVudCBhbmQgc3VibWl0IGNvbW1l bnRzLiBJZiB5b3UgDQo+PiBoYXZlIG5vIHNwZWNpZmljIGNvbW1lbnRzIHRvIG1ha2UgdGhlbiBw bGVhc2Ugc2VuZCBhIG5vdGUgaW5kaWNhdGluZyANCj4+IHlvdSBoYXZlIHJldmlld2VkIGl0IGFu IGFncmVlIGl0IGlzIHJlYWR5IHRvIGFkdmFuY2UuDQo+Pg0KPj4gICAgICBUaGFua3MsDQo+PiAg ICAgIFBhdWwgS3l6aXZhdA0KPj4NCg0KDQo= From nobody Wed Mar 16 15:59:23 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 514C412D64C for ; Wed, 16 Mar 2016 15:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 zmuj4haqawhD for ; Wed, 16 Mar 2016 15:59:17 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4908612D812 for ; Wed, 16 Mar 2016 15:59:01 -0700 (PDT) Received: from [81.187.2.149] (port=47139 helo=[192.168.0.86]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1agKP5-0000bu-9I; Wed, 16 Mar 2016 22:58:59 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: Date: Wed, 16 Mar 2016 22:58:56 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Daniel Burnett X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "clue@ietf.org" Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-06 ends 18 March 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: Wed, 16 Mar 2016 22:59:21 -0000 > On 8 Mar 2016, at 19:35, Daniel Burnett = wrote: >=20 > This message announces the start of a 1.5 week WGLC for = draft-ietf-clue-rtp-mapping. The last call will end at midnight on = Friday, 18 March 2016 to allow time for a rev before the 21st. I=E2=80=99ve reviewed this draft, and have a number of comments. Most of = these relate to how RTP sessions are used, and to terminology. In = particular, in section 3, and likely elsewhere, the draft uses the term = =E2=80=9Cmixer=E2=80=9D to refer to something that is clearly not a = mixer in the RTP sense. The terminology needs to be corrected.=20 Details: Section 3: some diagrams might help illustrate the various options. Section 3, 2nd paragraph: for clarity, I suggest changing =E2=80=9CThere = can be one or more RTP sessions, and each RTP session can carry multiple = RTP streams identified by their SSRC=E2=80=9D to =E2=80=9CThere can be = one or more RTP sessions, each sent on a separate 5-tuple, and having a = separate SSRC space, with each RTP session carrying multiple RTP streams = identified by their SSRC=E2=80=9D. Section 3, 4th paragraph: how does the mixer handle RTCP? That is, does = it forward RTCP for the SSRCs that it sends as CSRCs, or not?=20 Section 3, 5th paragraph: what is meant by =E2=80=9CIn the Selective = Forwarding middlebox topology, the peer to mixer communication is = unicast with RTCP mixer feedback=E2=80=9D? Is this intending to say that = there is a separate unicast RTP session on between each peer and the = mixer? If so, the terminology =E2=80=9Cmixer=E2=80=9D is incorrect: a = mixer is a well-defined RTP concept, that shares a single RTP session. Section 3, 5th paragraph: what is meant by =E2=80=9Cprojected=E2=80=9D? = The draft doesn=E2=80=99t define this operation, or explain what the = middlebox has to do to project an SSRC. I assume this is some sort of = back-to-back pair of RTP sessions, but it=E2=80=99s not explained. Section 3, 5th paragraph: RTCP is terminated by the =E2=80=9Cmixer=E2=80=9D= , but SSRCs are =E2=80=9Cprojected=E2=80=9D. What is done about RTCP for = the projected SSRCs? Section 3, 1st bullet point: =E2=80=9CThe mixer may either use the = source SSRC when forwarding RTP packets, or use its own created SSRC=E2=80= =9D is unclear. A middlebox that is acting as an RTP mixer will always = use its own SSRC, and include the SSRC of the mixed streams as the CSRC; = this happens even if it=E2=80=99s only forwarding a single RTP stream. = If the middlebox forwards packets with their original SSRC, it=E2=80=99s = not an RTP mixer. The terminology needs fixing. Section 3, 2nd bullet point: =E2=80=9CThe mixer terminates the RTCP from = the source, creating separate RTP sessions with the peers=E2=80=9D - = this is not how an RTP mixer works. The terminology needs to be fixed.=20= Section 4.5, Media-7, 2nd paragraph: a mixer always provides CSRCs, so = this requirement is unclear. --=20 Colin Perkins https://csperkins.org/ From nobody Thu Mar 17 11:48:49 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 C8CA712D8BE for ; Thu, 17 Mar 2016 11:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 IK05GO5jDFci for ; Thu, 17 Mar 2016 11:48:46 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E04EF12D7FE for ; Thu, 17 Mar 2016 11:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7676; q=dns/txt; s=iport; t=1458240526; x=1459450126; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=91BYJTEgnP3cr8sK5ZQd2HIg5I9Aj+XYdEMMD0bw1Rg=; b=VGRa6ByXhv9U9bmNMYryjD4nV8gUpu94I3Rb9E/cQ1agb85ZudHEFzeh wgCafD2LacN3ZW+/SBkUFStB7QY3EikkieZO/n1wy7B+Pf8GLbO4vRIHe eWAQ8qNr8/20Z9BBHtyPzfG9x0d33Bfe60U2YnP4CG4V0F5LyR9O0WBz5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgAp++pW/xbLJq1ehBhuphgFAYEPk?= =?us-ascii?q?lgBDYFvFwqFbAKBchQBAQEBAQEBZCeEQQEBAQMBAQEBNTYKDQQLEQQBAQEJFgg?= =?us-ascii?q?HCQMCAQIBFR8JCBMGAgEBiBsIDsEEAQEBAQEBAQEBAQEBAQEBAQEBAReFVoUMi?= =?us-ascii?q?HYBBJdUhW+CcoUggWVLg36DBIVUhg2Idh4BAUKCAxmBSTwuimMBAQE?= X-IronPort-AV: E=Sophos;i="5.24,350,1454976000"; d="scan'208";a="676097871" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Mar 2016 18:48:43 +0000 Received: from [10.47.200.59] ([10.47.200.59]) (authenticated bits=0) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u2HImheC026159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 17 Mar 2016 18:48:43 GMT Message-ID: <56EAFC10.6050307@cisco.com> Date: Thu, 17 Mar 2016 18:48:48 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <20160121162918.2158.51064.idtracker@ietfa.amsl.com> <56A10D0B.2020509@cisco.com> <56A1B915.6040800@nteczone.com> <1dd8eb0fd9f84d92bf7c4766197bb386@XCH-RCD-016.cisco.com> <56E82822.8090301@alum.mit.edu> In-Reply-To: <56E82822.8090301@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: rohanse2 Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt 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: Thu, 17 Mar 2016 18:48:49 -0000 Hi Paul, I did originally have a 'MUST also remove the CLUE group' bit, but then I thought that there might be usecases where people want to keep the CLUE-controlled media m-lines negotiated, though. If they remove the CLUE group then they have to zero all the CLUE-controlled m-lines (since without a CLUE group these then just become normal m-lines). Maybe that's a contrived use-case though, and we could have a 'MUST remove the CLUE group and SHOULD 0 all CLUE-controlled m-lines' type bit at the end. Rob On 15/03/16 15:20, Paul Kyzivat wrote: > On 3/15/16 12:22 AM, Rob Hansen (rohanse2) wrote: >> Hi Christian, >> >> Have just uploaded a new draft, incorporating your suggestions - >> thank you for providing them. On the section on disabling CLUE >> mid-call it is now explicit about the procedure for doing so. It also >> covers what to do if the far end does so, and clarifies that if the >> data channel fails or is closed without a corresponding SDP >> negotiation to disable it CLUE-controlled media should continue to flow. > > In section 4.5.5.3: > > If, during an ongoing CLUE-enabled call a device wishes to disable > CLUE, it can do so by following the procedures for closing a data > channel defined in Section 5.2.4 of > [I-D.ietf-mmusic-data-channel-sdpneg]: sending a new SDP offer/answer > exchange and subsequent SCTP SSN reset for the CLUE channel. It MUST > also remove the "mid" for the data channel from the CLUE group. > > Shouldn't the entire clue group be removed??? > > Otherwise this seems good. > > Thanks, > Paul > >> Rob >> >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: 22 January 2016 05:08 >> To: clue@ietf.org >> Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt >> >> >> Hello Rob, >> >> Thanks for the update. A couple of comments: >> >> cl. 4.5.2.2 adds "lines for compatible encodings" - is compatible the >> right term here? Isn't it more "accepted encodings"? >> >> cl. 4.5.4.3: I've made a comment a couple of times now about the need >> to mention SCTP reset for disabling CLUE mid call but it appears to >> be missed. Both draft-ietf-clue-datachannel (cl.3.2.7) and >> draft-ietf-mmusic-data-channel-sdpneg (cl.5.2.4) both mention that an >> SCTP SSN reset has to be performed. >> draft-ietf-mmusic-data-channel-sdpneg (cl.5.2.4) mentions that its >> protocol specific whether this is announced by SDP. >> >> So I would propose to word the first paragraph of cl.4.5.4.3 >> differently: >> >> "If order to close a CLUE data channel in an ongoing CLUE-enabled >> call, an endpoint shall follow the procedures for closing a data >> channel defined in clause 5.2.4 >> [draft-ietf-mmusic-data-channel-sdpneg] by sending a new SDP >> offer/answer exchange and subsequent SCTP SSN reset for the CLUE >> channel. >> >> In the event that this occurs, CLUE is no longer enabled and sending of >> all CLUE-controlled media associated with the corresponding CLUE group >> MUST stop. If the data channel is still present but not included in >> the CLUE group semantic CLUE protocol messages MUST no longer be sent." >> >> Regards, Christian >> >> >> >> >> >> On 22/01/2016 3:53 AM, Robert Hansen wrote: >>> Hi all, apologies that this took longer than intended to revise and >>> check. >>> >>> Thanks to all the reviewers - almost all suggestions were >>> incorporated, usually as-is when suggested text was provided. >>> >>> * Removed the entire 'Media line directionality' section as a >>> discussion of the pros/cons of using bidirectional vs unidirectional >>> schemes wasn't suitable for a finalised version. The unidirectionality >>> requirement is covered normatively in an earlier section. >>> >>> * BUNDLE no longer includes an address synchronisation step so the >>> suggestion to wait until that done has been replaced with some general >>> language about following any negotiated extensions. >>> >>> * Added OPTIONS negotiation to the example flow, and revised the flow >>> to ensure it matched protocol document. >>> >>> * Section on not sending CLUE control media until CLUE negotiation >>> completes narrowed to notify that only RTP should not be sent until >>> negotiation completes and add RTCP to the list of things that should >>> be sent as normal, in line with a=inactive. >>> >>> * Make explicit that m=recvonly lines don't need to have a label, as >>> only m=sendonly lines are referenced by CLUE protocol messages. >>> >>> * Fix formatting of IANA sections. Improve syntax of feature tag >>> section in line with Paul's suggestions. Definition of feature tag >>> narrowed to be multiple media lines 'negotiated via CLUE protocol' >>> rather than more generic 'multiple media lines'. >>> >>> One thing that Paul brought up was that in 5.1 "Later there are >>> references to named states and transitions in the clue protocol. These >>> don't seem to be consistent with the current state machine >>> definitions" - I've checked and to me they seem to be consistent with >>> the state machines in the protocol document. >>> >>> Rob >>> >>> On 21/01/16 16:29, internet-drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the ControLling mUltiple streams for >>>> tElepresence Working Group of the IETF. >>>> >>>> Title : CLUE Signaling >>>> Authors : Paul Kyzivat >>>> Lennard Xiao >>>> Christian Groves >>>> Robert Hansen >>>> Filename : draft-ietf-clue-signaling-07.txt >>>> Pages : 36 >>>> Date : 2016-01-21 >>>> >>>> Abstract: >>>> This document specifies how CLUE-specific signaling such as >>>> the CLUE >>>> protocol [I-D.ietf-clue-protocol] and the CLUE data channel >>>> [I-D.ietf-clue-datachannel] are used with each other and with >>>> existing signaling mechanisms such as SIP and SDP to produce a >>>> telepresence call. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ >>>> >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-clue-signaling-07 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-07 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission until the htmlized version and diff are available at >>>> tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Mar 17 13:01:26 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 D732E12D680 for ; Thu, 17 Mar 2016 13:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 tMbKA22oO9D1 for ; Thu, 17 Mar 2016 13:01:13 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019EF12D622 for ; Thu, 17 Mar 2016 13:01:06 -0700 (PDT) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-09v.sys.comcast.net with comcast id X80N1s0044tLnxL01816df; Thu, 17 Mar 2016 20:01:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-02v.sys.comcast.net with comcast id X8151s00E3KdFy101815cy; Thu, 17 Mar 2016 20:01:06 +0000 To: clue@ietf.org References: <20160121162918.2158.51064.idtracker@ietfa.amsl.com> <56A10D0B.2020509@cisco.com> <56A1B915.6040800@nteczone.com> <1dd8eb0fd9f84d92bf7c4766197bb386@XCH-RCD-016.cisco.com> <56E82822.8090301@alum.mit.edu> <56EAFC10.6050307@cisco.com> From: Paul Kyzivat Message-ID: <56EB0D01.7080406@alum.mit.edu> Date: Thu, 17 Mar 2016 16:01:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56EAFC10.6050307@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458244866; bh=165QzdYKvVAH8j0WppQplsviuu5ahKpHChzITyqdkEQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=CSBY13mLYgnVzkN+Gtq9pCdpuGj3FF6vyfXug2nOP2dIqsTVMtFrMlcunpH+LXgaU v//d1WvpYmaTiH5wa+hVaKEZKVtbuRzhXaRVkCskGQU9D9fCMNK/x99Q70m5qtwDgE tY1PBfmsqF13DaZ4CrCEjPPueLz8B/KyClYUBxZgDtWyOA5xH0gsh1/4iR178vYl3e 5AZjAHEMdZfxaK1Uo+uNnN8iINQcrdbXtRdeixHBLhlAvVPhlt93gWt7uC+fiyUe9e T/pIr7MDC3xZIDC1wMvocp/4UPKRGA9Xk3+RNZ9bJQEKFzy2UhXwpSxaBpkE8yzSCR Uzr5ZNwF0pS4g== Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt 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: Thu, 17 Mar 2016 20:01:24 -0000 On 3/17/16 2:48 PM, Robert Hansen wrote: > Hi Paul, > > I did originally have a 'MUST also remove the CLUE group' bit, but then > I thought that there might be usecases where people want to keep the > CLUE-controlled media m-lines negotiated, though. If they remove the > CLUE group then they have to zero all the CLUE-controlled m-lines (since > without a CLUE group these then just become normal m-lines). > > Maybe that's a contrived use-case though, and we could have a 'MUST > remove the CLUE group and SHOULD 0 all CLUE-controlled m-lines' type bit > at the end. ISTM is is certainly *possible* to keep the (previously) clue-controlled media lines after terminating the clue session. At that point I think they must cease to be clue-controlled. So the clue group becomes meaningless at that point. If we want to ascribe some particular meaning to media lines in a clue group without clue channel, then we need to specify what that meaning is. Absent that, ISTM the proper thing to do is to remove the clue group. Then the previously clue-controlled media should be terminated (port=0), or else retained as non-clue-controlled media. If retained, then the significance of them becomes a private matter. Thanks, Paul > Rob > > On 15/03/16 15:20, Paul Kyzivat wrote: >> On 3/15/16 12:22 AM, Rob Hansen (rohanse2) wrote: >>> Hi Christian, >>> >>> Have just uploaded a new draft, incorporating your suggestions - >>> thank you for providing them. On the section on disabling CLUE >>> mid-call it is now explicit about the procedure for doing so. It also >>> covers what to do if the far end does so, and clarifies that if the >>> data channel fails or is closed without a corresponding SDP >>> negotiation to disable it CLUE-controlled media should continue to flow. >> >> In section 4.5.5.3: >> >> If, during an ongoing CLUE-enabled call a device wishes to disable >> CLUE, it can do so by following the procedures for closing a data >> channel defined in Section 5.2.4 of >> [I-D.ietf-mmusic-data-channel-sdpneg]: sending a new SDP offer/answer >> exchange and subsequent SCTP SSN reset for the CLUE channel. It MUST >> also remove the "mid" for the data channel from the CLUE group. >> >> Shouldn't the entire clue group be removed??? >> >> Otherwise this seems good. >> >> Thanks, >> Paul >> >>> Rob >>> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >>> Sent: 22 January 2016 05:08 >>> To: clue@ietf.org >>> Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt >>> >>> >>> Hello Rob, >>> >>> Thanks for the update. A couple of comments: >>> >>> cl. 4.5.2.2 adds "lines for compatible encodings" - is compatible the >>> right term here? Isn't it more "accepted encodings"? >>> >>> cl. 4.5.4.3: I've made a comment a couple of times now about the need >>> to mention SCTP reset for disabling CLUE mid call but it appears to >>> be missed. Both draft-ietf-clue-datachannel (cl.3.2.7) and >>> draft-ietf-mmusic-data-channel-sdpneg (cl.5.2.4) both mention that an >>> SCTP SSN reset has to be performed. >>> draft-ietf-mmusic-data-channel-sdpneg (cl.5.2.4) mentions that its >>> protocol specific whether this is announced by SDP. >>> >>> So I would propose to word the first paragraph of cl.4.5.4.3 >>> differently: >>> >>> "If order to close a CLUE data channel in an ongoing CLUE-enabled >>> call, an endpoint shall follow the procedures for closing a data >>> channel defined in clause 5.2.4 >>> [draft-ietf-mmusic-data-channel-sdpneg] by sending a new SDP >>> offer/answer exchange and subsequent SCTP SSN reset for the CLUE >>> channel. >>> >>> In the event that this occurs, CLUE is no longer enabled and sending of >>> all CLUE-controlled media associated with the corresponding CLUE group >>> MUST stop. If the data channel is still present but not included in >>> the CLUE group semantic CLUE protocol messages MUST no longer be sent." >>> >>> Regards, Christian >>> >>> >>> >>> >>> >>> On 22/01/2016 3:53 AM, Robert Hansen wrote: >>>> Hi all, apologies that this took longer than intended to revise and >>>> check. >>>> >>>> Thanks to all the reviewers - almost all suggestions were >>>> incorporated, usually as-is when suggested text was provided. >>>> >>>> * Removed the entire 'Media line directionality' section as a >>>> discussion of the pros/cons of using bidirectional vs unidirectional >>>> schemes wasn't suitable for a finalised version. The unidirectionality >>>> requirement is covered normatively in an earlier section. >>>> >>>> * BUNDLE no longer includes an address synchronisation step so the >>>> suggestion to wait until that done has been replaced with some general >>>> language about following any negotiated extensions. >>>> >>>> * Added OPTIONS negotiation to the example flow, and revised the flow >>>> to ensure it matched protocol document. >>>> >>>> * Section on not sending CLUE control media until CLUE negotiation >>>> completes narrowed to notify that only RTP should not be sent until >>>> negotiation completes and add RTCP to the list of things that should >>>> be sent as normal, in line with a=inactive. >>>> >>>> * Make explicit that m=recvonly lines don't need to have a label, as >>>> only m=sendonly lines are referenced by CLUE protocol messages. >>>> >>>> * Fix formatting of IANA sections. Improve syntax of feature tag >>>> section in line with Paul's suggestions. Definition of feature tag >>>> narrowed to be multiple media lines 'negotiated via CLUE protocol' >>>> rather than more generic 'multiple media lines'. >>>> >>>> One thing that Paul brought up was that in 5.1 "Later there are >>>> references to named states and transitions in the clue protocol. These >>>> don't seem to be consistent with the current state machine >>>> definitions" - I've checked and to me they seem to be consistent with >>>> the state machines in the protocol document. >>>> >>>> Rob >>>> >>>> On 21/01/16 16:29, internet-drafts@ietf.org wrote: >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the ControLling mUltiple streams for >>>>> tElepresence Working Group of the IETF. >>>>> >>>>> Title : CLUE Signaling >>>>> Authors : Paul Kyzivat >>>>> Lennard Xiao >>>>> Christian Groves >>>>> Robert Hansen >>>>> Filename : draft-ietf-clue-signaling-07.txt >>>>> Pages : 36 >>>>> Date : 2016-01-21 >>>>> >>>>> Abstract: >>>>> This document specifies how CLUE-specific signaling such as >>>>> the CLUE >>>>> protocol [I-D.ietf-clue-protocol] and the CLUE data channel >>>>> [I-D.ietf-clue-datachannel] are used with each other and with >>>>> existing signaling mechanisms such as SIP and SDP to produce a >>>>> telepresence call. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ >>>>> >>>>> There's also a htmlized version available at: >>>>> https://tools.ietf.org/html/draft-ietf-clue-signaling-07 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-07 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at >>>>> tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Mar 17 14:44:26 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 B433312D667; Thu, 17 Mar 2016 14:44:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317214424.17080.724.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 14:44:24 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-datachannel-12.txt 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, 17 Mar 2016 21:44:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : CLUE Protocol data channel Author : Christer Holmberg Filename : draft-ietf-clue-datachannel-12.txt Pages : 14 Date : 2016-03-17 Abstract: This document defines how to use the WebRTC data channel mechanism in order to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol messages between two CLUE entities. The document defines how to describe the SCTPoDTLS association used to realize the CLUE data channel using the Session Description Protocol (SDP), and defines usage of SDP-based "SCTP over DTLS" data channel negotiation mechanism for establishing a CLUE data channel. Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer procedures for negotiating usage of a CLUE data channel, are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-datachannel-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-datachannel-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 17 14:47:46 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 DFE5812DAAB for ; Thu, 17 Mar 2016 14:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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 ZZaHPTC7wxAb for ; Thu, 17 Mar 2016 14:47:41 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACBC512DA17 for ; Thu, 17 Mar 2016 14:47:40 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-25-56eb25faea1a Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F5.8D.23401.AF52BE65; Thu, 17 Mar 2016 22:47:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.122]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Thu, 17 Mar 2016 22:46:37 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Draft new version: draft-ietf-clue-datachannel-12 Thread-Index: AdGAlmR50ShRERtOSe+cyxDUDAr7IQ== Date: Thu, 17 Mar 2016 21:46:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37EC00DD@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37EC00DDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdWveX6uswg7NTNSxmTvvAarH/1GVm ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvj8cXlzAWTxCsuvFnK0sB4XaSLkZNDQsBE 4tyqd4wQtpjEhXvr2boYuTiEBA4zSlzpfMIM4SxhlDh2+SxQFQcHm4CFRPc/bZAGEQFliaOb +9lAbGYBW4mtc9aygNjCAlYSqw9tZoSosZeYOe8blK0nse/ENrB6FgFViV2re8FsXgFfiUN7 zrCC2IxAR3w/tYYJYqa4xK0n85kgjhOQWLLnPDOELSrx8vE/VghbSaJxyRNWkNOYBfIlvh20 ghgpKHFy5hOWCYzCs5BMmoVQNQtJFUSJjsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4 tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzB2Dm75bbWD8eBzx0OMAhyMSjy8BU9fhgmxJpYVV+Ye YpTgYFYS4f2i8jpMiDclsbIqtSg/vqg0J7X4EKM0B4uSOC/bp8thQgLpiSWp2ampBalFMFkm Dk6pBsayly6X592esX6LBOPSwOsmx/Qsa498vGLIKXn/8rG//tbaRnXWiy9dUtsyb3VVTPnp 7bUH9jdILorubl+ecafs1dkmiyW8FZv2tfyZHBhzY85BgdrrMVOuykz0+fLJeF4od0jux8Q7 G76FbxDMUtKStlnbuT5sk6PcggdCnzfxlla0PfNjYoxWYinOSDTUYi4qTgQADAENLpkCAAA= Archived-At: Cc: "clue-chairs@tools.ietf.org" Subject: [clue] Draft new version: draft-ietf-clue-datachannel-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: Thu, 17 Mar 2016 21:47:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37EC00DDESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the WGLC comments, I've submitted a new version (-12) of draft-iet= f-clue-datachannel. For the GitHub fans: https://github.com/cdh4u/draft-clue-datachannel Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37EC00DDESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on the WGLC comments, I’ve submitted a n= ew version (-12) of draft-ietf-clue-datachannel.

 

For the GitHub fans: https://github.com/cdh4u/draft-clue-datachannel

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37EC00DDESESSMB209erics_-- From nobody Fri Mar 18 18:12:42 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 EFF4512D991 for ; Fri, 18 Mar 2016 18:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, 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 CfM0lyVmtckq for ; Fri, 18 Mar 2016 18:12:35 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74B112D941 for ; Fri, 18 Mar 2016 18:12:34 -0700 (PDT) Received: from [216.82.242.36] by server-13.bemta-8.messagelabs.com id 2C/82-05573-187ACE65; Sat, 19 Mar 2016 01:12:33 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-13.tower-94.messagelabs.com!1458349951!41108980!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 8.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 125343 invoked from network); 19 Mar 2016 01:12:32 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-13.tower-94.messagelabs.com with AES128-SHA encrypted SMTP; 19 Mar 2016 01:12:32 -0000 Received: from SACWPHUBCAS03V.polycom.com (10.236.3.233) by crpehubprd02.polycom.com (10.236.0.154) with Microsoft SMTP Server (TLS) id 8.3.389.2; Fri, 18 Mar 2016 18:12:31 -0700 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by SACWPHUBCAS03V.polycom.com ([fe80::5588:3af:ccc1:5fa7%12]) with mapi; Fri, 18 Mar 2016 18:12:31 -0700 From: "Duckworth, Mark" To: Daniel Burnett , "clue@ietf.org" Date: Fri, 18 Mar 2016 18:12:28 -0700 Thread-Topic: [clue] WGLC for draft-ietf-clue-rtp-mapping-06 ends 18 March Thread-Index: AdF5ccCGaq7wpvxORK69PT9wOcMLlAICnQDA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52FC1904E70F8@CRPMBOXPRD08.polycom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00AF_01D1815A.E0C212F0" MIME-Version: 1.0 Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-06 ends 18 March 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: Sat, 19 Mar 2016 01:12:37 -0000 ------=_NextPart_000_00AF_01D1815A.E0C212F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00B0_01D1815A.E0C212F0" ------=_NextPart_001_00B0_01D1815A.E0C212F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I reviewed the document again. I don=E2=80=99t have anything to add to = the suggestions other reviewers have already made. Mark =20 From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Daniel Burnett Sent: Tuesday, March 08, 2016 2:36 PM To: clue@ietf.org Subject: [clue] WGLC for draft-ietf-clue-rtp-mapping-06 ends 18 March =20 This message announces the start of a 1.5 week WGLC for = draft-ietf-clue-rtp-mapping. The last call will end at midnight on = Friday, 18 March 2016 to allow time for a rev before the 21st. PLEASE REVIEW NOW. =20 -- Dan (for the Chairs) =20 ------=_NextPart_001_00B0_01D1815A.E0C212F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I reviewed the document again. I don=E2=80=99t have anything to add = to the suggestions other reviewers have already = made.

Mark

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of Daniel = Burnett
Sent: Tuesday, March 08, 2016 2:36 PM
To: = clue@ietf.org
Subject: [clue] WGLC for = draft-ietf-clue-rtp-mapping-06 ends 18 = March

 

This message announces the start of a 1.5 = week WGLC for draft-ietf-clue-rtp-mapping. The last call will = end at midnight on Friday, 18 March 2016 to allow = time for a rev before the 21st.

PLEASE REVIEW = NOW.

 

-- Dan (for the = Chairs)

 

------=_NextPart_001_00B0_01D1815A.E0C212F0-- ------=_NextPart_000_00AF_01D1815A.E0C212F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUEjCCBQ0w ggL1oAMCAQICEBrVY02YeFKcQ+zVfznU/o4wDQYJKoZIhvcNAQEFBQAwGTEXMBUGA1UEAxMOUG9s eWNvbS1Sb290Q0EwHhcNMTMxMTA0MTg1NzA2WhcNMjMxMTA0MTkwNjU4WjAZMRcwFQYDVQQDEw5Q b2x5Y29tLVJvb3RDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMzj+6krY3OF7mtq +O2/yC5heUML7DFZn2cp0Mkp/vos7TDrysGdPDdEIK+zYvZQZs6TrGzPh0XXnEpMcHE7V4nD5zN3 VX0+Zg46w0wCHdkgq/GV3EKlyg0AsX8LgooGlUMeuUNpe+sT0WBl3mXB97TUw7mnRLY1m/IAlyFv 4XO8LfQ1L03vfLBRAVft7xc9Okm6DbHrPxFx9VKpgIkSIUvIx/BK0zXBa/0arWW3tfimfY9t5KdJ Wqb68E8Nb0bD8S0Ve0O76TCR4dVE/HmVj6YrauGcUGfvB4yT+bOOCGlsOw3NoHW2G9PZJF9B9PvV cWzv9Jw3AlzGU2sQMbVD1ZiiRgkG47bvqvi/tg38vWEDMj1lzSpMp/FhC8YrSaGb4YwjM52w9MXM DNypbOFZ/0WjrykwuGB1P9Ga38nRlaMkMJ3lE7P1pQMgxElO5uE+1TI5kTJ9mIGgQtQb57w4vkkJ kHNKjmqzOo3IFkhEIUS3ARPkYG4HWzP7xtmcYBoEx4QwpbxYQKKcxN9h/zuv9LYc79WvnF+i+aj0 1YJKoldsPnIXhG3HullYVQb+v19q8cqm0OGUEq7e2wY72H6JiT6YFc5kZitpZ65L5d1OGVLyFO6b iC79ARA9eBE5L3g9zF/du+U1k9L6LWW3VaHr3ZDCECU8ZX5QeBrqv2aTb0VNAgMBAAGjUTBPMAsG A1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSMD03mpjCj/UgRICWESaXA53z3 0TAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAAOCAgEAs02vFW5Je6895ZBWadxy5vxR z2imWk97qU2sMFSMnmf9QeqPwdawGO33zWr1sSQr8d67AHQc+3ihZuoAaeQAAC6Lww9r17Q3vVqg 7Qge86101Xw1fjXqTFUnWTxBK0S7re7pMqWlqaFgFQOHBMLnrM9z+NQIyDh7st9JjA+bRfFwErQ9 5CziXu+o/4q7eDBP1WaI0yKkEcOQ2LyPuCCE4hcshcJABiSYPax8nW71foHb+bv92IYvYXu2Wpa6 VgnxYqdi2k0Yk8CDiYalVsc+7QH0euQ1YIcovPbpZ02AirLqiiy6XB9i8OKfuapKSftsdfjLKqwI L7lKqz/4uAheETQsORVEh4IT0P8RRaIgHBOBVz/DOW+/IiiYagOJIYqbwGIFImQ7uOLNCoP5qY4y PLUZhmHFnnr7xtz4gv455KP9cwtPYcAarc/IB7WkTmEhFYa19k4jXlZ19AZIO/SPhvV7qz50zqB+ pCReRB5fXnf3qhRSw2WpRD4xr/q8OrWTfQRdXaooTJ14tRziqjEWLz4nPQKbE45aAjgwO0Rp6k5J tWGPhCxmuru/iqVES98VbjuAoo2qYZk7eNrqcnMuSxgqU0bgyie/R/FfMcbsw6rAh7T+qfBSxVIQ tpiqPwtZR5kdi6af3vf4w9q1PvEGrNipAjKEN2HW73558qGfPMowggZ5MIIEYaADAgECAhNuAAAA AgUmZh85ZflDAAAAAAACMA0GCSqGSIb3DQEBBQUAMBkxFzAVBgNVBAMTDlBvbHljb20tUm9vdENB MB4XDTEzMTEwNDE5MTM1MFoXDTIzMTEwNDE5MDY1OFowSDETMBEGCgmSJomT8ixkARkWA2NvbTEX MBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAOZhKwn7h/qKsHx8zQQPT356Og5GOOJ26SKfzS6dIZaD NjFIhS/5QRd3HZ9I1qFD8faDfpIHL+NzC0xqYJUZsEKntD+cCj99nx33t9D6GCmsEEngeLV0FO/u DlDcCXVJNJWS65E05vKyWFPlIRegDs+E73mNh3dHZ53mgrsCFd8PnX5Zm6zm+dAinDTUreXzSuzT si5yuZ10jHdEoin3bQyYQfAe4nR7BiqcQzYnD+JgU+NrZZ555xMdwVtRhjIFuFHwCN1BgWL8+cmI PTmW3bS/irYkbUn/IYFXGJIdgeZTzsp22+OPChBkCBiy86d9RaM6qvOV/ZLmq0bj4souN1cNBg0g ZnYIgTypQY/5Ew99FJJDor4TH1R5YNtqgwxBiSZSc0WSKy8WBrcUpBM+FP1gETY2sqZh2ApFkhU1 7BBLXcEwu6dnSO9Y5u0zJfOTKPesVaeGTfvzTEcm6A8xKO6V+ai/zhu3egbv4SmlPGiMENMPsWRy cG0c73xz/w9RwpWpImjIcE3+XA9rPhIdNj2KN4sbMJvvN5/ZLJHRScE5F3pltq2sFLyPSqhukYVY NRVXmdJ14FCArDqlrREeWLA2tP4ir0WeFeX6KgU+QrmWvdw1hJZ9/lPkiqDvuBWvDVyON0u/Dvi3 p6RJmWJlC5F8ajRegnM+BAYfokRZkvOHAgMBAAGjggGJMIIBhTAQBgkrBgEEAYI3FQEEAwIBADAd BgNVHQ4EFgQUcIfA57S89xZAbs9iT83FhcVNeekwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEw CwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUjA9N5qYwo/1IESAlhEml wOd899EwbwYDVR0fBGgwZjBkoGKgYIYuaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtpL1BvbHlj b20tUm9vdENBLmNybIYuaHR0cDovL2NkcDIucG9seWNvbS5jb20vcGtpL1BvbHljb20tUm9vdENB LmNybDCBhgYIKwYBBQUHAQEEejB4MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMS5wb2x5Y29tLmNv bS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMi5wb2x5Y29t LmNvbS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQDAITSF89YEDKMA zqteWVdg8IqzdMHSHIJGybNrbe1UJj6trSldu42wcgjYLgJrTIDEUEX2Qp1xywpv+zpVAE1bVoek 6ot846XEIiOTofJYnwACZNnCLJ3ijG2iuBCSJjPc6FzwCF/2DMR0erdh8PNhEnl3xDRNyqVOy+DC mlLssSjPgej1UxM4yaDZZUCBrkv1dB3a4qkTbMPFBj5CkC5gPnyKTRW7iUFMKr0pXvByGPHCtRbu ShXAcoSdVH2f8cLUfJ8raVMWu1ynjOMcvlagDaZAcbzLSc8hzhxJNC6Wel9U1uFyEaYGodJTMxzv e5zRU5wZod5kPaEThCKq12Fr9Sz/dYYp4Rup/SymTS4A46qMIrOi6i3icxa3SYAhsCeALdcrgCH4 +cCtKiEE1UpqIfJq8P/+FE6cnfHyGaXD+wn4BTA5BrUBg900HNVNf1Y6BDMqaXDeAPKbiSb5FDot PjAW0v7GLoshHMr+951EdhaFNSUyOV8CoSx9b9BjlYpjJV+QtiaqJLn9UlNOa987Fg9dIY4vrfqH q9kCVr+sVpQsZ6DC17bE7etrHPevRny/EcLmuJY1RD56gPAyePHFs1GEhmKVW9ZlLWtNs79G6wSf ZRnr3vRAtr7v0zWyjfvn52HWM4kbXedjCa/q9boJMVqK+8DJawhrrn38Liw7oDCCCIAwggZooAMC AQICE2sAANv9iRUGFNx/sYkAAAAA2/0wDQYJKoZIhvcNAQELBQAwSDETMBEGCgmSJomT8ixkARkW A2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTAe Fw0xNjAyMTYxNzI1NTlaFw0xNzAyMTUxNzI1NTlaMIGnMRMwEQYKCZImiZPyLGQBGRYDY29tMRcw FQYKCZImiZPyLGQBGRYHcG9seWNvbTEPMA0GA1UECxMGUGVvcGxlMRIwEAYDVQQLEwlFbXBsb3ll ZXMxDTALBgNVBAsTBE5BTEExGDAWBgNVBAMTD0R1Y2t3b3J0aCwgTWFyazEpMCcGCSqGSIb3DQEJ ARYaTWFyay5EdWNrd29ydGhAcG9seWNvbS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDUKfyJTxXkwEsUnHz/9m3k1jNMh31VSjpcboNOXMLE7ERqwC+KdVON0NLHp5ctN4kWewuu YDOuS+Qhp/Pm/+T2acQ0cqw+oY3nvKl7erYfC5Ul0EATlD3aUTGz34L2iKttOm9YID2GylBH9670 PHQ7n3YqC5sh1C7l2S4CznZz5c4ATRw1VtAzWskinzwYWKeiJV2ybr4JU9EM5QAGqM84jFXV2kN2 3CGKmAWlo6GIXstg82hfTkfubmgW9BQ+iyHEfwP1DIvdLh4tsyrgHoz+qomNaXmG+jUiP5CktXDF KueQLciDeg9HyxGh7AgtTvdMtI3KZUFCDyKDN4k0ux/5AgMBAAGjggQBMIID/TA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiGpOVThtjlcoO1gRiEnaYag+m7OimFw9RYg9ngHQIBZAIBBzApBgNV HSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwCwYDVR0PBAQDAgWgMDUGCSsG AQQBgjcVCgQoMCYwCgYIKwYBBQUHAwIwCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDBDBEBgkqhkiG 9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZI hvcNAwcwHQYDVR0OBBYEFBENjiHBionI5U/bTdJlzr9d3XeNMB8GA1UdIwQYMBaAFHCHwOe0vPcW QG7PYk/NxYXFTXnpMIIBOgYDVR0fBIIBMTCCAS0wggEpoIIBJaCCASGGgbxsZGFwOi8vL0NOPVBv bHljb20tU1VCQ0EwMSxDTj12d2NvbG9zdWJjYTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXBvbHljb20sREM9Y29tP2Nl cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludIYvaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtpL1BvbHljb20tU1VCQ0EwMS5jcmyGL2h0 dHA6Ly9jZHAyLnBvbHljb20uY29tL3BraS9Qb2x5Y29tLVNVQkNBMDEuY3JsMIIBPQYIKwYBBQUH AQEEggEvMIIBKzCBrgYIKwYBBQUHMAKGgaFsZGFwOi8vL0NOPVBvbHljb20tU1VCQ0EwMSxDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz1wb2x5Y29tLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTA7BggrBgEFBQcwAoYvaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtp L1BvbHljb20tU1VCQ0EwMS5jcnQwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZHAyLnBvbHljb20uY29t L3BraS9Qb2x5Y29tLVNVQkNBMDEuY3J0MEgGA1UdEQRBMD+gIQYKKwYBBAGCNxQCA6ATDBFtYXJr ZEBwb2x5Y29tLmNvbYEaTWFyay5EdWNrd29ydGhAcG9seWNvbS5jb20wDQYJKoZIhvcNAQELBQAD ggIBAHSlqpzE3JJ6cwdt2ve4eLY7IBfvrGjyFRQRfUgHg7SpxJVjB1jIZY7xXeGcBozQDSO6nQF6 KN3s+Mhy1GgH0tRMZBqefwZaT0taRdMHH/bXxDE4Qf8BRMXNIPZPb+2CV4ldFakuT1VZwmg1Gdtc ZU41o/zXYUBkzjPRX4DaEBWDsxI8Z3OX0lz3Kps3CocagYE+sjTaPIEFF3Gztyw5I8fS/nMnrSq3 G91bqqWE0teuGfBdt6tKqavJ0qHobkOQRV2bQi6OPzLZg8a1IaSZMviUDgzj/VASvw7phEUScEVf VqAvoru/7TWREyoc/lSvsd+PTpMeOjLUDre/FAbRGpN9Sx8FuBgvvb3wYdIMg/R8tIaQ8tqaAG/3 dSa9IeRfWOrcAOuc8TUieSDsTqugStWtKVsO8dCcZtdaPpL0deSjjEF+Ep9ZfqufhibQyFGNTjRK VwgxCQc+owwJx69vo2oDlzwWYhASQmwXVW9eiSWnvvMhvAny5dftCFaV47mSyQimkQ3k/rsX2Cg9 qbeuI0dSSD5c5pgE6z3jkF8ISL/1WitwCtG5Yqqp7Q8G2a35smlSVRzc1WTAiy6jZHSPZsbnRu5Y 9BnsB/TOcmKt9kAn6VUAC4j+Rq7MokZJzmj0sKNMH4qz3bo6ZMImkGS3xCLyvsK4iilg1Me67dlz bbJ1MYIDdzCCA3MCAQEwXzBIMRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYH cG9seWNvbTEYMBYGA1UEAxMPUG9seWNvbS1TVUJDQTAxAhNrAADb/YkVBhTcf7GJAAAAANv9MAkG BSsOAwIaBQCgggHtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MDMxOTAxMTIyOFowIwYJKoZIhvcNAQkEMRYEFBT0zIddOdy4lK7slLBtvFqQI1XvMG4GCSsGAQQB gjcQBDFhMF8wSDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20x GDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMQITawAA2/2JFQYU3H+xiQAAAADb/TBwBgsqhkiG9w0B CRACCzFhoF8wSDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20x GDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMQITawAA2/2JFQYU3H+xiQAAAADb/TCBqwYJKoZIhvcN AQkPMYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG 9w0BAQEFAASCAQBYxsozq3qJQdzAusRLLi+1i/TCzPykxdh4UEbvXLCSLERDPHCIoyYIhxIRP7C5 LHDI9T/9+cNGf7baeJzyKxFKfyDlnmiIJatpYaS2mGLFm12RerFPfPghTDhdcC5A8ADAVPFK+JCB AT5O8XNDWVFhkGXFeKEkE+l5Ci7ACsUdXNW/6nTIpHNLP3MsCWo6ZPXzrtsn978baTSZGoIgD4lE 7YBmZK9GBER1HozoDWSmdNbwvSY061YagjQqzRGQM1SGB6wCipgqK3IHY7haaErwU+cIELpZJCGM ugnRoQVWWTbebV1qJNKKe9GyMJW5nN15uzyN7mKVb2GPxD5GiDu/AAAAAAAA ------=_NextPart_000_00AF_01D1815A.E0C212F0-- From nobody Sat Mar 19 19:40:32 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 A8CF112D6BD for ; Sat, 19 Mar 2016 19:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com 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 dWGW3Cg9-r1j for ; Sat, 19 Mar 2016 19:40:30 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08E812D567 for ; Sat, 19 Mar 2016 19:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=SmVXyMHpcjMDZl0LirdEk6wt4ChqQQnKy51JVbrhoa8=; b=FyhHjyNFwwcRQFO918QOOBg62w NTH4oZlQUBkxbbnGDhr1O9k55VBrwtunyGiYLqxwXGKGa1eYskOhHGon6uocNfpBmghIsQoMetbM3 itpYFuo/QLD9X9mCULVdBlBVZDdlhMrm+HnDjIJaFRONoNtxWEF6D6UsD+WOUc1raqBR6YKTFIPfh bM57cXm6y6GXF7ND9Fs6gEdojilfnQ7Gb17J4O2sjMEX9HV38eR4r8VDvHxeNAUoV0sQVCZakJjIo H9N7+h11mIwSpIEpRiAludAyw/xQV5HzKhDyZbie4HjE6y9mcJglQagdZMP3Q5+JEmxl+mvWW11xH MR1C/SRQ==; Received: from [206.121.102.138] (port=51566 helo=[10.211.45.93]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1ahTI4-003vci-RM for clue@ietf.org; Sun, 20 Mar 2016 13:40:29 +1100 To: clue@ietf.org References: <20160121162918.2158.51064.idtracker@ietfa.amsl.com> <56A10D0B.2020509@cisco.com> <56A1B915.6040800@nteczone.com> <1dd8eb0fd9f84d92bf7c4766197bb386@XCH-RCD-016.cisco.com> <56E82822.8090301@alum.mit.edu> <56EAFC10.6050307@cisco.com> <56EB0D01.7080406@alum.mit.edu> From: Christian Groves Message-ID: <56EE0D9B.2010009@nteczone.com> Date: Sun, 20 Mar 2016 13:40:27 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56EB0D01.7080406@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt 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: Sun, 20 Mar 2016 02:40:31 -0000 On 18/03/2016 7:01 AM, Paul Kyzivat wrote: > On 3/17/16 2:48 PM, Robert Hansen wrote: >> Hi Paul, >> >> I did originally have a 'MUST also remove the CLUE group' bit, but then >> I thought that there might be usecases where people want to keep the >> CLUE-controlled media m-lines negotiated, though. If they remove the >> CLUE group then they have to zero all the CLUE-controlled m-lines (since >> without a CLUE group these then just become normal m-lines). >> >> Maybe that's a contrived use-case though, and we could have a 'MUST >> remove the CLUE group and SHOULD 0 all CLUE-controlled m-lines' type bit >> at the end. > > ISTM is is certainly *possible* to keep the (previously) > clue-controlled media lines after terminating the clue session. At > that point I think they must cease to be clue-controlled. So the clue > group becomes meaningless at that point. > > If we want to ascribe some particular meaning to media lines in a clue > group without clue channel, then we need to specify what that meaning is. > > Absent that, ISTM the proper thing to do is to remove the clue group. > Then the previously clue-controlled media should be terminated > (port=0), or else retained as non-clue-controlled media. If retained, > then the significance of them becomes a private matter. > > Thanks, > Paul > [CNG] Seems a reasonable approach. Regards, Christian From nobody Mon Mar 21 15:16:02 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 4ED9D12D0AD; Mon, 21 Mar 2016 15:16:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321221600.12199.43134.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 15:16:00 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-protocol-07.txt 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: Mon, 21 Mar 2016 22:16:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : CLUE protocol Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-protocol-07.txt Pages : 55 Date : 2016-03-21 Abstract: The CLUE protocol is an application protocol conceived for the description and negotiation of a CLUE telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined, respectively, in [I-D.ietf-clue-framework] and [RFC7262]. The companion document [I-D.ietf-clue-signaling] delves into CLUE signaling details, as well as on the SIP/SDP session establishment phase. CLUE messages flow upon the CLUE data channel, based on reliable and ordered SCTP over DTLS transport, as described in [I-D.ietf-clue-datachannel]. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-protocol-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 15:22:27 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 AD95E12D106; Mon, 21 Mar 2016 15:22:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321222223.12223.2217.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 15:22:23 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-signaling-09.txt 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: Mon, 21 Mar 2016 22:22:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : CLUE Signaling Authors : Paul Kyzivat Lennard Xiao Christian Groves Robert Hansen Filename : draft-ietf-clue-signaling-09.txt Pages : 37 Date : 2016-03-21 Abstract: This document specifies how CLUE-specific signaling such as the CLUE protocol [I-D.ietf-clue-protocol] and the CLUE data channel [I-D.ietf-clue-datachannel] are used with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-signaling-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 15:50: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 35CA012D102 for ; Mon, 21 Mar 2016 15:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 zrs7ES2TlSuS for ; Mon, 21 Mar 2016 15:50:42 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F085B12D0E0 for ; Mon, 21 Mar 2016 15:50:40 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-08v.sys.comcast.net with comcast id Ymqb1s00352QWKC01mqgoS; Mon, 21 Mar 2016 22:50:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-09v.sys.comcast.net with comcast id Ymqf1s00H3KdFy101mqg5i; Mon, 21 Mar 2016 22:50:40 +0000 To: CLUE References: <20160321221600.12199.43632.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <56F07ABF.7030909@alum.mit.edu> Date: Mon, 21 Mar 2016 18:50:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160321221600.12199.43632.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458600640; bh=fUsY2fBpLJ6GH0HgIgpYhLsr79gGNnBn4gFQbaX06yo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=sfeM7PZuoYutCiQ9GqMwxICKEfxgRThwgkUZ/G4ZvQvto+AbDp/xqxIsFMhaeHpJM duXpivWBdDc5GjxqNT9fld/lkxe6d/lY+QC6T1ZeRAnoPh/yeuntpA8xHLijrOjUZE xcfP86qLKg+6LnNXS802i6REQsS3kxOXZ1uC0NZJBa3u4zktjLb+Lc+rGGruKujweZ NKpxvSrzytCjDMK/UZauAnR9shp/Vukhu1X1whJWQJ12cilx/Gs+OG18ArpP4UgAWw K/vG2xHyy2wlux1ZxCq3lnf62vp8/jpFeilBWjrSMtlHIaJyTtiHgk7w2zkA3FIvWM JPJpYu7wYdG8A== Archived-At: Subject: Re: [clue] New Version Notification - draft-ietf-clue-protocol-07.txt 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, 21 Mar 2016 22:50:43 -0000 After a *very* quick look at this new version, I noticed one issue: In section 4.7, in the table, there are two entries labeled 302. The 2nd of those (Conflicting values) should be 303. (That will make it consistent with section 11.4.2. Thanks, Paul From nobody Tue Mar 22 06:21:28 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 C83E612D7B6 for ; Tue, 22 Mar 2016 06:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 l4TM-JyZFFAQ for ; Tue, 22 Mar 2016 06:21:24 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043C212D7B8 for ; Tue, 22 Mar 2016 06:21:18 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id l68so192421365wml.0 for ; Tue, 22 Mar 2016 06:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=umf65Bn+LOqm+mxDfbJrNlJYvljuVNPuopZ9r6ZIqVM=; b=fh+dY5h/KIVjm2SL8UrLxpND/cU43aPosJv0pd3QCiJnowFJYECHtMb+i6r+A0GGwH G798Lgujgg2wPq11dCmY9dK7VDM5vFy5ipMin6YSjfKrl85A14pMjN1VQQA21WrCnohX bnMd8+NiOWRoXX2SVlDetCgXjC6qk4MWWM8xesTwxVuznxYv02bEBBiiSZDl+dUDv4Nf pmQno5xFq9s/Eg7U2P6DLOL6djktFEMkrsmIC0EBnGKqZObbMAikE/3Twkiaxkq8UpJ1 mRluXlkPg6vj057JHw3OoeZsCsqp9pp8nV+GpWW3h8wL35xNTChzJOYP33w6UUHEX9bb sNfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language; bh=umf65Bn+LOqm+mxDfbJrNlJYvljuVNPuopZ9r6ZIqVM=; b=gFSDG1qkDLyz2TlAc/cWmH/QPEDbXepbGFsHByqaOmJ48AI+vKMMOV5GqbgH07DoKK qj3syilmS0FJb5kBZz3P3KlEWJ+KeXJBFt0/a+NnskDA+D7WpOU6eIlMF7+Doxz4xHeO ppo4U3KXrU1YaTuUBWLkRZd2T848eleCS/Jh5CG/ZWzVo5LPEIFsjNmuzE/o8E5ietyG LWd9WBwWLv9GjjskY8tiTu9+NaO5RhcnaYIlWgctwyP4nJHh1POu4fyv2BL92ChLjir2 j+gziHSQUyfuRUEdehF7U3yJxzicwncNoXAtIfSzosb72yqExRVd2IR716FOyThpQeeM S5kA== X-Gm-Message-State: AD7BkJKOqv3jxyw6gZxYsvvbbfpD2F/apddYqZUiEkOJuA9zhqTmO9o1sCRnl1XTXL4y9Q== X-Received: by 10.194.60.145 with SMTP id h17mr39011680wjr.47.1458652876456; Tue, 22 Mar 2016 06:21:16 -0700 (PDT) Received: from RoniPC (bzq-79-178-98-202.red.bezeqint.net. [79.178.98.202]) by smtp.gmail.com with ESMTPSA id y72sm17416900wmh.21.2016.03.22.06.21.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2016 06:21:15 -0700 (PDT) From: "Roni Even" To: Date: Tue, 22 Mar 2016 15:21:10 +0200 Message-ID: <1f6e01d1843d$b3ff4ea0$1bfdebe0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1F6F_01D1844E.778893D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGEPT5CFdPSTZn0Q6WlzhXmromVUQ== Content-Language: he Archived-At: Subject: [clue] CLUE session in BA 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, 22 Mar 2016 13:21:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1F6F_01D1844E.778893D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The WG chairs feel that we do not really need to have a session in Buenos Aires. It looks like all documents are after WGLC and need to finish the open issues discussed on the list. This will also support our intention to finish the work and close the WG. Any opinion from the WGs. Thanks Roni Even CLUE co-chair ------=_NextPart_000_1F6F_01D1844E.778893D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The WG chairs = feel that we do not really need to have a session in Buenos Aires. =

It looks like all documents are = after WGLC and need to finish the open issues discussed on the = list.

This will also support our = intention to finish the work and close the WG.

 

Any opinion = from the WGs.

 

Thanks

Roni = Even

CLUE co-chair =

------=_NextPart_000_1F6F_01D1844E.778893D0-- From nobody Tue Mar 22 11:04:52 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 2018112D750 for ; Tue, 22 Mar 2016 11:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 D28xfISa2pOc for ; Tue, 22 Mar 2016 11:04:45 -0700 (PDT) Received: from brc1.unina.it (brc1.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611F212D723 for ; Tue, 22 Mar 2016 11:04:45 -0700 (PDT) X-ASG-Debug-ID: 1458669882-05ce37326b2db8540001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id JLsBUkCO6LcoJc2N (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Tue, 22 Mar 2016 19:04:42 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id u2MI0sPG029482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Mar 2016 19:04:42 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_0254974E-3967-47C4-95A8-27CD9775720D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] CLUE session in BA In-Reply-To: <1f6e01d1843d$b3ff4ea0$1bfdebe0$@gmail.com> Date: Tue, 22 Mar 2016 19:04:02 +0100 Message-Id: References: <1f6e01d1843d$b3ff4ea0$1bfdebe0$@gmail.com> To: Roni Even X-Mailer: Apple Mail (2.2098) X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1458669882 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.28059 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: clue@ietf.org Subject: Re: [clue] CLUE session in BA 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, 22 Mar 2016 18:04:48 -0000 --Apple-Mail=_0254974E-3967-47C4-95A8-27CD9775720D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Agreed! Simon > On 22 Mar 2016, at 14:21, Roni Even wrote: >=20 > Hi, > The WG chairs feel that we do not really need to have a session in = Buenos Aires.=20 > It looks like all documents are after WGLC and need to finish the open = issues discussed on the list. > This will also support our intention to finish the work and close the = WG. > =20 > Any opinion from the WGs. > =20 > Thanks > Roni Even > CLUE co-chair=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue = --Apple-Mail=_0254974E-3967-47C4-95A8-27CD9775720D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Agreed!

Simon

On 22 = Mar 2016, at 14:21, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi,
The WG = chairs feel that we do not really need to have a session in Buenos = Aires. 
It looks = like all documents are after WGLC and need to finish the open issues = discussed on the list.
This will also support our intention to finish the work and = close the WG.
 
Any opinion from the WGs.
 
Thanks
Roni Even
CLUE co-chair 
_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

= --Apple-Mail=_0254974E-3967-47C4-95A8-27CD9775720D-- From nobody Tue Mar 22 13:24:30 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 2EFBA12D970 for ; Tue, 22 Mar 2016 13:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com 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 jZ6QK_4UyEU5 for ; Tue, 22 Mar 2016 13:24:28 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A5012D979 for ; Tue, 22 Mar 2016 13:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=HQC4U2vbyWnw7ttwVuQbdfpx9Jn+tjF5D15mJyQk6fU=; b=KuU2GRxw7L/Ijg/8Ak+iOaYPEI LqVQdYQ43m0JegViosL88TtYhWl4qlIb+KR4kmmKioApAbyfQ6ToeVWCY9BPfJaPjCz1vLh3/crvL 8yW4zdo3LMnWYVsn+S56mrus7JaECzG/7hSPAxVti6/vnDLJ+n5to3obqnBMRuQC8L6e+IPDTeZnF GYIRFog/UG8SaOfRciwPHj8UIb175ParXbtn6EN1PDa4mO36HQxF8ZJXV79lcl1i05VLuvC4G6VMq 6qRI9CwkGhpFjdrgR9vYXQn7oxnA8ww11KZtlGGBQ62+QjP4qpPcH1XOS/lYfjFVxLaTmC/hvrRD2 UNwih5gQ==; Received: from ppp118-209-30-74.lns20.mel4.internode.on.net ([118.209.30.74]:50600 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1aiSqd-000rn9-9m for clue@ietf.org; Wed, 23 Mar 2016 07:24:15 +1100 To: clue@ietf.org References: <1f6e01d1843d$b3ff4ea0$1bfdebe0$@gmail.com> From: Christian Groves Message-ID: <56F1A9EB.5070007@nteczone.com> Date: Wed, 23 Mar 2016 07:24:11 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] CLUE session in BA 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, 22 Mar 2016 20:24:29 -0000 +1 Christian On 23/03/2016 5:04 AM, Simon Pietro Romano wrote: > Agreed! > > Simon > >> On 22 Mar 2016, at 14:21, Roni Even > > wrote: >> >> Hi, >> The WG chairs feel that we do not really need to have a session in >> Buenos Aires. >> It looks like all documents are after WGLC and need to finish the >> open issues discussed on the list. >> This will also support our intention to finish the work and close the WG. >> Any opinion from the WGs. >> Thanks >> Roni Even >> CLUE co-chair >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Mar 22 15:41:00 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 D0CA712D0A1 for ; Tue, 22 Mar 2016 15:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=UNCQwbrj; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=ZuLprb+N 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 uUZ8wAr7GUaz for ; Tue, 22 Mar 2016 15:40:57 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E12712D098 for ; Tue, 22 Mar 2016 15:40:57 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A3E5520DEB for ; Tue, 22 Mar 2016 18:40:56 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 22 Mar 2016 18:40:56 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=kn0nF GjzsURyX2z4vOs1aq70c1U=; b=UNCQwbrjHYLcZAjcj8fsd/lG4HgRJI+0VFy7q Bs2nPY+4YVQVuJWlCm1R/zQ8twNLG+sfZKZ0IVffY9LRWiLp1PCgNuascu8S2BvZ 2KLf0nPuezX1PtsVMVixI7f3JS/XLAkmND47GDs5e0OLsCJjG+IDpwQJJtDKFpDv h26apo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=kn0nFGjzsURyX2z4vOs1aq70c1U=; b=ZuLpr b+Np10gxegkQ77QDoF036Vn4d9QkGaM07sjOCtElREfHXYA5VTu+DUXny3OX6nA1 H7t0hFz6edmDbAtacBuSBk8bbCONdRayCek4seg2KsxkZZ9Hna7Jab2CLwwczn3i rJObkgWqBhRyz6MB0pJNmpkyRZoPrO6jT+AoXI= X-Sasl-enc: mqSVmwuO7Ub8OjxcWpIXHaEGHBLVacsxVnv7Hb90q2GH 1458686456 Received: from dhcp-171-68-20-144.cisco.com (dhcp-171-68-20-144.cisco.com [171.68.20.144]) by mail.messagingengine.com (Postfix) with ESMTPA id 1ABECC00016; Tue, 22 Mar 2016 18:40:56 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0D409D44-8D24-49C3-9FB5-242C38D47AC1" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <1f6e01d1843d$b3ff4ea0$1bfdebe0$@gmail.com> Date: Tue, 22 Mar 2016 15:41:13 -0700 Message-Id: <4CFBCCBF-CF6F-495A-83A3-95D55AD4271E@cooperw.in> References: <1f6e01d1843d$b3ff4ea0$1bfdebe0$@gmail.com> To: Roni Even X-Mailer: Apple Mail (2.3112) Archived-At: Cc: clue@ietf.org Subject: Re: [clue] CLUE session in BA 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, 22 Mar 2016 22:40:59 -0000 --Apple-Mail=_0D409D44-8D24-49C3-9FB5-242C38D47AC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The protocol document still does not have a security considerations = section, or any discussion really of the threat model against this = protocol and how known threats are thwarted. This is a significant = omission and as I=E2=80=99ve mentioned to the shepherd it is not even = worth requesting publication of the document until the security = properties of the protocol are properly described in the document. I would suggest that folks use the 1 hour allotted to make progress in = this area, whether by discussing it in the WG slot, or having a = selection of folks go work together on it (and cancelling the WG = session), or even by updating the draft to address this before the = meeting (I=E2=80=99ll use my AD override to waive the deadline) and = having a discussion of the added text. Thanks, Alissa > On Mar 22, 2016, at 6:21 AM, Roni Even wrote: >=20 > Hi, > The WG chairs feel that we do not really need to have a session in = Buenos Aires.=20 > It looks like all documents are after WGLC and need to finish the open = issues discussed on the list. > This will also support our intention to finish the work and close the = WG. > =20 > Any opinion from the WGs. > =20 > Thanks > Roni Even > CLUE co-chair=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue = --Apple-Mail=_0D409D44-8D24-49C3-9FB5-242C38D47AC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
The protocol document still does not have a = security considerations section, or any discussion really of the threat = model against this protocol and how known threats are thwarted. This is = a significant omission and as I=E2=80=99ve mentioned to the shepherd it = is not even worth requesting publication of the document until the = security properties of the protocol are properly described in the = document.

I = would suggest that folks use the 1 hour allotted to make progress in = this area, whether by discussing it in the WG slot, or having a = selection of folks go work together on it (and cancelling the WG = session), or even by updating the draft to address this before the = meeting (I=E2=80=99ll use my AD override to waive the deadline) and = having a discussion of the added text.

Thanks,
Alissa

On Mar 22, 2016, at 6:21 AM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi,
The WG chairs feel that we do not = really need to have a session in Buenos Aires. 
It looks = like all documents are after WGLC and need to finish the open issues = discussed on the list.
This will also support our intention to finish the work and = close the WG.
 
Any opinion from the WGs.
 
Thanks
Roni Even
CLUE co-chair 
_______________________________________________
clue mailing = list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

= --Apple-Mail=_0D409D44-8D24-49C3-9FB5-242C38D47AC1-- From nobody Tue Mar 22 15:48:20 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 C3D0312D6E0 for ; Tue, 22 Mar 2016 15:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 m1mDII38Swb0 for ; Tue, 22 Mar 2016 15:48:18 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7630212D105 for ; Tue, 22 Mar 2016 15:48:18 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by comcast with SMTP id iV5WakDauMjYpiV61aI3M0; Tue, 22 Mar 2016 22:48:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458686897; bh=mIV4kvu6m4nlExV89Enn7aezd4Qmneq6ETd5/ge30jA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=A9zS66YTQ9TLgvAzTQjbIa4nlLUT+1LqJcQojznlQtpUKHcOsJE/VCVmpNs1/MqL8 BnSRAjzl2Fx+vYyTbokX7JIihsZvr/wzribypT0O3AUj9CXpwGt09FDDiyZr4BcvMC UAkVDtxY+pouO5X1e71df043V7fqtUwFJqbOyTe+XreSM5G9Z7Y7iFbRJ1m6J6TAeZ oey9+geD6cVmKQtVevy91GrXA5DK0ryGYlIhsKGYwdZhgNy7AbD7+uALywJvuYCPnX wkukSW8pKPktVbA2hBEXF3mbOCP7ua42iy9+D00gxh5wYDE8x+HNGt4DIL1pPjiv7i ZVFF3zsk8q8Iw== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with comcast id ZAoH1s0013KdFy101AoHE6; Tue, 22 Mar 2016 22:48:17 +0000 To: clue@ietf.org References: <1f6e01d1843d$b3ff4ea0$1bfdebe0$@gmail.com> <4CFBCCBF-CF6F-495A-83A3-95D55AD4271E@cooperw.in> From: Paul Kyzivat Message-ID: <56F1CBAF.9040109@alum.mit.edu> Date: Tue, 22 Mar 2016 18:48:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <4CFBCCBF-CF6F-495A-83A3-95D55AD4271E@cooperw.in> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [clue] CLUE session in BA 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, 22 Mar 2016 22:48:19 -0000 Alissa, On 3/22/16 6:41 PM, Alissa Cooper wrote: > The protocol document still does not have a security considerations > section, or any discussion really of the threat model against this > protocol and how known threats are thwarted. This is a significant > omission and as I’ve mentioned to the shepherd it is not even worth > requesting publication of the document until the security properties of > the protocol are properly described in the document. You're ahead of me. I haven't had time to review the new version yet. > I would suggest that folks use the 1 hour allotted to make progress in > this area, whether by discussing it in the WG slot, or having a > selection of folks go work together on it (and cancelling the WG > session), or even by updating the draft to address this before the > meeting (I’ll use my AD override to waive the deadline) and having a > discussion of the added text. I won't be there. But anything that gets the document done is good!!! Thanks, Paul > Thanks, > Alissa > >> On Mar 22, 2016, at 6:21 AM, Roni Even > > wrote: >> >> Hi, >> The WG chairs feel that we do not really need to have a session in >> Buenos Aires. >> It looks like all documents are after WGLC and need to finish the open >> issues discussed on the list. >> This will also support our intention to finish the work and close the WG. >> Any opinion from the WGs. >> Thanks >> Roni Even >> CLUE co-chair >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Mar 22 16:19:16 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 1818012D0DE for ; Tue, 22 Mar 2016 16:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 m9PM_GYHLj1E for ; Tue, 22 Mar 2016 16:19:12 -0700 (PDT) Received: from brc1.unina.it (brc1.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765E112D096 for ; Tue, 22 Mar 2016 16:19:12 -0700 (PDT) X-ASG-Debug-ID: 1458688749-05ce37326b2de8a30001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id G0rfeMwSwKHaAsDN (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2016 00:19:09 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from android-1ca95d607d90d7ed.fritz.box ([151.70.39.99]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id u2MNJ8IW023461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2016 00:19:09 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <56F1CBAF.9040109@alum.mit.edu> References: <1f6e01d1843d$b3ff4ea0$1bfdebe0$@gmail.com> <4CFBCCBF-CF6F-495A-83A3-95D55AD4271E@cooperw.in> <56F1CBAF.9040109@alum.mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----BDH3U24AWMTW4MOS11T2SMUP3N2OTR" Content-Transfer-Encoding: 8bit From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] CLUE session in BA Date: Wed, 23 Mar 2016 00:19:22 +0100 To: Paul Kyzivat , clue@ietf.org Message-ID: X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1458688749 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 151.70.39.99 as permitted sender) X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, BSF_SPF_SOFTFAIL, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.28069 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: Subject: Re: [clue] CLUE session in BA 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, 22 Mar 2016 23:19:15 -0000 ------BDH3U24AWMTW4MOS11T2SMUP3N2OTR Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 This version of the draft was not meant to fill the security section gap. It was aimed at addressing the comments we got after the last review round. The next version of the draft will contain security considerations. It won't be ready by the proposed extended deadline, though. I am not attending IETF95 in person, by the way. My proposal for those willing to contribute with comments and suggestions is to leverage ML discussions. Cheers, Simon Il 22 Marzo 2016 23:48:15 CET, Paul Kyzivat ha scritto: >Alissa, > >On 3/22/16 6:41 PM, Alissa Cooper wrote: >> The protocol document still does not have a security considerations >> section, or any discussion really of the threat model against this >> protocol and how known threats are thwarted. This is a significant >> omission and as I’ve mentioned to the shepherd it is not even worth >> requesting publication of the document until the security properties >of >> the protocol are properly described in the document. > >You're ahead of me. I haven't had time to review the new version yet. > >> I would suggest that folks use the 1 hour allotted to make progress >in >> this area, whether by discussing it in the WG slot, or having a >> selection of folks go work together on it (and cancelling the WG >> session), or even by updating the draft to address this before the >> meeting (I’ll use my AD override to waive the deadline) and having a >> discussion of the added text. > >I won't be there. But anything that gets the document done is good!!! > > Thanks, > Paul > >> Thanks, >> Alissa >> >>> On Mar 22, 2016, at 6:21 AM, Roni Even >> > wrote: >>> >>> Hi, >>> The WG chairs feel that we do not really need to have a session in >>> Buenos Aires. >>> It looks like all documents are after WGLC and need to finish the >open >>> issues discussed on the list. >>> This will also support our intention to finish the work and close >the WG. >>> Any opinion from the WGs. >>> Thanks >>> Roni Even >>> CLUE co-chair >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue ------BDH3U24AWMTW4MOS11T2SMUP3N2OTR Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit This version of the draft was not meant to fill the security section gap. It was aimed at addressing the comments we got after the last review round. The next version of the draft will contain security considerations. It won't be ready by the proposed extended deadline, though. I am not attending IETF95 in person, by the way. My proposal for those willing to contribute with comments and suggestions is to leverage ML discussions.

Cheers,

Simon

Il 22 Marzo 2016 23:48:15 CET, Paul Kyzivat <pkyzivat@alum.mit.edu> ha scritto:
Alissa,

On 3/22/16 6:41 PM, Alissa Cooper wrote:
 The protocol document still does not have a security considerations
 section, or any discussion really of the threat model against this
 protocol and how known threats are thwarted. This is a significant
 omission and as I’ve mentioned to the shepherd it is not even worth
 requesting publication of the document until the security properties of
 the protocol are properly described in the document.

You're ahead of me. I haven't had time to review the new version yet.

 I would suggest that folks use the 1 hour allotted to make progress in
 this area, whether by discussing it in the WG slot, or hav
 ing
a
 selection of folks go work together on it (and cancelling the WG
 session), or even by updating the draft to address this before the
 meeting (I’ll use my AD override to waive the deadline) and having a
 discussion of the added text.

I won't be there. But anything that gets the document done is good!!!

	Thanks,
	Paul

 Thanks,
 Alissa

 On Mar 22, 2016, at 6:21 AM, Roni Even <ron.even.tlv@gmail.com
 <mailto:ron.even.tlv@gmail.com>> wrote:

 Hi,
 The WG chairs feel that we do not really need to have a session in
 Buenos Aires.
 It looks like all documents are after WGLC and need to finish the open
 issues discu
 ssed on
the list.
 This will also support our intention to finish the work and close the WG.
 Any opinion from the WGs.
 Thanks
 Roni Even
 CLUE co-chair

 clue mailing list
 clue@ietf.org <mailto:clue@ietf.org>
 https://www.ietf.org/mailman/listinfo/clue




 clue mailing list
 clue@ietf.org
 https://www.ietf.org/mailman/listinfo/clue



clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

------BDH3U24AWMTW4MOS11T2SMUP3N2OTR-- From nobody Wed Mar 23 09:28:17 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 E20AF12D748 for ; Wed, 23 Mar 2016 09:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=NsUP7PSn; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=C9vew8bY 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 jlkYPeikR0G0 for ; Wed, 23 Mar 2016 09:28:13 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2065412D746 for ; Wed, 23 Mar 2016 09:28:13 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 1C7B620958 for ; Wed, 23 Mar 2016 12:28:10 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 23 Mar 2016 12:28:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=NYTmN EJUYWCOKfSbMLFjaMOrGmY=; b=NsUP7PSn+koi5VS9Eef3hzas4mYZ1OR9xh2SX vsKhGI8NUw9TXj8ejhJi1vqJh5KKlTXQnnwmgdrSoLuhIU4E/5xgLtlC4j8FgWeb NH258Odo/+ZWwVcdjsDm7iik/xvUQhG9ZeCo3RYzFsPAcYu3/9H1l+2qj8divpZh UDnsiM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=NYTmNEJUYWCOKfSbMLFjaMOrGmY=; b=C9vew 8bYnoOkt8U5x0yI103Yz0OWy9E6M4TqCO6SLublqzV4p4RcDZeXW91CW718GEfYB EeZCp2oZcmArcEKAS1zZmBXxeP5ETyTsM38XrY0GHBLyn0Mn2+xrjoxq8GZXSLoi nFgId22DvQ7aiv8xLe3B4HBzFc944fXSE53lGw= X-Sasl-enc: WhmxLnBRnUZxgMGvcamvz2881hGIwbDhJTyE7F+x0FOu 1458750489 Received: from dhcp-171-68-122-59.cisco.com (dhcp-171-68-122-59.cisco.com [171.68.122.59]) by mail.messagingengine.com (Postfix) with ESMTPA id 7D5FA6800E1; Wed, 23 Mar 2016 12:28:09 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F9F317BE-C6F9-4A69-B185-DC1F19DD1B28" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: Date: Wed, 23 Mar 2016 09:28:29 -0700 Message-Id: <8547D6F9-3222-4BE6-B2FF-4662C505C2A4@cooperw.in> References: <1f6e01d1843d$b3ff4ea0$1bfdebe0$@gmail.com> <4CFBCCBF-CF6F-495A-83A3-95D55AD4271E@cooperw.in> <56F1CBAF.9040109@alum.mit.edu> To: Simon Pietro Romano X-Mailer: Apple Mail (2.3112) Archived-At: Cc: clue@ietf.org Subject: Re: [clue] CLUE session in BA 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: Wed, 23 Mar 2016 16:28:17 -0000 --Apple-Mail=_F9F317BE-C6F9-4A69-B185-DC1F19DD1B28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ok. I was mainly reacting to the comment that all documents are after = WGLC, the implication being they are nearing readiness for publication = requests. After the security analysis of the protocol is done, the WG = will need to review it before requesting publication. Ideally a document = would not even go out for WGLC until the security considerations were = documented. Alissa > On Mar 22, 2016, at 4:19 PM, Simon Pietro Romano = wrote: >=20 > This version of the draft was not meant to fill the security section = gap. It was aimed at addressing the comments we got after the last = review round. The next version of the draft will contain security = considerations. It won't be ready by the proposed extended deadline, = though. I am not attending IETF95 in person, by the way. My proposal for = those willing to contribute with comments and suggestions is to leverage = ML discussions. >=20 > Cheers, >=20 > Simon >=20 > Il 22 Marzo 2016 23:48:15 CET, Paul Kyzivat ha = scritto: > Alissa, >=20 > On 3/22/16 6:41 PM, Alissa Cooper wrote: > The protocol document still does not have a security considerations > section, or any discussion really of the threat model against this > protocol and how known threats are thwarted. This is a significant > omission and as I=E2=80=99ve mentioned to the shepherd it is not even = worth > requesting publication of the document until the security properties = of > the protocol are properly described in the document. >=20 > You're ahead of me. I haven't had time to review the new version yet. >=20 > I would suggest that folks use the 1 hour allotted to make progress = in > this area, whether by discussing it in the WG slot, or hav > ing > a > selection of folks go work together on it (and cancelling the WG > session), or even by updating the draft to address this before the > meeting (I=E2=80=99ll use my AD override to waive the deadline) and = having a > discussion of the added text. >=20 > I won't be there. But anything that gets the document done is good!!! >=20 > Thanks, > Paul >=20 > Thanks, > Alissa >=20 > On Mar 22, 2016, at 6:21 AM, Roni Even > wrote: >=20 > Hi, > The WG chairs feel that we do not really need to have a session in > Buenos Aires. > It looks like all documents are after WGLC and need to finish the = open > issues discu > ssed on > the list. > This will also support our intention to finish the work and close the = WG. > Any opinion from the WGs. > Thanks > Roni Even > CLUE co-chair >=20 > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue = >=20 >=20 >=20 >=20 > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue = >=20 >=20 > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue = >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --Apple-Mail=_F9F317BE-C6F9-4A69-B185-DC1F19DD1B28 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Ok. I was mainly reacting to the comment that = all documents are after WGLC, the implication being they are nearing = readiness for publication requests. After the security analysis of the = protocol is done, the WG will need to review it before requesting = publication. Ideally a document would not even go out for WGLC until the = security considerations were documented.

Alissa

On = Mar 22, 2016, at 4:19 PM, Simon Pietro Romano <spromano@unina.it> = wrote:

This version of the draft was not meant to fill the security = section gap. It was aimed at addressing the comments we got after the = last review round. The next version of the draft will contain security = considerations. It won't be ready by the proposed extended deadline, = though. I am not attending IETF95 in person, by the way. My proposal for = those willing to contribute with comments and suggestions is to leverage = ML discussions.

Cheers,

Simon

Il 22 = Marzo 2016 23:48:15 CET, Paul Kyzivat <pkyzivat@alum.mit.edu> ha scritto:
Alissa,

On 3/22/16 =
6:41 PM, Alissa Cooper wrote:
 The protocol document still does =
not have a security considerations
 section, or any =
discussion really of the threat model against this
 =
protocol and how known threats are thwarted. This is a significant
 omission and as I=E2=80=99ve mentioned to the shepherd it is =
not even worth
 requesting publication of the document =
until the security properties of
 the protocol are =
properly described in the document.

You're ahead of me. I haven't had time to review the new =
version yet.

 I would suggest that folks use =
the 1 hour allotted to make progress in
 this area, =
whether by discussing it in the WG slot, or hav
 ing
a
 selection of folks go work together on it (and =
cancelling the WG
 session), or even by updating the draft =
to address this before the
 meeting (I=E2=80=99ll use my =
AD override to waive the deadline) and having a
 =
discussion of the added text.

I =
won't be there. But anything that gets the document done is good!!!

	Thanks,
	Paul

 Thanks,
 Alissa

 On Mar =
22, 2016, at 6:21 AM, Roni Even <ron.even.tlv@gmail.com
 <mailto:ron.even.tlv@gmail.com>> wrote:

 Hi,
 The WG chairs feel that we =
do not really need to have a session in
 Buenos Aires.
 It looks like all documents are after WGLC and need to =
finish the open
 issues discu
 ssed on
the list.
 This will also support our intention to finish =
the work and close the WG.
 Any opinion from the WGs.
 Thanks
 Roni Even
 CLUE =
co-chair

 clue mailing =
list
 clue@ietf.org <mailto:clue@ietf.org>
 https://www.ietf.org/mailman/listinfo/clue




 clue mailing list
 clue@ietf.org
 =
https://www.ietf.org/mailman/listinfo/clue



clue mailing =
list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

______________________________________= _________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

= --Apple-Mail=_F9F317BE-C6F9-4A69-B185-DC1F19DD1B28-- From nobody Wed Mar 23 09:37:10 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 76E8312D739 for ; Wed, 23 Mar 2016 09:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 D-qwxFtOJrhM for ; Wed, 23 Mar 2016 09:37:06 -0700 (PDT) Received: from brc1.unina.it (brc1.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D75812D1DC for ; Wed, 23 Mar 2016 09:37:05 -0700 (PDT) X-ASG-Debug-ID: 1458751022-05ce3732642ea3f00001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id 8w7FsHB6ejlsr61g (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2016 17:37:02 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from node-4x1.pool-1-2.dynamic.totbb.net ([91.252.52.110]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id u2NGb0sC031912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2016 17:37:01 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <8547D6F9-3222-4BE6-B2FF-4662C505C2A4@cooperw.in> References: <1f6e01d1843d$b3ff4ea0$1bfdebe0$@gmail.com> <4CFBCCBF-CF6F-495A-83A3-95D55AD4271E@cooperw.in> <56F1CBAF.9040109@alum.mit.edu> <8547D6F9-3222-4BE6-B2FF-4662C505C2A4@cooperw.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----BWTN6Y39U8MNYF7QY7N1RT5I3I4R84" Content-Transfer-Encoding: 8bit From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] CLUE session in BA Date: Wed, 23 Mar 2016 17:37:14 +0100 To: Alissa Cooper Message-ID: <5FE3C2D1-FE4C-4C9A-B55A-AE014AEB9CF2@unina.it> X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1458751022 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 91.252.52.110 as permitted sender) X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, BSF_SPF_SOFTFAIL, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.28088 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: Cc: clue@ietf.org Subject: Re: [clue] CLUE session in BA 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: Wed, 23 Mar 2016 16:37:09 -0000 ------BWTN6Y39U8MNYF7QY7N1RT5I3I4R84 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Agreed! Simon Il 23 Marzo 2016 17:28:29 CET, Alissa Cooper ha scritto: >Ok. I was mainly reacting to the comment that all documents are after >WGLC, the implication being they are nearing readiness for publication >requests. After the security analysis of the protocol is done, the WG >will need to review it before requesting publication. Ideally a >document would not even go out for WGLC until the security >considerations were documented. > >Alissa > >> On Mar 22, 2016, at 4:19 PM, Simon Pietro Romano >wrote: >> >> This version of the draft was not meant to fill the security section >gap. It was aimed at addressing the comments we got after the last >review round. The next version of the draft will contain security >considerations. It won't be ready by the proposed extended deadline, >though. I am not attending IETF95 in person, by the way. My proposal >for those willing to contribute with comments and suggestions is to >leverage ML discussions. >> >> Cheers, >> >> Simon >> >> Il 22 Marzo 2016 23:48:15 CET, Paul Kyzivat >ha scritto: >> Alissa, >> >> On 3/22/16 6:41 PM, Alissa Cooper wrote: >> The protocol document still does not have a security considerations >> section, or any discussion really of the threat model against this >> protocol and how known threats are thwarted. This is a significant >> omission and as I’ve mentioned to the shepherd it is not even worth >> requesting publication of the document until the security properties >of >> the protocol are properly described in the document. >> >> You're ahead of me. I haven't had time to review the new version yet. >> >> I would suggest that folks use the 1 hour allotted to make progress >in >> this area, whether by discussing it in the WG slot, or hav >> ing >> a >> selection of folks go work together on it (and cancelling the WG >> session), or even by updating the draft to address this before the >> meeting (I’ll use my AD override to waive the deadline) and having a >> discussion of the added text. >> >> I won't be there. But anything that gets the document done is good!!! >> >> Thanks, >> Paul >> >> Thanks, >> Alissa >> >> On Mar 22, 2016, at 6:21 AM, Roni Even > > wrote: >> >> Hi, >> The WG chairs feel that we do not really need to have a session in >> Buenos Aires. >> It looks like all documents are after WGLC and need to finish the >open >> issues discu >> ssed on >> the list. >> This will also support our intention to finish the work and close >the WG. >> Any opinion from the WGs. >> Thanks >> Roni Even >> CLUE co-chair >> >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > >> >> >> >> >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > >> >> >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue ------BWTN6Y39U8MNYF7QY7N1RT5I3I4R84 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Agreed!

Simon

Il 23 Marzo 2016 17:28:29 CET, Alissa Cooper <alissa@cooperw.in> ha scritto:
Ok. I was mainly reacting to the comment that all documents are after WGLC, the implication being they are nearing readiness for publication requests. After the security analysis of the protocol is done, the WG will need to review it before requesting publication. Ideally a document would not even go out for WGLC until the security considerations were documented.

Alissa

On Mar 22, 2016, at 4:19 PM, Simon Pietro Romano <spromano@unina.it> wrote:

This version of the draft was not meant to fill the security section gap. It was aimed at addressing the comments we got after the last review round. The next version of the draft will contain security considerations. It won't be ready by the proposed extended deadline, though. I am not attending IETF95 in person, by the way. My proposal for those willing to contribute with comments and suggestions is to leverage ML discussions.

Cheers,

Simon

Il 22 Marzo 2016 23:48:15 CET, Paul Kyzivat <pkyzivat@alum.mit.edu> ha scritto:
Alissa,

On 3/22/16 6:41 PM, Alissa Cooper wrote:
 The protocol document still does not have a security considerations
 section, or any discussion really of the threat model against this
 protocol and how known threats are thwarted. This is a significant
 omission and as I’ve mentioned to the shepherd it is not even worth
 requesting publication of the document until the security properties of
 the protocol are properly described in the document.

You're ahead of me. I haven't had time to review the new version yet.

 I would suggest that folks use the 1 hour allotted 
 to make
progress in
 this area, whether by discussing it in the WG slot, or hav
 ing
a
 selection of folks go work together on it (and cancelling the WG
 session), or even by updating the draft to address this before the
 meeting (I’ll use my AD override to waive the deadline) and having a
 discussion of the added text.

I won't be there. But anything that gets the document done is good!!!

	Thanks,
	Paul

 Thanks,
 Alissa

 On Mar 22, 2016, at 6:21 AM, Roni Even <ron.even.tlv@gmail.com
 <mailto:ron.even.tlv@gmail.com>>
 
wrote:

 Hi,
 The WG chairs feel that we do not really need to have a session in
 Buenos Aires.
 It looks like all documents are after WGLC and need to finish the open
 issues discu
 ssed on
the list.
 This will also support our intention to finish the work and close the WG.
 Any opinion from the WGs.
 Thanks
 Roni Even
 CLUE co-chair

 clue mailing list
 clue@ietf.org <mailto:clue@ietf.org>
 https://www.ietf.org/mailman/listinfo/clue




 clue mailing list
 clue@ietf.org
 https://www.ietf.org/mailman/listinfo/clue



clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

------BWTN6Y39U8MNYF7QY7N1RT5I3I4R84-- From nobody Tue Mar 29 09:23:38 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 3C7C112D9E6 for ; Tue, 29 Mar 2016 09:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=Rn6j6RIk; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=tzDuRVkZ 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 vTm3pYeH3HVo for ; Tue, 29 Mar 2016 09:23:34 -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 D2D2112D9B1 for ; Tue, 29 Mar 2016 09:18:34 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 2E86A2249A for ; Tue, 29 Mar 2016 12:18:34 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 29 Mar 2016 12:18:34 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=sfKki RNXlnSdq+BMOUH0CD7triE=; b=Rn6j6RIklssIZbDkaje1IB7Xsfv98XMlqNjzf wchgiqg3YaQfjQPoKYDRV3GwXcyOy+ymOaEdYjo89hpm56rCfDQaY2gWDZ6SpAab 1Acl2/zeMbh8P02XKBPGFEB3BOGmDi1JWsPFA+2Ue3dgPcVsx2IKygLLQ9g5KrY/ Eulzr8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=sfKkiRNXlnSdq+BMOUH0CD7triE=; b=tzDuR VkZvdsXUcAJxUHjhKsqSRBUGrB1mzeYhXdJHB/uIbnkgR1UvVEMjljWmFB654tBL bQCkf/KsRVxzEmfp0u+WuzEimcRCfhi2z0trrfjF80E9bHzVdSrrJohIBCReJB1k j/A7fJYSydfbH2v4kyBpuUXRkmPkmWKxtPbT2Y= X-Sasl-enc: 2WdY4uLNfcvrLwsBTgOVmAIZHUQ7wEC4v35h4vIDokYf 1459268313 Received: from dhcp-171-68-20-59.cisco.com (dhcp-171-68-20-59.cisco.com [171.68.20.59]) by mail.messagingengine.com (Postfix) with ESMTPA id A53BEC00013; Tue, 29 Mar 2016 12:18:33 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_FEC873F7-AAF5-40A6-BBA2-F504B7CC02D8" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <1f6e01d1843d$b3ff4ea0$1bfdebe0$@gmail.com> Date: Tue, 29 Mar 2016 09:19:11 -0700 Message-Id: <76F31D98-2BCF-4C59-BC39-CF77BF701A5A@cooperw.in> References: <1f6e01d1843d$b3ff4ea0$1bfdebe0$@gmail.com> To: Roni Even X-Mailer: Apple Mail (2.3112) Archived-At: Cc: clue@ietf.org Subject: Re: [clue] CLUE session in BA 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, 29 Mar 2016 16:23:37 -0000 --Apple-Mail=_FEC873F7-AAF5-40A6-BBA2-F504B7CC02D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please inform the secretariat if you have decided to cancel the meeting. Thanks, Alissa > On Mar 22, 2016, at 6:21 AM, Roni Even wrote: >=20 > Hi, > The WG chairs feel that we do not really need to have a session in = Buenos Aires.=20 > It looks like all documents are after WGLC and need to finish the open = issues discussed on the list. > This will also support our intention to finish the work and close the = WG. > =20 > Any opinion from the WGs. > =20 > Thanks > Roni Even > CLUE co-chair=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue = --Apple-Mail=_FEC873F7-AAF5-40A6-BBA2-F504B7CC02D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Please inform the secretariat if you have = decided to cancel the meeting.

Thanks,
Alissa

On Mar 22, 2016, at 6:21 AM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi,
The WG chairs feel that we do not = really need to have a session in Buenos Aires. 
It looks = like all documents are after WGLC and need to finish the open issues = discussed on the list.
This will also support our intention to finish the work and = close the WG.
 
Any opinion from the WGs.
 
Thanks
Roni Even
CLUE co-chair 
_______________________________________________
clue mailing = list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

= --Apple-Mail=_FEC873F7-AAF5-40A6-BBA2-F504B7CC02D8--