From nobody Mon Dec 9 18:08:31 2019 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 7EDDA12002F; Mon, 9 Dec 2019 18:08:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-clue-protocol@ietf.org, "Daniel C. Burnett" , Paul Kyzivat , clue-chairs@ietf.org, pkyzivat@alum.mit.edu, clue@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <157594370947.2228.10813919080713010576.idtracker@ietfa.amsl.com> Date: Mon, 09 Dec 2019 18:08:29 -0800 Archived-At: Subject: [clue] Benjamin Kaduk's No Objection on draft-ietf-clue-protocol-19: (with COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 02:08:29 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-clue-protocol-19: 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-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting No Objection, as the concerns noted in my previous Discuss ballot position are not necessarily blocking issues for an Experimental document, and in fact further experience might be helpful to reveal the appropriate values and behaviors to use for timeouts and loop-avoidance. My previous ballot position is preserved below; I note that some of the "substantial comments that do not rise to Discuss level" seem to still be present in the -19. DISCUSS Thanks for the generally clear and well-written document! I would like to discuss whether there needs to be more prominent coverage of timers/timeouts, especially as relating to the state machines. (I'd be happy to learn that this is well-covered elsewhere in the document set; I just haven't run into it yet.) In a similar vein, do we want to have any treatment of avoiding infinite loops (e.g., when a 'configure' or 'advertisement' is rejected in expectation of modification but the sending implementation continues to generate an identical message)? It is not clear to me that any change to the document text is needed in either case, but I don't know to what extent the topics have already been discussed. COMMENT I also have some substantial comments that do not rise to Discuss-level. How do I know which endpoint is the channel initiator and which is the channel receiver? draft-ietf-clue-signaling suggests that the DTLS client is the channel initiator, but even that is not explicit about it -- the protocol could be considered under-specified if there is insufficient clarity. Section 2 The MCU definition doesn't actually expand the acronym, which seems a little reader-unfriendly. Section 5.1 There are perhaps more XML extension points in here than is reasonable for some of these elements (e.g., ). Section 5.2 If the responseCode is between 200 and 299 inclusive, the response MUST also include , , and elements; Maybe re-mention that MP and MC are booleans here. Finally, the commonly supported extensions are copied in the field. Does this need to say that only extensions that are applicable to the negotiated protocol version are included? (Also, how does one handle an extension that exists for multiple major versions -- are there two elments for it in the message?) Upon reception of the 'optionsResponse' the version to be used is the one provided in the tag of the message. The following CLUE messages MUST use such a version number in the "v" attribute. The allowed extensions in the CLUE dialogue are those indicated in the of the 'optionsResponse' message. Couldn't this restriction on the "v" value apply even to the 'optionsResponse' message? Section 5.3 The 'advertisement' message is used by the MP to advertise the available media captures and related information to the MC. [...] I'd consider avoiding the definite article "the" to refer to MP/MC roles, since in many caess there will be 2+ of each, and we don't want to confuse the reader into thinking that there is an MP/CR equivalence or something like that. So, perhaps "each MP" and "the corresponding MC". Section 5.4 As it can be seen from the message schema provided in the following excerpt (Figure 6), the 'ack' contains a response code and a reason string for describing the processing result of the 'advertisement'. [...] [the reason string is part of the base clueResponseType] The text quoted here could be read as implying that the reason string is required in the 'ack' message, a stronger requirement than of the base clueResponseType where it has minOccurs=0. Some greater clarity in the text here is probably called for, especially since when the 'ack' is piggybacked on a 'configure' message, there is no provision for a reason string at all. Section 5.5 The element MUST NOT be present if an 'ack' message has been already sent back to the MP. I think you need to clarify that this is scoped to the current advSequenceNr. Section 5.6 It contains (Figure 8) a response code with a reason string indicating either the success or the failure (along with failure details) of a 'configure' request processing. [...] [Same comment about reason string as for 'ack'] Section 5.7 Such new response codes MUST NOT overwrite the ones here defined and they MUST respect the semantics of the first code digit. nit: is this "overwrite" or "override"? This document does not define response codes starting with "1", and such response codes are not allowed to appear in major version 1 of the CLUE protocol. The range from 100 to 199 inclusive is reserved for future major versions of the protocol to define response codes for delayed or incomplete operations if necessary. Response codes starting with "5" through "9" are reserved for future major versions of the protocol to define new classes of response, and are not allowed in major version 1 of the CLUE protocol. Response codes starting with "0" are not allowed. This text seems to also preclude extensions to major version '1' from defining 1xx or [5-9]xx reason codes; is that the intent? Section 6 When the CLUE data channel set up starts ("start channel"), the CP moves from the IDLE state to the CHANNEL SETUP state. nit: only one of "sets up" and "starts" is needed. When in the ACTIVE state, the CP starts the envisioned sub-state machines (i.e., the MP state machine and the MC state machine) according to the roles it plays in the telepresence sessions. Such roles have been previously declared in the 'options' and 'optionsResponse' messages involved in the initiation phase (see OPTIONS sections Section 5.1 and Section 5.2 for the details). [...] My reading of the initiation phase is that each CP sends only a boolean indication of whether it supports the MP/MC roles, and so each party has to determine on its own whether it will act as a MP and/or MC; is that correct? If so, do we need to say anything about how the boolean matrix translates to activating the respective sub-state machines? Section 6.1 'configure+ack' messages referring to out-of- date (i.e., having a sequence number equal to or less than the highest seen so far) advertisements MUST be ignored, i.e., they do not trigger any state transition. [...] Is this really less than or equal or just less than? Also, is "seen" the right verb, since IIUC these are sequence numbers that the MP has *generated* in its advertisements? Section 7 In other words, in this example, the MP MUST use version 1.4 and downgrade to the lower version. [...] nit: does the phrase "and downgrade to the lower version" add any value here? The word "downgrade" can have negative connotations in some other contexts, so if it's not adding value I'd suggest avoiding it. Section 8 As reported in Figure 13, the values of the fields of the element (either new information or new messages) take the following values: [...] o the major standard version of the protocol that the extension refers to. The XSL includes a full version (including minor), even though the semantics basically only use the major version. That said, why is the 'version' element minOccurs="0" -- what are the semantics when it is absent? Section 8.1 The CLUE data model document ([I-D.ietf-clue-data-model-schema]) envisions the possibility of adding this kind of "extra" information in the description of a video capture by keeping the compatibility with the CLUE data model schema. [...] nit: I don't think this is grammatical; maybe just "keeping compatibility". Section 10 This claims to be a "call flow" example, but the described flows only contain a single unidirectional media flow, which is not really consistent with the normal usage of the word "call". Buried in the body text there is a disclaimer: [...] For the sake of simplicity, the following call flow focuses only on the dialogue between MP CP1 and MC CP2. I would suggest making the presence of this simplification much clearer from the start, perhaps "CLUE protocol messages exchanged in the following call flow are detailed; only one direction of media is shown for simplicity, as the other direction is precisely symmetric". CP2 acknowledges the second 'advertisement' message with an 'ack' message (Section 10.7). In a second moment, CP2 changes the requested media streams from CP1 by sending to CP1 a 'configure' message replacing the previously selected video streams with the new composed media streams advertised by CP1 (Section 10.8). This might be an appropriate place to indicate that media from the previous configuration continue to flow during the reconfiguration process. It might also be worth noting again somewhere in here (or a subsection) that there are three (well, two, since we only show one direction of media) distinct sequence number spaces per sender, and that the discontinuity between Section 10.2 and 10.3's numbers is correct. Section 11 Thanks for the well-thought-through security considerations; in combination with the linked documents (particularly the framework), they cover all the considerations (especially privacy considerations) that I had in mind. Section 14.2 We appear to be citing both 5117 and 7667, whereas the latter obsoletes the former. From nobody Mon Dec 9 18:35:46 2019 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 D48EE12002F; Mon, 9 Dec 2019 18:35:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: clue@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: clue@ietf.org Message-ID: <157594534474.2094.15261009667824730263@ietfa.amsl.com> Date: Mon, 09 Dec 2019 18:35:44 -0800 Archived-At: Subject: [clue] I-D Action: draft-ietf-clue-signaling-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 02:35:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence WG of the IETF. Title : Session Signaling for Controlling Multiple Streams for Telepresence (CLUE) Authors : Robert Hanton Paul Kyzivat Lennard Xiao Christian Groves Filename : draft-ietf-clue-signaling-15.txt Pages : 43 Date : 2019-12-09 Abstract: This document specifies how CLUE-specific signaling such as the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-clue-signaling-15 https://datatracker.ietf.org/doc/html/draft-ietf-clue-signaling-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 9 18:42:20 2019 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D2112002F for ; Mon, 9 Dec 2019 18:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=EYJw2Yih; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=IW5ARta0 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 LA2SpYJZLlbr for ; Mon, 9 Dec 2019 18:42:17 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7CE412001A for ; Mon, 9 Dec 2019 18:42:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1552; q=dns/txt; s=iport; t=1575945737; x=1577155337; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=4UPD6Idxb4xjQaMhxDubaSq5Kbacr/z6vRm2A25eX28=; b=EYJw2YihAIhbsT/8nhy496AyN0ARJGV92J8+h6/TKkPWy/iJrIzJKqzW gcao4j/k/+9sF5X69vg1C2+F1mD1uyljcfMYNAgU2T05GTQJxP6AgR4Wy 09Ul4rtADXgDpsIDzvNTPVSCdZOiK7BtTI9mgDDa77a6OnlA9KaBnFK/Z g=; IronPort-PHdr: =?us-ascii?q?9a23=3AZ/arHBZdYaRFu+zXvXuYMYz/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavwaCwzGt9PDndu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6HQBUBe9d/4MNJK1lHQEBOAUFAQI?= =?us-ascii?q?JAYFYgUkkLAVsWCAECyqEA4NGA4sFTpoWglIDVAkBAQEMAQEjCgIBAYRAAhe?= =?us-ascii?q?CAiQ4EwIDDQEBBAEBAQIBBQRthTcBC4VrEREMAQE4EQEiAhkNAgQwFREBBBs?= =?us-ascii?q?agwGCRgMuAQ6hSQKBOIhhdYEygn4BAQWBSUGDERiCFwMGgQ4oAYlOgkmCGoE?= =?us-ascii?q?RR4JMgyICAwGBYYMOMoIsgUABjmaeNgYEgi4DhyCOXpoyjkqIRZFmAgQCBAU?= =?us-ascii?q?CDgEBBYFpIoFYcFCBHoEaATNQERSMcheDUIUUhT90gSiNYAEB?= X-IronPort-AV: E=Sophos;i="5.69,297,1571702400"; d="scan'208";a="379422966" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Dec 2019 02:42:16 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id xBA2gGio017426 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 10 Dec 2019 02:42:16 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Dec 2019 20:42:16 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Dec 2019 20:42:15 -0600 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 9 Dec 2019 20:42:15 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZIACeh9yCMBMWyJuN9/3ebNTiOajl0O08n24QBEiChSQ26wuuzrBWO6aJGzQPsPo+Vs32bS9dXp29ttZ0mPSPKHkZh8Z5YoSSpHU+jj58JIeWwW9shUOVMpQuub7HgC72pxjnizBuNPEZ/XPIjGi/34t5Hcn/dMu7FQ/SA0uOpuwwLK20uvAcsoJU8uLxfoz/h6pNs/lWXEhDJ3wMbKL6/YlL++AY9UNrov2Q5xMpcpexDWwRQOcI7V5OXLMnjSlcOp8qAIxaSTuNzZUZLZiLGovDquzCn5hvxz2I2wJ5/uSPZ0uLzS7B3lI4F3VF2K2H4afWlFNcZfrQ+dyfW4PwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4UPD6Idxb4xjQaMhxDubaSq5Kbacr/z6vRm2A25eX28=; b=T+7BX0Gx0u4Sw1py3nAs7CNlpbYSMc/0CxurAOixHJMHCJocPadh010A2FbLx35tEXXTyuoQ9kTfbQnUR7kXQSVsHh0F74UvTl5Uuq/M1FIf9hUXyydcgrNEWJ+rQJ7tjKI7aIDYb1VVLfLiFmwQBhcWYJrigoWbWx94h0hsBbVtimN68hwQtzd/aI5Cb7jmPRl1n5KicnvwrIqYNSUjcUJH+DNy6uUSQ5DJyYwVpFcI2dxWx4m3UNM+gVHAN6hT5qTZ9i4AzzQmr3sIs5s0Px6SXeqVxA1pwvL3HL6j+v+RAvXuR6KWDk9z8lLLi0pTIrQY94jRYxJ61Imw6Gp6Tw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4UPD6Idxb4xjQaMhxDubaSq5Kbacr/z6vRm2A25eX28=; b=IW5ARta0MA5mDQOg5rv1ACpuF3qCUyY2+fFyPkz+tjFz0qqqGZIE1T1VMbfINjUxRQXYWtmf4mzZlSYW1fK0GV35EiwxAhTJgddYeYFDQacoayXXn/pRICc9ukqMAqcD68jRJVQBY3Gd/wh0dXq4kBmy9l9/t+569/5BqNCQK+E= Received: from BN6PR11MB1633.namprd11.prod.outlook.com (10.172.23.22) by BN6PR11MB4131.namprd11.prod.outlook.com (10.255.130.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.12; Tue, 10 Dec 2019 02:42:14 +0000 Received: from BN6PR11MB1633.namprd11.prod.outlook.com ([fe80::dd97:a79d:86d4:452a]) by BN6PR11MB1633.namprd11.prod.outlook.com ([fe80::dd97:a79d:86d4:452a%12]) with mapi id 15.20.2516.018; Tue, 10 Dec 2019 02:42:14 +0000 From: "Rob Hanton (rohanse2)" To: "clue@ietf.org" Thread-Topic: New version of draft-ietf-clue-signaling Thread-Index: AdWvAqWj9dkpCBqpR3ysZos6yRAyqA== Date: Tue, 10 Dec 2019 02:42:14 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rohanse2@cisco.com; x-originating-ip: [2001:420:c0c0:1003::a6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c39c3239-1bd6-4621-16fe-08d77d1a9096 x-ms-traffictypediagnostic: BN6PR11MB4131: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(346002)(39860400002)(136003)(189003)(199004)(66446008)(64756008)(1730700003)(66476007)(66946007)(186003)(8676002)(6506007)(66556008)(7696005)(5660300002)(5640700003)(478600001)(966005)(76116006)(86362001)(2906002)(55016002)(9686003)(8936002)(52536014)(305945005)(316002)(71190400001)(71200400001)(81156014)(81166006)(6916009)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB4131; H:BN6PR11MB1633.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: knz0KtSB5bBksaDn9plaNM1pj1p9DoIzZYP3vA7i8VcC9joTX1rkaKdQgbGfuLiNI8slMZk6DjQgDWJsEOC136kPjEXIImqqKwwqjBeCy26ylWGSc0uqcxJ1LS7TwE232KGKJpSAZkQP0BuNEPIgG//Ti89vwDoBCyR8br1lvTkaXnH8PXLjfrw4z8bamrjegcD3p8J0Z+MOcggEy75G3s9mosQQsrq9GzwjFLRJqwQbch6yLECgoIxYtrMtTV0G9aRM0gZqU5Yb551mhoUIWCH+jyEftctflEyqsD2LnVlbY5VfvfcYUVqcho9y8pMljF1J7cJGUEsxQRSEmtfmONkrcCEYxOlZp4m+7JbHEFXuUM3wfwhqRLzPmXmobk3ByugNYqIT1ottEvbD+tgnJFHMQHO9xDqGJtT6REV4y50PYtRbD3mE22iiwCVwJucY0dCoUhR6nZd4aq2TkEiv35bBbgg271RDrVsEdtNdDEc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c39c3239-1bd6-4621-16fe-08d77d1a9096 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2019 02:42:14.2092 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bQAsR4C2t+CVkvmWvuvPjqlpufTcP7LJcqPZe/2EwZnbRMB1CDze4O7i51bzQrNCvKwRT7fwmRkNY2yB2ztdPQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB4131 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: [clue] New version of draft-ietf-clue-signaling X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 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, 10 Dec 2019 02:42:20 -0000 QSBuZXcgdmVyc2lvbiBvZiBkcmFmdC1pZXRmLWNsdWUtc2lnbmFsaW5nIGlzIG5vdyB1cCwgZGVh bGluZyB3aXRoIHRoZSBwb2ludHMgcmFpc2VkIGluIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtY2x1ZS1zaWduYWxpbmcvYmFsbG90LyAtIHRoYW5rcyB2ZXJ5IG11 Y2ggdG8gdGhvc2Ugd2hvIHByb3ZpZGVkIHNvbWUgZXhjZWxsZW50IGZlZWRiYWNrLg0KDQpXaGls ZSBhbG1vc3QgYWxsIHRoZSBjaGFuZ2VzIGFyZSBqdXN0IHR3ZWFrcyB0byBjbGFyaWZ5IGludGVu dCBvciBtYWtlIGl0IG1vcmUgcmVhZGFibGUsIHRoZXJlIGlzIG9uZSBtZWFuaW5nZnVsIGNoYW5n ZS4gT25lIGlzc3VlIHJhaXNlZCBpbiB0aGUgYmFsbG90IHdhcyB0aGF0IHByZXZpb3VzbHkgRFRM Uy1TUlRQIHdhcyBvbmx5IG1hbmRhdG9yeSB0byBzdXBwb3J0LCBub3QgdXNlLiBXaGVuIHdlIGZp cnN0IGRpZCB0aGUgc2VjdXJpdHkgc2VjdGlvbiBhbmQgZGlzY3Vzc2VkIHRoZSB2dWxuZXJhYmls aXR5IG9mIENMVUUgdG8gYSB2aWRlbyBoYW1tZXIgYXR0YWNrIHdlIG1hZGUgRFRMUy1TUlRQIG1h bmRhdG9yeSB0byB1c2UsIGJ1dCBhdCBhIHN1YnNlcXVlbnQgSUVURiBzZXNzaW9uIHRoYXQgd2Fz IGNoYW5nZWQgdG8gc3VwcG9ydCBhcyB0aGVyZSB3ZXJlIGNvbmNlcm5zIGFib3V0IG5lZWRpbmcg dG8gZG8gRFRMUy1TUlRQIGluIHByb3ByaWV0YXJ5IGVudmlyb25tZW50cyB3aGVyZSBvdGhlciBt ZWNoYW5pc21zIGFyZSBhdmFpbGFibGUgZm9yIHJlY2VpdmVyIGludGVudCBhc3N1cmFuY2UuIFRv IHJlc29sdmUgdGhpcywgSSd2ZSBtYWRlIHRoZSBjaGFuZ2UgSSBwcmV2aW91c2x5IHByb3Bvc2Vk IG9uIHRoZSBsaXN0LCBtYWtpbmcgRFRMUy1TUlRQIG1hbmRhdG9yeSB0byBzdXBwb3J0IChhcyBi ZWZvcmUpIGFuZCBub3cgbWFuZGF0b3J5IHRvIHVzZSAqdW5sZXNzKiBzb21lIG90aGVyIG1lY2hh bmlzbSBpcyBwcm92aWRpbmcgcmVjZWl2ZXIgaW50ZW50IGFzc3VyYW5jZS4NCg0KQXBvbG9naWVz IGZvciB0aGUgZGVsYXkgaW4gcHJvZHVjaW5nIHRoZSBuZXcgdmVyc2lvbiwgYW5kIHRoYW5rcyBv bmNlIGFnYWluIHRvIHNvbWUgdmVyeSBkaWxpZ2VudCByZXZpZXdzLg0KDQpSb2INCg== From nobody Mon Dec 9 20:00:41 2019 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 2F15912002F; Mon, 9 Dec 2019 20:00:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-clue-signaling@ietf.org, Roni Even , "Daniel C. Burnett" , Roni Even , clue-chairs@ietf.org, roni.even@huawei.com, clue@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <157595044012.2114.9695939071907286568.idtracker@ietfa.amsl.com> Date: Mon, 09 Dec 2019 20:00:40 -0800 Archived-At: Subject: [clue] Benjamin Kaduk's No Objection on draft-ietf-clue-signaling-15: (with COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 04:00:40 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-clue-signaling-15: 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-signaling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for resolving my Discuss (and comment!) points! I assume the RFC Editor will fix the s/cdata hannel/data channel/. From nobody Wed Dec 11 10:15:31 2019 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 7CE051200B5; Wed, 11 Dec 2019 06:46:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , adam@nostrum.com, "Daniel C. Burnett" , clue@ietf.org, roni.even@huawei.com, Roni Even , Roni Even , clue-chairs@ietf.org, draft-ietf-clue-signaling@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157607561047.11571.517115142231847548.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2019 06:46:50 -0800 Archived-At: X-Mailman-Approved-At: Wed, 11 Dec 2019 10:15:30 -0800 Subject: [clue] Document Action: 'Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)' to Experimental RFC (draft-ietf-clue-signaling-15.txt) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 14:46:50 -0000 The IESG has approved the following document: - 'Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)' (draft-ietf-clue-signaling-15.txt) as Experimental RFC This document is the product of the ControLling mUltiple streams for tElepresence Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ Technical Summary This document specifies how CLUE-specific signaling such as the CLUE protocol and the CLUE data channel are used with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. Working Group Summary The document was discussed in the meetings, and on the mailing list. The open issues were addressed and there are no open issues, there was consensus on the content of the document. Document Quality There is an existing implementation of the signaling. The whole CLUE work was initiated by video conferencing Tele-Presence equipment manufacturers wanting interoperability. Personnel Roni Even is the Document Shepherd. The responsible AD is Adam Roach. From nobody Wed Dec 11 10:15:35 2019 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 D178612011E; Wed, 11 Dec 2019 06:48:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , adam@nostrum.com, "Daniel C. Burnett" , clue@ietf.org, pkyzivat@alum.mit.edu, clue-chairs@ietf.org, Paul Kyzivat , draft-ietf-clue-protocol@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157607573179.11380.3285214335565627919.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2019 06:48:51 -0800 Archived-At: X-Mailman-Approved-At: Wed, 11 Dec 2019 10:15:30 -0800 Subject: [clue] Document Action: 'Protocol for Controlling Multiple Streams for Telepresence (CLUE)' to Experimental RFC (draft-ietf-clue-protocol-19.txt) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 14:48:52 -0000 The IESG has approved the following document: - 'Protocol for Controlling Multiple Streams for Telepresence (CLUE)' (draft-ietf-clue-protocol-19.txt) as Experimental RFC This document is the product of the ControLling mUltiple streams for tElepresence Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ Technical Summary The CLUE protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE working group. A companion document delves into CLUE signaling details, as well as on the SIP/ SDP session establishment phase. CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP over DTLS transport. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. Working Group Summary Nothing of particular note occurred during the development of this document. Document Quality A prototype implementation of an earlier version of the protocol was built and demonstrated. Personnel Who is the Document Shepherd? Paul Kyzivat Who is the Responsible Area Director? Adam Roach From nobody Mon Dec 16 12:34:00 2019 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98DC12091D; Mon, 16 Dec 2019 12:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-nn6QUiqM4X; Mon, 16 Dec 2019 12:33:55 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 80507120915; Mon, 16 Dec 2019 12:33:52 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id b15so6532347iln.3; Mon, 16 Dec 2019 12:33:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=NGt1pp2Z1uQSPiBoQXD9bTj3sXEkZdQ/jD56WOo1R04=; b=dEm4QBEh+QCpQMLepzX4+OW1YF5sCslmOvFcKa7TTYOw3xBuxukkTIbfi2kPP5yvmT J5/0cX9dY09uS8PVh+fdY1GBgDcoPNvLHiHOZGZ3WZLzPju9NbmKcn1ZXXqVdDRhmMwJ Yp/+Nx+T9OUUnxYPo7f7H8fSHVgo5Mf9SokwYIIZQ6Rvgx0n5eS7tyR14ZXvebnZauzg IW131sUSS8qCmM+FmBWWsawmjAVRXV+G6N0jxo+PfZ2oN6jaYmLb3+KpEp+BLQuAcabQ bk1RhRpnv2FBvjUH+xUIfc93VvbOkYhG8JIbtWC4p8ul/5lSJLiHrxFSkfcZMneL/2Ej b8hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=NGt1pp2Z1uQSPiBoQXD9bTj3sXEkZdQ/jD56WOo1R04=; b=sonoSBu6I+/Qg/f6jTUD3xsz5S0uJrTbTb1nMb5zOcgkCr1At8d1jou3MORdhDvl6I Su7MY9PxlbfWYZ+r2PGxIDe6Td2+g2DQIIQEXWparm6JOA38lmY1Z5Fno2NQp9osIOuc iI2Yv4F+Wjt4ybyPD0FqtCJtxKKjdP8C0gcY2JddaHmhZ3S+oBEQzIaBY0smEI87eVic rFcpu6fi/F8ohEJW6cCG04X5XGabITw7rfuETg8MZN9s252NpwEtA98ZsHY08oPkOxIm pqTSjoXq5dGghw+qsWsv6KTKiLBI1SWuNKWAVbnRLIMTP3YjBQYCxeF/Offo5BAYB4wP IkCQ== X-Gm-Message-State: APjAAAXQJr7X0/x75jZXU6L0Wu/VPWMdRxeEXusrXC4lC5EnqQuqX4m/ lmAIGvkj4X6wH2024e5cVKw037fNylLDEE3hjKkdfE4n X-Google-Smtp-Source: APXvYqw5+aH4bL287S9avMexnQ9ullMddkQWAbdXDgHdJyLH/ji9rcOcNB2BXcU0Mbr2tX/bT0S6pWAoQvMB/4l78IU= X-Received: by 2002:a92:8307:: with SMTP id f7mr13455897ild.183.1576528431481; Mon, 16 Dec 2019 12:33:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Tue, 17 Dec 2019 07:33:39 +1100 Message-ID: To: clue@ietf.org, draft-ietf-clue-protocol.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000230b520599d82126" Archived-At: Subject: [clue] Fwd: XML review of draft-ietf-clue-protocol-17 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 20:33:58 -0000 --000000000000230b520599d82126 Content-Type: text/plain; charset="UTF-8" FYI, this email never hit the mailing list for some reason. ---------- Forwarded message --------- From: Martin Thomson Date: Wed, 17 Oct. 2018, 11:09 Subject: XML review of draft-ietf-clue-protocol-17 To: I was asked to provide expert review of the registrations for the XML schema in this document and noticed a few problems. I also have a few suggestions. 1. Don't use schemaLocation in this document, especially in the schema, but also in examples 2. Please try to be more consistent with prefixes throughout. The namespace defined in the draft is sometimes given no prefix, sometimes the overly generic "ns2". I appreciate that these are generated examples, but more thought needs to be given to that. In particular, the schema assigns two different prefixes to the same namespace. 3. This definition is useless: All that a definition like this does is force people to waste bytes. The namespace is sufficient to identify the protocol. Use of fixed and required attributes is best left to restrictions of complex types. 4. You can add the attribute extension point to the base message definition. Element extensions unfortunately have to be attached to specific message types for ordering reasons, but attributes are unordered. 5. Consider vertical whitespace in your code. It helps readability considerably. --000000000000230b520599d82126 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI, this email never hit the mailing list for some reaso= n.

---------- Forwarded message ---------
From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 17 Oct. 2018, 11:09
Subject: XML review of draft-ietf-= clue-protocol-17
To: <clue@ietf.org= >


I was asked to provide expert review of the regis= trations for the XML
schema in this document and noticed a few problems.=C2=A0 I also have a few=
suggestions.

1. Don't use schemaLocation in this document, especially in the
schema, but also in examples

2. Please try to be more consistent with prefixes throughout.=C2=A0 The
namespace defined in the draft is sometimes given no prefix, sometimes
the overly generic "ns2".=C2=A0 I appreciate that these are gener= ated
examples, but more thought needs to be given to that.=C2=A0 In particular,<= br> the schema assigns two different prefixes to the same namespace.

3. This definition is useless:

=C2=A0 =C2=A0 <xs:attribute name=3D"protocol" type=3D"xs:= string" fixed=3D"CLUE"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 use=3D"required" />

All that a definition like this does is force people to waste bytes.
The namespace is sufficient to identify the protocol.=C2=A0 Use of fixed and required attributes is best left to restrictions of complex types.

4. You can add the attribute extension point to the base message
definition.=C2=A0 Element extensions unfortunately have to be attached to specific message types for ordering reasons, but attributes are
unordered.

5. Consider vertical whitespace in your code.=C2=A0 It helps readability considerably.
--000000000000230b520599d82126-- From nobody Mon Dec 16 14:01:20 2019 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AB3120934; Mon, 16 Dec 2019 14:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=RsPMxcF8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hHYCmL7R 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 YeQoeMoug_eU; Mon, 16 Dec 2019 14:01:16 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E006120933; Mon, 16 Dec 2019 14:01:16 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 500FE217FC; Mon, 16 Dec 2019 17:01:15 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 16 Dec 2019 17:01:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=2fql0PbJKvW+xABFvJ3RJ7/UmcVzlGT+UA9eEW9enAY=; b=RsPMxcF8 kMFJCOteCJbXF7XNtOL3cv413USV4wQdCSZ2AkAJyG5QgPxXsduLDZmavYCIa8os 8LvDjSYrap6S7j73uUDsNLW1AEuSdqHzQPinLEK8/NMTyUiQb8AtvAp1zqUWvQgk 3oJoUvE+8TUalNDQs/vGlboOtNqsNvsZXWZWgbvnyu16Wg3wgyw70+/g/wTeEac7 Welrdp++6H4cSQ8jsxcSRsrFcnkWAq03qcWwPiP+amZ0JFRpeUf4Syn1saqdonpJ f5CiCbIa1JRXU7hsTveDL7EvHd2oxAx3j8e/MarDfyKz1SZ/wVNnx23tlUL491D8 IJTmIbZliqQkMw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=2fql0PbJKvW+xABFvJ3RJ7/UmcVzl GT+UA9eEW9enAY=; b=hHYCmL7RwQsqx6lCBmfnxE4uQWEX/znpXhwvJbELg2aBP c4ZmEWGFdsSWkXgPQmMGQ0iYz8c64P3lBI640TiaGE3557TnWk3jo8/z9mwcjDbc FszvcuSJ6XtLraaEAywNoffgpbu3SayTI/HpwE6OX4Gbc/X7ZZgSwj5MPSGQEVj1 mT+NPropahGAGZqkFF2jM3nMuG8ISejq+9xkkjrl2ImN43gQB2mejMxoqHUotCGB Dh+LapW+FMSV4s47UmhVbJPtFYRr2AUFTF26BDNm6o7+JWxjliKPX4sMXactN+Fx oS2n0uxLyvEh2gA972i0eBcwk0XWRWTxKTVcUmBrw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddthedgudehiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EC6E7E00AE; Mon, 16 Dec 2019 17:01:14 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-680-g58d4e90-fmstable-20191213v1 Mime-Version: 1.0 Message-Id: <7d93fd15-98ac-40ed-be43-d1ecde3e5d4e@www.fastmail.com> Date: Tue, 17 Dec 2019 09:00:54 +1100 From: "Martin Thomson" To: clue@ietf.org, draft-ietf-clue-protocol.all@ietf.org Content-Type: text/plain Archived-At: Subject: [clue] XML review of draft-ietf-clue-protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 22:01:18 -0000 (I sent the original of this email in October 2018, then forgot about it. Apparently it never made it through. Here's hoping that it works this time. Trying with a different, maybe better privileged, account.) --- I was asked to provide expert review of the registrations for the XML schema in this document and noticed a few problems. I also have a few suggestions. 1. Don't use schemaLocation in this document, especially in the schema, but also in examples. 2. Please try to be more consistent with prefixes throughout. The namespace defined in the draft is sometimes given no prefix, sometimes the overly generic "ns2". I appreciate that these are generated examples, but more thought needs to be given to that. In particular, the schema assigns two different prefixes to the same namespace. 3. This definition is useless: All that a definition like this does is force people to waste bytes. The namespace is sufficient to identify the protocol. Use of fixed and required attributes is best left to restrictions of complex types. 4. You can add the attribute extension point to the base message definition. Element extensions unfortunately have to be attached to specific message types for ordering reasons, but attributes are unordered. 5. Consider vertical whitespace in your code. It helps readability considerably. From nobody Mon Dec 16 17:39:27 2019 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F5712096E; Mon, 16 Dec 2019 17:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=E2dKPuHO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HT5Us5VB 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 AkIHp40aqqXD; Mon, 16 Dec 2019 17:39:22 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BFBD120945; Mon, 16 Dec 2019 17:39:22 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 81E38221F8; Mon, 16 Dec 2019 20:39:21 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 16 Dec 2019 20:39:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=A19Egj8a6EotIKJddv702DG3glMgKGw O9bztx+4vq5Y=; b=E2dKPuHOWsqzec+eoeDzqHP2jshutnKV4/hHQW2YVicniM3 w0r0vdxsVp0r9I8cLrxZvomJdCdDyvyTO1yjtO6+ZMJ8awrDNriGX1UtHWdaJs/d FcXk+FFuRXDlDo2LHIGkLJoZwRRmP37zCHcBfIhbGZGabtvWzlHYR3KaZh8Vjqph bX/uZi3rqvGw63WSByK2JApX7Ot5gWsiD8eyOlIRA9c6tcNvY59uF4Gjm2cyFdCp ZsyOk/13bxnR/Vlx7UiAcLpJRCNJTtcvkAhtqM+zfwiBd7XcACpHzPOQ+AOWYFPW DBQZST8Frgbmtbzdf/WA2hyavymSJGFYITKGsww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=A19Egj 8a6EotIKJddv702DG3glMgKGwO9bztx+4vq5Y=; b=HT5Us5VBcJYkj9oh+Gd8ft D/2PKWuPLxBTSvhamxcfdlachszwguaffogahcwdNRx0R+vtulfwdwoC+V4T9xzl SLzm3aNZDSuDcFv03rxIuI25trgJmw86/RmBJP/NrNYztZZ3aR7p/RXbrRhoXJBI pSWr84APkPnrJveOTvzplIMpdiv/sMr6irfji+2IjwKeL9cvi0lc09WDHxEhyYt1 RuthEDoPVwIdQnHlvaJTkIDe3T3yjONboiqQoh7L1DLUYRXr8eZQzzzPsL4yE7Dg MYlQ0keVzRbHFpXxfa1XlyzpZaF8+hcj3c01x0cIqB2ii17LFqqGZ2HgIAz85ZKA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddtiedgfeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepuhhnihhnrgdrihhtnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1A7EFE00A2; Mon, 16 Dec 2019 20:39:21 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-689-g5a57b82-fmstable-20191216v1 Mime-Version: 1.0 Message-Id: <9f6bd42b-1b7a-454c-8ee4-8aa0f2e66eef@www.fastmail.com> In-Reply-To: <7d93fd15-98ac-40ed-be43-d1ecde3e5d4e@www.fastmail.com> References: <7d93fd15-98ac-40ed-be43-d1ecde3e5d4e@www.fastmail.com> Date: Tue, 17 Dec 2019 12:39:01 +1100 From: "Martin Thomson" To: clue@ietf.org, draft-ietf-clue-protocol.all@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [clue] XML review of draft-ietf-clue-protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2019 01:39:25 -0000 In the form of RFC editor notes for the first item: Section 9: REMOVE: NOTE TO THE RFC-Editor: Please replace "data-model-schema-19.xsd" with the right schema location for the CLUE data model schema document (which is still to be defined at the time of this writing) in this section prior to publication as an RFC. REMOVE: xmlns:tns="urn:ietf:params:xml:ns:clue-protocol" OLD: NEW: And in Sections 10.1 through 10.9: REMOVE: xsi:schemaLocation="urn:ietf:params:xml:ns:clue-protocol http://wpage.unina.it/spromano/clue-protocol-17-schema-file.xsd" The others would have been better to fix, but they don't need to block document publication. On Tue, Dec 17, 2019, at 09:00, Martin Thomson wrote: > (I sent the original of this email in October 2018, then forgot about > it. Apparently it never made it through. Here's hoping that it works > this time. Trying with a different, maybe better privileged, account.) > --- > > I was asked to provide expert review of the registrations for the XML > schema in this document and noticed a few problems. I also have a few > suggestions. > > 1. Don't use schemaLocation in this document, especially in the > schema, but also in examples. > > 2. Please try to be more consistent with prefixes throughout. The > namespace defined in the draft is sometimes given no prefix, sometimes > the overly generic "ns2". I appreciate that these are generated > examples, but more thought needs to be given to that. In particular, > the schema assigns two different prefixes to the same namespace. > > 3. This definition is useless: > > use="required" /> > > All that a definition like this does is force people to waste bytes. > The namespace is sufficient to identify the protocol. Use of fixed > and required attributes is best left to restrictions of complex types. > > 4. You can add the attribute extension point to the base message > definition. Element extensions unfortunately have to be attached to > specific message types for ordering reasons, but attributes are > unordered. > > 5. Consider vertical whitespace in your code. It helps readability > considerably. From nobody Mon Dec 23 23:42:40 2019 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 3DA36120052; Mon, 23 Dec 2019 23:42:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ron.even.tlv@gmail.com, adam@nostrum.com, clue-chairs@ietf.org, clue@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157717335921.2357.11997169084898455393.idtracker@ietfa.amsl.com> Date: Mon, 23 Dec 2019 23:42:39 -0800 Archived-At: Subject: [clue] clue - Not having a session at IETF 107 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2019 07:42:39 -0000 Roni Even, a chair of the clue working group, indicated that the clue working group does not plan to hold a session at IETF 107. This message was generated and sent by the IETF Meeting Session Request Tool.