From nobody Tue Dec 1 11:44:07 2015 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 77CE51B3056 for ; Tue, 1 Dec 2015 11:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 LuZ7w3DFbS68 for ; Tue, 1 Dec 2015 11:44:03 -0800 (PST) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id 060391B2F9D for ; Tue, 1 Dec 2015 11:44:02 -0800 (PST) X-AuditID: 12074412-f79a76d000007c8b-3f-565df881af53 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 75.2A.31883.188FD565; Tue, 1 Dec 2015 14:44:01 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id tB1JhxF2015978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Dec 2015 14:44:00 -0500 To: Simon Pietro Romano , Roberta Presta From: Paul Kyzivat Message-ID: <565DF87E.9050402@alum.mit.edu> Date: Tue, 1 Dec 2015 14:43:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixO6iqNv4IzbM4NZxMYv9py4zW7z6XGWx re0GswOzx5IlP5k8fmx5yhTAFMVtk5RYUhacmZ6nb5fAnXFxKVfBLu2K27NLGhgblLoYOTkk BEwkGt+dZYSwxSQu3FvP1sXIxSEkcJlRYvXR+cwgCSGBJ0wSfx/7gNgiAnESS2deZwexmQUk JG5fnMcEYrMJaEnMOfSfBcQWFgiT6Fu2HCzOK6AtcXxLA1g9i4CKxOVTU9lAbFGBNInD1z6w QtQISpyc+YQFYqaZxLzND5khbHmJ7W/nME9g5JuFpGwWkrJZSMoWMDKvYpRLzCnN1c1NzMwp Tk3WLU5OzMtLLdI108vNLNFLTSndxAgJP6EdjOtPyh1iFOBgVOLhlVgbEybEmlhWXJl7iFGS g0lJlFf9ZWyYEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeRc+BcrwpiZVVqUX5MClpDhYlcd6f i9X9hATSE0tSs1NTC1KLYLIyHBxKEryu34EaBYtS01Mr0jJzShDSTBycIMO5pESKU/NSUosS S0sy4kFRF18MjDuQFA/QXj2Qdt7igsRcoChE6ylGRSlx3m6QhABIIqM0D24sLKm8YhQH+lKY twGkigeYkOC6XwENZgIa/OFPNMjgkkSElFQDI5tOz9ZDPO0LQw63rq4x/iW52OXPDZHydvXG 9OvfatnkW6KaMu2Ff4eccN9pdeP8nBeyC55byEir+XNcmTPtjJHNZZHFm3hCOFuM7wbZ7Jkq MbdWucLvpMMhC0O2/qN8CXPWHTrue0Fr/znDiTpZtwT1ZRLc1MSYptXwiGjyvbrw3kvqU9tq JZbijERDLeai4kQAcuDRSQUDAAA= Archived-At: Cc: CLUE Subject: [clue] draft-ietf-clue-protocol-06: stuff found while preparing submission writeup 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 Dec 2015 19:44:05 -0000 I did another final review of the protool draft while doing my shepherd writeup. Unfortunately I found a number of things that ought to be cleared up before submitting to the iesg. I'm sorry about this - I ought to have caught these things sooner. * Section 4: Section 4 says sequence numbers are incremented for each message. Does something say what number the first message gets? I haven't seen anything. Does that mean that the first message can have any number? I don't think anything says whether version numbers are to be compared textually or numerically. In particular, are "1.2", "01.2", "1.02", and "01.02" all considered to match? And then: Each CP should manage up to three (independent) streams of sequence numbers: ... Why is "should" used here? It seems to me it is a logical necessity. So wouldn't "needs to" be more appropriate? * Section 4.1: ... Only one element MUST be provided for each major version supported, containing the maximum minor version number of such a version, since all minor versions are backward compatible. I don't know how to parse this. I *think* you mean "*Exactly* one ...". * Section 4.5: The optional boolean element, set to "true", if present, indicates that the CONF message also acknowledges the referred advertisement, by applying in that way a piggybacking mechanism for simultaneously acknowledging and replying to the ADV message. In the above case, the CONF message MUST carry a 200 (Success) response code. The element MUST not be present if an ACK message has been already sent back to the MP. The above says that if is present then 200 response code must also be present. But I see no place to put a response code in the CONF message. I think what is intended is that a CONF with *implies* a 200 response code for the ADV. * Section 4.7: What code should be used for problems that don't seem to fit any of the ones listed? For instance, what if a CONF contains but the advertisement had previously been acknowledged? (Would 301 apply to that?) In SIP, the n00 codes are catch-alls, while other nXX are more specific. Here the n00 values are specific. For the inappropriate I would expect 400 to work, but its definition doesn't work. Doing that allows the recipient of nXX that it doesn't understand to treat it as n00. That isn't really possible now. So ISTM that 300 & 400 ought to be redefined as "syntax errors or inconsistencies", and 400 as "semantic errors". And then new specific error codes assigned for "The XML syntax is not correct" and "Version not supported". * Section 5: s/both send a receive/both send and receive/ * Section 7: I don't think it is clear what is to be done when a higher minor version is supported by one end than the other. According to paragraph three the end at the higher version should be able to sent that unchanged, while the other end ignores the parts it doesn't understand. According to paragraph 4 it seems that the end with the higher version should censor itself down to the lower version. (Which means that it needs to keep track of what has to be omitted.) ISTM the document ought to state the required behavior. My thought is that it be REQUIRED to ignore unknown elements and attributes. That seems like the easier way to manage the version incompatibility. (Of course it would also be ok for the end with the higher version to censor itself, but that should be optional.) It seems that paragraph five was hopeful thinking and hasn't been realized. At this point it probably ought to be removed. * Section 8: I don't understand how the version element in an option is intended to work. If an option is defined for version M.m, does it also apply to other versions? I guess it ought to apply to later minor versions of the same major version. If I had an option that will work with more than one major version, how would I declare it? I can't list more than one version for it. So I guess I have to declare it as more than one option element. Can those be identical except for the version? Or do they require different names? In the OPTIONS RESPONSE, does the version need to be identical to what was in the request? * Section 11.3: Is see "File extension(s): .clue," declared. To do that, wouldn't we need to register the extension somewhere? Do we need this? wouldn't .xml be sufficient? * Section 11.4: Why are we registering new NAPTR tags? AFAIK we don't need or use them. * Section 11.5.1: How should the registry be formatted? Is it one column, or two? And what is their significance? I guess the part in parens is an optional abbreviation. But neither part is actually used in the protocol, only in the text of the document. The actual names used in the protocol are defined in the schema: "options", "optionsResponse", "advertisement", "ack", "configure", "configureResponse". I guess *those* names would be the ones that ought to be registered, if any. But do they need to be registered at all? They are defined in the schema. If more are defined, won't they be in another version of the *same* schema? * I previously noted that idnits returns a bunch of errors that need to be fixed. All are superficial. * Typos: s/seperate/separate/ (I've heard this is the most common spelling error in English.) Sorry about this, Paul From nobody Tue Dec 1 12:48:01 2015 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 9229D1B37BB for ; Tue, 1 Dec 2015 12:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.625 X-Spam-Level: X-Spam-Status: No, score=-0.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=0.6, SPF_SOFTFAIL=0.665, T_FILL_THIS_FORM_SHORT=0.01] 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 D22XJrGeHxxa for ; Tue, 1 Dec 2015 12:47:59 -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 59C0E1B37B9 for ; Tue, 1 Dec 2015 12:47:59 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-02v.sys.comcast.net with comcast id oLmz1r0072JGN3p01Lnyka; Tue, 01 Dec 2015 20:47:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-10v.sys.comcast.net with comcast id oLnx1r00a3KdFy101Lnywa; Tue, 01 Dec 2015 20:47:58 +0000 References: <56535BCD.5040803@alum.mit.edu> To: "Robert Hansen (rohanse2)" From: Paul Kyzivat Message-ID: <565E077D.1010907@alum.mit.edu> Date: Tue, 1 Dec 2015 15:47:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56535BCD.5040803@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=1449002878; bh=9akzyaviQKhvjhx1FQTbpEVcu0iZ1sky6Xf4xEVUJe0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=knxynsr4MVUjdsBa4qSCAEOUVttYWvQKu/TNImbI0rgmxjfy6iPLF8ncFQ0UJuVXu Mps8loJyK+Et5erC+VYrlSRQnqCFV47vlo5x3ok/NTaiTSCu3CEj1OnQ0GMsYYMDIw NzInG7vT/1sukVefBxZZbCAE+g+08HxgzpHymIT1tmmXnoPS6xdd3ZmQSGU/1A97Wq WzeCg+4Nm0JRkp1blagf/T1AGOLS0qtPhkCWsnYo8I6KzC24fpffiZzhg7C9vD2nR+ Ac1o+a1I4xI3mmt4YFJZgZeBeFNlY+lDgAZ7iqcM2ZNMncMIOSvM8HsXk1RheGMGEW A10+pMrzhtf0g== Archived-At: Cc: clue@ietf.org Subject: [clue] registration of "clue" grouping framework attribute in signaling draft 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 Dec 2015 20:48:00 -0000 Another issue with signaling. The formatting of the info for the registration of the new SDP grouping attribute is also messed up, to the point of being undecipherable. Thanks, Paul On 11/23/15 1:32 PM, Paul Kyzivat wrote: > I was doing a final review of the signaling draft. I notice that the > registration of sip.clue in the IANA considerations section is a bit > sloppy. This will be subjected to expert review, so it should be brought > up to standard so that the expert is happy. > > Since I happen to be the expert, I can suggest what would make me happy. > :-) > > This specification registers a new media feature tag in the SIP > [RFC3264] tree per the procedures defined in [RFC2506] and [RFC3840]. > > Media feature tag name: sip.clue > > Summary of the media feature indicated by this tag: This feature tag > indicates that the device supports CLUE controlled media. > > Values appropriate for use with this feature tag: Boolean. > > The feature tag is intended primarily for use in the following > applications, protocols, services, or negotiation mechanisms: > > This feature tag is most useful in a communications application for > describing the capabilities of a device which uses multiple media > streams. > > Related standards or documents: RFC XXXX [this document] > > Security Considerations: Security considerations for this media > feature tag are discussed in Section 12 of RFC XXXX. > > Name(s) & email address(es) of person(s) to contact for > further information: > > - CLUE workgroup: clue@ietf.org > - CLUE chairmen: clue-chairs@ietf.org > > Intended usage: COMMON > > (I suspect that the formatting is already better in the xml, but lost by > xml2rfc.) > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Dec 1 14:49:32 2015 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 780CF1AD34C for ; Tue, 1 Dec 2015 14:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Gu2_2FEpYegU for ; Tue, 1 Dec 2015 14:49:25 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.109]) (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 53D321AD2D5 for ; Tue, 1 Dec 2015 14:49:25 -0800 (PST) Received: from [216.82.254.20] by server-13.bemta-7.messagelabs.com id AC/FD-23405-4F32E565; Tue, 01 Dec 2015 22:49:24 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-5.tower-47.messagelabs.com!1449010163!7230603!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6569 invoked from network); 1 Dec 2015 22:49:24 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-5.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 1 Dec 2015 22:49:24 -0000 Received: from SACWPHUBCAS03V.polycom.com (10.236.3.207) by Crpehubprd01.polycom.com (10.236.0.158) with Microsoft SMTP Server (TLS) id 8.3.389.2; Tue, 1 Dec 2015 14:49:23 -0800 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.113]) by SACWPHUBCAS03V.polycom.com ([fe80::4d59:a373:bb38:b976%12]) with mapi; Tue, 1 Dec 2015 14:49:23 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , Simon Pietro Romano , Roberta Presta Date: Tue, 1 Dec 2015 14:49:21 -0800 Thread-Topic: [clue] draft-ietf-clue-protocol-06: stuff found while preparing submission writeup Thread-Index: AdEscKxBefrmMRt+R9CSHOa4sEKETAAF5K0w Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52FC172A04EC9@CRPMBOXPRD08.polycom.com> References: <565DF87E.9050402@alum.mit.edu> In-Reply-To: <565DF87E.9050402@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5C4AC54BFF7A0842A6A11F554D6FB52FC172A04EC9CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: Cc: CLUE Subject: Re: [clue] draft-ietf-clue-protocol-06: stuff found while preparing submission writeup 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 Dec 2015 22:49:30 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52FC172A04EC9CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, My previous comments also mentioned similar things about sequence numbers a= nd . Simon responded in email on Oct 19. I agree about section 4.5, the in this case should imply 200 success. About comparing version numbers, the text says both major and minor version= numbers are unsigned integers. My interpretation is these are compared num= erically, so yes all your examples below match. Probably the document shoul= d be more clear about this. And also "1.2" is not the same as "1.20". Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, December 01, 2015 2:44 PM > To: Simon Pietro Romano; Roberta Presta > Cc: CLUE > Subject: [clue] draft-ietf-clue-protocol-06: stuff found while preparing > submission writeup > > I did another final review of the protool draft while doing my shepherd > writeup. Unfortunately I found a number of things that ought to be > cleared up before submitting to the iesg. I'm sorry about this - I ought > to have caught these things sooner. > > * Section 4: > > Section 4 says sequence numbers are incremented for each message. Does > something say what number the first message gets? I haven't seen > anything. Does that mean that the first message can have any number? > > I don't think anything says whether version numbers are to be compared > textually or numerically. In particular, are "1.2", "01.2", "1.02", and > "01.02" all considered to match? > > And then: > > Each CP should manage up to three (independent) streams of sequence > numbers: ... > > Why is "should" used here? It seems to me it is a logical necessity. So > wouldn't "needs to" be more appropriate? > > * Section 4.1: > > ... Only one element MUST > be provided for each major version supported, containing the maximum > minor version number of such a version, since all minor versions are > backward compatible. > > I don't know how to parse this. I *think* you mean "*Exactly* one ...". > > * Section 4.5: > > The optional boolean element, set to "true", if present, > indicates that the CONF message also acknowledges the referred > advertisement, by applying in that way a piggybacking mechanism for > simultaneously acknowledging and replying to the ADV message. In the > above case, the CONF message MUST carry a 200 (Success) response > code. The element MUST not be present if an ACK message has > been already sent back to the MP. > > The above says that if is present then 200 response code must also > be present. But I see no place to put a response code in the CONF message= . > > I think what is intended is that a CONF with *implies* a 200 > response code for the ADV. > > * Section 4.7: > > What code should be used for problems that don't seem to fit any of the > ones listed? For instance, what if a CONF contains but the > advertisement had previously been acknowledged? (Would 301 apply to > that?) > > In SIP, the n00 codes are catch-alls, while other nXX are more specific. > Here the n00 values are specific. For the inappropriate I would > expect 400 to work, but its definition doesn't work. > > Doing that allows the recipient of nXX that it doesn't understand to > treat it as n00. That isn't really possible now. So ISTM that 300 & 400 > ought to be redefined as "syntax errors or inconsistencies", and 400 as > "semantic errors". And then new specific error codes assigned for "The > XML syntax is not correct" and "Version not supported". > > * Section 5: > > s/both send a receive/both send and receive/ > > * Section 7: > > I don't think it is clear what is to be done when a higher minor version > is supported by one end than the other. According to paragraph three the > end at the higher version should be able to sent that unchanged, while > the other end ignores the parts it doesn't understand. According to > paragraph 4 it seems that the end with the higher version should censor > itself down to the lower version. (Which means that it needs to keep > track of what has to be omitted.) > > ISTM the document ought to state the required behavior. My thought is > that it be REQUIRED to ignore unknown elements and attributes. That > seems like the easier way to manage the version incompatibility. (Of > course it would also be ok for the end with the higher version to censor > itself, but that should be optional.) > > It seems that paragraph five was hopeful thinking and hasn't been > realized. At this point it probably ought to be removed. > > * Section 8: > > I don't understand how the version element in an option is intended to > work. If an option is defined for version M.m, does it also apply to > other versions? I guess it ought to apply to later minor versions of the > same major version. > > If I had an option that will work with more than one major version, how > would I declare it? I can't list more than one version for it. So I > guess I have to declare it as more than one option element. Can those be > identical except for the version? Or do they require different names? > > In the OPTIONS RESPONSE, does the version need to be identical to what > was in the request? > > * Section 11.3: > > Is see "File extension(s): .clue," declared. To do that, wouldn't we > need to register the extension somewhere? Do we need this? wouldn't .xml > be sufficient? > > * Section 11.4: > > Why are we registering new NAPTR tags? AFAIK we don't need or use them. > > * Section 11.5.1: > > How should the registry be formatted? Is it one column, or two? And what > is their significance? > > I guess the part in parens is an optional abbreviation. But neither part > is actually used in the protocol, only in the text of the document. The > actual names used in the protocol are defined in the schema: "options", > "optionsResponse", "advertisement", "ack", "configure", > "configureResponse". > > I guess *those* names would be the ones that ought to be registered, if > any. But do they need to be registered at all? They are defined in the > schema. If more are defined, won't they be in another version of the > *same* schema? > > * I previously noted that idnits returns a bunch of errors that need to > be fixed. All are superficial. > > * Typos: > > s/seperate/separate/ > (I've heard this is the most common spelling error in English.) > > Sorry about this, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --_000_5C4AC54BFF7A0842A6A11F554D6FB52FC172A04EC9CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul,=

 

My previous comments also mentioned similar things about sequence numbe= rs and <ack>.  Simon responded in email on Oct 19.

 

I agree about section 4.5, the <ack> in this case should imply= 200 success.

 

About comparing version numbers, the text says both m= ajor and minor version numbers are unsigned integers. My interpretation is = these are compared numerically, so yes all your examples below match. Proba= bly the document should be more clear about this. And also “1.2”= ; is not the same as “1.20”.

 

Mark

 

> -----Ori= ginal Message-----

> From: clue [mailto:clue-= bounces@ietf.org] On Behalf Of Paul Kyzivat

>= Sent: Tuesday, December 01, 2015 2:44 PM

> T= o: Simon Pietro Romano; Roberta Presta

> Cc: = CLUE

> Subject: [clue] draft-ietf-clue-protoc= ol-06: stuff found while preparing

> submissi= on writeup

>

>= I did another final review of the protool draft while doing my shepherd

> writeup. Unfortunately I found a number of th= ings that ought to be

> cleared up before sub= mitting to the iesg. I'm sorry about this - I ought

> to have caught these things sooner.

>= ;

> * Section 4:

= >

> Section 4 says sequence numbers are i= ncremented for each message. Does

> something= say what number the first message gets? I haven't seen

> anything. Does that mean that the first message can have any n= umber?

>

> I d= on't think anything says whether version numbers are to be compared

> textually or numerically. In particular, are "= ;1.2", "01.2", "1.02", and

> "01.02" all considered to match?

>

> And then:

>

>     Each CP s= hould manage up to three (independent) streams of sequence

>     numbers: ...

>

> Why is "should" used h= ere? It seems to me it is a logical necessity. So

> wouldn't "needs to" be more appropriate?

>

> * Section 4.1:

>

>    &nb= sp;... Only one <version> element MUST

>= ;     be provided for each major version supported, con= taining the maximum

>     = ;minor version number of such a version, since all minor versions are

>     backward compatible.

=

>

> I don't know = how to parse this. I *think* you mean "*Exactly* one ...".

>

> * Section 4.5:

>

>   = ;  The optional boolean <ack> element, set to "true&qu= ot;, if present,

>     in= dicates that the CONF message also acknowledges the referred

>     advertisement, by applying in tha= t way a piggybacking mechanism for

>  &n= bsp;  simultaneously acknowledging and replying to the ADV messag= e.  In the

>     abo= ve case, the CONF message MUST carry a 200 (Success) response

>     code.  The <ack> el= ement MUST not be present if an ACK message has

= >     been already sent back to the MP.

>

> The above says that i= f <ack> is present then 200 response code must also

> be present. But I see no place to put a response code in the= CONF message.

>

= > I think what is intended is that a CONF with <ack> *implies* a 2= 00

> response code for the ADV.

>

> * Section 4.7:

>

> What code should= be used for problems that don't seem to fit any of the

> ones listed? For instance, what if a CONF contains <ack>= but the

> advertisement had previously been = acknowledged? (Would 301 apply to

> that?)

>

> In SIP, the = n00 codes are catch-alls, while other nXX are more specific.

> Here the n00 values are specific. For the inappropriate &= lt;ack> I would

> expect 400 to work, but = its definition doesn't work.

>

> Doing that allows the recipient of nXX that it doesn't= understand to

> treat it as n00. That isn't = really possible now. So ISTM that 300 & 400

= > ought to be redefined as "syntax errors or inconsistencies",= and 400 as

> "semantic errors". An= d then new specific error codes assigned for "The

> XML syntax is not correct" and "Version not supported= ".

>

> * = Section 5:

>

>= s/both send a receive/both send and receive/

&g= t;

> * Section 7:

>

> I don't think it is clear what is to= be done when a higher minor version

> is sup= ported by one end than the other. According to paragraph three the

> end at the higher version should be able to sent th= at unchanged, while

> the other end ignores t= he parts it doesn't understand. According to

>= ; paragraph 4 it seems that the end with the higher version should censor

> itself down to the lower version. (Which mea= ns that it needs to keep

> track of what has = to be omitted.)

>

> ISTM the document ought to state the required behavior. My thought is=

> that it be REQUIRED to ignore unknown elem= ents and attributes. That

> seems like the ea= sier way to manage the version incompatibility. (Of

> course it would also be ok for the end with the higher version to = censor

> itself, but that should be optional.= )

>

> It seems= that paragraph five was hopeful thinking and hasn't been

> realized. At this point it probably ought to be removed.

=

>

> * Section 8:<= /p>

>

> I don't un= derstand how the version element in an option is intended to

> work. If an option is defined for version M.m, does it al= so apply to

> other versions? I guess it ough= t to apply to later minor versions of the

> s= ame major version.

>

> If I had an option that will work with more than one major version= , how

> would I declare it? I can't list more= than one version for it. So I

> guess I have= to declare it as more than one option element. Can those be

> identical except for the version? Or do they require diff= erent names?

>

&g= t; In the OPTIONS RESPONSE, does the version need to be identical to what

> was in the request?

>

> * Section 11.3:

>

> Is see "File extension(= s): .clue," declared. To do that, wouldn't we

> need to register the extension somewhere? Do we need this? wouldn't= .xml

> be sufficient?

>

> * Section 11.4:

>

> Why are we registering new= NAPTR tags? AFAIK we don't need or use them.

&g= t;

> * Section 11.5.1:

>

> How should the registry be form= atted? Is it one column, or two? And what

> i= s their significance?

>

> I guess the part in parens is an optional abbreviation. But nei= ther part

> is actually used in the protocol,= only in the text of the document. The

> actu= al names used in the protocol are defined in the schema: "options"= ;,

> "optionsResponse", "adver= tisement", "ack", "configure",

> "configureResponse".

>=

> I guess *those* names would be the ones t= hat ought to be registered, if

> any. But do = they need to be registered at all? They are defined in the

> schema. If more are defined, won't they be in another versi= on of the

> *same* schema?

>

> * I previously noted that id= nits returns a bunch of errors that need to

>= be fixed. All are superficial.

>

> * Typos:

>

> s/seperate/separate/

> (= I've heard this is the most common spelling error in English.)

>

>    &nb= sp;        Sorry about this,

>          =    Paul

>

> _______________________________________________

> clue mailing list

> = clue@ietf.org

> https://www.ietf.org/mailman/listinfo/clue

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52FC172A04EC9CRPMBOXPRD08p_-- From nobody Tue Dec 1 17:55:24 2015 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 7FE951B30D8 for ; Tue, 1 Dec 2015 17:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 1rXbqXGVJKJd for ; Tue, 1 Dec 2015 17:55:22 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91AB1B30AB for ; Tue, 1 Dec 2015 17:55:21 -0800 (PST) Received: from ppp118-209-236-134.lns20.mel8.internode.on.net ([118.209.236.134]:62082 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1a3wdY-004CdK-Ec for clue@ietf.org; Wed, 02 Dec 2015 12:55:16 +1100 To: clue@ietf.org References: <565DF87E.9050402@alum.mit.edu> From: Christian Groves Message-ID: <565E4F83.1090506@nteczone.com> Date: Wed, 2 Dec 2015 12:55:15 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565DF87E.9050402@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 - cserver5.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: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: cserver5.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] draft-ietf-clue-protocol-06: stuff found while preparing submission writeup 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 Dec 2015 01:55:23 -0000 Hello Paul, all, I agree with many of the comments. A couple of responses: ..snip.. > > > * Section 7: > > I don't think it is clear what is to be done when a higher minor > version is supported by one end than the other. According to paragraph > three the end at the higher version should be able to sent that > unchanged, while the other end ignores the parts it doesn't > understand. According to paragraph 4 it seems that the end with the > higher version should censor itself down to the lower version. (Which > means that it needs to keep track of what has to be omitted.) > > ISTM the document ought to state the required behavior. My thought is > that it be REQUIRED to ignore unknown elements and attributes. That > seems like the easier way to manage the version incompatibility. (Of > course it would also be ok for the end with the higher version to > censor itself, but that should be optional.) [CNG] I pretty sure the intention is that by using the OPTIONs the endpoints agree on a single version. Cl.3 in the overview indicates that the participants agree on a protocol version. To me that implies both endpoints use that version. > > It seems that paragraph five was hopeful thinking and hasn't been > realized. At this point it probably ought to be removed. [CNG] I agree. > > * Section 8: > > I don't understand how the version element in an option is intended to > work. If an option is defined for version M.m, does it also apply to > other versions? I guess it ought to apply to later minor versions of > the same major version. [CNG] Good questions. I assume that for major version changes which could be non-backward compatible that it can't be assumed that the extension will also work for the major version change. I agree on the minor versions. > > If I had an option that will work with more than one major version, > how would I declare it? I can't list more than one version for it. So > I guess I have to declare it as more than one option element. Can > those be identical except for the version? Or do they require > different names? > > In the OPTIONS RESPONSE, does the version need to be identical to what > was in the request? > > Regards, Christian From nobody Wed Dec 2 02:23:11 2015 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 1B7AC1A86FF for ; Wed, 2 Dec 2015 02:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.901 X-Spam-Level: X-Spam-Status: No, score=-13.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 NjBOOlYAkBzN for ; Wed, 2 Dec 2015 02:23:08 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5488B1A8700 for ; Wed, 2 Dec 2015 02:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2414; q=dns/txt; s=iport; t=1449051788; x=1450261388; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=nGwwkmlh3rKuKj9zuG2XIJqC49F4WoCLnsuIHWbP0h4=; b=kPOWpX4Mg1sfigL2jF9cAOCDwrCTk4jmmeu4c/QiUAB14T4NlwjSfybj owm6lwLQoLq6hGEYCuk3sOc6IfmDZYugDOYxE8b2ZpuQo3D5Z7taOrBtc 7vgWHU3uIKYB7X3a1fqIZjq0kqQob7+WknSG3J7rHS088kFOXDIQafqC0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAwDmxV5W/xbLJq1eDoN/b6p4AQEBA?= =?us-ascii?q?QEBBQGBDpF2AQ2BbhcKhW0CggcUAQEBAQEBAYEKhDUBAQQBAQE1MwMKARALDgo?= =?us-ascii?q?JFg8JAwIBAgEVMAYNAQUCAQGIKw2+fQEBAQEBAQEBAQEBAQEBAQEBAQEBARQEh?= =?us-ascii?q?g2FRIQqEQGEfQEEjSWJN4sBgjqBcYcwk0kfAQFCg0Y+PjSELoFBAQEB?= X-IronPort-AV: E=Sophos;i="5.20,372,1444694400"; d="scan'208";a="613195608" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2015 10:23:06 +0000 Received: from [10.47.200.89] ([10.47.200.89]) (authenticated bits=0) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tB2AN5Re011024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 2 Dec 2015 10:23:06 GMT Message-ID: <565EC68B.7080104@cisco.com> Date: Wed, 02 Dec 2015 10:23:07 +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: Paul Kyzivat References: <56535BCD.5040803@alum.mit.edu> <565E077D.1010907@alum.mit.edu> In-Reply-To: <565E077D.1010907@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: rohanse2 Archived-At: Cc: clue@ietf.org Subject: Re: [clue] registration of "clue" grouping framework attribute in signaling draft 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 Dec 2015 10:23:10 -0000 Hi Paul, yes, good point - will fix that. BTW, planned to finish revising the document over the weekend but it turns out that the Eurostar disagrees with me in ways other trains don't when it comes to reading or writing so I didn't get much done; will look to finish it this weekend instead. Rob On 01/12/15 20:47, Paul Kyzivat wrote: > Another issue with signaling. The formatting of the info for the > registration of the new SDP grouping attribute is also messed up, to > the point of being undecipherable. > > Thanks, > Paul > > On 11/23/15 1:32 PM, Paul Kyzivat wrote: >> I was doing a final review of the signaling draft. I notice that the >> registration of sip.clue in the IANA considerations section is a bit >> sloppy. This will be subjected to expert review, so it should be brought >> up to standard so that the expert is happy. >> >> Since I happen to be the expert, I can suggest what would make me happy. >> :-) >> >> This specification registers a new media feature tag in the SIP >> [RFC3264] tree per the procedures defined in [RFC2506] and >> [RFC3840]. >> >> Media feature tag name: sip.clue >> >> Summary of the media feature indicated by this tag: This feature tag >> indicates that the device supports CLUE controlled media. >> >> Values appropriate for use with this feature tag: Boolean. >> >> The feature tag is intended primarily for use in the following >> applications, protocols, services, or negotiation mechanisms: >> >> This feature tag is most useful in a communications application for >> describing the capabilities of a device which uses multiple media >> streams. >> >> Related standards or documents: RFC XXXX [this document] >> >> Security Considerations: Security considerations for this media >> feature tag are discussed in Section 12 of RFC XXXX. >> >> Name(s) & email address(es) of person(s) to contact for >> further information: >> >> - CLUE workgroup: clue@ietf.org >> - CLUE chairmen: clue-chairs@ietf.org >> >> Intended usage: COMMON >> >> (I suspect that the formatting is already better in the xml, but lost by >> xml2rfc.) >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > From nobody Sun Dec 13 07:41:30 2015 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 0D3391A6F22 for ; Sun, 13 Dec 2015 07:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 i8o64PRXmeZQ for ; Sun, 13 Dec 2015 07:41:26 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 CF7C21A879F for ; Sun, 13 Dec 2015 07:41:24 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id p66so31521828wmp.1 for ; Sun, 13 Dec 2015 07:41:24 -0800 (PST) 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:content-type :thread-index:content-language; bh=Tzh46M66x3JKxO4I6Y+MNPHZLMfCazsW2VohMwE4NeQ=; b=kycse9Ainqjvccnxy3ltmA4q40ohsrPahLswPG2vYOev8SfQ1pPAAHHofc1wZ1YaVi 3LFIvFYDz5RMrKAoyUa4xfqotKbUvm+jbWoN+58iHQcEmMWa1mCvCcatO46XESmy1daW rl+4JjkeIl2/YohARa+uqcl8/3j6XTaVVmHkEeAzrDzj0gVozdGa/aeSpeJMB7Mri6yd XiuFThi7NAAO2aaGFHZDcn4YpWGQo9DB/OljIB0j+itMceaaif+/jJnU6nq9Dtz9b5Uo vlm61V2sy/ticqNkdPP8+m5CcMWKtXZMtyE+OHQDHEkWsoU+rVHCDEsQFE05beUVWFIk LmaA== X-Received: by 10.28.3.131 with SMTP id 125mr18117056wmd.64.1450021283400; Sun, 13 Dec 2015 07:41:23 -0800 (PST) Received: from RoniPC (bzq-79-177-166-72.red.bezeqint.net. [79.177.166.72]) by smtp.gmail.com with ESMTPSA id n127sm12020657wmf.12.2015.12.13.07.41.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Dec 2015 07:41:22 -0800 (PST) From: "Roni Even" To: Date: Sun, 13 Dec 2015 17:41:20 +0200 Message-ID: <000901d135bc$b7d505d0$277f1170$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01D135CD.7B5E7210" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdE1u/DLvK+5MhHWTF24CK4V8Q4x3g== Content-Language: he Archived-At: Subject: [clue] Short WGLC on https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-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: Sun, 13 Dec 2015 15:41:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000A_01D135CD.7B5E7210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi guys, (I cc'ed those who reviewed the draft before) We had a WGLC on the 09 version a couple on month ago. The -11 version supposedly address all issues. I would like to have a short 10 days WGLC till December 23rd before sending to publication. Please review https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-11 and see if you are OK One open issue was if we need a IANA registry for the Policy attribute (section 11.10) Thanks Roni ------=_NextPart_000_000A_01D135CD.7B5E7210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi guys, = (I cc’ed those who reviewed the draft before)

 

We had a = WGLC on the 09 version a couple on month ago. The -11 version supposedly = address all issues.

I would like to = have a short 10 days WGLC till December 23rd before sending = to publication.

Please review https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-11 = and see if you are OK

 

One open = issue was if we need a IANA registry for the Policy attribute (section = 11.10)

 

Thanks

Roni

------=_NextPart_000_000A_01D135CD.7B5E7210-- From nobody Mon Dec 14 18:35:14 2015 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 9978F1B29A7 for ; Mon, 14 Dec 2015 18:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 DV7jCFn7lwNU for ; Mon, 14 Dec 2015 18:35:12 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE441AD37B for ; Mon, 14 Dec 2015 18:25:46 -0800 (PST) Received: from ppp118-209-39-77.lns20.mel4.internode.on.net ([118.209.39.77]:61504 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1a8fJ8-001fYq-RA; Tue, 15 Dec 2015 13:25:42 +1100 To: Roni Even , clue@ietf.org References: <000901d135bc$b7d505d0$277f1170$@gmail.com> From: Christian Groves Message-ID: <566F7A25.6090505@nteczone.com> Date: Tue, 15 Dec 2015 13:25:41 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <000901d135bc$b7d505d0$277f1170$@gmail.com> 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 - cserver5.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: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: cserver5.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] Short WGLC on https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-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, 15 Dec 2015 02:35:13 -0000 Hello Roni, We could have had the 12 days of Christmas CLUE comments :-) Nothing major that I saw. Please find my comments below: Section. 3 - NIT: two ".." in Capture scene view Section. 3 - CLUE participant: I'd suggest to add "e.g." before the "either an Endpoint or MCU". CLUE could be used in other types e.g. MDD. Section. 3 - Endpoint: There should be a ":" after endpoint. Section. 3 - The definitions for "Stream Characteristics and Video Capture" don't match what's defined in the framework document. Section. 4 - " As a general remark, please notice that optional elements that don't define what their absence means are intended to be associated with undefined properties." I didn't quite understand what this was getting at? Section. 7, 8, 9, 10 etc.: At the end of the description the text is finished by a "." followed by a reference, e.g. element. (Section 11.28). Should the "." after element be deleted? e.g. as per section 6. Section 11.4 - NIT "can not" -> "cannot" Section 11.5 - What is a "registered" presentation? I know what a presentation is but what's the registered part? Section 11.5 - I propose to move the text "Non spatially definable captures do not embed such element in their XML description: they are instead characterized by having the tag set to "true" (see Section 11.6)." Up one paragraph so that it is contained in the paragraph describing the non-spatially definable. Section 11.13 - NIT extraneous ")" e.g. ... (section 11)) Section 11.16 - NIT "highly dinamic" -> "highly dynamic" Section 11.19.1 Embedded Text & Section 11.19.2 Captured People: Why is this a level 3 heading when the other attributes are level 2? Section 11.20 & General: "Sensitivity Pattern" seems to be defined in XML as "sensitivyPattern" e.g. dropping "it". Is this intentional? I assume not as 11.20.1 talks about not < sensitivyPattern> or < sensitivyPatternType>. Section 11.27.3 - NIT "simultanous" -> "simultaneous" Section 11.29.1.3 - maybe change "his" to "their" to keep it gender neutral. Section 14 - Related to Roni's comment on value extension. Should we discuss in this section how to extend the existing values of an attribute? With respect to the policy I think its similar to quite a few of the attributes defined by the framework, e.g. view, person type, presentation etc. These all could be extended. Regards, Christian On 14/12/2015 2:41 AM, Roni Even wrote: > > Hi guys, (I cc’ed those who reviewed the draft before) > > We had a WGLC on the 09 version a couple on month ago. The -11 version > supposedly address all issues. > > I would like to have a short 10 days WGLC till December 23^rd before > sending to publication. > > Please review > https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-11 and > see if you are OK > > One open issue was if we need a IANA registry for the Policy attribute > (section 11.10) > > Thanks > > Roni > From nobody Tue Dec 15 14:56:56 2015 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 74EE41B2CBA; Tue, 15 Dec 2015 14:56:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151215225655.19408.56476.idtracker@ietfa.amsl.com> Date: Tue, 15 Dec 2015 14:56:55 -0800 Archived-At: Cc: clue-chairs@ietf.org, draft-ietf-clue-framework@ietf.org, clue@ietf.org Subject: [clue] Ben Campbell's Yes on draft-ietf-clue-framework-24: (with COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 22:56:55 -0000 Ben Campbell has entered the following ballot position for draft-ietf-clue-framework-24: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have some minor comments. These should be easy to resolve, and I don't think any are show-stoppers. === Subtantive === - Section 3, MCU definition. Does this need a normative reference to 4353? I'm not sure the definition can be understood as written without reading it. - 4, paragraph (5): The 2119 "OPTIONAL" is vague about what it applies to. Use of companion protocols? Consider stating this descriptively. -4, last paragraph: I don't think the 2119 "REQUIRED" is needed or appropriate here. It doesn't seem to add anything, and might be interpreted to not allow local policy decisions, etc. -5, paragraph 5: The paragraph describes what Media Capture means, but never really defines what "Encoding" means. (And the definition of "Encoding" in the terminology section is somewhat circular.) - 5, 3rd paragraph after Fig 2: Isn't setting up media transmission a primary effect? -6, third bullet: It seems kind of odd to use a MUST for this, given that the criteria of professionally installed is somewhat vague. I think a non-normative recommendation would make more sense. - 7.1.1.7, "Note" Where are these keywords expected to be defined? This seems like an unfinished section--is it an open to do item? - 7.1.1.8 Why is this limited (with a MUST) to these defined values? This list assumes traditional usages. It seems like a more open list would allow for innovative usage. For example, a game court, an outdoor space, etc. - 7.1.1.9: This section seems to need a normative reference to 5646. - 7.1.1.10: Are LOGO, PHOTO, or SOUND the only kinds of large content that can be carried here? -7.1.1.11: Is the list of person types exhaustive? -7.1.1.12: How is priority interpreted? Larger number is higher priority? Is it strictly a matter of ordering, or does 2N represent twice the priority of N? -8, paragraph after Table 5: "Simultaneous Transmission Sets MUST allow all the media Captures in any particular Capture Scene View..." This seems to reverse the causality. Since the simultaneous transmission set is based on physical limits, shouldn't it say that any particular CSV MUST respect the limitations in the simultaneous transmission sets? (Same for Global View). - 15, 2nd paragraph: I think this requires 5239 to be a normative reference. -15, paragaph 4: "DTLS/SRTP MUST be supported and SHOULD be used unless the media, which is based on RTP, is secured by other means..." Is "secured by other means" intended to be the sole exception? If so, then this might should say MUST ... unless". As defined in 2119, a SHOULD would allow an implementation to skip the protection for other reasons, if the implementer was aware of the implications, etc... Also, should the references to 7201 and 7202 be normative? === Editorial === - Figure 2: By SDP Media Session you mean an RTP session as described by the basic SDP right? That is not an SDP session per se. -5, third paragraph from end: Please avoid 2119 keywords inside parenthetical phrases. Also, it's redundant to say implementations of a protocol MUST follow the protocol :-) From nobody Wed Dec 16 10:58:47 2015 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 4FF311A8876; Wed, 16 Dec 2015 10:58:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216185846.25360.72739.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 10:58:46 -0800 Archived-At: Cc: clue-chairs@ietf.org, draft-ietf-clue-framework@ietf.org, clue@ietf.org Subject: [clue] Spencer Dawkins' Yes on draft-ietf-clue-framework-24: (with COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 18:58:46 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-clue-framework-24: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I remember the first couple of years of CLUE. This was worth writing. I'm a Yes, but did have some editorial suggestions and questions. In Section 1. Introduction, Current telepresence systems, though based on open standards such as RTP [RFC3550] and SIP [RFC3261], cannot easily interoperate with each other. this text hasn't changed since the 00 individual draft from 2012. Is it still true for "current" telepresence systems? In this text: If the physical space does not have a well-defined front and back, the provider chooses any direction for X and Y consistent with right-handed coordinates. is there any reference/pointer you could provide to a definition of "consistent with right-handed coordinates"? If everyone understands that but me, please ignore this comment ... Is "line of capture" a meaningful concept on its own? Or is it only meaningful as "point on line of capture"? I wonder if it would be less confusing if you always called "volume of capture" "3-D volume of capture". I was consistently assuming "volume" was an audio thing, when I saw "volume of capture" with no qualifier. You define it as "3 dimentional volume of capture", but then drop that qualifier in subsequent use. Is Person Type just a string for presentation? If so, that's fine, but the framework defines 8 types in some detail, and notes that this list isn't exhaustive and that custom person types can be defined, so I wonder if there's any expectation that CLUE will do anything specific, based on Person Type. PIP isn't expanded until its 5th use (if I'm reading correctly). I'm guessing that PiPs is the plural of PiP, but that's a guess, and I wouldn't mind a word or two of explanation about that. "Tiled" is probably a term of art, so maybe it doesn't need an explanation, but it's not clear whether "tiled" and "PiP" are the same thing or not (which would be a good thing to include in an explanation, if you add one). From nobody Wed Dec 16 13:15:29 2015 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 47EE71A8A44 for ; Wed, 16 Dec 2015 13:15:19 -0800 (PST) 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, 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 oHqzHhyFCIv5 for ; Wed, 16 Dec 2015 13:15:13 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.198]) (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 B40E01A8A75 for ; Wed, 16 Dec 2015 13:15:12 -0800 (PST) Received: from [216.82.241.100] by server-6.bemta-8.messagelabs.com id EB/C7-09771-F54D1765; Wed, 16 Dec 2015 21:15:11 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-220.messagelabs.com!1450300509!16642813!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22402 invoked from network); 16 Dec 2015 21:15:10 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-9.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 16 Dec 2015 21:15:10 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.113]) by Crpehubprd01.polycom.com ([::1]) with mapi; Wed, 16 Dec 2015 13:15:09 -0800 From: "Duckworth, Mark" To: Roni Even , "clue@ietf.org" Date: Wed, 16 Dec 2015 13:15:07 -0800 Thread-Topic: Mark's comments RE: Short WGLC on https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-11 Thread-Index: AdE4Rtahd2HY8M3hTMS/Dtzk7MzYMA== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52FC172A058EF@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5C4AC54BFF7A0842A6A11F554D6FB52FC172A058EFCRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: Subject: [clue] Mark's comments RE: Short WGLC on https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-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, 16 Dec 2015 21:15:19 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52FC172A058EFCRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 4, why did maxCaptureType change from unsignedInt to positiveIntege= r? I thought we agreed not to use the unbounded integer types. Is it just t= o disallow the value zero? Is there another way to do that without allowing= unbounded values? I had a few comments way back on draft 07, some of which didn't seem to be add= ressed. I think they are still worthwhile considering, so I include them ag= ain here. Section 17 example "... endpoint-style Media Provider's offer". I think it should be "... end= point-style Media Provider's advertisement" Section 17 p 48 simultaneous sets - I think it makes more sense to say you = can't provide the loudest segment at same time as the zoomed out view, beca= use they would be using the same camera at different zoom levels in this ex= ample. So VC3 and VC4 can't be simultaneous. So then SS2 should be just (V= C0, VC2, VC4). The spatial information in the sample file doesn't make sense, it looks lik= e just a placeholder because it is identical for all captures. I have this = proposal for spatial information. AC0 0.0 0.0 10.0 0.0 1.0 10.0 VC0 - left -2.0 0.0 10.0 -3.0 20.0 9.0 -1.0 20.0 9.0 -3.0 20.0 11.0 -1.0 20.0 11.0 VC1 - center 0.0 0.0 10.0 -1.0 20.0 9.0 1.0 20.0 9.0 -1.0 20.0 11.0 1.0 20.0 11.0 VC2 - right 2.0 0.0 10.0 1.0 20.0 9.0 3.0 20.0 9.0 1.0 20.0 11.0 3.0 20.0 11.0 VC3 - loudest segment -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 VC4 - zoomed out 0.0 0.0 10.0 -3.0 20.0 7.0 3.0 20.0 7.0 -3.0 20.0 13.0 3.0 20.0 13.0 I suggest VC3 should have spatial information, rather than true, because the framework says "For a switched Capture that switch= es between different sections within a larger area, the area of capture MUS= T use coordinates for the larger potential area." There are two elements with just VC4. I think one of them shou= ld have AC0 instead. Maybe VC3 and VC4 should have priority =3D 2? Otherwise they all have prio= rity=3D1, which isn't useful. p 53 - remove VC3 from SS2 as I mentioned above. Section 18 MCC example. Looks like this one is an extension of previous, so any updates to section = 17 should apply here too. VC3 VC5 VC6 and VC7 should all have the same spatial information, same as V= C3 in section 17. Some captures should have lower priority, if they are all the same it doesn= 't help. I think VC7 should have this too: 3 VC7 also needs an encoding group EG0 Again, simultaneous sets don't seem quite right. SS1: (SE1, VC3, VC7) I added VC3 SS2: (VC0, VC2, VC4) I removed VC7, because can't do all the segments at sa= me time as VC4 zoomed out. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Sunday, December 13, 2015 10:41 AM To: clue@ietf.org Cc: Rob Hansen (rohanse2); Christian Groves; Paul Kyzivat; danielcburnett@g= mail.com; Duckworth, Mark Subject: Short WGLC on https://tools.ietf.org/html/draft-ietf-clue-data-mod= el-schema-11 Hi guys, (I cc'ed those who reviewed the draft before) We had a WGLC on the 09 version a couple on month ago. The -11 version supp= osedly address all issues. I would like to have a short 10 days WGLC till December 23rd before sending= to publication. Please review https://tools.ietf.org/html/draft-ietf-clue-data-model-schema= -11 and see if you are OK One open issue was if we need a IANA registry for the Policy attribute (sec= tion 11.10) Thanks Roni --_000_5C4AC54BFF7A0842A6A11F554D6FB52FC172A058EFCRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Section 4, why did maxCaptureType change from unsignedIn= t to positiveInteger? I thought we agreed not to use the unbounded integer = types. Is it just to disallow the value zero? Is there another way to do th= at without allowing unbounded values?

 

I had a few comments way bac= k on draft 07, some of which didn’t seem to be addressed. I think= they are still worthwhile considering, so I include them again here.<= /o:p>

&nb= sp;

Section 17 example

<= p class=3DMsoNormal>“... endpoint-style Media Provider’s offer&= #8221;.  I think it should be “... endpoint-style Media Provider= ’s advertisement”

 

Section 17 p 48 simultaneous sets – I = think it makes more sense to say you can’t provide the loudest segmen= t at same time as the zoomed out view, because they would be using the same= camera at different zoom levels in this example.  So VC3 and VC4 can&= #8217;t be simultaneous. So then SS2 should be just (VC0, VC2, VC4).

 

The s= patial information in the sample file doesn’t make sense, it looks li= ke just a placeholder because it is identical for all captures. I have this= proposal for spatial information.

AC0

<capturePoint>=

  <x>0.0</x>

  <y>0.0</y>

  <z>10.0</z>

  <lineOfCapturePoi= nt>

    <x>0.0</x>=

 &n= bsp;  <y>1.0</y>

    <z>10.0= </z>

  </lineOfCapturePoint>

</captur= ePoint>

 

VC0 - left

<capturePoint>= ;

  <x>-2.0</x>

  <y>0.0</= y>

  <z>10.0</z>

</capturePoint>= ;

<captureArea>

  <bottomLeft>  <= ;x>-3.0</x> <y>20.0</y> <z>9.0</z> </bo= ttomLeft>

  <bottomRight> <x>-1.0</x> &l= t;y>20.0</y> <z>9.0</z> </bottomRight>

=   <topLeft>     <x>-3.0</x> <= y>20.0</y> <z>11.0</z> </topLeft>

 = ; <topRight>    <x>-1.0</x> <y>20.0&= lt;/y> <z>11.0</z> </topRight>

</captureAr= ea>

 

VC1 - center

<capturePoint>=

  <x>0.0</x>

  <y>0.0</y&= gt;

  <z>10.0</z>

</capturePoint>= ;

<captureArea>

  <bottomLeft>  <= ;x>-1.0</x> <y>20.0</y> <z>9.0</z> </bo= ttomLeft>

  <bottomRight> <x>1.0</x>&nbs= p; <y>20.0</y> <z>9.0</z> </bottomRight>=

  <topLeft>     <x>-1.0</x>= <y>20.0</y> <z>11.0</z> </topLeft>

=   <topRight>    <x>1.0</x>  <= y>20.0</y> <z>11.0</z> </topRight>

<= /captureArea>

 

= VC2 - right

=

<captureP= oint>

  <x>2.0</x>

  <y>0.= 0</y>

  <z>10.0</z>

</capturePo= int>

<captureArea>

  <bottomLeft>&nbs= p; <x>1.0</x> <y>20.0</y> <z>9.0</z> &l= t;/bottomLeft>

  <bottomRight> <x>3.0</x>= ; <y>20.0</y> <z>9.0</z> </bottomRight><= /o:p>

  <topLeft>     <x>1.0</x> &= lt;y>20.0</y> <z>11.0</z> </topLeft><= /span>

&n= bsp; <topRight>    <x>3.0</x> <y>20.= 0</y> <z>11.0</z> </topRight>

=

</capture= Area>

 

VC3 - loudest segment

<captur= eArea>

  <bottomLeft>  <x>-3.0</x> = <y>20.0</y> <z>9.0</z> </bottomLeft>

  <bottomRight> <x>3.0</x>  <y>20.0</= y> <z>9.0</z> </bottomRight>

  <topLe= ft>     <x>-3.0</x> <y>20.0</y&= gt; <z>11.0</z> </topLeft>

  <topRight&= gt;    <x>3.0</x>  <y>20.0</y> = <z>11.0</z> </topRight>

</captureArea>

 

VC4 - zoomed out

<capturePoint>

  <y>0.0</y>

  <z>10.0</z>

</capturePoint>

  <bottomLeft>  <x>-3.= 0</x> <y>20.0</y> <z>7.0</z> </bottomLeft&= gt;

  <bottomRight> <x>3.0</x>  <y&= gt;20.0</y> <z>7.0</z> </bottomRight>

&nbs= p; <topLeft>     <x>-3.0</x> <y>= ;20.0</y> <z>13.0</z> </topLeft><= /p>

  &l= t;topRight>    <x>3.0</x>  <y>20.0= </y> <z>13.0</z> </topRight>

<= p class=3DMsoNormal></captureA= rea>

 

I suggest VC3 should have spatial information, rather than= <nonSpatiallyDefinable>true, because the framework says “For a= switched Capture that switches between different sections within a larger = area, the area of capture MUST use coordinates for the larger potential are= a.”

 

There are two <sceneView> elements with just VC4.  = I think one of them should have AC0 instead.

 

Maybe VC3 and VC4 should hav= e priority =3D 2?  Otherwise they all have priority=3D1, which isnR= 17;t useful.

 

p 53 - remove VC3 from SS2 as I mentioned above.<= /p>

 

Section 1= 8 MCC example.

 

Looks like this one is an extension of previous, so any up= dates to section 17 should apply here too.

VC3 VC5 VC6 and VC7 should all have the same spatial information, same a= s VC3 in section 17.

Some captures shoul= d have lower priority, if they are all the same it doesn’t help.=

I think VC7 should have this too:=

<maxCaptures exactNumber=3D”true”&g= t;3</maxCaptures>

VC7 also needs a= n encoding group

<encGroupIDREF>EG= 0</encGroupIDREF>

Again, simultane= ous sets don’t seem quite right.

S= S1: (SE1, VC3, VC7) I added VC3

SS2: (VC= 0, VC2, VC4) I removed VC7, because can’t do all the segments at same= time as VC4 zoomed out.

 

Mark

 

From: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent:<= /b> Sunday, December 13, 2015 10:41 AM
To: clue@ietf.org
Cc= : Rob Hansen (rohanse2); Christian Groves; Paul Kyzivat; danielcburnett= @gmail.com; Duckworth, Mark
Subject: Short WGLC on https://tools.= ietf.org/html/draft-ietf-clue-data-model-schema-11

 

Hi = guys, (I cc’ed those who reviewed the draft before)

 

We had a WGLC o= n the 09 version a couple on month ago. The -11 version supposedly address = all issues.

I would like to have a short= 10 days WGLC till December 23rd before sending to publication. =

Please review https://tools.ietf.org/= html/draft-ietf-clue-data-model-schema-11 and see if you are OK

 

One o= pen issue was if we need a IANA registry for the Policy attribute (section = 11.10)

 

Thanks

Roni

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52FC172A058EFCRPMBOXPRD08p_-- From nobody Thu Dec 17 04:55:31 2015 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 4D7E31A6F3C; Thu, 17 Dec 2015 04:55:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151217125527.4771.42784.idtracker@ietfa.amsl.com> Date: Thu, 17 Dec 2015 04:55:27 -0800 Archived-At: Cc: clue-chairs@ietf.org, draft-ietf-clue-framework@ietf.org, clue@ietf.org Subject: [clue] Stephen Farrell's No Objection on draft-ietf-clue-framework-24: (with COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 12:55:27 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-clue-framework-24: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a pretty comprehensive description. These sound like fun systems on which to work. Pity there are so many IPR declarations with not great terms and for something that to me at least doesn't appear to require invention (just construction of existing bits) but I guess that's the world we live in and the WG were ok with that. - 7.1.1.3 - I wondered if the "MUST be co-planar" requirement could cause issues (bugs) if receivers don't check for that. Are receivers expected to verify that on receipt or is the MUST only for senders? - 7.1.1.10: privacy issues abound, but section 15 only refers to the communications security aspect. I think you ought recommend that implementations SHOULD minimise the information sent, and SHOULD give users control over what is sent. You might want to note the utility of sending the same subset of information for regular repeated calls but I'm not sure what clue protocol might know that calls are repeats or if there's a better way to manage re-use of privacy settings for users. - The secdir review [1] noted some issues that may be worth considering for later WG documents. I'd encourage folks to try get in touch with the reviewer when doing later work as that might avoid some late-surprises. (That is not a threat btw, just encouragement to try take advantage of a reviewer who likes to consider more than just what's in front of him today:-) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06244.html From nobody Thu Dec 17 05:44:41 2015 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 7AA561B2D1C; Thu, 17 Dec 2015 05:44:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151217134440.10479.95444.idtracker@ietfa.amsl.com> Date: Thu, 17 Dec 2015 05:44:40 -0800 Archived-At: Cc: clue-chairs@ietf.org, draft-ietf-clue-framework@ietf.org, clue@ietf.org Subject: [clue] Benoit Claise's No Objection on draft-ietf-clue-framework-24: (with COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 13:44:40 -0000 Benoit Claise has entered the following ballot position for draft-ietf-clue-framework-24: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As reviewed by Eric Vyncke in his OPS-DIR review (mainly for documentation purposes): This rather long I-D is quite clear and easy to understand with multiple examples. I found nothing in this framework document which could cause operational issues. The CLUE devices are able to detect other CLUE-enabled devices which is of course good for migration/interoperation. Unrelated to this specific ID (so feel free to ignore) but more on the other documents (data model & protocol): the protocol extensions are briefly mentioned in this framework document section 11, but, can the WG take special care in versioning the CLUE protocol (as proposed in the current protocol I-D) as well as allowing extension of the finite set of values for some information? For exemple, the "view" (section 7.1.1.8) has only a limited set of values and there appears to have no way to extend it, is there an intent to open a IANA registry for those values? Probably not as the IANA considerations are 'none'. Does CLUE WG (or another) have the intent to develop a YANG model? It does not appear in the CLUE WG charter. As a small nit, I would suggest to move the long section 12 (informative examples) as an appendix. From nobody Thu Dec 17 18:58:10 2015 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 4A7C71B3260; Thu, 17 Dec 2015 18:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.534 X-Spam-Level: * X-Spam-Status: No, score=1.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, T_DKIM_INVALID=0.01] 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 NOX3JSkKZZGl; Thu, 17 Dec 2015 18:58:08 -0800 (PST) Received: from msh03.myshophosting.com (fw01.ch31995.smartservers.com.au [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 6FF3E1B325F; Thu, 17 Dec 2015 18:58:08 -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:Cc:References:To:Subject; bh=HHuT7tgznlbss4vmJeWY/6PBQyNCHqYDr1WKkaQE65U=; b=JelBfIvUBsadOELWOt55cKVK6J 9Ns1zbe7izslepWeSGBTK19M+LbVmrPRJZ9ououOFNFrXtOOx/osr8NmZ5QFkAdBx+9eR6ONKZjip QYFrRXJx7EnkHzhNr8TMy/L0ZmYtbzP8DnHeJIqiI+MRdoWMME9wZ6z9XCkeIfit/DAU9+yQC+q40 RrKU+JNihFCRqOoXqfINOEeFGMAMjrhoCDB+nJ0etAipM0v/H0KfZ4wD4Ja6vtl3syBLAMEk5g0sy DE/PXFbVCjpoSaz5lsz2PmG5OdfyGrmQusq6pE7t6qsI8DV8yzxlNTCaZfUZ88AlLi+dMpK/XU74a OsiHeknw==; Received: from ppp118-209-47-181.lns20.mel4.internode.on.net ([118.209.47.181]:59595 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1a9lF5-004CAL-99; Fri, 18 Dec 2015 13:58:03 +1100 To: Ben Campbell , The IESG References: <20151215225655.19408.56476.idtracker@ietfa.amsl.com> From: Christian Groves Message-ID: <56737636.6070500@nteczone.com> Date: Fri, 18 Dec 2015 13:57:58 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151215225655.19408.56476.idtracker@ietfa.amsl.com> 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: Cc: clue-chairs@ietf.org, draft-ietf-clue-framework@ietf.org, clue@ietf.org Subject: Re: [clue] Ben Campbell's Yes on draft-ietf-clue-framework-24: (with COMMENT) 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, 18 Dec 2015 02:58:10 -0000 Hello Ben, Answers to a few of your comments below: On 16/12/2015 9:56 AM, Ben Campbell wrote: > ..snip.. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > > - 7.1.1.10: Are LOGO, PHOTO, or SOUND the only kinds of large content > that can be carried here? [CNG] The xcard/vcard specification allows these fields to carry base64 data. Thus a large amount of data could be included. The only other field is the KEYS field that carries security key information. We didn't think the keys field would be likely to carry the same amount of data as the LOGO, PHOTO or sound fields. > > -7.1.1.11: Is the list of person types exhaustive? [CNG] For defined types yes. Additional types could be registered. It also allows user specified non-registered types. > > -7.1.1.12: How is priority interpreted? Larger number is higher priority? > Is it strictly a matter of ordering, or does 2N represent twice the > priority of N? [CNG] Just a matter of ordering. Regards, Christian From nobody Thu Dec 17 19:05:47 2015 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 B03DB1A9060; Thu, 17 Dec 2015 19:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.534 X-Spam-Level: * X-Spam-Status: No, score=1.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, T_DKIM_INVALID=0.01] 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 FFci6ueCfw15; Thu, 17 Dec 2015 19:05:44 -0800 (PST) Received: from msh03.myshophosting.com (fw01.ch31995.smartservers.com.au [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 50DC31A00B4; Thu, 17 Dec 2015 19:05:44 -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:Cc:References:To:Subject; bh=A03Crfz3DvBEh2wHSBiF3jhSJxxDrGKv6Dah9DEc548=; b=piFyMcj1IxVChPP8dVHRmLZrym L3smBGbGOeGg3a8N752Ip4CaBb4/ZCtw1QD+rtpR5IEuSYV646QVcgbc8GyPkB5Cdqv6IpdDkP7Vl S8+bDWKsPPaTJqOAMz1Dru9ZEWGTd3cyK96UE9sOBouV0GNGkaU9yI6iESGvOhyCdSOLO0tViwhZ9 xfMT8KCTVbtOfmfwbnYX2ohru1sSnSbgd5weq++kgvCdTDofusffOJavva6VxXD+42785dbNpuoYM JNWbox0JG3XpG9UZpDH4PfIaxQvP75FUIhvL/x6KLH6q3dNHGuQQ75dLgfyUqOB672/4ot4eXYxSg DpdraYHg==; Received: from ppp118-209-47-181.lns20.mel4.internode.on.net ([118.209.47.181]:59604 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1a9lMU-004CMb-Hc; Fri, 18 Dec 2015 14:05:42 +1100 To: Spencer Dawkins , The IESG References: <20151216185846.25360.72739.idtracker@ietfa.amsl.com> From: Christian Groves Message-ID: <56737801.8010908@nteczone.com> Date: Fri, 18 Dec 2015 14:05:37 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151216185846.25360.72739.idtracker@ietfa.amsl.com> 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: Cc: clue-chairs@ietf.org, draft-ietf-clue-framework@ietf.org, clue@ietf.org Subject: Re: [clue] Spencer Dawkins' Yes on draft-ietf-clue-framework-24: (with COMMENT) 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, 18 Dec 2015 03:05:45 -0000 Hello Spencer, Please see my responses below. Regards, Christian On 17/12/2015 5:58 AM, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-clue-framework-24: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I remember the first couple of years of CLUE. This was worth writing. > > I'm a Yes, but did have some editorial suggestions and questions. > > In Section 1. Introduction, > > Current telepresence systems, though based on open standards such > as RTP [RFC3550] and SIP [RFC3261], cannot easily interoperate with > each other. > > this text hasn't changed since the 00 individual draft from 2012. Is it > still true for "current" telepresence systems? > > In this text: > > If the physical space does not > have a well-defined front and back, the provider chooses any > direction for X and Y consistent with right-handed coordinates. > > is there any reference/pointer you could provide to a definition of > "consistent with right-handed coordinates"? If everyone understands that > but me, please ignore this comment ... > > Is "line of capture" a meaningful concept on its own? Or is it only > meaningful as "point on line of capture"? [CNG] "line of capture" is a synonym for "the direction and axis of the capturing device". Its meaningful. The "point on line of capture" allows it to be calculated. > > I wonder if it would be less confusing if you always called "volume of > capture" "3-D volume of capture". I was consistently assuming "volume" > was an audio thing, when I saw "volume of capture" with no qualifier. You > define it as "3 dimentional volume of capture", but then drop that > qualifier in subsequent use. > > Is Person Type just a string for presentation? If so, that's fine, but > the framework defines 8 types in some detail, and notes that this list > isn't exhaustive and that custom person types can be defined, so I wonder > if there's any expectation that CLUE will do anything specific, based on > Person Type. [CNG] The string could be presented or it could be consumed for capture selection. I.e. the policy of a consumer could say they always want to see/hear the "chair". The endpoint would then select captures attributed to the chair. > > PIP isn't expanded until its 5th use (if I'm reading correctly). I'm > guessing that PiPs is the plural of PiP, but that's a guess, and I > wouldn't mind a word or two of explanation about that. "Tiled" is > probably a term of art, so maybe it doesn't need an explanation, but it's > not clear whether "tiled" and "PiP" are the same thing or not (which > would be a good thing to include in an explanation, if you add one). > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Dec 17 22:06:40 2015 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 B45AF1B3381; Thu, 17 Dec 2015 22:06:35 -0800 (PST) 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, T_RP_MATCHES_RCVD=-0.01] 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 A39uaeypHpic; Thu, 17 Dec 2015 22:06:34 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 97A241B3380; Thu, 17 Dec 2015 22:06:34 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBI66XZm039286 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 18 Dec 2015 00:06:34 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Christian Groves" Date: Fri, 18 Dec 2015 00:06:33 -0600 Message-ID: <23BA935D-B2F2-439E-8F18-F85C4F382660@nostrum.com> In-Reply-To: <56737636.6070500@nteczone.com> References: <20151215225655.19408.56476.idtracker@ietfa.amsl.com> <56737636.6070500@nteczone.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: clue-chairs@ietf.org, draft-ietf-clue-framework@ietf.org, clue@ietf.org, The IESG Subject: Re: [clue] Ben Campbell's Yes on draft-ietf-clue-framework-24: (with COMMENT) 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, 18 Dec 2015 06:06:35 -0000 Thanks! Comments inline. Ben. On 17 Dec 2015, at 20:57, Christian Groves wrote: > Hello Ben, > > Answers to a few of your comments below: > > On 16/12/2015 9:56 AM, Ben Campbell wrote: >> ..snip.. >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> >> - 7.1.1.10: Are LOGO, PHOTO, or SOUND the only kinds of large content >> that can be carried here? > [CNG] The xcard/vcard specification allows these fields to carry > base64 data. Thus a large amount of data could be included. The only > other field is the KEYS field that carries security key information. > We didn't think the keys field would be likely to carry the same > amount of data as the LOGO, PHOTO or sound fields. That seems like a reasonable assumption. >> >> -7.1.1.11: Is the list of person types exhaustive? > [CNG] For defined types yes. Additional types could be registered. It > also allows user specified non-registered types. Okay. >> >> -7.1.1.12: How is priority interpreted? Larger number is higher >> priority? >> Is it strictly a matter of ordering, or does 2N represent twice the >> priority of N? > [CNG] Just a matter of ordering. Okay. It would at least be worth mentioning that a higher number means a higher priority. > > Regards, Christian From nobody Fri Dec 18 13:40:52 2015 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 391C61B392F; Fri, 18 Dec 2015 13:40:51 -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 W2YryVBinTIf; Fri, 18 Dec 2015 13:40:49 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.194]) (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 64A171B3931; Fri, 18 Dec 2015 13:40:49 -0800 (PST) Received: from [216.82.241.100] by server-2.bemta-8.messagelabs.com id 9B/D3-18064-06D74765; Fri, 18 Dec 2015 21:40:48 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-220.messagelabs.com!1450474847!17463188!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7976 invoked from network); 18 Dec 2015 21:40:47 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-9.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 18 Dec 2015 21:40:47 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.113]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 18 Dec 2015 13:40:46 -0800 From: "Duckworth, Mark" To: Ben Campbell Date: Fri, 18 Dec 2015 13:40:44 -0800 Thread-Topic: [clue] Ben Campbell's Yes on draft-ietf-clue-framework-24: (with COMMENT) Thread-Index: AdE5Wk4CBLZoLYGUR5Sy3CFgHJ9pdgAggtMA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52FC172A05AEC@CRPMBOXPRD08.polycom.com> References: <20151215225655.19408.56476.idtracker@ietfa.amsl.com> <56737636.6070500@nteczone.com> <23BA935D-B2F2-439E-8F18-F85C4F382660@nostrum.com> In-Reply-To: <23BA935D-B2F2-439E-8F18-F85C4F382660@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "clue-chairs@ietf.org" , "draft-ietf-clue-framework@ietf.org" , "clue@ietf.org" , The IESG Subject: Re: [clue] Ben Campbell's Yes on draft-ietf-clue-framework-24: (with COMMENT) 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, 18 Dec 2015 21:40:51 -0000 About the priority value, the data model document specifies a lower number = is higher priority. I will also respond to some more of the comments on the framework next week= . =20 Mark > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Friday, December 18, 2015 1:07 AM > To: Christian Groves > Cc: The IESG; clue-chairs@ietf.org; draft-ietf-clue-framework@ietf.org; > clue@ietf.org > Subject: Re: [clue] Ben Campbell's Yes on draft-ietf-clue-framework-24: (= with > COMMENT) >=20 > Thanks! Comments inline. >=20 > Ben. >=20 > On 17 Dec 2015, at 20:57, Christian Groves wrote: >=20 > > Hello Ben, > > > > Answers to a few of your comments below: > > > > On 16/12/2015 9:56 AM, Ben Campbell wrote: > >> ..snip.. > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> > >> > >> - 7.1.1.10: Are LOGO, PHOTO, or SOUND the only kinds of large content > >> that can be carried here? > > [CNG] The xcard/vcard specification allows these fields to carry > > base64 data. Thus a large amount of data could be included. The only > > other field is the KEYS field that carries security key information. > > We didn't think the keys field would be likely to carry the same > > amount of data as the LOGO, PHOTO or sound fields. >=20 > That seems like a reasonable assumption. >=20 > >> > >> -7.1.1.11: Is the list of person types exhaustive? > > [CNG] For defined types yes. Additional types could be registered. It > > also allows user specified non-registered types. >=20 > Okay. >=20 > >> > >> -7.1.1.12: How is priority interpreted? Larger number is higher > >> priority? > >> Is it strictly a matter of ordering, or does 2N represent twice the > >> priority of N? > > [CNG] Just a matter of ordering. >=20 > Okay. It would at least be worth mentioning that a higher number means a > higher priority. >=20 > > > > Regards, Christian From nobody Tue Dec 22 10:16:22 2015 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 383671A8A3A; Tue, 22 Dec 2015 10:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 CgNJDIGDEvo0; Tue, 22 Dec 2015 10:16:16 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.195]) (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 D182A1A8A28; Tue, 22 Dec 2015 10:16:15 -0800 (PST) Received: from [216.82.241.100] by server-3.bemta-8.messagelabs.com id 95/EF-03824-E6399765; Tue, 22 Dec 2015 18:16:14 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-8.tower-220.messagelabs.com!1450808171!18583654!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8131 invoked from network); 22 Dec 2015 18:16:12 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-8.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 22 Dec 2015 18:16:12 -0000 Received: from SACWPHUBCAS02V.polycom.com (10.236.3.232) by Crpehubprd01.polycom.com (10.236.0.158) with Microsoft SMTP Server (TLS) id 8.3.389.2; Tue, 22 Dec 2015 10:16:11 -0800 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.113]) by SACWPHUBCAS02V.polycom.com ([fe80::5d20:679e:276b:7a8%12]) with mapi; Tue, 22 Dec 2015 10:16:10 -0800 From: "Duckworth, Mark" To: Ben Campbell , "clue@ietf.org" Date: Tue, 22 Dec 2015 10:16:09 -0800 Thread-Topic: Ben Campbell's Yes on draft-ietf-clue-framework-24: (with COMMENT) Thread-Index: AdE3i/cRtmygn7O8TuK692ye/w9E8wFNVQrQ Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F3AB@CRPMBOXPRD08.polycom.com> References: <20151215225655.19408.56476.idtracker@ietfa.amsl.com> In-Reply-To: <20151215225655.19408.56476.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "clue-chairs@ietf.org" , "draft-ietf-clue-framework@ietf.org" , The IESG Subject: Re: [clue] Ben Campbell's Yes on draft-ietf-clue-framework-24: (with COMMENT) 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, 22 Dec 2015 18:16:18 -0000 SGVsbG8gQmVuLA0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2suDQpJIGhhdmUgYSBmZXcgbW9yZSBy ZXNwb25zZXMgdG8geW91ciBjb21tZW50cyBiZWxvdy4NCk1hcmsNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW4gQ2FtcGJlbGwgW21haWx0bzpiZW5Abm9zdHJ1bS5j b21dDQo+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE1LCAyMDE1IDU6NTcgUE0NCg0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEkgaGF2ZSBzb21l IG1pbm9yIGNvbW1lbnRzLiBUaGVzZSBzaG91bGQgYmUgZWFzeSB0byByZXNvbHZlLCBhbmQgSSBk b24ndA0KPiB0aGluayBhbnkgYXJlIHNob3ctc3RvcHBlcnMuDQo+IA0KPiA9PT0gU3VidGFudGl2 ZSA9PT0NCj4gDQo+IC0gU2VjdGlvbiAzLCBNQ1UgZGVmaW5pdGlvbi4NCj4gRG9lcyB0aGlzIG5l ZWQgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIDQzNTM/IEknbSBub3Qgc3VyZSB0aGUgZGVmaW5p dGlvbg0KPiBjYW4gYmUgdW5kZXJzdG9vZCBhcyB3cml0dGVuIHdpdGhvdXQgcmVhZGluZyBpdC4N CltEdWNrd29ydGgsIE1hcmtdIEkgZG9uJ3Qga25vdy4gSXMgdGhlcmUgYW55IG9iamVjdGlvbiB0 byBtYWtpbmcgUkZDNDM1MyBhIG5vcm1hdGl2ZSByZWZlcmVuY2U/DQoNCj4gLSA0LCBwYXJhZ3Jh cGggKDUpOg0KPiBUaGUgMjExOSAiT1BUSU9OQUwiIGlzIHZhZ3VlIGFib3V0IHdoYXQgaXQgYXBw bGllcyB0by4gVXNlIG9mIGNvbXBhbmlvbg0KPiBwcm90b2NvbHM/IENvbnNpZGVyIHN0YXRpbmcg dGhpcyBkZXNjcmlwdGl2ZWx5Lg0KW0R1Y2t3b3J0aCwgTWFya10gSSB0aGluayBpdCB3YXMgbWVh bnQgdG8gc2F5IHRoZSBNZWRpYSBQcm92aWRlciBhbmQgTWVkaWEgQ29uc3VtZXIgbWF5IHVzZSBp bmZvcm1hdGlvbiBpbiBDTFVFIG1lc3NhZ2VzIHRvIHJlZHVjZSB0aGUgY29tcGxleGl0eSBvZiBT SVAgb2ZmZXIvYW5zd2VyIG1lc3NhZ2VzLiBXb3VsZCBpdCBiZSBtb3JlIGNsZWFyIHRvIHJlcGxh Y2UgImFsdGhvdWdoIGl0IHNob3VsZCBiZSBzdHJlc3NlZCB0aGF0IHRoZWlyIHVzZSBpbiBhbiBp bXBsZW1lbnRhdGlvbiBpcyBPUFRJT05BTCIgd2l0aCAidGhlIE1lZGlhIFByb3ZpZGVyIGFuZCBN ZWRpYSBDb25zdW1lciBtYXkgdXNlIGluZm9ybWF0aW9uIGluIENMVUUgbWVzc2FnZXMgdG8gcmVk dWNlIHRoZSBjb21wbGV4aXR5IG9mIFNJUCBvZmZlci9hbnN3ZXIgbWVzc2FnZXMiPyAgT3IgaXMg aXQgc3VwcG9zZWQgdG8gbWVhbiBzb21ldGhpbmcgZWxzZT8NCg0KPiAtNCwgbGFzdCBwYXJhZ3Jh cGg6DQo+IEkgZG9uJ3QgdGhpbmsgdGhlIDIxMTkgIlJFUVVJUkVEIiBpcyBuZWVkZWQgb3IgYXBw cm9wcmlhdGUgaGVyZS4gSXQNCj4gZG9lc24ndCBzZWVtIHRvIGFkZCBhbnl0aGluZywgYW5kIG1p Z2h0IGJlIGludGVycHJldGVkIHRvIG5vdCAgYWxsb3cNCj4gbG9jYWwgcG9saWN5IGRlY2lzaW9u cywgZXRjLg0KW0R1Y2t3b3J0aCwgTWFya10gSG93IGFib3V0IHJlcGxhY2luZyB0aGF0IGNsYXVz ZSB3aXRoICJ3aGVyZWFzIGFuIEVuZHBvaW50IG9yIE1DVSB0aGF0IGFjY2VwdHMgaXQgaXMgaW5k aWNhdGluZyBzdXBwb3J0IGZvciBDTFVFIGFzIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50IGFu ZCBpdHMgY29tcGFuaW9uIGRvY3VtZW50cyI/DQoNCj4gLTUsIHBhcmFncmFwaCA1Og0KPiBUaGUg cGFyYWdyYXBoIGRlc2NyaWJlcyB3aGF0IE1lZGlhIENhcHR1cmUgbWVhbnMsIGJ1dCBuZXZlciBy ZWFsbHkNCj4gZGVmaW5lcyB3aGF0ICJFbmNvZGluZyIgbWVhbnMuIChBbmQgdGhlIGRlZmluaXRp b24gb2YgIkVuY29kaW5nIiBpbiB0aGUNCj4gdGVybWlub2xvZ3kgc2VjdGlvbiBpcyBzb21ld2hh dCBjaXJjdWxhci4pDQpbRHVja3dvcnRoLCBNYXJrXSBFbmNvZGluZ3MgYXJlIGZ1cnRoZXIgZGVz Y3JpYmVkIGluIHNlY3Rpb24gOS4NCg0KPiAtIDUsIDNyZCBwYXJhZ3JhcGggYWZ0ZXIgRmlnIDI6 DQo+IElzbid0IHNldHRpbmcgdXAgbWVkaWEgdHJhbnNtaXNzaW9uIGEgcHJpbWFyeSBlZmZlY3Q/ DQpbRHVja3dvcnRoLCBNYXJrXSBJIHRoaW5rIHNvLiBIb3cgYWJvdXQgd2UgcmVtb3ZlIHRoZSB3 b3JkICJzaWRlIj8NCg0KPiAtNiwgdGhpcmQgYnVsbGV0Og0KPiBJdCBzZWVtcyBraW5kIG9mIG9k ZCB0byB1c2UgYSAgTVVTVCBmb3IgdGhpcywgIGdpdmVuIHRoYXQgdGhlIGNyaXRlcmlhIG9mDQo+ IHByb2Zlc3Npb25hbGx5IGluc3RhbGxlZCBpcyBzb21ld2hhdCB2YWd1ZS4gSSB0aGluayBhIG5v bi1ub3JtYXRpdmUNCj4gcmVjb21tZW5kYXRpb24gd291bGQgbWFrZSBtb3JlIHNlbnNlLg0KW0R1 Y2t3b3J0aCwgTWFya10gSXQgZG9lcyBzZWVtIG9kZC4gSSB0aGluayB0aGUgd29ya2luZyBncm91 cCBwcmV2aW91c2x5IGRpc2N1c3NlZCB0aGlzIGFuZCBkZWNpZGVkIG9uIHVzaW5nIE1VU1QuDQoN Cj4gLSA3LjEuMS43LCAiTm90ZSINCj4gV2hlcmUgYXJlIHRoZXNlIGtleXdvcmRzIGV4cGVjdGVk IHRvIGJlIGRlZmluZWQ/IFRoaXMgc2VlbXMgbGlrZSBhbg0KPiB1bmZpbmlzaGVkIHNlY3Rpb24t LWlzIGl0IGFuIG9wZW4gdG8gZG8gaXRlbT8NCltEdWNrd29ydGgsIE1hcmtdIFRoZSBkYXRhIG1v ZGVsIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgdmFsdWVzLCBhbmQgaG93IHRvIGV4dGVuZCB0aGVt Lg0KDQo+IC0gNy4xLjEuOA0KPiBXaHkgaXMgdGhpcyBsaW1pdGVkICh3aXRoIGEgTVVTVCkgdG8g dGhlc2UgZGVmaW5lZCB2YWx1ZXM/IFRoaXMgbGlzdA0KPiBhc3N1bWVzIHRyYWRpdGlvbmFsIHVz YWdlcy4gSXQgc2VlbXMgbGlrZSBhIG1vcmUgb3BlbiBsaXN0IHdvdWxkIGFsbG93DQo+IGZvciAg aW5ub3ZhdGl2ZSB1c2FnZS4gRm9yIGV4YW1wbGUsIGEgZ2FtZSBjb3VydCwgYW4gb3V0ZG9vciBz cGFjZSwgZXRjLg0KW0R1Y2t3b3J0aCwgTWFya10gQWdhaW4sIHRoZSBkYXRhIG1vZGVsIGRlc2Ny aWJlcyBob3cgdG8gZXh0ZW5kIHRoaXMgc3R1ZmYuIFdvdWxkIGl0IGJlIGJldHRlciB0byBzYXkg IlBvc3NpYmxlIHZhbHVlcyBhcmU6IiA/DQoNCj4gLSA3LjEuMS45Og0KPiBUaGlzIHNlY3Rpb24g c2VlbXMgdG8gbmVlZCBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gNTY0Ni4NCltEdWNrd29ydGgs IE1hcmtdIE9rYXksIGlzIHRoZXJlIGFueSBvYmplY3Rpb24gdG8gY2hhbmdpbmcgdGhpcyBmcm9t IGluZm9ybWF0aXZlIHRvIG5vcm1hdGl2ZT8NCg0KPiAtIDcuMS4xLjEwOiBBcmUgTE9HTywgUEhP VE8sIG9yIFNPVU5EIHRoZSBvbmx5IGtpbmRzIG9mIGxhcmdlIGNvbnRlbnQNCj4gdGhhdCBjYW4g YmUgY2FycmllZCBoZXJlPw0KPiANCj4gLTcuMS4xLjExOiBJcyB0aGUgbGlzdCBvZiBwZXJzb24g dHlwZXMgZXhoYXVzdGl2ZT8NCj4gDQo+IC03LjEuMS4xMjogSG93IGlzIHByaW9yaXR5IGludGVy cHJldGVkPyBMYXJnZXIgbnVtYmVyIGlzIGhpZ2hlciBwcmlvcml0eT8NCj4gSXMgaXQgc3RyaWN0 bHkgYSBtYXR0ZXIgb2Ygb3JkZXJpbmcsIG9yIGRvZXMgMk4gcmVwcmVzZW50IHR3aWNlIHRoZQ0K PiBwcmlvcml0eSBvZiBOPw0KW0R1Y2t3b3J0aCwgTWFya10gU2VlIENocmlzdGlhbiBHcm92ZSdz IHJlc3BvbnNlLg0KDQo+IC04LCBwYXJhZ3JhcGggYWZ0ZXIgVGFibGUgNTogIlNpbXVsdGFuZW91 cyBUcmFuc21pc3Npb24gU2V0cyBNVVNUIGFsbG93DQo+IGFsbA0KPiAgICB0aGUgbWVkaWEgQ2Fw dHVyZXMgaW4gYW55IHBhcnRpY3VsYXIgQ2FwdHVyZSBTY2VuZSBWaWV3Li4uIg0KPiANCj4gVGhp cyBzZWVtcyB0byByZXZlcnNlIHRoZSBjYXVzYWxpdHkuIFNpbmNlIHRoZSBzaW11bHRhbmVvdXMg dHJhbnNtaXNzaW9uDQo+IHNldCBpcyBiYXNlZCBvbiBwaHlzaWNhbCBsaW1pdHMsIHNob3VsZG4n dCBpdCBzYXkgdGhhdCBhbnkgcGFydGljdWxhciBDU1YNCj4gTVVTVCByZXNwZWN0IHRoZSBsaW1p dGF0aW9ucyBpbiB0aGUgc2ltdWx0YW5lb3VzIHRyYW5zbWlzc2lvbiBzZXRzPyAoU2FtZQ0KPiBm b3IgR2xvYmFsIFZpZXcpLg0KW0R1Y2t3b3J0aCwgTWFya10gVGhlIHBvaW50IGlzbid0IGFib3V0 IGNhdXNhbGl0eSwgaXQgaXMganVzdCBzYXlpbmcgdGhlIHR3byBoYXZlIHRvIGJlIG11dHVhbGx5 IGNvbnNpc3RlbnQuDQoNCj4gLSAxNSwgMm5kIHBhcmFncmFwaDoNCj4gSSB0aGluayB0aGlzIHJl cXVpcmVzIDUyMzkgdG8gYmUgYSBub3JtYXRpdmUgcmVmZXJlbmNlLg0KW0R1Y2t3b3J0aCwgTWFy a10gT2theSwgaXMgdGhlcmUgYW55IG9iamVjdGlvbiB0byBjaGFuZ2luZyB0aGlzIGZyb20gaW5m b3JtYXRpdmUgdG8gbm9ybWF0aXZlPw0KDQo+IC0xNSwgcGFyYWdhcGggNDogIkRUTFMvU1JUUCBN VVNUIGJlIHN1cHBvcnRlZCBhbmQgU0hPVUxEIGJlIHVzZWQNCj4gdW5sZXNzDQo+IHRoZSBtZWRp YSwgd2hpY2ggaXMgYmFzZWQgb24gUlRQLCBpcyBzZWN1cmVkIGJ5IG90aGVyIG1lYW5zLi4uIg0K PiBJcyAic2VjdXJlZCBieSBvdGhlciBtZWFucyIgaW50ZW5kZWQgdG8gYmUgdGhlIHNvbGUgZXhj ZXB0aW9uPyBJZiBzbywNCj4gdGhlbiB0aGlzIG1pZ2h0IHNob3VsZCBzYXkgTVVTVCAuLi4gdW5s ZXNzIi4gQXMgZGVmaW5lZCBpbiAyMTE5LCBhIFNIT1VMRA0KPiB3b3VsZCBhbGxvdyBhbiBpbXBs ZW1lbnRhdGlvbiB0byBza2lwIHRoZSBwcm90ZWN0aW9uIGZvciBvdGhlciByZWFzb25zLA0KPiBp ZiB0aGUgaW1wbGVtZW50ZXIgd2FzIGF3YXJlIG9mIHRoZSBpbXBsaWNhdGlvbnMsIGV0Yy4uLg0K PiBBbHNvLCBzaG91bGQgdGhlIHJlZmVyZW5jZXMgdG8gNzIwMSBhbmQgNzIwMiBiZSBub3JtYXRp dmU/DQpbRHVja3dvcnRoLCBNYXJrXSBJIGRvbid0IGtub3cuIERvZXMgYW55Ym9keSBlbHNlIGhh dmUgYSBzdWdnZXN0aW9uIGFib3V0IHRoaXM/DQoNCj4gPT09IEVkaXRvcmlhbCA9PT0NCj4gDQo+ IC0gRmlndXJlIDI6DQo+IEJ5IFNEUCBNZWRpYSBTZXNzaW9uIHlvdSBtZWFuIGFuIFJUUCBzZXNz aW9uIGFzIGRlc2NyaWJlZCBieSB0aGUgYmFzaWMNCj4gU0RQIHJpZ2h0PyBUaGF0IGlzIG5vdCBh biBTRFAgc2Vzc2lvbiBwZXIgc2UuDQpbRHVja3dvcnRoLCBNYXJrXSBJIHRoaW5rIHRoZSBkaWFn cmFtIHNob3VsZCBzYXkgIkJBU0lDIE1FRElBIFNFU1NJT04iLCBhbmQgIlVQREFURUQgTUVESUEg U0VTU0lPTiIuIFRoaXMgd291bGQgYmUgY29uc2lzdGVudCB3aXRoIHRoZSB0ZXh0IGltbWVkaWF0 ZWx5IGFmdGVyIHRoZSBmaWd1cmUgdGhhdCBzYXlzICJBbiBpbml0aWFsIG9mZmVyL2Fuc3dlciBl eGNoYW5nZSBlc3RhYmxpc2hlcyBhIGJhc2ljIG1lZGlhIHNlc3Npb24uLi4iIEFueSBvYmplY3Rp b25zPw0KDQo+IC01LCB0aGlyZCBwYXJhZ3JhcGggZnJvbSBlbmQ6DQo+IFBsZWFzZSBhdm9pZCAy MTE5IGtleXdvcmRzIGluc2lkZSBwYXJlbnRoZXRpY2FsIHBocmFzZXMuIEFsc28sIGl0J3MNCj4g cmVkdW5kYW50IHRvIHNheSBpbXBsZW1lbnRhdGlvbnMgb2YgYSBwcm90b2NvbCBNVVNUIGZvbGxv dyB0aGUgcHJvdG9jb2wNCj4gOi0pDQpbRHVja3dvcnRoLCBNYXJrXSBIb3cgYWJvdXQgY2hhbmdl IHRoZSBwaHJhc2UgdG8gIiAoYWx0aG91Z2ggdGhlIENvbnN1bWVyIGZvbGxvd3MgdGhlIENMVUUg cHJvdG9jb2wgYW5kLCB0aGVyZWZvcmUsIGdyYWNlZnVsbHkgcmVjZWl2ZXMgYW5kIHJlc3BvbmRz ICh0aHJvdWdoIGEgQ29uZmlndXJlKSB0byB0aGUgUHJvdmlkZXIncyBpbmZvcm1hdGlvbikiID8N Cg0K From nobody Tue Dec 22 15:19:14 2015 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 110571A92F2; Tue, 22 Dec 2015 15:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.534 X-Spam-Level: * X-Spam-Status: No, score=1.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, T_DKIM_INVALID=0.01] 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 NaTbPGas_Zvp; Tue, 22 Dec 2015 15:19:09 -0800 (PST) Received: from msh03.myshophosting.com (fw01.ch31995.smartservers.com.au [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 3B3991A92EE; Tue, 22 Dec 2015 15:19:09 -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:Cc:References:To:Subject; bh=bXFZCRPZg+ZeupDF2Z3oMb34OPckP/FJMI7fWVH+Y7Q=; b=patfVviN/op97SehSqglBT93Qh zMcvCW5Bp4p4vjgFkeiH2UVMm70ff6CM/JU8Q24OqXB/mDODIWFTJoZEKsbJ1rYsj2oUMYQ9nfP+/ yL+yuN1BCcEztTN1ShK3I3rTeAhWUyEMm3SepYICpqr1q9xgrrZO/kskfT/A7PTpkakGOep+h/Nbb aBpLepb/+/bDbpK5FatShXBdqEOLSQ0gOZtlil1ogUGWXi8OtSQJ50qYttz028GOfClWLrBpi2Mxn xvM7gE8SrAj9Gq4WTdw9vcm1RbEK5lmPq33EodiVtTcY1NZ5BrvPkpOWldExlO3ulf0h9jUYGsN7y ca72EPgA==; Received: from ppp118-209-109-182.lns20.mel4.internode.on.net ([118.209.109.182]:63431 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1aBWCt-003Nu3-5S; Wed, 23 Dec 2015 10:19:03 +1100 To: "Duckworth, Mark" , Ben Campbell , "clue@ietf.org" References: <20151215225655.19408.56476.idtracker@ietfa.amsl.com> <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F3AB@CRPMBOXPRD08.polycom.com> From: Christian Groves Message-ID: <5679DA62.4020408@nteczone.com> Date: Wed, 23 Dec 2015 10:18:58 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F3AB@CRPMBOXPRD08.polycom.com> 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: Cc: "clue-chairs@ietf.org" , "draft-ietf-clue-framework@ietf.org" , The IESG Subject: Re: [clue] Ben Campbell's Yes on draft-ietf-clue-framework-24: (with COMMENT) 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, 22 Dec 2015 23:19:12 -0000 Hello Mark, Some comments below on your replies. Regards, Christian On 23/12/2015 5:16 AM, Duckworth, Mark wrote: > Hello Ben, > Thanks for the feedback. > I have a few more responses to your comments below. > Mark > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Tuesday, December 15, 2015 5:57 PM >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I have some minor comments. These should be easy to resolve, and I don't >> think any are show-stoppers. >> >> === Subtantive === >> >> - Section 3, MCU definition. >> Does this need a normative reference to 4353? I'm not sure the definition >> can be understood as written without reading it. > [Duckworth, Mark] I don't know. Is there any objection to making RFC4353 a normative reference? [CNG] I'm not sure its appropriate. The definition says "RFC4353-like" (doesn't sound particularly normative) and says then indicates that the MCU is without a RFC4353. Again its not normatively saying to use it. Just because the reference is information doesn't mean a person shouldn't read it if they're unfamiliar with it. > >> - 4, paragraph (5): >> The 2119 "OPTIONAL" is vague about what it applies to. Use of companion >> protocols? Consider stating this descriptively. > [Duckworth, Mark] I think it was meant to say the Media Provider and Media Consumer may use information in CLUE messages to reduce the complexity of SIP offer/answer messages. Would it be more clear to replace "although it should be stressed that their use in an implementation is OPTIONAL" with "the Media Provider and Media Consumer may use information in CLUE messages to reduce the complexity of SIP offer/answer messages"? Or is it supposed to mean something else? > >> -4, last paragraph: >> I don't think the 2119 "REQUIRED" is needed or appropriate here. It >> doesn't seem to add anything, and might be interpreted to not allow >> local policy decisions, etc. > [Duckworth, Mark] How about replacing that clause with "whereas an Endpoint or MCU that accepts it is indicating support for CLUE as specified in this document and its companion documents"? > >> -5, paragraph 5: >> The paragraph describes what Media Capture means, but never really >> defines what "Encoding" means. (And the definition of "Encoding" in the >> terminology section is somewhat circular.) > [Duckworth, Mark] Encodings are further described in section 9. > >> - 5, 3rd paragraph after Fig 2: >> Isn't setting up media transmission a primary effect? > [Duckworth, Mark] I think so. How about we remove the word "side"? > >> -6, third bullet: >> It seems kind of odd to use a MUST for this, given that the criteria of >> professionally installed is somewhat vague. I think a non-normative >> recommendation would make more sense. > [Duckworth, Mark] It does seem odd. I think the working group previously discussed this and decided on using MUST. [CNG] The MUST relates to systems that know their physical dimensions providing them in an Advertisement rather than relating to professionally installed systems. We could strike the "(for example professionally installed Telepresence room systems)" if that's causing a problem. > >> - 7.1.1.7, "Note" >> Where are these keywords expected to be defined? This seems like an >> unfinished section--is it an open to do item? > [Duckworth, Mark] The data model document describes the values, and how to extend them. > >> - 7.1.1.8 >> Why is this limited (with a MUST) to these defined values? This list >> assumes traditional usages. It seems like a more open list would allow >> for innovative usage. For example, a game court, an outdoor space, etc. > [Duckworth, Mark] Again, the data model describes how to extend this stuff. Would it be better to say "Possible values are:" ? > >> - 7.1.1.9: >> This section seems to need a normative reference to 5646. > [Duckworth, Mark] Okay, is there any objection to changing this from informative to normative? [CNG] That's OK for me. > >> - 7.1.1.10: Are LOGO, PHOTO, or SOUND the only kinds of large content >> that can be carried here? >> >> -7.1.1.11: Is the list of person types exhaustive? >> >> -7.1.1.12: How is priority interpreted? Larger number is higher priority? >> Is it strictly a matter of ordering, or does 2N represent twice the >> priority of N? > [Duckworth, Mark] See Christian Grove's response. > >> -8, paragraph after Table 5: "Simultaneous Transmission Sets MUST allow >> all >> the media Captures in any particular Capture Scene View..." >> >> This seems to reverse the causality. Since the simultaneous transmission >> set is based on physical limits, shouldn't it say that any particular CSV >> MUST respect the limitations in the simultaneous transmission sets? (Same >> for Global View). > [Duckworth, Mark] The point isn't about causality, it is just saying the two have to be mutually consistent. > >> - 15, 2nd paragraph: >> I think this requires 5239 to be a normative reference. > [Duckworth, Mark] Okay, is there any objection to changing this from informative to normative? [CNG] OK > >> -15, paragaph 4: "DTLS/SRTP MUST be supported and SHOULD be used >> unless >> the media, which is based on RTP, is secured by other means..." >> Is "secured by other means" intended to be the sole exception? If so, >> then this might should say MUST ... unless". As defined in 2119, a SHOULD >> would allow an implementation to skip the protection for other reasons, >> if the implementer was aware of the implications, etc... >> Also, should the references to 7201 and 7202 be normative? > [Duckworth, Mark] I don't know. Does anybody else have a suggestion about this? [CNG] I think the wording around this was discussed for awhile and what's in the framework was the compromise we came up with, i.e. "Its a really good idea to secure the media using SRTP-DTLS, but we can't force you if you have a reason not to". > >> === Editorial === >> >> - Figure 2: >> By SDP Media Session you mean an RTP session as described by the basic >> SDP right? That is not an SDP session per se. > [Duckworth, Mark] I think the diagram should say "BASIC MEDIA SESSION", and "UPDATED MEDIA SESSION". This would be consistent with the text immediately after the figure that says "An initial offer/answer exchange establishes a basic media session..." Any objections? [CNG] OK > >> -5, third paragraph from end: >> Please avoid 2119 keywords inside parenthetical phrases. Also, it's >> redundant to say implementations of a protocol MUST follow the protocol >> :-) > [Duckworth, Mark] How about change the phrase to " (although the Consumer follows the CLUE protocol and, therefore, gracefully receives and responds (through a Configure) to the Provider's information)" ? > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Dec 22 15:35:38 2015 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 12B901AC3CF; Tue, 22 Dec 2015 15:35:34 -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 sAZUkZ80lM51; Tue, 22 Dec 2015 15:35:32 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.195]) (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 00E041AC3CE; Tue, 22 Dec 2015 15:35:31 -0800 (PST) Received: from [216.82.242.36] by server-3.bemta-8.messagelabs.com id 99/1B-03824-24ED9765; Tue, 22 Dec 2015 23:35:30 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-3.tower-94.messagelabs.com!1450827329!14906462!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 126422 invoked from network); 22 Dec 2015 23:35:30 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-3.tower-94.messagelabs.com with AES128-SHA encrypted SMTP; 22 Dec 2015 23:35:30 -0000 Received: from PWEHUB01.polycom.com (10.236.2.221) by crpehubprd02.polycom.com (10.236.0.154) with Microsoft SMTP Server (TLS) id 8.3.389.2; Tue, 22 Dec 2015 15:35:29 -0800 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.113]) by PWEHUB01.polycom.com ([::1]) with mapi; Tue, 22 Dec 2015 15:35:29 -0800 From: "Duckworth, Mark" To: Spencer Dawkins Date: Tue, 22 Dec 2015 15:35:27 -0800 Thread-Topic: Spencer Dawkins' Yes on draft-ietf-clue-framework-24: (with COMMENT) Thread-Index: AdE4M/DGhysWmDUWQeuaNeL+kxdAyQE2qzNQ Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F413@CRPMBOXPRD08.polycom.com> References: <20151216185846.25360.72739.idtracker@ietfa.amsl.com> In-Reply-To: <20151216185846.25360.72739.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "clue-chairs@ietf.org" , "draft-ietf-clue-framework@ietf.org" , "clue@ietf.org" , The IESG Subject: Re: [clue] Spencer Dawkins' Yes on draft-ietf-clue-framework-24: (with COMMENT) 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, 22 Dec 2015 23:35:34 -0000 SGVsbG8gU3BlbmNlciwNClRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb25zLiBJIGhhdmUgc29tZSBy ZXNwb25zZXMgYmVsb3cuDQpNYXJrDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogU3BlbmNlciBEYXdraW5zIFttYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5j b21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTYsIDIwMTUgMTo1OSBQTQ0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEkgcmVtZW1iZXIg dGhlIGZpcnN0IGNvdXBsZSBvZiB5ZWFycyBvZiBDTFVFLiBUaGlzIHdhcyB3b3J0aCB3cml0aW5n Lg0KPiANCj4gSSdtIGEgWWVzLCBidXQgZGlkIGhhdmUgc29tZSBlZGl0b3JpYWwgc3VnZ2VzdGlv bnMgYW5kIHF1ZXN0aW9ucy4NCj4gDQo+IEluIFNlY3Rpb24gMS4gSW50cm9kdWN0aW9uLA0KPiAN Cj4gICAgQ3VycmVudCB0ZWxlcHJlc2VuY2Ugc3lzdGVtcywgdGhvdWdoIGJhc2VkIG9uIG9wZW4g c3RhbmRhcmRzIHN1Y2gNCj4gICAgYXMgUlRQIFtSRkMzNTUwXSBhbmQgU0lQIFtSRkMzMjYxXSwg Y2Fubm90IGVhc2lseSBpbnRlcm9wZXJhdGUgd2l0aA0KPiAgICBlYWNoIG90aGVyLg0KPiANCj4g dGhpcyB0ZXh0IGhhc24ndCBjaGFuZ2VkIHNpbmNlIHRoZSAwMCBpbmRpdmlkdWFsIGRyYWZ0IGZy b20gMjAxMi4gSXMgaXQNCj4gc3RpbGwgdHJ1ZSBmb3IgImN1cnJlbnQiIHRlbGVwcmVzZW5jZSBz eXN0ZW1zPw0KW0R1Y2t3b3J0aCwgTWFya10gWWVzLg0KDQo+IEluIHRoaXMgdGV4dDoNCj4gDQo+ ICAgIElmIHRoZSBwaHlzaWNhbCBzcGFjZSBkb2VzIG5vdA0KPiAgICBoYXZlIGEgd2VsbC1kZWZp bmVkIGZyb250IGFuZCBiYWNrLCB0aGUgcHJvdmlkZXIgY2hvb3NlcyBhbnkNCj4gICAgZGlyZWN0 aW9uIGZvciBYIGFuZCBZIGNvbnNpc3RlbnQgd2l0aCByaWdodC1oYW5kZWQgY29vcmRpbmF0ZXMu DQo+IA0KPiBpcyB0aGVyZSBhbnkgcmVmZXJlbmNlL3BvaW50ZXIgeW91IGNvdWxkIHByb3ZpZGUg dG8gYSBkZWZpbml0aW9uIG9mDQo+ICJjb25zaXN0ZW50IHdpdGggcmlnaHQtaGFuZGVkIGNvb3Jk aW5hdGVzIj8gSWYgZXZlcnlvbmUgdW5kZXJzdGFuZHMgdGhhdA0KPiBidXQgbWUsIHBsZWFzZSBp Z25vcmUgdGhpcyBjb21tZW50IC4uLg0KW0R1Y2t3b3J0aCwgTWFya10gSSB0aGluayBaIHNob3Vs ZCBiZSBpbmNsdWRlZCwgc28gIi4uLiBhbnkgZGlyZWN0aW9uIGZvciBYIGFuZCBZIGFuZCBaIGNv bnNpc3RlbnQgd2l0aCByaWdodC1oYW5kZWQgY29vcmRpbmF0ZXMuIiBJIHRoaW5rIHJpZ2h0LWhh bmRlZCBjb29yZGluYXRlcyBpcyBhIHdlbGwta25vd24gdGhpbmcuDQoNCj4gSXMgImxpbmUgb2Yg Y2FwdHVyZSIgYSBtZWFuaW5nZnVsIGNvbmNlcHQgb24gaXRzIG93bj8gT3IgaXMgaXQgb25seQ0K PiBtZWFuaW5nZnVsIGFzICJwb2ludCBvbiBsaW5lIG9mIGNhcHR1cmUiPw0KPiANCj4gSSB3b25k ZXIgaWYgaXQgd291bGQgYmUgbGVzcyBjb25mdXNpbmcgaWYgeW91IGFsd2F5cyBjYWxsZWQgInZv bHVtZSBvZg0KPiBjYXB0dXJlIiAiMy1EIHZvbHVtZSBvZiBjYXB0dXJlIi4gSSB3YXMgY29uc2lz dGVudGx5IGFzc3VtaW5nICJ2b2x1bWUiDQo+IHdhcyBhbiBhdWRpbyB0aGluZywgd2hlbiBJIHNh dyAidm9sdW1lIG9mIGNhcHR1cmUiIHdpdGggbm8gcXVhbGlmaWVyLiBZb3UNCj4gZGVmaW5lIGl0 IGFzICIzIGRpbWVudGlvbmFsIHZvbHVtZSBvZiBjYXB0dXJlIiwgYnV0IHRoZW4gZHJvcCB0aGF0 DQo+IHF1YWxpZmllciBpbiBzdWJzZXF1ZW50IHVzZS4NCltEdWNrd29ydGgsIE1hcmtdIEl0IGlz IG1lbnRpb25lZCBvbmx5IHdpdGhpbiBhIHNpbmdsZSBwYXJhZ3JhcGgsIHNvIGl0IHNlZW1zIGNs ZWFyIHRvIG1lLiBPciBpZiB5b3UgdGhpbmsgaXQgcmVhbGx5IG5lZWRzIG1vcmUgY2xhcml0eSwg d2UgY291bGQgY2FsbCBpdCAic3BhdGlhbCB2b2x1bWUiIGluc3RlYWQgb2YganVzdCAidm9sdW1l Ii4NCg0KPiBJcyBQZXJzb24gVHlwZSBqdXN0IGEgc3RyaW5nIGZvciBwcmVzZW50YXRpb24/IElm IHNvLCB0aGF0J3MgZmluZSwgYnV0DQo+IHRoZSBmcmFtZXdvcmsgZGVmaW5lcyA4IHR5cGVzIGlu IHNvbWUgZGV0YWlsLCBhbmQgbm90ZXMgdGhhdCB0aGlzIGxpc3QNCj4gaXNuJ3QgZXhoYXVzdGl2 ZSBhbmQgdGhhdCBjdXN0b20gcGVyc29uIHR5cGVzIGNhbiBiZSBkZWZpbmVkLCBzbyBJIHdvbmRl cg0KPiBpZiB0aGVyZSdzIGFueSBleHBlY3RhdGlvbiB0aGF0IENMVUUgd2lsbCBkbyBhbnl0aGlu ZyBzcGVjaWZpYywgYmFzZWQgb24NCj4gUGVyc29uIFR5cGUuDQo+IA0KPiBQSVAgaXNuJ3QgZXhw YW5kZWQgdW50aWwgaXRzIDV0aCB1c2UgKGlmIEknbSByZWFkaW5nIGNvcnJlY3RseSkuIEknbQ0K PiBndWVzc2luZyB0aGF0IFBpUHMgaXMgdGhlIHBsdXJhbCBvZiBQaVAsIGJ1dCB0aGF0J3MgYSBn dWVzcywgYW5kIEkNCj4gd291bGRuJ3QgbWluZCBhIHdvcmQgb3IgdHdvIG9mIGV4cGxhbmF0aW9u IGFib3V0IHRoYXQuICJUaWxlZCIgaXMNCj4gcHJvYmFibHkgYSB0ZXJtIG9mIGFydCwgc28gbWF5 YmUgaXQgZG9lc24ndCBuZWVkIGFuIGV4cGxhbmF0aW9uLCBidXQgaXQncw0KPiBub3QgY2xlYXIg d2hldGhlciAidGlsZWQiIGFuZCAiUGlQIiBhcmUgdGhlIHNhbWUgdGhpbmcgb3Igbm90ICh3aGlj aA0KPiB3b3VsZCBiZSBhIGdvb2QgdGhpbmcgdG8gaW5jbHVkZSBpbiBhbiBleHBsYW5hdGlvbiwg aWYgeW91IGFkZCBvbmUpLg0KW0R1Y2t3b3J0aCwgTWFya10gV2UgY2FuIGFkZCAiUGljdHVyZSBp biBQaWN0dXJlIiBhdCB0aGUgZmlyc3QgdXNlLCBhbmQgbWFrZSB0aGVtIGFsbCBjb25zaXN0ZW50 bHkgIlBpUCIgaW5zdGVhZCBvZiBzb21ldGltZXMgIlBJUCIuICBZZXMsIFBpUHMgaXMgdGhlIHBs dXJhbC4gV2hlbiB0aWxlZCBpcyBtZW50aW9uZWQgaXQgaXMgYWJvdXQgRW5kcG9pbnQgQSwgd2hp Y2ggaXMgc2hvd24gZGlhZ3JhbW1hdGljYWxseSBpbiBGaWd1cmUgOCBzbyBJIHRoaW5rIGl0IHNo b3VsZCBiZSBjbGVhci4NCg== From nobody Tue Dec 22 15:50:52 2015 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 6E32A1AC40A; Tue, 22 Dec 2015 15:50:51 -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 JxvtB-wFNAI2; Tue, 22 Dec 2015 15:50:50 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.194]) (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 9873C1AC409; Tue, 22 Dec 2015 15:50:49 -0800 (PST) Received: from [216.82.241.100] by server-2.bemta-8.messagelabs.com id 47/36-18064-8D1E9765; Tue, 22 Dec 2015 23:50:48 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-220.messagelabs.com!1450828247!18661958!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12716 invoked from network); 22 Dec 2015 23:50:48 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-9.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 22 Dec 2015 23:50:48 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.113]) by Crpehubprd01.polycom.com ([::1]) with mapi; Tue, 22 Dec 2015 15:50:47 -0800 From: "Duckworth, Mark" To: Stephen Farrell , The IESG Date: Tue, 22 Dec 2015 15:50:45 -0800 Thread-Topic: Stephen Farrell's No Objection on draft-ietf-clue-framework-24: (with COMMENT) Thread-Index: AdE4ykddbypNqHMUQ92EMHdPU1GW1QER8MXw Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F414@CRPMBOXPRD08.polycom.com> References: <20151217125527.4771.42784.idtracker@ietfa.amsl.com> In-Reply-To: <20151217125527.4771.42784.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "clue-chairs@ietf.org" , "draft-ietf-clue-framework@ietf.org" , "clue@ietf.org" Subject: Re: [clue] Stephen Farrell's No Objection on draft-ietf-clue-framework-24: (with COMMENT) 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, 22 Dec 2015 23:50:51 -0000 SGVsbG8gU3RlcGhlbiwNCkkgaGF2ZSBhIGZldyByZXNwb25zZXMgYmVsb3cuDQpNYXJrDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWls dG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0NCj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVy IDE3LCAyMDE1IDc6NTUgQU0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IA0KPiBUaGFua3MgZm9yIGEgcHJldHR5IGNvbXByZWhlbnNpdmUgZGVzY3JpcHRp b24uIFRoZXNlIHNvdW5kIGxpa2UNCj4gZnVuIHN5c3RlbXMgb24gd2hpY2ggdG8gd29yay4NCj4g DQo+IFBpdHkgdGhlcmUgYXJlIHNvIG1hbnkgSVBSIGRlY2xhcmF0aW9ucyB3aXRoIG5vdCBncmVh dCB0ZXJtcyBhbmQNCj4gZm9yIHNvbWV0aGluZyB0aGF0IHRvIG1lIGF0IGxlYXN0IGRvZXNuJ3Qg YXBwZWFyIHRvIHJlcXVpcmUNCj4gaW52ZW50aW9uIChqdXN0IGNvbnN0cnVjdGlvbiBvZiBleGlz dGluZyBiaXRzKSBidXQgSSBndWVzcyB0aGF0J3MNCj4gdGhlIHdvcmxkIHdlIGxpdmUgaW4gYW5k IHRoZSBXRyB3ZXJlIG9rIHdpdGggdGhhdC4NCj4gDQo+IC0gNy4xLjEuMyAtIEkgd29uZGVyZWQg aWYgdGhlICJNVVNUIGJlIGNvLXBsYW5hciIgcmVxdWlyZW1lbnQNCj4gY291bGQgY2F1c2UgaXNz dWVzIChidWdzKSBpZiByZWNlaXZlcnMgZG9uJ3QgY2hlY2sgZm9yIHRoYXQuIEFyZQ0KPiByZWNl aXZlcnMgZXhwZWN0ZWQgdG8gdmVyaWZ5IHRoYXQgb24gcmVjZWlwdCBvciBpcyB0aGUgTVVTVCBv bmx5DQo+IGZvciBzZW5kZXJzPw0KW0R1Y2t3b3J0aCwgTWFya10gRXZlcnl0aGluZyBpbiBhbiBh ZHZlcnRpc2VtZW50IGNvdWxkIGNhdXNlIGlzc3VlcyAoYnVncykgaWYgdGhlIFByb3ZpZGVyIHB1 dHMgaW5jb3JyZWN0IGluZm9ybWF0aW9uIGluIGl0LiBUaGVyZSBhcmUgbWFueSBwb3NzaWJsZSB3 YXlzIGFuIGFkdmVydGlzZW1lbnQgY2FuIGJlIGludGVybmFsbHkgaW5jb25zaXN0ZW50LiBJbiB0 aGUgQ0xVRSBwcm90b2NvbCBkb2N1bWVudCBpdCBkZWZpbmVzIGEgIkNvbmZsaWN0aW5nIHZhbHVl cyIgZXJyb3IgY29kZSwgd2hpY2ggYSBtZXNzYWdlIHJlY2lwaWVudCBjYW4gc2VuZCBiYWNrIHRv IHRoZSBzZW5kZXIgaWYgdGhlIHJlY2lwaWVudCBkZXRlY3RzIGFuIGVycm9yIGluIHRoZSBtZXNz YWdlLg0KDQo+IC0gNy4xLjEuMTA6IHByaXZhY3kgaXNzdWVzIGFib3VuZCwgYnV0IHNlY3Rpb24g MTUgb25seSByZWZlcnMgdG8NCj4gdGhlIGNvbW11bmljYXRpb25zIHNlY3VyaXR5IGFzcGVjdC4g SSB0aGluayB5b3Ugb3VnaHQgcmVjb21tZW5kDQo+IHRoYXQgaW1wbGVtZW50YXRpb25zIFNIT1VM RCBtaW5pbWlzZSB0aGUgaW5mb3JtYXRpb24gc2VudCwgYW5kDQo+IFNIT1VMRCBnaXZlIHVzZXJz IGNvbnRyb2wgb3ZlciB3aGF0IGlzIHNlbnQuIFlvdSBtaWdodCB3YW50IHRvDQo+IG5vdGUgdGhl IHV0aWxpdHkgb2Ygc2VuZGluZyB0aGUgc2FtZSBzdWJzZXQgb2YgaW5mb3JtYXRpb24gZm9yDQo+ IHJlZ3VsYXIgcmVwZWF0ZWQgY2FsbHMgYnV0IEknbSBub3Qgc3VyZSB3aGF0IGNsdWUgcHJvdG9j b2wgbWlnaHQNCj4ga25vdyB0aGF0IGNhbGxzIGFyZSByZXBlYXRzIG9yIGlmIHRoZXJlJ3MgYSBi ZXR0ZXIgd2F5IHRvIG1hbmFnZQ0KPiByZS11c2Ugb2YgcHJpdmFjeSBzZXR0aW5ncyBmb3IgdXNl cnMuDQpbRHVja3dvcnRoLCBNYXJrXSBJIG1ha2VzIHNlbnNlIHRvIG1lIHRvIGFkZCBhIHN0YXRl bWVudCBsaWtlICJhbiBpbXBsZW1lbnRhdGlvbiBTSE9VTEQgZ2l2ZSB1c2VycyBjb250cm9sIG92 ZXIgd2hhdCBzZW5zaXRpdmUgaW5mb3JtYXRpb24gaXMgc2VudCBpbiBhbiBBZHZlcnRpc2VtZW50 LiIgQnV0IEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIHNheSAiU0hPVUxEIG1pbmltaXplIHRoZSBp bmZvcm1hdGlvbiBzZW50IiwgYmVjYXVzZSB0aGF0IHdvdWxkIGRlZmVhdCB0aGUgcHVycG9zZSBv ZiBpbmNsdWRpbmcgdGhhdCBpbmZvcm1hdGlvbiBpbiB0aGUgcHJvdG9jb2wgaW4gdGhlIGZpcnN0 IHBsYWNlLg0KDQo+IC0gVGhlIHNlY2RpciByZXZpZXcgWzFdIG5vdGVkIHNvbWUgaXNzdWVzIHRo YXQgbWF5IGJlIHdvcnRoDQo+IGNvbnNpZGVyaW5nIGZvciBsYXRlciBXRyBkb2N1bWVudHMuIEkn ZCBlbmNvdXJhZ2UgZm9sa3MgdG8gdHJ5DQo+IGdldCBpbiB0b3VjaCB3aXRoIHRoZSByZXZpZXdl ciB3aGVuIGRvaW5nIGxhdGVyIHdvcmsgYXMgdGhhdA0KPiBtaWdodCBhdm9pZCBzb21lIGxhdGUt c3VycHJpc2VzLiAoVGhhdCBpcyBub3QgYSB0aHJlYXQgYnR3LCBqdXN0DQo+IGVuY291cmFnZW1l bnQgdG8gdHJ5IHRha2UgYWR2YW50YWdlIG9mIGEgcmV2aWV3ZXIgd2hvIGxpa2VzIHRvDQo+IGNv bnNpZGVyIG1vcmUgdGhhbiBqdXN0IHdoYXQncyBpbiBmcm9udCBvZiBoaW0gdG9kYXk6LSkNCj4g DQo+ICAgIFsxXSBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NlY2Rpci9j dXJyZW50L21zZzA2MjQ0Lmh0bWwNCj4gDQoNCg== From nobody Tue Dec 22 15:57:53 2015 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 13BF21AC424; Tue, 22 Dec 2015 15:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1ixF-1WwbNxK; Tue, 22 Dec 2015 15:57:50 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7A41AC3FF; Tue, 22 Dec 2015 15:57:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2622EBE7C; Tue, 22 Dec 2015 23:57:48 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPghGRUtoewq; Tue, 22 Dec 2015 23:57:46 +0000 (GMT) Received: from [10.87.48.83] (unknown [86.46.22.208]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EA8D1BE64; Tue, 22 Dec 2015 23:57:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450828666; bh=GHG1LWqCf4ILDEuu6ly/Kl2q+AC1vBA4p+LpjZHATEI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=T+K3huK5hY0ZfA0sAEO/VB566u1m/WTzm1Slw50McMhBiCs1obPzdGt9e7DfakFVG L6pgHgkXjJKYH4R5ncI8y9vJXFhB/rQITu5avC2X6nSx5ASbBVv1ZavysZV6JLHk4K ozqF6Llp6ZtR7fvaSJxudcPxgQhEN8VMo+pUux54= To: "Duckworth, Mark" , The IESG References: <20151217125527.4771.42784.idtracker@ietfa.amsl.com> <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F414@CRPMBOXPRD08.polycom.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5679E379.1040306@cs.tcd.ie> Date: Tue, 22 Dec 2015 23:57:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F414@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "clue-chairs@ietf.org" , "draft-ietf-clue-framework@ietf.org" , "clue@ietf.org" Subject: Re: [clue] Stephen Farrell's No Objection on draft-ietf-clue-framework-24: (with COMMENT) 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, 22 Dec 2015 23:57:53 -0000 Hiya, On 22/12/15 23:50, Duckworth, Mark wrote: > Hello Stephen, I have a few responses below. Mark > >> -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, December 17, >> 2015 7:55 AM >> ---------------------------------------------------------------------- >> >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> Thanks for a pretty comprehensive description. These sound like >> fun systems on which to work. >> >> Pity there are so many IPR declarations with not great terms and >> for something that to me at least doesn't appear to require >> invention (just construction of existing bits) but I guess that's >> the world we live in and the WG were ok with that. >> >> - 7.1.1.3 - I wondered if the "MUST be co-planar" requirement could >> cause issues (bugs) if receivers don't check for that. Are >> receivers expected to verify that on receipt or is the MUST only >> for senders? > [Duckworth, Mark] Everything in an advertisement could cause issues > (bugs) if the Provider puts incorrect information in it. There are > many possible ways an advertisement can be internally inconsistent. > In the CLUE protocol document it defines a "Conflicting values" error > code, which a message recipient can send back to the sender if the > recipient detects an error in the message. Fair enough. OTOH, I'm still no clearer if the spec is calling for the MUST to be enforced by recipients or not. Don't you think the document ought say that explicitly? I do, FWIW. > >> - 7.1.1.10: privacy issues abound, but section 15 only refers to >> the communications security aspect. I think you ought recommend >> that implementations SHOULD minimise the information sent, and >> SHOULD give users control over what is sent. You might want to note >> the utility of sending the same subset of information for regular >> repeated calls but I'm not sure what clue protocol might know that >> calls are repeats or if there's a better way to manage re-use of >> privacy settings for users. > [Duckworth, Mark] I makes sense to me to add a statement like "an > implementation SHOULD give users control over what sensitive > information is sent in an Advertisement." Great. > But I don't think we should > say "SHOULD minimize the information sent", because that would defeat > the purpose of including that information in the protocol in the > first place. I disagree fwiw, but that may be down to different interpretations of what minimise means. To me, it means "only send what's needed to get what you want to happen" and "as a receiver, don't expect senders to include information you don't really need." Taking that meaning, I'm not sure how one could really oppose data minimisation and be privacy friendly tbh. Cheers, S. > >> - The secdir review [1] noted some issues that may be worth >> considering for later WG documents. I'd encourage folks to try get >> in touch with the reviewer when doing later work as that might >> avoid some late-surprises. (That is not a threat btw, just >> encouragement to try take advantage of a reviewer who likes to >> consider more than just what's in front of him today:-) >> >> [1] >> https://www.ietf.org/mail-archive/web/secdir/current/msg06244.html >> > From nobody Tue Dec 22 18:43:14 2015 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 B55971A90B4; Tue, 22 Dec 2015 18:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.534 X-Spam-Level: * X-Spam-Status: No, score=1.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, T_DKIM_INVALID=0.01] 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 XSs1VD7nL7Zl; Tue, 22 Dec 2015 18:43:07 -0800 (PST) Received: from msh03.myshophosting.com (fw01.ch31995.smartservers.com.au [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 4D3141A90B0; Tue, 22 Dec 2015 18:43:07 -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:Cc:References:To:Subject; bh=LtzxGjr/Mq3R5lbyjSfBdHaysPrffDJRMtmfi86bT78=; b=JZp8NjVy2DYzdFlZiQPpm8fmL0 fB082anHM3RnWh2RPJXQi82M6SPpF5YcaELCvtEVCpjveXRONN8vJsivgCKGTyBcG4fecWA1BVZ1g 7Vdc8BTp4Tc8esAFJOBiwX2WkoMOSikGrctVllSQJpRglSq3/lhBkZGafuzktxvBmih6yyBi3LICH n20LJyYEldA0uzFDq6ZLzEN2uFuNKBxJphEK8fyfnSYckdLCk0/YlOcr3EY21evjPp+EGPKt+naF9 gRk52W0QyzHT4XA4gO+x/ZySu14d5Yd0iYJJ2nqbjAnpUAFB4ko0zavvwOBm2bXaZgYYsiXz1e/q5 fWheMx7Q==; Received: from ppp118-209-109-182.lns20.mel4.internode.on.net ([118.209.109.182]:50405 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1aBZOI-003W78-7L; Wed, 23 Dec 2015 13:43:02 +1100 To: Stephen Farrell , "Duckworth, Mark" , The IESG References: <20151217125527.4771.42784.idtracker@ietfa.amsl.com> <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F414@CRPMBOXPRD08.polycom.com> <5679E379.1040306@cs.tcd.ie> From: Christian Groves Message-ID: <567A0A31.4060702@nteczone.com> Date: Wed, 23 Dec 2015 13:42:57 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5679E379.1040306@cs.tcd.ie> 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: Cc: "clue-chairs@ietf.org" , "draft-ietf-clue-framework@ietf.org" , "clue@ietf.org" Subject: Re: [clue] Stephen Farrell's No Objection on draft-ietf-clue-framework-24: (with COMMENT) 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, 23 Dec 2015 02:43:09 -0000 Hello Stephen, Please see below my comment below marked [CNG]. On 23/12/2015 10:57 AM, Stephen Farrell wrote: > Hiya, > > On 22/12/15 23:50, Duckworth, Mark wrote: >> Hello Stephen, I have a few responses below. Mark >> >>> -----Original Message----- From: Stephen Farrell >>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, December 17, >>> 2015 7:55 AM >>> ---------------------------------------------------------------------- >>> >>> > COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> > Thanks for a pretty comprehensive description. These sound like >>> fun systems on which to work. >>> >>> Pity there are so many IPR declarations with not great terms and >>> for something that to me at least doesn't appear to require >>> invention (just construction of existing bits) but I guess that's >>> the world we live in and the WG were ok with that. >>> >>> - 7.1.1.3 - I wondered if the "MUST be co-planar" requirement could >>> cause issues (bugs) if receivers don't check for that. Are >>> receivers expected to verify that on receipt or is the MUST only >>> for senders? >> [Duckworth, Mark] Everything in an advertisement could cause issues >> (bugs) if the Provider puts incorrect information in it. There are >> many possible ways an advertisement can be internally inconsistent. >> In the CLUE protocol document it defines a "Conflicting values" error >> code, which a message recipient can send back to the sender if the >> recipient detects an error in the message. > Fair enough. OTOH, I'm still no clearer if the spec is calling > for the MUST to be enforced by recipients or not. Don't you think > the document ought say that explicitly? I do, FWIW. > >>> - 7.1.1.10: privacy issues abound, but section 15 only refers to >>> the communications security aspect. I think you ought recommend >>> that implementations SHOULD minimise the information sent, and >>> SHOULD give users control over what is sent. You might want to note >>> the utility of sending the same subset of information for regular >>> repeated calls but I'm not sure what clue protocol might know that >>> calls are repeats or if there's a better way to manage re-use of >>> privacy settings for users. >> [Duckworth, Mark] I makes sense to me to add a statement like "an >> implementation SHOULD give users control over what sensitive >> information is sent in an Advertisement." > Great. > >> But I don't think we should >> say "SHOULD minimize the information sent", because that would defeat >> the purpose of including that information in the protocol in the >> first place. > I disagree fwiw, but that may be down to different interpretations > of what minimise means. To me, it means "only send what's needed to > get what you want to happen" and "as a receiver, don't expect senders > to include information you don't really need." Taking that meaning, > I'm not sure how one could really oppose data minimisation and be > privacy friendly tbh. [CNG] I would tend to agree with Mark. The point of CLUE is that an endpoint advertises information, the consumer decides what's relevant to it. The advertisement is not asking the consumer to do anything or asking the consumer to make something happen. The endpoint advertises the information it has. The consumer chooses what information is relevant to it for the selection and presentation of captures. One consumer may find the fact that knowing a capture contains the "chair" useful, another may not. The advertiser isn't in a place to figure this out. Regards, Christian > > Cheers, > S. > > >>> - The secdir review [1] noted some issues that may be worth >>> considering for later WG documents. I'd encourage folks to try get >>> in touch with the reviewer when doing later work as that might >>> avoid some late-surprises. (That is not a threat btw, just >>> encouragement to try take advantage of a reviewer who likes to >>> consider more than just what's in front of him today:-) >>> >>> [1] >>> https://www.ietf.org/mail-archive/web/secdir/current/msg06244.html >>> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Dec 22 19:04:35 2015 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 721FD1A90F6; Tue, 22 Dec 2015 19:04:33 -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, 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 ypjSt1G903He; Tue, 22 Dec 2015 19:04:26 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::716]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9B01A90F4; Tue, 22 Dec 2015 19:04:25 -0800 (PST) Received: from CO2PR07MB619.namprd07.prod.outlook.com (10.141.228.151) by CO2PR07MB617.namprd07.prod.outlook.com (10.141.228.143) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 23 Dec 2015 03:04:06 +0000 Received: from CO2PR07MB619.namprd07.prod.outlook.com ([10.141.228.151]) by CO2PR07MB619.namprd07.prod.outlook.com ([10.141.228.151]) with mapi id 15.01.0361.006; Wed, 23 Dec 2015 03:04:06 +0000 From: Stephan Wenger To: Stephen Farrell , "Duckworth, Mark" , The IESG Thread-Topic: Stephen Farrell's No Objection on draft-ietf-clue-framework-24: (with COMMENT) Thread-Index: AQHRPROaVSsO04ACc06yQcAIMBsc057XrvOA//+t8AA= Date: Wed, 23 Dec 2015 03:04:04 +0000 Message-ID: References: <20151217125527.4771.42784.idtracker@ietfa.amsl.com> <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F414@CRPMBOXPRD08.polycom.com> <5679E379.1040306@cs.tcd.ie> In-Reply-To: <5679E379.1040306@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.174.30.183] x-microsoft-exchange-diagnostics: 1; CO2PR07MB617; 5:CQaxjUHOzKLGQw2cPdTsLf+HUk2V+w1QDPx2lQWB/57ZPfrXbVv+JTqbxD+T9E22yBbWIx4y2BrLijo1yqzrVwMVeHKk83iM0tiUnaB522oCjpfVrKSVnRUmV2ZkOc63/InoRQIQo8z235Cvioah7Q==; 24:Grsnpr3IW2fiVZMAjdbQAUKUDvgACkfqvpwF+A1XbfSIAWa1PKJKF1kpaAQeTElOPs55XTJuuEBw/PzO/iJ4Icsuv4cd5h8jq+ufAdYyIBw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR07MB617; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:CO2PR07MB617; BCL:0; PCL:0; RULEID:; SRVR:CO2PR07MB617; x-forefront-prvs: 0799B1B2D7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(479174004)(199003)(13464003)(189002)(86362001)(81156007)(5001960100002)(97736004)(189998001)(101416001)(1096002)(82746002)(105586002)(1220700001)(106356001)(5004730100002)(83716003)(11100500001)(33656002)(586003)(5001770100001)(76176999)(19580395003)(87936001)(6116002)(36756003)(19580405001)(15975445007)(77096005)(106116001)(230783001)(99286002)(54356999)(66066001)(50986999)(92566002)(5008740100001)(3846002)(10400500002)(40100003)(2950100001)(122556002)(5002640100001)(2900100001)(102836003)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR07MB617; H:CO2PR07MB619.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <93D1B8029162E84D97A2F4A202C46896@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2015 03:04:04.6390 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR07MB617 Archived-At: Cc: "clue-chairs@ietf.org" , "draft-ietf-clue-framework@ietf.org" , "clue@ietf.org" Subject: Re: [clue] Stephen Farrell's No Objection on draft-ietf-clue-framework-24: (with COMMENT) 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, 23 Dec 2015 03:04:33 -0000 SGksDQpQbGVhc2Ugc2VlIGlubGluZSwNClN0ZXBoYW4NCg0KDQoNCg0KT24gMTIvMjIvMTUsIDE1 OjU3LCAiU3RlcGhlbiBGYXJyZWxsIiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4gd3JvdGU6 DQoNCj4NCj5IaXlhLA0KPg0KPk9uIDIyLzEyLzE1IDIzOjUwLCBEdWNrd29ydGgsIE1hcmsgd3Jv dGU6DQo+PiBIZWxsbyBTdGVwaGVuLCBJIGhhdmUgYSBmZXcgcmVzcG9uc2VzIGJlbG93LiBNYXJr DQo+PiANCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBTdGVwaGVuIEZhcnJl bGwNCj4+PiBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdIFNlbnQ6IFRodXJzZGF5 LCBEZWNlbWJlciAxNywNCj4+PiAyMDE1IDc6NTUgQU0gDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+ DQo+Pj4gDQo+Q09NTUVOVDoNCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4NCj4+Pg0KPj4+IA0KPlRo YW5rcyBmb3IgYSBwcmV0dHkgY29tcHJlaGVuc2l2ZSBkZXNjcmlwdGlvbi4gVGhlc2Ugc291bmQg bGlrZQ0KPj4+IGZ1biBzeXN0ZW1zIG9uIHdoaWNoIHRvIHdvcmsuDQo+Pj4gDQo+Pj4gUGl0eSB0 aGVyZSBhcmUgc28gbWFueSBJUFIgZGVjbGFyYXRpb25zIHdpdGggbm90IGdyZWF0IHRlcm1zIGFu ZCANCj4+PiBmb3Igc29tZXRoaW5nIHRoYXQgdG8gbWUgYXQgbGVhc3QgZG9lc24ndCBhcHBlYXIg dG8gcmVxdWlyZSANCj4+PiBpbnZlbnRpb24gKGp1c3QgY29uc3RydWN0aW9uIG9mIGV4aXN0aW5n IGJpdHMpIGJ1dCBJIGd1ZXNzIHRoYXQncyANCj4+PiB0aGUgd29ybGQgd2UgbGl2ZSBpbiBhbmQg dGhlIFdHIHdlcmUgb2sgd2l0aCB0aGF0Lg0KPj4+IA0KPj4+IC0gNy4xLjEuMyAtIEkgd29uZGVy ZWQgaWYgdGhlICJNVVNUIGJlIGNvLXBsYW5hciIgcmVxdWlyZW1lbnQgY291bGQNCj4+PiBjYXVz ZSBpc3N1ZXMgKGJ1Z3MpIGlmIHJlY2VpdmVycyBkb24ndCBjaGVjayBmb3IgdGhhdC4gQXJlIA0K Pj4+IHJlY2VpdmVycyBleHBlY3RlZCB0byB2ZXJpZnkgdGhhdCBvbiByZWNlaXB0IG9yIGlzIHRo ZSBNVVNUIG9ubHkgDQo+Pj4gZm9yIHNlbmRlcnM/DQo+PiBbRHVja3dvcnRoLCBNYXJrXSBFdmVy eXRoaW5nIGluIGFuIGFkdmVydGlzZW1lbnQgY291bGQgY2F1c2UgaXNzdWVzDQo+PiAoYnVncykg aWYgdGhlIFByb3ZpZGVyIHB1dHMgaW5jb3JyZWN0IGluZm9ybWF0aW9uIGluIGl0LiBUaGVyZSBh cmUNCj4+IG1hbnkgcG9zc2libGUgd2F5cyBhbiBhZHZlcnRpc2VtZW50IGNhbiBiZSBpbnRlcm5h bGx5IGluY29uc2lzdGVudC4NCj4+IEluIHRoZSBDTFVFIHByb3RvY29sIGRvY3VtZW50IGl0IGRl ZmluZXMgYSAiQ29uZmxpY3RpbmcgdmFsdWVzIiBlcnJvcg0KPj4gY29kZSwgd2hpY2ggYSBtZXNz YWdlIHJlY2lwaWVudCBjYW4gc2VuZCBiYWNrIHRvIHRoZSBzZW5kZXIgaWYgdGhlDQo+PiByZWNp cGllbnQgZGV0ZWN0cyBhbiBlcnJvciBpbiB0aGUgbWVzc2FnZS4NCj4NCj5GYWlyIGVub3VnaC4g T1RPSCwgSSdtIHN0aWxsIG5vIGNsZWFyZXIgaWYgdGhlIHNwZWMgaXMgY2FsbGluZw0KPmZvciB0 aGUgTVVTVCB0byBiZSBlbmZvcmNlZCBieSByZWNpcGllbnRzIG9yIG5vdC4gRG9uJ3QgeW91IHRo aW5rDQo+dGhlIGRvY3VtZW50IG91Z2h0IHNheSB0aGF0IGV4cGxpY2l0bHk/IEkgZG8sIEZXSVcu DQoNClRoZSB3aG9sZSBzZWN0aW9uIDcgKG9idmlvdXNseSBpbmNsdWRpbmcgNy4xLjEuMyksIGFu ZCBzZWN0aW9ucyA4IGFuZCA5LCBhcmUgaW50ZW50aW9uYWxseSB3cml0dGVuIGFzIGEgZGF0YSBz dHJ1Y3R1cmUgc3BlY2lmaWNhdGlvbiBvbmx5LiAgSSB3b3VsZCBoYXRlIGJyZWFraW5nIHRoaXMg Y2xlYW4gKEkgdGhpbmspIGRvYyBzdHJ1Y3R1cmUgYnkgaW50cm9kdWNpbmcgc2VuZGVycyBvciBy ZWNlaXZlcnMuIA0KDQpPbmUgd2F5IHRvIGdpdmUgU3RlcGhlbiB3aGF0IGhlIHdhbnRzIHdpdGhv dXQgYnJlYWtpbmcgdGhlIGRvYyBzdHJ1Y3R1cmUgYXMgZGVzY3JpYmVkIGFib3ZlIHdvdWxkIGJl IHRvIGFkZCBhIHNlbnRlbmNlIGxpa2Ug4oCcQW4gQXJlYSBvZiBDYXB0dXJlIGF0dHJpYnV0ZSB3 aGVyZSB0aGUgZm91ciBwb2ludHMgYXJlIG5vdCBjby1wbGFuYXIgaXMgdW5kZWZpbmVkOyB0aGUg YXR0cmlidXRl4oCZcyB2YWx1ZXMgTVVTVCBiZSBpZ25vcmVkIGFuZCBoYW5kbGVkIGFzIGlmIHRo ZSBhdHRyaWJ1dGUgd2VyZSBub3QgYXZhaWxhYmxlLCBleGNlcHQgZm9yIGVycm9yIGhhbmRsaW5n IChpLmUuIHJlcG9ydGluZyBpbmNvbnNpc3RlbnQgdmFsdWVzKS4iDQoNCj4NCj4+IA0KPj4+IC0g Ny4xLjEuMTA6IHByaXZhY3kgaXNzdWVzIGFib3VuZCwgYnV0IHNlY3Rpb24gMTUgb25seSByZWZl cnMgdG8gDQo+Pj4gdGhlIGNvbW11bmljYXRpb25zIHNlY3VyaXR5IGFzcGVjdC4gSSB0aGluayB5 b3Ugb3VnaHQgcmVjb21tZW5kIA0KPj4+IHRoYXQgaW1wbGVtZW50YXRpb25zIFNIT1VMRCBtaW5p bWlzZSB0aGUgaW5mb3JtYXRpb24gc2VudCwgYW5kIA0KPj4+IFNIT1VMRCBnaXZlIHVzZXJzIGNv bnRyb2wgb3ZlciB3aGF0IGlzIHNlbnQuIFlvdSBtaWdodCB3YW50IHRvIG5vdGUNCj4+PiB0aGUg dXRpbGl0eSBvZiBzZW5kaW5nIHRoZSBzYW1lIHN1YnNldCBvZiBpbmZvcm1hdGlvbiBmb3IgcmVn dWxhcg0KPj4+IHJlcGVhdGVkIGNhbGxzIGJ1dCBJJ20gbm90IHN1cmUgd2hhdCBjbHVlIHByb3Rv Y29sIG1pZ2h0IGtub3cgdGhhdA0KPj4+IGNhbGxzIGFyZSByZXBlYXRzIG9yIGlmIHRoZXJlJ3Mg YSBiZXR0ZXIgd2F5IHRvIG1hbmFnZSByZS11c2Ugb2YNCj4+PiBwcml2YWN5IHNldHRpbmdzIGZv ciB1c2Vycy4NCj4+IFtEdWNrd29ydGgsIE1hcmtdIEkgbWFrZXMgc2Vuc2UgdG8gbWUgdG8gYWRk IGEgc3RhdGVtZW50IGxpa2UgImFuDQo+PiBpbXBsZW1lbnRhdGlvbiBTSE9VTEQgZ2l2ZSB1c2Vy cyBjb250cm9sIG92ZXIgd2hhdCBzZW5zaXRpdmUNCj4+IGluZm9ybWF0aW9uIGlzIHNlbnQgaW4g YW4gQWR2ZXJ0aXNlbWVudC4iIA0KPg0KPkdyZWF0Lg0KPg0KPj4gQnV0IEkgZG9uJ3QgdGhpbmsg d2Ugc2hvdWxkDQo+PiBzYXkgIlNIT1VMRCBtaW5pbWl6ZSB0aGUgaW5mb3JtYXRpb24gc2VudCIs IGJlY2F1c2UgdGhhdCB3b3VsZCBkZWZlYXQNCj4+IHRoZSBwdXJwb3NlIG9mIGluY2x1ZGluZyB0 aGF0IGluZm9ybWF0aW9uIGluIHRoZSBwcm90b2NvbCBpbiB0aGUNCj4+IGZpcnN0IHBsYWNlLg0K Pg0KPkkgZGlzYWdyZWUgZndpdywgYnV0IHRoYXQgbWF5IGJlIGRvd24gdG8gZGlmZmVyZW50IGlu dGVycHJldGF0aW9ucw0KPm9mIHdoYXQgbWluaW1pc2UgbWVhbnMuIFRvIG1lLCBpdCBtZWFucyAi b25seSBzZW5kIHdoYXQncyBuZWVkZWQgdG8NCj5nZXQgd2hhdCB5b3Ugd2FudCB0byBoYXBwZW4i IGFuZCAiYXMgYSByZWNlaXZlciwgZG9uJ3QgZXhwZWN0IHNlbmRlcnMNCj50byBpbmNsdWRlIGlu Zm9ybWF0aW9uIHlvdSBkb24ndCByZWFsbHkgbmVlZC4iIFRha2luZyB0aGF0IG1lYW5pbmcsDQo+ SSdtIG5vdCBzdXJlIGhvdyBvbmUgY291bGQgcmVhbGx5IG9wcG9zZSBkYXRhIG1pbmltaXNhdGlv biBhbmQgYmUNCj5wcml2YWN5IGZyaWVuZGx5IHRiaC4NCg0KR2VuZXJhbGx5IHNwZWFraW5nLCB0 aGUgeENhcmQgaW5mbyBhYm91dCB3aGljaCB0aGlzIHNlY3Rpb24gaXMgY29uY2VybmVkIGFib3V0 IGlzIG5vdCByZXF1aXJlZCB0byBtYWtlIGFueXRoaW5nIOKAnHdvcmvigJ0gcHJvdG9jb2wtd2lz ZS4gIEl04oCZcyBmdWxseSBvcHRpb25hbCBtZXRhZGF0YS4gIEhvd2V2ZXIsIGl04oCZcyBvZnRl biB1c2VmdWwgbWV0YWRhdGEuICBGb3IgZXhhbXBsZSwgd2hlbiB5b3UgaGF2ZSBhIHRocmVlIHdh eSBjb25mZXJlbmNlIHdpdGggc2l4IHBlb3BsZSBwZXIgcm9vbSAoZm9yIGEgdG90YWwgb2YgMTIg cGVvcGxlIHZpc2libGUgb24gZWFjaCByb29t4oCZcyBzY3JlZW4pLCBpdOKAmXMgdXNlZnVsIHRv IGtub3cgdGhlIG5hbWVzIG9mIHRob3NlIHBlb3BsZSwgYmVjYXVzZSB5b3UgbWF5IG5vdCBrbm93 IGFsbCBvZiB0aGVtIGJ5IG5hbWUgYW5kIHlvdSB3YW50IHRvIGJlIGFibGUgdG8gYWRkcmVzcyB0 aGVtIGRpcmVjdGx5IGluIGEgY29udmVyc2F0aW9uLCByYXRoZXIgdGhhbiBzYXkg4oCcdGhlIGxh ZHkgd2hvIHNwb2tlIG5leHQgdG8gbGFzdCIuICBUaGF04oCZcyB3aHkgbW9zdCAoYWxsPykgb2Yg dG9kYXnigJlzIG5vbi1zdGFuZGFyZCBpbXBsZW1lbnRhdGlvbnMgb2YgdGVsZXByZXNlbmNlIGFs bG93IHRvLCBhcyB0aGUgbWluaW11bSwgc29tZXRoaW5nIGxpa2UgbmFtZXMgYW5kIGxvY2F0aW9u cyBvZiB0aGUgcGFydGljaXBhbnRzIHNvbWV3aGVyZSBvdmVybGFpZCBvbiB0aGUgZGVjb2RlZCB3 aW5kb3dzLiAgUXVpdGUgb2Z0ZW4sIHRoZXJlIGlzIGFsc28gYSB1c2VyLWludGVyZmFjZSBvdXRz aWRlIHRoZSBtYWluIHRlbGVwcmVzZW5jZSBzY3JlZW5zLCBvbiB3aGljaCBvbmUgY291bGQgaGF2 ZSBzaWRlIGNvbnZlcnNhdGlvbnMgdGhyb3VnaCB0ZXh0IGNoYXQgZXRjLiAgT24gdGhvc2UgdXNl ciBpbnRlcmZhY2VzLCBvZnRlbiwgZW1haWwgYWRkcmVzc2VzIGFuZCBzaW1pbGFyIGluZm8gaXMg YXZhaWxhYmxlLiAgVGhhdOKAmXMgd2hhdCB0aGlzIHhDYXJkIGluZm8gaXMgdXNlZCBmb3IuICBT byBpZiB5b3UgaW50ZXJwcmV0IOKAnHdvcmvigJ0gYnJvYWRseSwgdGhlbiB5ZXMsIHRoZSB4Q2Fy ZCBtZXRhZGF0YSBpcyBuZWNlc3NhcnkgdG8gbWFrZSB0aGUgc3lzdGVtIHdvcmsgKOKAnHdvcmsi IGJlaW5nIGRlZmluZWQgYXMgYmVpbmcgdXNlZnVsIHRvIHRoZSB1c2VycykuDQoNCldoZW4gd2Ug c3RhcnRlZCB3aXRoIHRoZSBmcmFtZXdvcmssIEkgYmVsaWV2ZSB0byByZWNhbGwgd2UgaGFkIGlu aXRpYWxseSBzaW1wbGUgY29kZSBwb2ludHMgbGlrZSBhIHN0cmluZyBmb3IgdGhlIG5hbWUgYW5k IGFub3RoZXIgZm9yIHRoZSBsb2NhdGlvbi4gIEhvd2V2ZXIsIHdlIG9wdGVkIHRvIGdlbmVyYWxp emUgdGhhdCB1c2luZyB4Q2FyZC4gIA0KDQpIb3cgdGhlIHhDYXJkcyBhcmUgcG9wdWxhdGVkIGlz IGFuIGVudGlyZWx5IGRpZmZlcmVudCBzdG9yeS4gIEl04oCZcyBhIHBvbGljeSB0aGluZy4gIEZv ciBleGFtcGxlLCB3aGVuIHVzaW5nIHRlbGVwcmVzZW5jZSBpbiBhbiBlbnRlcnByaXNlLCBjb25j ZWl2YWJseSwgc2NyaXB0aW5nIGJ5IHRoZSBJVCBkZXBhcnRtZW50IHdvdWxkIHBvcHVsYXRlIHRo ZSB4Q2FyZCB3aXRoIGFsbCBpbmZvIGF2YWlsYWJsZSBpbiB0aGUgY29tcGFueSBwaG9uZWJvb2ss IHRvIGVuc3VyZSB0aGUgbW9zdCBwcm9kdWN0aXZlIG1lZXRpbmcuICBMZXQgdGhlIHJlY2Vpdmlu ZyB1c2VycyBzb3J0IG91dCB3aGF0IHRoZXkgd2FudCB0byBzZWUgZGlzcGxheWVkLCBhbmQgd2hh dCBub3QuICBIb3dldmVyLCB3aGVuIHRoZSBzYW1lIHRlbGVwcmVzZW5jZSByb29tIOKAnGRpYWxz 4oCdIG91dCB0byBhIGRpZmZlcmVudCBmaXJtLCBjZXJ0YWlubHkgY29uZmlkZW50aWFsIGluZm9y bWF0aW9uIHN1Y2ggYXMgaW50ZXJuYWwgcmVwb3J0aW5nIHN0cnVjdHVyZXMsIHBheWdyYWRlcywg YW5kIHBlcmhhcHMgZXZlbiBwaG9uZSBudW1iZXJzIGFuZCB3aGF0bm90IHdvdWxkIGJlIG9taXR0 ZWQuICBBZ2Fpbiwgc2NyaXB0aW5nIGJ5IElUIHdvdWxkIGVuc3VyZSB0aGF0LiAgSWYgdGhlIHNh bWUgcm9vbSB3ZXJlIHVzZWQgYWZ0ZXItaG91cnMgZm9yIGEgbWVldGluZyBvZiBhbm9ueW1vdXMg YWxjb2hvbGljcyBncm91cHMsIGNsZWFybHksIG9uZSB3b3VsZCBub3QgcG9wdWxhdGUgdGhlIHhD YXJkIGF0IGFsbCwgYW5kIHRoYXQgd291bGQgcHJvYmFibHkgYmUgc29tZXdoZXJlIGluIHRoZSBh ZHZhbmNlZCBzZXR0aW5ncyBpbiB0aGUgdXNlciBpbnRlcmZhY2UgKGFuZCBzb21lb25lIHdobyBi b29rcyBhIHRlbGVwcmVzZW5jZSByb29tIGZvciBzdWNoIGEgbWVldGluZyBiZXR0ZXIgYmUgcXVh bGlmaWVkIHRvIHRpbmtlciB3aXRoIHRob3NlIHNldHRpbmdzKS4gIA0KDQpTbyB5ZXMsIE1hcmsg aXMgcmlnaHQsIGl04oCZcyBlbnRpcmVseSBhIHVzZXLigJlzIGNob2ljZSB3aGF0IHRvIHNlbmQs IGlmIHlvdSBkZWZpbmUg4oCcdXNlcuKAnSBicm9hZGx5IGVub3VnaC4gIEdvaW5nIGZ1cnRoZXIs IGl04oCZcyBhbHNvIHRoZSB1c2Vy4oCZcyBjaG9pY2Ugd2hhdCB0byBkbyB3aXRoIHJlY2VpdmVk IGluZm8uDQoNCkkgZG8gbm90IGJlbGlldmUgdGhlcmUgaXMgYW55IHZhbHVlIGluIGRvY3VtZW50 aW5nIHRoZSBhYm92ZSBjaG9pY2VzLiAgVGhlIG9wdGlvbnMgYXJlIGtub3duIGFuZCB1bmRlcnN0 b29kIGluIHRoZSBpbmR1c3RyeSBhdCBsYXJnZSwgYW5kIGJ5IHJlYXNvbmFibHkgY29tcGV0ZW50 IHBlb3BsZS4gIA0KICANClN0ZXBoYW4NCg0KDQoNCg0KPg0KPkNoZWVycywNCj5TLg0KPg0KPg0K Pj4gDQo+Pj4gLSBUaGUgc2VjZGlyIHJldmlldyBbMV0gbm90ZWQgc29tZSBpc3N1ZXMgdGhhdCBt YXkgYmUgd29ydGggDQo+Pj4gY29uc2lkZXJpbmcgZm9yIGxhdGVyIFdHIGRvY3VtZW50cy4gSSdk IGVuY291cmFnZSBmb2xrcyB0byB0cnkgZ2V0DQo+Pj4gaW4gdG91Y2ggd2l0aCB0aGUgcmV2aWV3 ZXIgd2hlbiBkb2luZyBsYXRlciB3b3JrIGFzIHRoYXQgbWlnaHQNCj4+PiBhdm9pZCBzb21lIGxh dGUtc3VycHJpc2VzLiAoVGhhdCBpcyBub3QgYSB0aHJlYXQgYnR3LCBqdXN0IA0KPj4+IGVuY291 cmFnZW1lbnQgdG8gdHJ5IHRha2UgYWR2YW50YWdlIG9mIGEgcmV2aWV3ZXIgd2hvIGxpa2VzIHRv IA0KPj4+IGNvbnNpZGVyIG1vcmUgdGhhbiBqdXN0IHdoYXQncyBpbiBmcm9udCBvZiBoaW0gdG9k YXk6LSkNCj4+PiANCj4+PiBbMV0NCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3NlY2Rpci9jdXJyZW50L21zZzA2MjQ0Lmh0bWwNCj4+PiANCj4+IA0K From nobody Wed Dec 23 02:26:00 2015 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 3C03E1ACE4C; Wed, 23 Dec 2015 02:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 6LdUuojbgAnn; Wed, 23 Dec 2015 02:25:57 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C791ACE4B; Wed, 23 Dec 2015 02:25:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 405B4BE5D; Wed, 23 Dec 2015 10:25:54 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6SaLzHtXpTE; Wed, 23 Dec 2015 10:25:53 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.22.208]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6872EBE54; Wed, 23 Dec 2015 10:25:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450866353; bh=td7mimpXYEU4D3mfD/bqHg/Vhkc81fNMIEXlg2EMM+0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=BAZgyNmAxep466ni0dJ/HaWNTDfhmsiJAUArfybJ/bPDsJEwnx0Potb8b9zMxmu4p hkfbxWy8LFKeHJZS/ASamC37NB2uqlj0UtcRPB085y7DzjT92YwPb1AFt57ARjmwzh FA1ZbQoNqD2JqcCQPeQ2xd6AfJeD3UGVfoqbKau4= To: Stephan Wenger , "Duckworth, Mark" , The IESG References: <20151217125527.4771.42784.idtracker@ietfa.amsl.com> <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F414@CRPMBOXPRD08.polycom.com> <5679E379.1040306@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <567A76AF.404@cs.tcd.ie> Date: Wed, 23 Dec 2015 10:25:51 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "clue-chairs@ietf.org" , "draft-ietf-clue-framework@ietf.org" , "clue@ietf.org" Subject: Re: [clue] Stephen Farrell's No Objection on draft-ietf-clue-framework-24: (with COMMENT) 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, 23 Dec 2015 10:25:59 -0000 Hi all, On 23/12/15 03:04, Stephan Wenger wrote: > I do not believe there is any value in documenting the above choices. > The options are known and understood in the industry at large, and by > reasonably competent people. I'll just note that the industry at large has IMO not yet done a good job on privacy, with e.g. user agents automatically re-sending data every time, once the data was entered or approved for sending once. (Yes, doing better has UI implications, but that's just a part of doing a good job.) And I consider the pushback from the authors here as a part of that - we need to get better at really considering privacy and at not just assuming that sending more data might be useful sometime and hence ought be done, just-in-case. In this case, I can imagine they may be tricky privacy issues to be considered as people join and leave calls. E.g. would Stephan's enterprise admin like all their employees to include job titles and business unit information in a call that involves outsiders? What if an outsider joins in the middle? And the same issues can come up where real privacy (a human and not corporate concept:-) is at issue, if I'm on a call with people with whom I'm happy to share location information and then a newcomer joins, what should I (or others) tell them? I think there may be real protocol design issues there as well as implementation issues. But, none of this is blocking now so by all means go ahead but I do think we are missing a good opportunity to provide guidance here in a framework document that might cause those writing protocol specifications and implementations to stop and think about privacy when they otherwise might not. S. PS: None of the above is meant to imply that we're bad at privacy for nefarious reasons - I mostly do not think that is the case, it's just a thing we need to get better at. From nobody Wed Dec 23 10:09:23 2015 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 15B7F1A6F6B for ; Wed, 23 Dec 2015 10:09:21 -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 JO2CU0BXVVqp for ; Wed, 23 Dec 2015 10:09:18 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0118.outbound.protection.outlook.com [65.55.169.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46A221A6F68 for ; Wed, 23 Dec 2015 10:09:18 -0800 (PST) Received: from CO2PR07MB619.namprd07.prod.outlook.com (10.141.228.151) by CO2PR07MB619.namprd07.prod.outlook.com (10.141.228.151) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 23 Dec 2015 18:09:13 +0000 Received: from CO2PR07MB619.namprd07.prod.outlook.com ([10.141.228.151]) by CO2PR07MB619.namprd07.prod.outlook.com ([10.141.228.151]) with mapi id 15.01.0361.006; Wed, 23 Dec 2015 18:09:13 +0000 From: Stephan Wenger To: Stephen Farrell , "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: Stephen Farrell's No Objection on draft-ietf-clue-framework-24: (with COMMENT) Thread-Index: AQHRPROaVSsO04ACc06yQcAIMBsc057XrvOA//+t8ACAAQGNgP//+1kA Date: Wed, 23 Dec 2015 18:09:12 +0000 Message-ID: References: <20151217125527.4771.42784.idtracker@ietfa.amsl.com> <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F414@CRPMBOXPRD08.polycom.com> <5679E379.1040306@cs.tcd.ie> <567A76AF.404@cs.tcd.ie> In-Reply-To: <567A76AF.404@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.174.30.183] x-microsoft-exchange-diagnostics: 1; CO2PR07MB619; 5:zOvUoq6Tfa4QgjXMriDZfD/ZwKWiCT2igvYR0ecA+IRpJ5tlxAoyDE+sGqSW9+bxRUl4qL4Q0VIb0f2BQBsZXrt3bgqcn9pWH4Es3jFCQCXh2sC88W8DHuKgG4H953+6Qu9OQhubdJWhp0pJj+ZKNA==; 24:hb6Ge/HC8IO2w14B5aF/bzEdisJGCb2yG4s0Nr9XZ4DuEKAFgXjfFGP6i06iVrhuRqXO6ztvoq3tg4FCEk5FNZa1VBB9eKTRPGg2FoXk5lg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR07MB619; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:CO2PR07MB619; BCL:0; PCL:0; RULEID:; SRVR:CO2PR07MB619; x-forefront-prvs: 0799B1B2D7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(53754006)(199003)(189002)(24454002)(33656002)(87936001)(92566002)(2950100001)(5001960100002)(83716003)(5008740100001)(101416001)(2900100001)(307094003)(19580395003)(86362001)(19580405001)(77096005)(189998001)(107886002)(106116001)(106356001)(1220700001)(230783001)(36756003)(99286002)(586003)(10400500002)(102836003)(1096002)(40100003)(105586002)(97736004)(93886004)(82746002)(3846002)(6116002)(76176999)(50986999)(2501003)(66066001)(5004730100002)(5002640100001)(122556002)(5001770100001)(81156007)(11100500001)(54356999)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR07MB619; H:CO2PR07MB619.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2015 18:09:12.9877 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR07MB619 Archived-At: Subject: Re: [clue] Stephen Farrell's No Objection on draft-ietf-clue-framework-24: (with COMMENT) 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, 23 Dec 2015 18:09:21 -0000 SGkgU3RlcGhlbiwgYWxsLA0KUHJ1bmluZyB0aGUgZGlzdHJpYnV0aW9uIGxpc3QsIGFzIHRoaXMg YXBwZWFycyB0byBiZSBhIHBvc3QgZmFjdG8gZGlzY3Vzc2lvbiB3aXRoIHJlc3BlY3QgdG8gdGhl IGZyYW1ld29yayBkb2N1bWVudCwgYW5kIEkgZG9u4oCZdCB3YW50IHRvIHdhc3RlIHRoZSBiYW5k d2lkdGggb2YgdGhlIElFU0cgZm9sa3MuDQoNCg0KDQoNCk9uIDEyLzIzLzE1LCAwMjoyNSwgIlN0 ZXBoZW4gRmFycmVsbCIgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOg0KDQo+DQo+ SGkgYWxsLA0KPg0KPk9uIDIzLzEyLzE1IDAzOjA0LCBTdGVwaGFuIFdlbmdlciB3cm90ZToNCj4+ IEkgZG8gbm90IGJlbGlldmUgdGhlcmUgaXMgYW55IHZhbHVlIGluIGRvY3VtZW50aW5nIHRoZSBh Ym92ZSBjaG9pY2VzLg0KPj4gVGhlIG9wdGlvbnMgYXJlIGtub3duIGFuZCB1bmRlcnN0b29kIGlu IHRoZSBpbmR1c3RyeSBhdCBsYXJnZSwgYW5kIGJ5DQo+PiByZWFzb25hYmx5IGNvbXBldGVudCBw ZW9wbGUuDQo+DQo+SSdsbCBqdXN0IG5vdGUgdGhhdCB0aGUgaW5kdXN0cnkgYXQgbGFyZ2UgaGFz IElNTyBub3QgeWV0IGRvbmUNCj5hIGdvb2Qgam9iIG9uIHByaXZhY3ksIHdpdGggZS5nLiB1c2Vy IGFnZW50cyBhdXRvbWF0aWNhbGx5DQo+cmUtc2VuZGluZyBkYXRhIGV2ZXJ5IHRpbWUsIG9uY2Ug dGhlIGRhdGEgd2FzIGVudGVyZWQgb3INCj5hcHByb3ZlZCBmb3Igc2VuZGluZyBvbmNlLiAoWWVz LCBkb2luZyBiZXR0ZXIgaGFzIFVJIGltcGxpY2F0aW9ucywNCj5idXQgdGhhdCdzIGp1c3QgYSBw YXJ0IG9mIGRvaW5nIGEgZ29vZCBqb2IuKQ0KPg0KPkFuZCBJIGNvbnNpZGVyIHRoZSBwdXNoYmFj ayBmcm9tIHRoZSBhdXRob3JzIGhlcmUgYXMgYSBwYXJ0IG9mDQo+dGhhdCAtIHdlIG5lZWQgdG8g Z2V0IGJldHRlciBhdCByZWFsbHkgY29uc2lkZXJpbmcgcHJpdmFjeSBhbmQNCj5hdCBub3QganVz dCBhc3N1bWluZyB0aGF0IHNlbmRpbmcgbW9yZSBkYXRhIG1pZ2h0IGJlIHVzZWZ1bA0KPnNvbWV0 aW1lIGFuZCBoZW5jZSBvdWdodCBiZSBkb25lLCBqdXN0LWluLWNhc2UuDQo+DQo+SW4gdGhpcyBj YXNlLCBJIGNhbiBpbWFnaW5lIHRoZXkgbWF5IGJlIHRyaWNreSBwcml2YWN5IGlzc3Vlcw0KPnRv IGJlIGNvbnNpZGVyZWQgYXMgcGVvcGxlIGpvaW4gYW5kIGxlYXZlIGNhbGxzLiBFLmcuIHdvdWxk DQo+U3RlcGhhbidzIGVudGVycHJpc2UgYWRtaW4gbGlrZSBhbGwgdGhlaXIgZW1wbG95ZWVzIHRv IGluY2x1ZGUNCj5qb2IgdGl0bGVzIGFuZCBidXNpbmVzcyB1bml0IGluZm9ybWF0aW9uIGluIGEg Y2FsbCB0aGF0IGludm9sdmVzDQo+b3V0c2lkZXJzPyBXaGF0IGlmIGFuIG91dHNpZGVyIGpvaW5z IGluIHRoZSBtaWRkbGU/IEFuZCB0aGUgc2FtZQ0KPmlzc3VlcyBjYW4gY29tZSB1cCB3aGVyZSBy ZWFsIHByaXZhY3kgKGEgaHVtYW4gYW5kIG5vdCBjb3Jwb3JhdGUNCj5jb25jZXB0Oi0pIGlzIGF0 IGlzc3VlLCBpZiBJJ20gb24gYSBjYWxsIHdpdGggcGVvcGxlIHdpdGggd2hvbQ0KPkknbSBoYXBw eSB0byBzaGFyZSBsb2NhdGlvbiBpbmZvcm1hdGlvbiBhbmQgdGhlbiBhIG5ld2NvbWVyDQo+am9p bnMsIHdoYXQgc2hvdWxkIEkgKG9yIG90aGVycykgdGVsbCB0aGVtPyBJIHRoaW5rIHRoZXJlIG1h eSBiZQ0KPnJlYWwgcHJvdG9jb2wgZGVzaWduIGlzc3VlcyB0aGVyZSBhcyB3ZWxsIGFzIGltcGxl bWVudGF0aW9uDQo+aXNzdWVzLg0KDQpObywgSSBkb27igJl0IHRoaW5rIHRoZXJlIGlzIGEgInJl YWwgcHJvdG9jb2wgZGVzaWduIGlzc3Vl4oCdLiAgVGhlcmUgYXJlIGNlcnRhaW5seSBwb2xpY3kg aXNzdWVzLiAgRGVwZW5kaW5nIG9uIHlvdXIgdmlld3BvaW50IHJlIHByaXZhY3kgdnMuIHVzYWJp bGl0eSAob24gd2hpY2ggd2Ugb2J2aW91c2x5IGhhdmUgZGlmZmVyZW50IG9waW5pb25zKSwgdGhl cmUgbWF5IGJlIGltcGxlbWVudGF0aW9uIGlzc3Vlcy4gIEJ1dCBJIGRvdWJ0IHRoZXJlIGFyZSBw cm90b2NvbCBpc3N1ZXMuICBBbmQsIGZvciB0aGUgZnJhbWV3b3JrLCB0aGVyZSBpcyBubyBpc3N1 ZSBhdCBhbGwuDQoNCkxldCBtZSBleHBsYWluIGJ5IHN0YXJ0aW5nIHdpdGggdGhlIGxhc3Qgc3Rh dGVtZW50LiAgQXMgSSBtZW50aW9uZWQgZWFybGllciAoYWx0aG91Z2ggaW4gYSBkaWZmZXJlbnQg Y29udGV4dCksIHRoZSByZWxldmFudCBwYXJ0IG9mIHRoZSBmcmFtZXdvcmsgZGVmaW5lcyBhIGRh dGEgc3RydWN0dXJlLCBidXQgbm90IGhvdyB0aGF0IGRhdGEgc3RydWN0dXJlIGlzIHBvcHVsYXRl ZCwgZXhjZXB0IGluIGEgaGFuZGZ1bCBvZiBjYXNlcyAobGlrZSB0aGUgY28tcGxhbmFyIHBvaW50 cyBpbiB0aGUgYXJlYSBvZiBjYXB0dXJlKSwgbm9uZSBvZiB3aGljaCBhcHBlYXIgdG8gaGF2ZSBw cml2YWN5IGlzc3Vlcy4gIFRoZSB4Q2FyZCBhdHRyaWJ1dGUgaXMgb3B0aW9uYWwsIGFuZCB3aXRo aW4gdGhlIHhDYXJkIHNwZWMsIGFsbCBmaWVsZHMgYXJlIG9wdGlvbmFsIGJ1dCB0aGUgcmVhbCBu YW1lIElJUkMuICBVbmxlc3MgeW91IHdhbnQgdG8gZW5mb3JjZSBhIHByaXZhY3kgcG9saWN5IGJ5 IGRhdGEgc3RydWN0dXJlIGRlc2lnbiwgdGhlcmUgaXMgbm8gcG9pbnQgdG8gbm9ybWF0aXZlbHkg c3BlY2lmeSBhbnl0aGluZyBoZXJlIGJleW9uZCBod2F0IGlzIGFscmVhZHkgc3BlY2lmaWVkLiAg IFdlIGNhbiAoYW5kIG5vdyBoYXZlKSBkcmF3biBzcGVjaWFsIGF0dGVudGlvbiB0byB0aGUgWGNh cmQgaW4gdGhlIGZyYW1ld29yayBkb2MsIGFuZCB3ZSBkbyB0aGF0IGV2ZW4gbW9yZSBzbyBpbiB0 aGUgZGF0YSBtb2RlbCBkb2MgKHdoaWNoIGZsZXNoZXMgb3V0IHRoZSBkZXRhaWxzIG9mIHRoZSBk YXRhIHN0cnVjdHVyZXMuICBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uIG9mIHRo ZSBkYXRhIG1vZGVsIGRvYyBhbHJlYWR5IG1lbnRpb25zIGluaXRpYWwgcmVxdWlyZW1lbnRzIHJl c3VsdGluZyBmcm9tIHRoZSBwb3RlbnRpYWwgdXNlIG9mIHhDYXJkLCB0aG91Z2ggdGhvc2UgYXJl IG5vdCBmdWxseSBmbGVzaGVkIG91dCB5ZXQgKHNvIHBsZWFzZSBkb27igJl0IGJlYXQgdXAgUm9i ZXJ0YSBhbmQgU2ltb24ganVzdCBub3cgOi0pLiAgSeKAmW0gc3VyZSB0aGUgY3VycmVudCBkaXNj dXNzaW9uIHdpbGwgbGVhZCB0byBhbiBpbXByb3ZlbWVudCB0aGVyZSwgd2hpY2ggaXMgaW4gcGFy dCB3aHkgSSBjb250aW51ZSB0byBiZWF0IHVwIHRoaXMgZGVhZCBob3JzZS4NCiANCg0KQXMgZmFy IGFzIHRoZSBwcm90b2NvbCBnb2VzLCBJIGRvbuKAmXQgdGhpbmsgdGhlcmUgYXJlIHByb3RvY29s IGRlc2lnbiBpc3N1ZXMuICBJdOKAmXMgYWJzb2x1dGVseSBzdXBwb3J0ZWQgYnkgdGhlIGN1cnJl bnQgZGVzaWduIHRoYXQgYSByb29tIGZ1bGwgb2YgYW5vbnltb3VzIGFsY29ob2xpY3Mgam9pbnMg YW4gZXhpc3RpbmcgaW50cmEtZW50ZXJwcmlzZSBjYWxsLCBhbmQgZG9lcyBub3Qgc2VuZCB0aGVp ciB4Q2FyZCBpbmZvLCBub3IgcmVjZWl2ZXMgdGhlIHhDYXJkcyBmcm9tIHRoZSBvdGhlciByb29t cy4gIEFsbCBhZHZlcnRpc2VtZW50cyBhcmUgc2VudCBwb2ludC10by1wb2ludCAobm8gbXVsdGlj YXN0IGRpc3RyaWJ1dGlvbiksIGFuZCBhbGwgY2FuIGJlIGhhbmQtdGFpbG9yZWQgdG8gZnVsZmls bCB0aGUgbmVlZHMgb2YgdGhlIHJlc3BlY3RpdmUgcmVjaXBpZW50cy4gIE5vd2hlcmUgaXQgaXMg c3RhdGVkIHRoYXQgYWxsIGF0dHJpYnV0ZXMgaW4gYWxsIGFkdmVydGlzZW1lbnRzIHNlbnQgdG8g YWxsIGVuZHBvaW50cyBoYXZlIHRvIGJlIGFsbCB0aGUgc2FtZS4gIFNvIHRoZSBwcm90b2NvbCBz aG91bGQgbm90IGhhdmUgYSDigJxyZWFsIHByb3RvY29sIGRlc2lnbiBpc3N1ZeKAnSB3aXRoIHJl c3BlY3QgdG8geENhcmRzLCByaWdodD8gIA0KDQpTdGVwaGFuDQoNCj4NCj5CdXQsIG5vbmUgb2Yg dGhpcyBpcyBibG9ja2luZyBub3cgc28gYnkgYWxsIG1lYW5zIGdvIGFoZWFkIGJ1dCBJDQo+ZG8g dGhpbmsgd2UgYXJlIG1pc3NpbmcgYSBnb29kIG9wcG9ydHVuaXR5IHRvIHByb3ZpZGUgZ3VpZGFu Y2UNCj5oZXJlIGluIGEgZnJhbWV3b3JrIGRvY3VtZW50IHRoYXQgbWlnaHQgY2F1c2UgdGhvc2Ug d3JpdGluZw0KPnByb3RvY29sIHNwZWNpZmljYXRpb25zIGFuZCBpbXBsZW1lbnRhdGlvbnMgdG8g c3RvcCBhbmQgdGhpbmsNCj5hYm91dCBwcml2YWN5IHdoZW4gdGhleSBvdGhlcndpc2UgbWlnaHQg bm90Lg0KPg0KPlMuDQo+DQo+UFM6IE5vbmUgb2YgdGhlIGFib3ZlIGlzIG1lYW50IHRvIGltcGx5 IHRoYXQgd2UncmUgYmFkIGF0DQo+cHJpdmFjeSBmb3IgbmVmYXJpb3VzIHJlYXNvbnMgLSBJIG1v c3RseSBkbyBub3QgdGhpbmsgdGhhdCBpcw0KPnRoZSBjYXNlLCBpdCdzIGp1c3QgYSB0aGluZyB3 ZSBuZWVkIHRvIGdldCBiZXR0ZXIgYXQuDQo+DQo= From nobody Thu Dec 24 14:52:53 2015 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 3B2541A6FB2; Thu, 24 Dec 2015 14:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 2gotvuaqkn5w; Thu, 24 Dec 2015 14:52:47 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4A79A1A0439; Thu, 24 Dec 2015 14:52:47 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBOMqhtA050910 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 24 Dec 2015 16:52:44 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Duckworth, Mark" Date: Thu, 24 Dec 2015 16:52:43 -0600 Message-ID: <470D77F2-2C5C-4295-ADF4-88FC8AA4337E@nostrum.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F3AB@CRPMBOXPRD08.polycom.com> References: <20151215225655.19408.56476.idtracker@ietfa.amsl.com> <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F3AB@CRPMBOXPRD08.polycom.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: "clue-chairs@ietf.org" , "draft-ietf-clue-framework@ietf.org" , "clue@ietf.org" , The IESG Subject: Re: [clue] Ben Campbell's Yes on draft-ietf-clue-framework-24: (with COMMENT) 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: Thu, 24 Dec 2015 22:52:49 -0000 Thanks for the response. A few more comments: Thanks! Ben. --------- [...] >> === Subtantive === >> >> - Section 3, MCU definition. >> Does this need a normative reference to 4353? I'm not sure the >> definition >> can be understood as written without reading it. > [Duckworth, Mark] I don't know. Is there any objection to making > RFC4353 a normative reference? Please make sure Alissa is onboard with any change here, since 4353 is informational. That's not a show stopper, but there are some process bits that would need to occur. An alternative would be to put some more words in the definition, so that the term MCU can be fully understood without the dependency. > >> - 4, paragraph (5): >> The 2119 "OPTIONAL" is vague about what it applies to. Use of >> companion >> protocols? Consider stating this descriptively. > [Duckworth, Mark] I think it was meant to say the Media Provider and > Media Consumer may use information in CLUE messages to reduce the > complexity of SIP offer/answer messages. Would it be more clear to > replace "although it should be stressed that their use in an > implementation is OPTIONAL" with "the Media Provider and Media > Consumer may use information in CLUE messages to reduce the complexity > of SIP offer/answer messages"? Or is it supposed to mean something > else? I think that helps--this doesn't seem like something that needs to use a 2119 keyword. It might also help to to tie the "such information" that is made available via CLUE mechanisms to the desirable mechanism to narrow the options. If nothing else, the use of "such information" to refer to "a mechanism" was a bit confusing to me. > >> -4, last paragraph: >> I don't think the 2119 "REQUIRED" is needed or appropriate here. It >> doesn't seem to add anything, and might be interpreted to not allow >> local policy decisions, etc. > [Duckworth, Mark] How about replacing that clause with "whereas an > Endpoint or MCU that accepts it is indicating support for CLUE as > specified in this document and its companion documents"? That helps, thanks. > >> -5, paragraph 5: >> The paragraph describes what Media Capture means, but never really >> defines what "Encoding" means. (And the definition of "Encoding" in >> the >> terminology section is somewhat circular.) > [Duckworth, Mark] Encodings are further described in section 9. Even if section 9 defined the term "encoding" (which as far as I can tell, it does not.), it would be helpful to have brief definition or forward reference in or before section 5. > >> - 5, 3rd paragraph after Fig 2: >> Isn't setting up media transmission a primary effect? > [Duckworth, Mark] I think so. How about we remove the word "side"? That helps, thanks. > >> -6, third bullet: >> It seems kind of odd to use a MUST for this, given that the >> criteria of >> professionally installed is somewhat vague. I think a non-normative >> recommendation would make more sense. > [Duckworth, Mark] It does seem odd. I think the working group > previously discussed this and decided on using MUST. The issue here is that MUST is contingent on a vague condition. (Systems that know their dimensions). I think the real condition should be something along the line of "Systems intended to convey spatial information ...". But that sort of simplifies to "Systems that want to provide real-world measurements MUST do so". > >> - 7.1.1.7, "Note" >> Where are these keywords expected to be defined? This seems like an >> unfinished section--is it an open to do item? > [Duckworth, Mark] The data model document describes the values, and > how to extend them. A citation of the data model would be helpful in this paragraph. > >> - 7.1.1.8 >> Why is this limited (with a MUST) to these defined values? This list >> assumes traditional usages. It seems like a more open list would >> allow >> for innovative usage. For example, a game court, an outdoor space, >> etc. > [Duckworth, Mark] Again, the data model describes how to extend this > stuff. The problem is, the wording _here_ effectively forbids extension. > Would it be better to say "Possible values are:" ? Maybe--or even "Currently defined values [citation] are as follows:" > >> - 7.1.1.9: >> This section seems to need a normative reference to 5646. > [Duckworth, Mark] Okay, is there any objection to changing this from > informative to normative? > >> -8, paragraph after Table 5: "Simultaneous Transmission Sets MUST >> allow >> all >> the media Captures in any particular Capture Scene View..." >> >> This seems to reverse the causality. Since the simultaneous >> transmission >> set is based on physical limits, shouldn't it say that any particular >> CSV >> MUST respect the limitations in the simultaneous transmission sets? >> (Same >> for Global View). > [Duckworth, Mark] The point isn't about causality, it is just saying > the two have to be mutually consistent. Is it really _mutual_ consistency, or would it make more sense to say that any related CSVs MUST be consistent with the simultaneous transmission set, if present? > >> - 15, 2nd paragraph: >> I think this requires 5239 to be a normative reference. > [Duckworth, Mark] Okay, is there any objection to changing this from > informative to normative? > >> -15, paragaph 4: "DTLS/SRTP MUST be supported and SHOULD be used >> unless >> the media, which is based on RTP, is secured by other means..." >> Is "secured by other means" intended to be the sole exception? If so, >> then this might should say MUST ... unless". As defined in 2119, a >> SHOULD >> would allow an implementation to skip the protection for other >> reasons, >> if the implementer was aware of the implications, etc... >> Also, should the references to 7201 and 7202 be normative? > [Duckworth, Mark] I don't know. Does anybody else have a suggestion > about this? > >> === Editorial === >> >> - Figure 2: >> By SDP Media Session you mean an RTP session as described by the >> basic >> SDP right? That is not an SDP session per se. > [Duckworth, Mark] I think the diagram should say "BASIC MEDIA > SESSION", and "UPDATED MEDIA SESSION". This would be consistent with > the text immediately after the figure that says "An initial > offer/answer exchange establishes a basic media session..." Any > objections? I am fine with that, or "... RTP session" > >> -5, third paragraph from end: >> Please avoid 2119 keywords inside parenthetical phrases. Also, it's >> redundant to say implementations of a protocol MUST follow the >> protocol >> :-) > [Duckworth, Mark] How about change the phrase to " (although the > Consumer follows the CLUE protocol and, therefore, gracefully receives > and responds (through a Configure) to the Provider's information)" ? That works, although I might suggest: " (although the Consumer follows the CLUE protocol and, therefore, gracefully receives and responds to the Provider's information using a Configure)" Also does it make sense to say "a Configure" vs "a Configure operation", or something to that effect? From nobody Thu Dec 24 14:53:21 2015 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 AA4711A6FB2; Thu, 24 Dec 2015 14:53:06 -0800 (PST) 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, T_RP_MATCHES_RCVD=-0.01] 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 PT2v1tFoRe4P; Thu, 24 Dec 2015 14:53:05 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 509FD1A6FB5; Thu, 24 Dec 2015 14:53:05 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBOMqhtB050910 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 24 Dec 2015 16:53:04 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Christian Groves" Date: Thu, 24 Dec 2015 16:53:03 -0600 Message-ID: In-Reply-To: <5679DA62.4020408@nteczone.com> References: <20151215225655.19408.56476.idtracker@ietfa.amsl.com> <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F3AB@CRPMBOXPRD08.polycom.com> <5679DA62.4020408@nteczone.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: "draft-ietf-clue-framework@ietf.org" , "clue@ietf.org" , "clue-chairs@ietf.org" , The IESG Subject: Re: [clue] Ben Campbell's Yes on draft-ietf-clue-framework-24: (with COMMENT) 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: Thu, 24 Dec 2015 22:53:06 -0000 Hi, A couple more comments below: Thanks! Ben. On 22 Dec 2015, at 17:18, Christian Groves wrote: > Hello Mark, > > Some comments below on your replies. > > Regards, > Christian > > On 23/12/2015 5:16 AM, Duckworth, Mark wrote: >> Hello Ben, >> Thanks for the feedback. >> I have a few more responses to your comments below. >> Mark >> >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@nostrum.com] >>> Sent: Tuesday, December 15, 2015 5:57 PM >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I have some minor comments. These should be easy to resolve, and I >>> don't >>> think any are show-stoppers. >>> >>> === Subtantive === >>> >>> - Section 3, MCU definition. >>> Does this need a normative reference to 4353? I'm not sure the >>> definition >>> can be understood as written without reading it. >> [Duckworth, Mark] I don't know. Is there any objection to making >> RFC4353 a normative reference? > [CNG] I'm not sure its appropriate. The definition says "RFC4353-like" > (doesn't sound particularly normative) and says then indicates that > the MCU is without a RFC4353. Again its not normatively saying to use > it. Just because the reference is information doesn't mean a person > shouldn't read it if they're unfamiliar with it. It goes on to say "without the [RFC4353] requirement". The criteria for a normative reference is one that is required to fully implement or understand the draft. I agree this one is borderline. If you think someone can understand the MCU definition without it well enough for the purposes of the document, then I won't push on it. [...] > >>> -6, third bullet: >>> It seems kind of odd to use a MUST for this, given that the >>> criteria of >>> professionally installed is somewhat vague. I think a non-normative >>> recommendation would make more sense. >> [Duckworth, Mark] It does seem odd. I think the working group >> previously discussed this and decided on using MUST. > [CNG] The MUST relates to systems that know their physical dimensions > providing them in an Advertisement rather than relating to > professionally installed systems. We could strike the "(for example > professionally installed Telepresence room systems)" if that's causing > a problem. Please see my related comment to Mark. [...] >> >>> -15, paragaph 4: "DTLS/SRTP MUST be supported and SHOULD be used >>> unless >>> the media, which is based on RTP, is secured by other means..." >>> Is "secured by other means" intended to be the sole exception? If >>> so, >>> then this might should say MUST ... unless". As defined in 2119, a >>> SHOULD >>> would allow an implementation to skip the protection for other >>> reasons, >>> if the implementer was aware of the implications, etc... >>> Also, should the references to 7201 and 7202 be normative? >> [Duckworth, Mark] I don't know. Does anybody else have a suggestion >> about this? > [CNG] I think the wording around this was discussed for awhile and > what's in the framework was the compromise we came up with, i.e. "Its > a really good idea to secure the media using SRTP-DTLS, but we can't > force you if you have a reason not to". "If you have a good reason not to" is substantially different than "if you are secured by other means".