From nobody Wed Jun 1 00:47:01 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C16B512B054; Wed, 1 Jun 2016 00:46:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160601074658.16192.65128.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2016 00:46:58 -0700 Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-data-model-schema@ietf.org Subject: [clue] Alexey Melnikov's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 07:46:59 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-clue-data-model-schema-15: Discuss 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-data-model-schema/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is generally a well written document, but I have a couple of very small points that need to be fixed: Abstract: I have no CLUE what you are talking about. Abstracts should be self contained, i.e. being understandable on its own. The Introduction section has more relevant text which you might want to copy here. In 11.13: you need to have a Normative Reference to the language tag document here (RFC 5646) when you describe the "lang" attribute. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In 11.24.1: A reference to xCard would be good to have here. In 16.30: MIME type name typo on the Subject line. "Application that use this media type: none ?" I don't think this is correct. Please provide some examples of applications that would be using this media type. If no applications are going to be using this media type, there is no need to register it ;-). From nobody Wed Jun 1 07:22:35 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 043AF12D599; Wed, 1 Jun 2016 07:22:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160601142232.16192.40456.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2016 07:22:32 -0700 Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-data-model-schema@ietf.org Subject: [clue] Ben Campbell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 14:22:34 -0000 Ben Campbell has entered the following ballot position for draft-ietf-clue-data-model-schema-15: Discuss 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-data-model-schema/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- - 11.2: I would like to discuss whether it's a good idea to allow arbitrary values for mediaType, beyond those types registered in IANA. The text seem to encourage proprietary values. Did the working group consider requiring IANA registration of some sort for new values? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: -11.10 - I have a similar question for as for mediaType. I didn't put it in the discuss because I think will have an overall smaller impact on interoperability. But I's still like to see discussion about why arbitrary values do not create an interop problem. - 15, 2nd and 3rd paragraph: Would it be reasonable to promote the SHOULD to a MUST when privacy sensitive or individually identifiable information is carried? Editorial and Nits: - The shepherd mentions a hope for an xml review during IESG processing. has that occurred? (If so, an update to the shepherd write up would be helpful.) -1, third paragraph, first sentence - I don't understand what the sentence means. -3, "CLUE Participant" - It seems a bit odd to repeat all the framework definitions here, but not repeat the one definition from the protocol doc. - 4, last sentence : "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'm not sure what that means. Can you elaborate? -11, first paragraph : "The features that are common to all media types appear within the media capture type, that has been designed as an abstract complex type." s/that/which -11.6: "...no MUST be provided." Consider promoting the negation into the 2119 keyword. E.g., "... MUST NOT be provided." - 11.7: "A multiple content capture is made by different captures" Should "made by" be "made up of"? -- "MAY show in its XML data model representation the element." Hard to parse. Consider " ... MAY show the element in its XML data model representation." -- "It is composed by a list of media capture identifiers" What is the antecedent of "It"? - 11.6: s/highly-dinamic/highly-dynamic - 13: "It has been conceived only for data model testing purposes..." What is the antecedent for "It"? - 15, 2nd paragraph: "Data model information carried within CLUE messages SHOULD be accessed only by authenticated endpoints." should "accessed" be "accessible"? (As it stands, it seems to depend on good behavior of endpoints, which I assume is not the intent.) -- "There might be more exceptions... More than what? - Normative References: It seems a bit odd to see these second (although I don't know if there is an actual "rule" about that.) Also, the shepherd write up said that there were only informative references. I assume these were added after the fact. It would be very helpful if shepherds would update the write ups when things are overtaken by events. From nobody Wed Jun 1 09:43:13 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D3F12D0AE; Wed, 1 Jun 2016 09:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfrP4gQXa7-h; Wed, 1 Jun 2016 09:43:05 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A2412B00E; Wed, 1 Jun 2016 09:43:05 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id z87so37251181wmh.0; Wed, 01 Jun 2016 09:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=Fe7SyyAMErVkipCGeTgvpOgQsqVjhaNUcWB9IdIN9pU=; b=ca/TTBymL3pvtFKaIy2VHuHwg7EfOhr++wzKQQwuoAE/K6EQgb4N6F+az1JfVemm0h tPhzNnAin4oNWbSvoILYf/SoeHI7kcbZTyW9viz9S/c34IFnPRLkkbEexpOd4hnuZdXS rXoER5WiBTJpHq+pJZqVP2J6v+AH3uDUqRWZcOFG/g+HYzyQnqtNim2bSsDeH5FNRglW hXcTdTJPklXvSznz5VcRiuYqO5EeQ+GKqHLL1puf6cJlkFNw+AhZSSFAlcMaCx6Mkoyu O5WbYRNcImuIqIwUqHEOyzh8S+pGntbhGOSiujsekzNDk2xtREAOKEU11a+76A06B/ns 3njw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=Fe7SyyAMErVkipCGeTgvpOgQsqVjhaNUcWB9IdIN9pU=; b=WOlFr7LzU4HdwXDDtC5gxCxNyEbk+6CmRH8TK4Eg2lBzImEXfgg7R2Du7UgNceIjYw rPVjSr6VN3nwd2e5eKzkaabcMreOEV+j6h1CaWb+aLYctpn0PWTd7HVkfTX3k9iF/9an SoJIFdBjcM5fZ4d/eF2DWXEpO4lHeN7WGkxC4MCyxM+VfbmCF2k7ufs1DYRiIhegoiq8 Pg4sIdtzfyHPMxxdtn7mGMZe+unzRdRMk4XcNfCZ0LRuwCKi9qIEuCTwFalpZYO5ubw/ bsQxQpwZY1uQSUvDu0kMKDcjlFYQ7ObaT4u2QyHnlupKLTQTwX8dpQyPzWpu3coSAFZX NlUQ== X-Gm-Message-State: ALyK8tIj25Y7DoEcP2UYxKKk0prp69dbiPwmln7CVm+hFq9PUIbyn4QJXZTSbHJDeW/BLQ== X-Received: by 10.194.221.37 with SMTP id qb5mr4372001wjc.171.1464799383791; Wed, 01 Jun 2016 09:43:03 -0700 (PDT) Received: from RoniPC (bzq-79-178-104-140.red.bezeqint.net. [79.178.104.140]) by smtp.gmail.com with ESMTPSA id r129sm6379799wmr.20.2016.06.01.09.43.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 09:43:02 -0700 (PDT) From: "Roni Even" To: "'Ben Campbell'" , "'The IESG'" References: <20160601142232.16192.40456.idtracker@ietfa.amsl.com> In-Reply-To: <20160601142232.16192.40456.idtracker@ietfa.amsl.com> Date: Wed, 1 Jun 2016 19:41:46 +0300 Message-ID: <061e01d1bc24$7de529b0$79af7d10$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_061F_01D1BC3D.A3334C10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI2BgOBuMOMks1XZhw3DxLLYZoTTJ8MOyAg Content-Language: he Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Ben Campbell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 16:43:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_061F_01D1BC3D.A3334C10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Inline Roni > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, June 01, 2016 5:23 PM > To: The IESG > Cc: draft-ietf-clue-data-model-schema@ietf.org; clue-chairs@ietf.org; > ron.even.tlv@gmail.com; clue@ietf.org > Subject: Ben Campbell's Discuss on = draft-ietf-clue-data-model-schema-15: > (with DISCUSS and COMMENT) >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-clue-data-model-schema-15: Discuss >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > - 11.2: I would like to discuss whether it's a good idea to allow = arbitrary > values for mediaType, beyond those types registered in IANA. > The text seem to encourage proprietary values. Did the working group > consider requiring IANA registration of some sort for new values? [Roni Even] ] I think that the meaning was to allow the media types from = the IANA registry = http://www.iana.org/assignments/media-types/media-types.xhtml . The = issue will be about the usage of other media types in the CLUE = environment and not about the values themselves. Alissa also suggested that we clarify it >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Substantive: >=20 > -11.10 - I have a similar question for as for mediaType. I = didn't put it > in the discuss because I think will have an overall smaller = impact on > interoperability. But I's still like to see discussion about why = arbitrary values > do not create an interop problem. >=20 >=20 > - 15, 2nd and 3rd paragraph: Would it be reasonable to promote the = SHOULD > to a MUST when privacy sensitive or individually identifiable = information is > carried? >=20 >=20 > Editorial and Nits: >=20 > - The shepherd mentions a hope for an xml review during IESG = processing. > has that occurred? (If so, an update to the shepherd write up would be > helpful.) [Roni Even] An XML review was done by Henry Thompson = https://mailarchive.ietf.org/arch/msg/clue/1WeFBrIo17CLL_t_6anoHAHMwqg =20 >=20 > -1, third paragraph, first sentence - I don't understand what the = sentence > means. >=20 > -3, "CLUE Participant" - It seems a bit odd to repeat all the = framework > definitions here, but not repeat the one definition from the protocol = doc. >=20 > - 4, last sentence : "As a general remark, please notice that optional > elements that don=E2=80=99t define what their absence means are = intended to be > associated with undefined properties." >=20 > I'm not sure what that means. Can you elaborate? >=20 > -11, first paragraph : "The features that are common to all media = types > appear within the media capture type, that has been designed as an > abstract complex type." >=20 > s/that/which >=20 > -11.6: "...no MUST be provided." >=20 > Consider promoting the negation into the 2119 keyword. E.g., "... > MUST NOT be provided." >=20 > - 11.7: "A multiple content capture is made > by different captures" >=20 > Should "made by" be "made up of"? >=20 > -- "MAY show in its XML data model > representation the element." >=20 > Hard to parse. Consider " ... MAY show the element in its = XML > data model representation." >=20 > -- "It is composed by a list of > media capture identifiers" >=20 > What is the antecedent of "It"? >=20 > - 11.6: s/highly-dinamic/highly-dynamic >=20 > - 13: "It has been conceived only for data model testing purposes..." > What is the antecedent for "It"? >=20 > - 15, 2nd paragraph: "Data model information carried within CLUE = messages > SHOULD be > accessed only by authenticated endpoints." >=20 > should "accessed" be "accessible"? (As it stands, it seems to depend = on good > behavior of endpoints, which I assume is not the intent.) >=20 > -- "There might be more exceptions... > More than what? >=20 > - Normative References: > It seems a bit odd to see these second (although I don't know if there = is an > actual "rule" about that.) Also, the shepherd write up said that there = were > only informative references. I assume these were added after the fact. = It > would be very helpful if shepherds would update the write ups when = things > are overtaken by events. ------=_NextPart_000_061F_01D1BC3D.A3334C10 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment From: "Roni Even" To: "'Henry S. Thompson'" , , Cc: References: In-Reply-To: Subject: RE: Appsdir review of XML schema in https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-14 Date: Thu, 12 May 2016 18:36:07 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFyRqhATyze6PpciVH2FXJ9BrlVHKB0OnUA Content-Language: he Thanks for the review, I forwarded it also to the CLUE WG mailing list Roni Even CLUE WG co-chair > -----Original Message----- > From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk] > Sent: Wednesday, May 11, 2016 6:58 PM > To: apps-discuss@ietf.org; draft-ietf-clue-data-model-schema.all@ietf.org > Cc: iesg@ietf.org > Subject: Appsdir review of XML schema in https://tools.ietf.org/html/draft- > ietf-clue-data-model-schema-14 > > [Argh, fumble-finger -- resending with correct address lines] > > Document: draft-ietf-clue-data-model-schema > Title: An XML Schema for the CLUE data model > Reviewer: Henry S. Thompson > Review Date: 2016-05-11 > IETF Last Call Date: 2016-05-23 > ESG Telechat Date: 2016-06-02 > > I have been selected as the Applications Area Directorate reviewer for this > draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > > Please resolve these comments along with any other Last Call comments you > may receive. Please wait for direction from your document shepherd or AD > before posting a new version of the draft. > > Summary: The XML Schema itself which is included in this draft is conformant > to the XML Schema 1.0 spec, and is good to go, subject to a minor > correction. There is a minor glitch in one of the XML examples, also easily > corrected. > > Comments: > > I tested the XML Schema document included as section 4 and it passes as > valid against the schema for schemas. The example document in section > 17 is schema-valid according to the corresponding schema. See 'Nits' > below for a minor problem with the example document in section 18. > > I briefly reviewed the schema document and it seems straightforward and fit > for its intended purpose. > > Minor Issues: > > Section 4, lines 13--14: > > schemaLocation="xcard.xsd"/> > > As this stands, it's not actually usable for validation purposes, because no > xcard.xsd file is supplied. Furthermore, there is no Appendix A, which is > alleged to provide it (see 11.29.1.2). > > I note further that the xCard RFC (6351) doesn't contain an XSD-format > schema document either. The IANA XML Registry [1] schema entry for the > urn:ietf:params:xml:ns:vcard-4.0 URN namespace _does_ however link to > such a schema document [2]. I suggest you either > a) Edit the draft so the above lines read > > schemaLocation="http://www.iana.org/assignments/xml- > registry/schema/vcard-4.0.xsd"/> > > (this is what I did to do the validity checks I did); > > or > > b) Delete the schemaLocation attribute and add a comment identifying > possible sources of a schema document for the vcard-4.0 namespace, > e.g. the above iana.org URI or the contents of Appendix A (if you > fill it in). > > Nits: > > Section 18, the XML example has a (copy-paste?) error, which renders that > example invalid against the schema. The line > > EG0 > > appears twice inside mediaCapture VC7, once on line 204 and once on line > 237. The first occurrence should be deleted. > > [1] http://www.iana.org/assignments/xml-registry/xml- > registry.xhtml#schema > [2] http://www.iana.org/assignments/xml-registry/schema/vcard-4.0.xsd > -- > Henry S. Thompson, School of Informatics, University of Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has > a .sig like this -- mail without it is forged spam] ------=_NextPart_000_061F_01D1BC3D.A3334C10-- From nobody Wed Jun 1 10:18:16 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8C012D15F; Wed, 1 Jun 2016 10:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=x/FGL3l5; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=kE3tH4em 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 QmE51r6mO9ze; Wed, 1 Jun 2016 10:18:09 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E70F12B04D; Wed, 1 Jun 2016 10:18:09 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 616C3207C6; Wed, 1 Jun 2016 13:18:06 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 01 Jun 2016 13:18:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=FCV/tfRX7aRgSgow2jvU+09WcSM=; b=x/FGL3 l5f/rdf4GRx8tKitKal7wn6Y/7yC3xP5Uf0AAkrS74Gr6oSY4CUHfnfGs2mhe0yt 7JZymyu9Rh8w0btyCqgHz3K+pmTdMbgXco8syvO7jyWCSpmkY4YcDazi2+9zMXB9 Cs4hOi8CVEMP0N9Z9huJ2vT6/swTK16oHrlkU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=FCV/tfRX7aRgSgo w2jvU+09WcSM=; b=kE3tH4emwUZV7OPRWv3M1DsBv4F/rgSQRY/zo6aslK7swmU VZC+1kKi19XNvm7W+8droDztgVFs6vbXumIJGVp/KP8F6yJtlnE2HBwJmEooQiy2 +JT1kvitRgcgUHrYRwTZVzEM+leBo/hrGbgsGg3CGIsyQYm+mlhoQpl6hs6k= X-Sasl-enc: Q0s6OotiQMrCvG/5rK+YGH3l4uMmaLB/W49mykrs7sAA 1464801486 Received: from dhcp-171-68-20-157.cisco.com (dhcp-171-68-20-157.cisco.com [171.68.20.157]) by mail.messagingengine.com (Postfix) with ESMTPA id 786F1F2A5B; Wed, 1 Jun 2016 13:18:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <061e01d1bc24$7de529b0$79af7d10$@gmail.com> Date: Wed, 1 Jun 2016 10:18:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160601142232.16192.40456.idtracker@ietfa.amsl.com> <061e01d1bc24$7de529b0$79af7d10$@gmail.com> To: Roni Even X-Mailer: Apple Mail (2.3124) Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, IESG , draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Ben Campbell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 17:18:11 -0000 > On Jun 1, 2016, at 9:41 AM, Roni Even wrote: >=20 > Inline > Roni >=20 >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, June 01, 2016 5:23 PM >> To: The IESG >> Cc: draft-ietf-clue-data-model-schema@ietf.org; clue-chairs@ietf.org; >> ron.even.tlv@gmail.com; clue@ietf.org >> Subject: Ben Campbell's Discuss on = draft-ietf-clue-data-model-schema-15: >> (with DISCUSS and COMMENT) >>=20 >> Ben Campbell has entered the following ballot position for >> draft-ietf-clue-data-model-schema-15: Discuss >>=20 >> 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.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> - 11.2: I would like to discuss whether it's a good idea to allow = arbitrary >> values for mediaType, beyond those types registered in IANA. >> The text seem to encourage proprietary values. Did the working group >> consider requiring IANA registration of some sort for new values? >=20 >=20 > [Roni Even] ] I think that the meaning was to allow the media types = from the IANA registry = http://www.iana.org/assignments/media-types/media-types.xhtml . The = issue will be about the usage of other media types in the CLUE = environment and not about the values themselves. > Alissa also suggested that we clarify it I asked this same question in my AD review and Simon updated the text. I = think the text as it is now is clear, but the question is whether the = approach is the best one. I think overall this spec favors customization = over interop more than I personally would have liked, but the WG did = have consensus around this particular trade-off and other similar ones, = so I respect that. Alissa From nobody Wed Jun 1 10:24:26 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7189C12D5B7; Wed, 1 Jun 2016 10:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_rcRp240b0y; Wed, 1 Jun 2016 10:24:18 -0700 (PDT) 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 ED59C12D5DE; Wed, 1 Jun 2016 10:24:17 -0700 (PDT) Received: from [10.10.1.2] ([162.216.46.76]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u51HODUc027933 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Jun 2016 12:24:15 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.76] claimed to be [10.10.1.2] From: "Ben Campbell" To: "Roni Even" Date: Wed, 01 Jun 2016 13:24:13 -0400 Message-ID: <4698EF47-EF15-4B33-9A14-4E2FB2A35488@nostrum.com> In-Reply-To: <061e01d1bc24$7de529b0$79af7d10$@gmail.com> References: <20160601142232.16192.40456.idtracker@ietfa.amsl.com> <061e01d1bc24$7de529b0$79af7d10$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, The IESG , draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Ben Campbell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 17:24:24 -0000 Also inline, On 1 Jun 2016, at 12:41, Roni Even wrote: > Inline > Roni > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, June 01, 2016 5:23 PM >> To: The IESG >> Cc: draft-ietf-clue-data-model-schema@ietf.org; clue-chairs@ietf.org; >> ron.even.tlv@gmail.com; clue@ietf.org >> Subject: Ben Campbell's Discuss on >> draft-ietf-clue-data-model-schema-15: >> (with DISCUSS and COMMENT) >> >> Ben Campbell has entered the following ballot position for >> draft-ietf-clue-data-model-schema-15: Discuss >> >> 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-data-model-schema/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> - 11.2: I would like to discuss whether it's a good idea to allow >> arbitrary >> values for mediaType, beyond those types registered in IANA. >> The text seem to encourage proprietary values. Did the working group >> consider requiring IANA registration of some sort for new values? > > > [Roni Even] ] I think that the meaning was to allow the media types > from the IANA registry > http://www.iana.org/assignments/media-types/media-types.xhtml . The > issue will be about the usage of other media types in the CLUE > environment and not about the values themselves. > Alissa also suggested that we clarify it I'm not sure I understand your response. When you say "other media types", do you mean other types that are registered in the media-type registry, but not described in RFC6838? Or other arbitary media types that are not registered or otherwise publicly documented? > >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Substantive: >> >> -11.10 - I have a similar question for as for mediaType. I >> didn't put it >> in the discuss because I think will have an overall smaller >> impact on >> interoperability. But I's still like to see discussion about why >> arbitrary values >> do not create an interop problem. >> >> >> - 15, 2nd and 3rd paragraph: Would it be reasonable to promote the >> SHOULD >> to a MUST when privacy sensitive or individually identifiable >> information is >> carried? >> >> >> Editorial and Nits: >> >> - The shepherd mentions a hope for an xml review during IESG >> processing. >> has that occurred? (If so, an update to the shepherd write up would >> be >> helpful.) > [Roni Even] An XML review was done by Henry Thompson > https://mailarchive.ietf.org/arch/msg/clue/1WeFBrIo17CLL_t_6anoHAHMwqg Thanks, I saw that shortly after sending. >> >> -1, third paragraph, first sentence - I don't understand what the >> sentence >> means. >> >> -3, "CLUE Participant" - It seems a bit odd to repeat all the >> framework >> definitions here, but not repeat the one definition from the protocol >> doc. >> >> - 4, last sentence : "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'm not sure what that means. Can you elaborate? >> >> -11, first paragraph : "The features that are common to all media >> types >> appear within the media capture type, that has been designed as an >> abstract complex type." >> >> s/that/which >> >> -11.6: "...no MUST be provided." >> >> Consider promoting the negation into the 2119 keyword. E.g., "... >> MUST NOT be provided." >> >> - 11.7: "A multiple content capture is made >> by different captures" >> >> Should "made by" be "made up of"? >> >> -- "MAY show in its XML data model >> representation the element." >> >> Hard to parse. Consider " ... MAY show the element in its >> XML >> data model representation." >> >> -- "It is composed by a list of >> media capture identifiers" >> >> What is the antecedent of "It"? >> >> - 11.6: s/highly-dinamic/highly-dynamic >> >> - 13: "It has been conceived only for data model testing purposes..." >> What is the antecedent for "It"? >> >> - 15, 2nd paragraph: "Data model information carried within CLUE >> messages >> SHOULD be >> accessed only by authenticated endpoints." >> >> should "accessed" be "accessible"? (As it stands, it seems to depend >> on good >> behavior of endpoints, which I assume is not the intent.) >> >> -- "There might be more exceptions... >> More than what? >> >> - Normative References: >> It seems a bit odd to see these second (although I don't know if >> there is an >> actual "rule" about that.) Also, the shepherd write up said that >> there were >> only informative references. I assume these were added after the >> fact. It >> would be very helpful if shepherds would update the write ups when >> things >> are overtaken by events. From nobody Wed Jun 1 10:27:08 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33A312D5B7; Wed, 1 Jun 2016 10:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=iCDXpYYA; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=pHS6FD3W 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 m6D9Gw0QLuJS; Wed, 1 Jun 2016 10:27:04 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDEEB12D0E5; Wed, 1 Jun 2016 10:27:03 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4880E2126E; Wed, 1 Jun 2016 13:27:03 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 01 Jun 2016 13:27:03 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=aRtvz3sJF/0Qmk2j50on2hpCtYE=; b=iCDXpY YAJ9QB7DWvkTBcFBmLcE/Vavk5aKaD6vNtPb4WcptQjIylvmcVI521xshsBYfeDu 7HZj5ttKMSe3cQ+F3DxD+rVu2KDvuDVnBTmumoYsv7qtnnZcwF/BihVanO+o+hFW 1pdEHAu+zYPrWlU3mKjFPRGWbzhDMoVjZ2H1s= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=aRtvz3sJF/0Qmk2 j50on2hpCtYE=; b=pHS6FD3WbtbpXaUbQ1qHQG+wan1vvMku82v5soF9USQSqkZ tUrdm4fAXos/zCLmNid0WpEBcLk8KvMQBNXg8/6xDZ7XoNgr7sshItIY5IGDNTWC IGYY2gmMtnxYRFEKcuUjYMsSZWGSXKu/6Jr7mykYMOo7O2bY2wKRdgr28zG0= X-Sasl-enc: BXHRtLHfUFvly+3cRzMBCsydPtMrzECQOSqBi7bXiGtP 1464802022 Received: from dhcp-171-68-20-157.cisco.com (dhcp-171-68-20-157.cisco.com [171.68.20.157]) by mail.messagingengine.com (Postfix) with ESMTPA id 83D96F2A4D; Wed, 1 Jun 2016 13:27:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20160531213800.20195.51327.idtracker@ietfa.amsl.com> Date: Wed, 1 Jun 2016 10:27:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <45F69808-DBC1-4A03-95B2-7E8357F59034@cooperw.in> References: <20160531213800.20195.51327.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) Archived-At: Cc: clue-chairs@ietf.org, CLUE , IESG , draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Kathleen Moriarty's Discuss on draft-ietf-clue-data-model-schema-14: (with DISCUSS) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 17:27:06 -0000 Hi Kathleen, > On May 31, 2016, at 2:38 PM, Kathleen Moriarty = wrote: >=20 > Kathleen Moriarty has entered the following ballot position for > draft-ietf-clue-data-model-schema-14: Discuss >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > The document looks good, I just have a couple of items on the security > considerations to discuss as they are not mentioned and I'm not sure = if > they have a good reason to be excluded. >=20 > 1. Session encryption to prevent active (tampering) or passive > (information gathering for example) attacks. Integrity protection and > authentication are mentioned, but without looking through a few > documents, I don't know if that means encryption or some hash value > comparisons or something else.=20 This is covered in the documents referenced in Section 25: = draft-ietf-clue-framework, draft-ietf-clue-datachannel, and = draft-ietf-clue-protocol. Alissa >=20 > 2. Schema drafts tend to cover the need for well-formed schemas as = part > of the security considerations. Can you add something in about that = (not > much is required, but it's good for implementers to know this is > important)? You can see two recent examples for guidance: > YANG - https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ > IODEF - https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ >=20 >=20 >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Jun 1 10:36:43 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E96512D168; Wed, 1 Jun 2016 10:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84DMZqDNbxYy; Wed, 1 Jun 2016 10:36:33 -0700 (PDT) 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 04C6712D0B6; Wed, 1 Jun 2016 10:36:32 -0700 (PDT) Received: from [10.10.1.2] ([162.216.46.76]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u51HaPBo028950 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Jun 2016 12:36:27 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.76] claimed to be [10.10.1.2] From: "Ben Campbell" To: "Alissa Cooper" Date: Wed, 01 Jun 2016 13:36:25 -0400 Message-ID: In-Reply-To: References: <20160601142232.16192.40456.idtracker@ietfa.amsl.com> <061e01d1bc24$7de529b0$79af7d10$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, IESG , draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Ben Campbell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 17:36:35 -0000 On 1 Jun 2016, at 13:18, Alissa Cooper wrote: >> On Jun 1, 2016, at 9:41 AM, Roni Even wrote: >> >> Inline >> Roni >> >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@nostrum.com] >>> Sent: Wednesday, June 01, 2016 5:23 PM >>> To: The IESG >>> Cc: draft-ietf-clue-data-model-schema@ietf.org; >>> clue-chairs@ietf.org; >>> ron.even.tlv@gmail.com; clue@ietf.org >>> Subject: Ben Campbell's Discuss on >>> draft-ietf-clue-data-model-schema-15: >>> (with DISCUSS and COMMENT) >>> >>> Ben Campbell has entered the following ballot position for >>> draft-ietf-clue-data-model-schema-15: Discuss >>> >>> 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-data-model-schema/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> - 11.2: I would like to discuss whether it's a good idea to allow >>> arbitrary >>> values for mediaType, beyond those types registered in IANA. >>> The text seem to encourage proprietary values. Did the working group >>> consider requiring IANA registration of some sort for new values? >> >> >> [Roni Even] ] I think that the meaning was to allow the media types >> from the IANA registry >> http://www.iana.org/assignments/media-types/media-types.xhtml . The >> issue will be about the usage of other media types in the CLUE >> environment and not about the values themselves. >> Alissa also suggested that we clarify it > > I asked this same question in my AD review and Simon updated the text. > I think the text as it is now is clear, but the question is whether > the approach is the best one. I think overall this spec favors > customization over interop more than I personally would have liked, > but the WG did have consensus around this particular trade-off and > other similar ones, so I respect that. I reviewed 14. Checking 15... Yes, that is more clear. I can accept that as working group consensus (and will clear). But as a "COMMENT", I think it might be helpful to add a sentence or two about why working group chose to balance things that way. Do people expect custom media types to be rare? Is there any concern about media-type name collisions? Ben. From nobody Wed Jun 1 10:37:55 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BE712D0E5; Wed, 1 Jun 2016 10:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=Xwy31twT; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=FLA+y12R 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 ICGYGwij_qaF; Wed, 1 Jun 2016 10:37:51 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57EF12D0DC; Wed, 1 Jun 2016 10:37:51 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1B0072139F; Wed, 1 Jun 2016 13:37:51 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Wed, 01 Jun 2016 13:37:51 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=2eR7xxKlxBAO2Agi89Zmh6acTmc=; b=Xwy31t wTuKXS18XGAE8LgtbIycdjCW92e+Uvw72yMMpiWmn8Pus6olpnP8FPpGWTCTypKo 8wLs2dop7iQnAzwT2AJhsf2TS2vPwdyMN8Ofh9WFgboptNaKc+TQk1aXvxWDlcqh dVG7MYUv2QcZ2p/wR2fcWDejfdO7kqLdpTedg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=2eR7xxKlxBAO2Ag i89Zmh6acTmc=; b=FLA+y12RsMUPMaXZOgYyHV1IOlY+pjXubLg2XNaLC2/CMDy SzTk/g6QAIJvWWzMbg7he6099cCvTEAiAUMXNzG+aUBeH4qrKlWBldlgA6K1JW+T ePlnvoRncEmy+mTneyj09Y/ogkGvAI/C4i+BsSSAhPaD6gbUJw+y63mv35IM= Received: by mailuser.nyi.internal (Postfix, from userid 99) id D2030A9021; Wed, 1 Jun 2016 13:37:50 -0400 (EDT) Message-Id: <1464802670.1029662.625029417.5E4385F0@webmail.messagingengine.com> X-Sasl-Enc: yqP36sFu2W2Hj33XG481urHG8ciBM9NDTGFsCsDRV0Ge 1464802670 From: Alexey Melnikov To: Ben Campbell , Roni Even MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-38f217ef Date: Wed, 01 Jun 2016 18:37:50 +0100 In-Reply-To: <4698EF47-EF15-4B33-9A14-4E2FB2A35488@nostrum.com> References: <20160601142232.16192.40456.idtracker@ietfa.amsl.com> <061e01d1bc24$7de529b0$79af7d10$@gmail.com> <4698EF47-EF15-4B33-9A14-4E2FB2A35488@nostrum.com> Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, The IESG , draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Ben Campbell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 17:37:54 -0000 Hi Ben, On Wed, Jun 1, 2016, at 06:24 PM, Ben Campbell wrote: > Also inline, > > On 1 Jun 2016, at 12:41, Roni Even wrote: > > > Inline > > Roni > > > >> -----Original Message----- > >> From: Ben Campbell [mailto:ben@nostrum.com] > >> Sent: Wednesday, June 01, 2016 5:23 PM > >> To: The IESG > >> Cc: draft-ietf-clue-data-model-schema@ietf.org; clue-chairs@ietf.org; > >> ron.even.tlv@gmail.com; clue@ietf.org > >> Subject: Ben Campbell's Discuss on > >> draft-ietf-clue-data-model-schema-15: > >> (with DISCUSS and COMMENT) > >> [snip] > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> - 11.2: I would like to discuss whether it's a good idea to allow > >> arbitrary > >> values for mediaType, beyond those types registered in IANA. > >> The text seem to encourage proprietary values. Did the working group > >> consider requiring IANA registration of some sort for new values? > > > > > > [Roni Even] ] I think that the meaning was to allow the media types > > from the IANA registry > > http://www.iana.org/assignments/media-types/media-types.xhtml . The > > issue will be about the usage of other media types in the CLUE > > environment and not about the values themselves. > > Alissa also suggested that we clarify it > > I'm not sure I understand your response. When you say "other media > types", do you mean other types that are registered in the media-type > registry, but not described in RFC6838? In case it helps: top level media types like "model", "application", "message", and not full media types like "application/pdf". These should be very rare. JUSTFONT WG is working on another one, but this is the first time something was added in more than 10 years. I honestly doubt anything other than "video", "audio" or "text" would be usable for CLUE anyway. > Or other arbitary media types > that are not registered or otherwise publicly documented? I would be impressed if any undocumented or unregistered top level media type would be interoperable, so I don't think any such media types matter. From nobody Wed Jun 1 10:40:10 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DCE12D0A4; Wed, 1 Jun 2016 10:40:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160601174008.16192.12356.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2016 10:40:08 -0700 Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-data-model-schema@ietf.org Subject: [clue] Ben Campbell's No Objection on draft-ietf-clue-data-model-schema-15: (with COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 17:40:08 -0000 Ben Campbell has entered the following ballot position for draft-ietf-clue-data-model-schema-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-data-model-schema/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: I cleared my discuss on 11.2. My original point was as follows: "I would like to discuss whether it's a good idea to allow arbitrary values for mediaType, beyond those types registered in IANA. The text seem to encourage proprietary values. Did the working group consider requiring IANA registration of some sort for new values?" I cleared because discussion showed that the working group thought about this, and made a conscious choice. I think it might still be helpful to add a sentence or two about the motivation for this particular balance between customization and interoperation. For example, do people expect new media-type values to be rare? Are there any concerns about value-collisions? -11.10 - I have a similar question for as for mediaType. I didn't put it in the discuss because I think will have an overall smaller impact on interoperability. But I's still like to see discussion about why arbitrary values do not create an interop problem. - 15, 2nd and 3rd paragraph: Would it be reasonable to promote the SHOULD to a MUST when privacy sensitive or individually identifiable information is carried? Editorial and Nits: - The shepherd mentions a hope for an xml review during IESG processing. has that occurred? (If so, an update to the shepherd write up would be helpful.) -1, third paragraph, first sentence - I don't understand what the sentence means. -3, "CLUE Participant" - It seems a bit odd to repeat all the framework definitions here, but not repeat the one definition from the protocol doc. - 4, last sentence : "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'm not sure what that means. Can you elaborate? -11, first paragraph : "The features that are common to all media types appear within the media capture type, that has been designed as an abstract complex type." s/that/which -11.6: "...no MUST be provided." Consider promoting the negation into the 2119 keyword. E.g., "... MUST NOT be provided." - 11.7: "A multiple content capture is made by different captures" Should "made by" be "made up of"? -- "MAY show in its XML data model representation the element." Hard to parse. Consider " ... MAY show the element in its XML data model representation." -- "It is composed by a list of media capture identifiers" What is the antecedent of "It"? - 11.6: s/highly-dinamic/highly-dynamic - 13: "It has been conceived only for data model testing purposes..." What is the antecedent for "It"? - 15, 2nd paragraph: "Data model information carried within CLUE messages SHOULD be accessed only by authenticated endpoints." should "accessed" be "accessible"? (As it stands, it seems to depend on good behavior of endpoints, which I assume is not the intent.) -- "There might be more exceptions... More than what? - Normative References: It seems a bit odd to see these second (although I don't know if there is an actual "rule" about that.) Also, the shepherd write up said that there were only informative references. I assume these were added after the fact. It would be very helpful if shepherds would update the write ups when things are overtaken by events. From nobody Wed Jun 1 10:46:12 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0044912D1A7; Wed, 1 Jun 2016 10:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OqzT4fMRg1N; Wed, 1 Jun 2016 10:46:07 -0700 (PDT) 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 69D6312D09D; Wed, 1 Jun 2016 10:46:07 -0700 (PDT) Received: from [10.10.1.2] ([162.216.46.76]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u51Hk0RO029921 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Jun 2016 12:46:02 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.76] claimed to be [10.10.1.2] From: "Ben Campbell" To: "Alexey Melnikov" Date: Wed, 01 Jun 2016 13:46:00 -0400 Message-ID: In-Reply-To: <1464802670.1029662.625029417.5E4385F0@webmail.messagingengine.com> References: <20160601142232.16192.40456.idtracker@ietfa.amsl.com> <061e01d1bc24$7de529b0$79af7d10$@gmail.com> <4698EF47-EF15-4B33-9A14-4E2FB2A35488@nostrum.com> <1464802670.1029662.625029417.5E4385F0@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, The IESG , draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Ben Campbell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 17:46:09 -0000 On 1 Jun 2016, at 13:37, Alexey Melnikov wrote: > Hi Ben, > > On Wed, Jun 1, 2016, at 06:24 PM, Ben Campbell wrote: >> Also inline, >> >> On 1 Jun 2016, at 12:41, Roni Even wrote: >> >>> Inline >>> Roni >>> >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>> Sent: Wednesday, June 01, 2016 5:23 PM >>>> To: The IESG >>>> Cc: draft-ietf-clue-data-model-schema@ietf.org; >>>> clue-chairs@ietf.org; >>>> ron.even.tlv@gmail.com; clue@ietf.org >>>> Subject: Ben Campbell's Discuss on >>>> draft-ietf-clue-data-model-schema-15: >>>> (with DISCUSS and COMMENT) >>>> > > [snip] > >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> - 11.2: I would like to discuss whether it's a good idea to allow >>>> arbitrary >>>> values for mediaType, beyond those types registered in IANA. >>>> The text seem to encourage proprietary values. Did the working >>>> group >>>> consider requiring IANA registration of some sort for new values? >>> >>> >>> [Roni Even] ] I think that the meaning was to allow the media types >>> from the IANA registry >>> http://www.iana.org/assignments/media-types/media-types.xhtml . The >>> issue will be about the usage of other media types in the CLUE >>> environment and not about the values themselves. >>> Alissa also suggested that we clarify it >> >> I'm not sure I understand your response. When you say "other media >> types", do you mean other types that are registered in the media-type >> registry, but not described in RFC6838? > > In case it helps: top level media types like "model", "application", > "message", and not full media types like "application/pdf". These > should > be very rare. JUSTFONT WG is working on another one, but this is the > first time something was added in more than 10 years. I honestly doubt > anything other than "video", "audio" or "text" would be usable for > CLUE > anyway. That was my assumption. That's part of why I wondered about the ability to ability to invent arbitrary values. (But note that I've already cleared my DISCUSS.) > >> Or other arbitary media types >> that are not registered or otherwise publicly documented? > > I would be impressed if any undocumented or unregistered top level > media > type would be interoperable, so I don't think any such media types > matter. Does that mean you don't think people will use undocumented media-types due to the lack of interoperability, or that anyone who does will be effectively proprietary and we should assume they don't want to interoperate in the first place? Thanks! Ben. From nobody Wed Jun 1 11:10:18 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC0F12D1AF; Wed, 1 Jun 2016 11:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLMHqsyVOnCq; Wed, 1 Jun 2016 11:10:09 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 8727B12D09D; Wed, 1 Jun 2016 11:10:09 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id y126so20968900qke.1; Wed, 01 Jun 2016 11:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4f3yZC0szKsXnY7m9L6qJ+1yFUfvFgbiDhw1fJ4zROE=; b=rSL5Brxj91ByWNSHhMYRWHEZIh5z1QxophsNqytMu9yNyXp2OKoQVzdhA765j0A3s9 6TSlXo8c0QCd7/LHPqXX/xnGqojt8GvUAqMdPnta2iH36cwQkqgW7eTjTBcRf1b8+1yL hiJsTV8oel5+FtJ12z8fQFt/MHpxKsAR+2TCTpuyTAWr+wgmudyRFtI/RrWV1MLmzRNN 5KUGe7g93oASHH2T3CZgkDZ+Q5sqbZpLyeUoAEELIuiISYeLVb+q593HkXlnx6ZY/Mh7 4whRdzO3hgCgAbCGfmLCtsJwDfz9OcCZ05YNm+rmvl9XrPfkuJ4JPoke7cG1HEL3AVYb SFPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4f3yZC0szKsXnY7m9L6qJ+1yFUfvFgbiDhw1fJ4zROE=; b=KJVwgIWaiMuhO4Rv2aNYzeWTClkhEaIz5VRQ4XxoZAscWG7SaPQWLWLXjJi4KvQ0X3 lL6ogq+b36YsEyatVuv+v7ctW+b/zgqHHurV+VKdg8QJFR9nVcpzRYN21VrjXcPKyHAt bq7SoVorsg4K/wdTMKWrlwJmj0YEmUDgt9DWI/Z7s52/gZF9d8AaZQnD8UK+BVCyZOpw 5KO3bjfoaobjQ/XChKLrLq4sE0Y8FJmuRuacLmXH2xGdQ2RH4hFBVF6syi/rWAeo3pXk UWWhvzBwxWRNYcxbWflZptmNgrSw6efsmlJYBO2ms3DQPA9WY5meCHG7hf6mAQQ8+2YH WqbQ== X-Gm-Message-State: ALyK8tL0eyioOoMJsXabfVIZtf1yvWOK6WIIZ0hQo3r0Gx3RkauYnA8shMDtcgC85FtQGg== X-Received: by 10.55.104.68 with SMTP id d65mr18321503qkc.190.1464804608469; Wed, 01 Jun 2016 11:10:08 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id 7sm9887328qto.21.2016.06.01.11.10.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 11:10:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (12H143) In-Reply-To: <45F69808-DBC1-4A03-95B2-7E8357F59034@cooperw.in> Date: Wed, 1 Jun 2016 14:10:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4A74E266-B15A-4449-9258-7AB19449D1C7@gmail.com> References: <20160531213800.20195.51327.idtracker@ietfa.amsl.com> <45F69808-DBC1-4A03-95B2-7E8357F59034@cooperw.in> To: Alissa Cooper Archived-At: Cc: "clue-chairs@ietf.org" , CLUE , IESG , "draft-ietf-clue-data-model-schema@ietf.org" Subject: Re: [clue] Kathleen Moriarty's Discuss on draft-ietf-clue-data-model-schema-14: (with DISCUSS) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 18:10:12 -0000 Sent from my iPhone > On Jun 1, 2016, at 1:27 PM, Alissa Cooper wrote: >=20 > Hi Kathleen, >=20 >> On May 31, 2016, at 2:38 PM, Kathleen Moriarty wrote: >>=20 >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-clue-data-model-schema-14: Discuss >>=20 >> 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.) >>=20 >>=20 >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html= >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> The document looks good, I just have a couple of items on the security >> considerations to discuss as they are not mentioned and I'm not sure if >> they have a good reason to be excluded. >>=20 >> 1. Session encryption to prevent active (tampering) or passive >> (information gathering for example) attacks. Integrity protection and >> authentication are mentioned, but without looking through a few >> documents, I don't know if that means encryption or some hash value >> comparisons or something else. >=20 > This is covered in the documents referenced in Section 25: draft-ietf-clue= -framework, draft-ietf-clue-datachannel, and draft-ietf-clue-protocol. >=20 Thanks, Alissa! I should have checked, but ran out of time yesterday and wa= nted yo get this out. I'll wait for a response on #2, then update comments.= Kathleen=20 > Alissa >=20 >>=20 >> 2. Schema drafts tend to cover the need for well-formed schemas as part >> of the security considerations. Can you add something in about that (not= >> much is required, but it's good for implementers to know this is >> important)? You can see two recent examples for guidance: >> YANG - https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ >> IODEF - https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >=20 From nobody Wed Jun 1 11:37:01 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B61012D18C; Wed, 1 Jun 2016 11:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=TfLNyBod; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=RzK1FFVV 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 qAlkJ5TOY_XW; Wed, 1 Jun 2016 11:36:57 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16AD912D16C; Wed, 1 Jun 2016 11:36:57 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 77F2420A47; Wed, 1 Jun 2016 14:36:56 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 01 Jun 2016 14:36:56 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=xPHMPCq7Wap8FGaBhM1oLIijK8g=; b=TfLNyB od8LZOGmssPKaPCDIIDnI3im8QrzbXSlGg7wIsFRUeqsjmxMTzecF+9BYg5UJ+K3 jvJ5mQM1Rc7FuliQra4JWrCdnxV89LBK/8+GQbgGaRK0NYlFTVoASzVq3Rsxv7nk N2YmAR4qThmc7LPnADsBI8fqFUyOtBR4P/YRk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=xPHMPCq7Wap8FGa BhM1oLIijK8g=; b=RzK1FFVV8EOdfvQ+osyrNR9CWBIGb5KayLNinGDojjLno0T rWBT7Vshjz2zHLz2jMgwJ2o10fivddQXfs7sY/x4F2sey/Dq2nXGbijD+mHi03Im fMMv7pSqQqSEevQCRiA9HFjes7wYZkDeWsAvXIGhw4fSer0b9Jngy5RbPJAA= X-Sasl-enc: sG0Uo7zhVkpZtQ1YNl8GBOPxl/Ulc4T8odzNBNZC4diO 1464806215 Received: from [10.234.137.180] (unknown [85.255.237.235]) by mail.messagingengine.com (Postfix) with ESMTPA id EA66FCCD8E; Wed, 1 Jun 2016 14:36:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Wed, 1 Jun 2016 19:43:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160601142232.16192.40456.idtracker@ietfa.amsl.com> <061e01d1bc24$7de529b0$79af7d10$@gmail.com> <4698EF47-EF15-4B33-9A14-4E2FB2A35488@nostrum.com> <1464802670.1029662.625029417.5E4385F0@webmail.messagingengine.com> To: Ben Campbell Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, The IESG , draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Ben Campbell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 18:36:59 -0000 Hi Ben, > On 1 Jun 2016, at 18:46, Ben Campbell wrote: >=20 >> On 1 Jun 2016, at 13:37, Alexey Melnikov wrote: >>=20 >> Hi Ben, >>=20 >>> On Wed, Jun 1, 2016, at 06:24 PM, Ben Campbell wrote: >>> Also inline, >>>=20 >>>> On 1 Jun 2016, at 12:41, Roni Even wrote: >>>>=20 >>>> Inline >>>> Roni >>>>=20 >>>>> -----Original Message----- >>>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>>> Sent: Wednesday, June 01, 2016 5:23 PM >>>>> To: The IESG >>>>> Cc: draft-ietf-clue-data-model-schema@ietf.org; clue-chairs@ietf.org; >>>>> ron.even.tlv@gmail.com; clue@ietf.org >>>>> Subject: Ben Campbell's Discuss on >>>>> draft-ietf-clue-data-model-schema-15: >>>>> (with DISCUSS and COMMENT) >>=20 >> [snip] >>=20 >>>>> ----------------------------------------------------------------------= >>>>> DISCUSS: >>>>> ----------------------------------------------------------------------= >>>>>=20 >>>>> - 11.2: I would like to discuss whether it's a good idea to allow >>>>> arbitrary >>>>> values for mediaType, beyond those types registered in IANA. >>>>> The text seem to encourage proprietary values. Did the working group >>>>> consider requiring IANA registration of some sort for new values? >>>>=20 >>>>=20 >>>> [Roni Even] ] I think that the meaning was to allow the media types >>>> from the IANA registry >>>> http://www.iana.org/assignments/media-types/media-types.xhtml . The >>>> issue will be about the usage of other media types in the CLUE >>>> environment and not about the values themselves. >>>> Alissa also suggested that we clarify it >>>=20 >>> I'm not sure I understand your response. When you say "other media >>> types", do you mean other types that are registered in the media-type >>> registry, but not described in RFC6838? >>=20 >> In case it helps: top level media types like "model", "application", >> "message", and not full media types like "application/pdf". These should >> be very rare. JUSTFONT WG is working on another one, but this is the >> first time something was added in more than 10 years. I honestly doubt >> anything other than "video", "audio" or "text" would be usable for CLUE >> anyway. >=20 > That was my assumption. That's part of why I wondered about the ability to= ability to invent arbitrary values. (But note that I've already cleared my D= ISCUSS.) My understanding was that each new media type would have to be registered in= the media type registry first, which is a rather high bar anyway. But maybe= that is not what the WG had in mind. I think it is more likely that "application" would be used, rather than an e= ntirely new media type. >>> Or other arbitary media types >>> that are not registered or otherwise publicly documented? >>=20 >> I would be impressed if any undocumented or unregistered top level media >> type would be interoperable, so I don't think any such media types >> matter. >=20 > Does that mean you don't think people will use undocumented media-types du= e to the lack of interoperability, or that anyone who does will be effective= ly proprietary and we should assume they don't want to interoperate in the f= irst place? Both :-). Experience with media types in other places shows that new media types are h= ard to deploy. > Thanks! >=20 > Ben. >=20 From nobody Wed Jun 1 11:39:28 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E429012D18C; Wed, 1 Jun 2016 11:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heP5KceIdbsd; Wed, 1 Jun 2016 11:39:25 -0700 (PDT) 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 AAC0912D16C; Wed, 1 Jun 2016 11:39:25 -0700 (PDT) Received: from [10.10.1.2] ([162.216.46.76]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u51IdJE5034445 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Jun 2016 13:39:21 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.76] claimed to be [10.10.1.2] From: "Ben Campbell" To: "Alexey Melnikov" Date: Wed, 01 Jun 2016 14:39:19 -0400 Message-ID: In-Reply-To: References: <20160601142232.16192.40456.idtracker@ietfa.amsl.com> <061e01d1bc24$7de529b0$79af7d10$@gmail.com> <4698EF47-EF15-4B33-9A14-4E2FB2A35488@nostrum.com> <1464802670.1029662.625029417.5E4385F0@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, The IESG , draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Ben Campbell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 18:39:28 -0000 On 1 Jun 2016, at 14:43, Alexey Melnikov wrote: > Hi Ben, > >> On 1 Jun 2016, at 18:46, Ben Campbell wrote: >> >>> On 1 Jun 2016, at 13:37, Alexey Melnikov wrote: >>> >>> Hi Ben, >>> >>>> On Wed, Jun 1, 2016, at 06:24 PM, Ben Campbell wrote: >>>> Also inline, >>>> >>>>> On 1 Jun 2016, at 12:41, Roni Even wrote: >>>>> >>>>> Inline >>>>> Roni >>>>> >>>>>> -----Original Message----- >>>>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>>>> Sent: Wednesday, June 01, 2016 5:23 PM >>>>>> To: The IESG >>>>>> Cc: draft-ietf-clue-data-model-schema@ietf.org; >>>>>> clue-chairs@ietf.org; >>>>>> ron.even.tlv@gmail.com; clue@ietf.org >>>>>> Subject: Ben Campbell's Discuss on >>>>>> draft-ietf-clue-data-model-schema-15: >>>>>> (with DISCUSS and COMMENT) >>> >>> [snip] >>> >>>>>> ---------------------------------------------------------------------- >>>>>> DISCUSS: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> - 11.2: I would like to discuss whether it's a good idea to allow >>>>>> arbitrary >>>>>> values for mediaType, beyond those types registered in IANA. >>>>>> The text seem to encourage proprietary values. Did the working >>>>>> group >>>>>> consider requiring IANA registration of some sort for new values? >>>>> >>>>> >>>>> [Roni Even] ] I think that the meaning was to allow the media >>>>> types >>>>> from the IANA registry >>>>> http://www.iana.org/assignments/media-types/media-types.xhtml . >>>>> The >>>>> issue will be about the usage of other media types in the CLUE >>>>> environment and not about the values themselves. >>>>> Alissa also suggested that we clarify it >>>> >>>> I'm not sure I understand your response. When you say "other media >>>> types", do you mean other types that are registered in the >>>> media-type >>>> registry, but not described in RFC6838? >>> >>> In case it helps: top level media types like "model", "application", >>> "message", and not full media types like "application/pdf". These >>> should >>> be very rare. JUSTFONT WG is working on another one, but this is the >>> first time something was added in more than 10 years. I honestly >>> doubt >>> anything other than "video", "audio" or "text" would be usable for >>> CLUE >>> anyway. >> >> That was my assumption. That's part of why I wondered about the >> ability to ability to invent arbitrary values. (But note that I've >> already cleared my DISCUSS.) > > My understanding was that each new media type would have to be > registered in the media type registry first, which is a rather high > bar anyway. But maybe that is not what the WG had in mind. I didn't get that from the text in version 14 or 15. But I might have read it wrong. (It happens.) > > I think it is more likely that "application" would be used, rather > than an entirely new media type. I think you are likely correct. > >>>> Or other arbitary media types >>>> that are not registered or otherwise publicly documented? >>> >>> I would be impressed if any undocumented or unregistered top level >>> media >>> type would be interoperable, so I don't think any such media types >>> matter. >> >> Does that mean you don't think people will use undocumented >> media-types due to the lack of interoperability, or that anyone who >> does will be effectively proprietary and we should assume they don't >> want to interoperate in the first place? > > Both :-). > > Experience with media types in other places shows that new media types > are hard to deploy. > >> Thanks! >> >> Ben. >> From nobody Wed Jun 1 12:32:27 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5082012D5F4; Wed, 1 Jun 2016 12:32:24 -0700 (PDT) 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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160601193224.16192.23638.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2016 12:32:24 -0700 Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-data-model-schema@ietf.org Subject: [clue] Stephen Farrell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 19:32:24 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-clue-data-model-schema-15: Discuss 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-data-model-schema/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There may be no change needed here, but I want to check. This draft defines no security mechanisms and doens't say how to interoperably use any security mechanisms. For example, I don't understand how one might (interoperably) do RBAC or other "advanced" security mechanisms that are promised in other CLUE documents. [1] Even worse, I don't get how one could e.g. use XMLENC to encrypt parts of the schema here, as that'd (I think) almost certainty have to have been considered in the design of this schema, but there's no evidence of that. That seems to end up meaning that the only security mechanisms that one can use with CLUE and for which one can currently achieve interop are transport security mechanisms. That all seems to conflict with text in the security consideration of the CLUE protocol draft. So my question to discuss is: other than transport security, what interoperable security mechanisms are expected to be defined in CLUE, and where might I find descriptions of those? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - section 25 says: "Indeed, authenticated access is strongly advisable, especially if you convey information about individuals ()..." I don't get the logic there - it seems incorrect actually. Personal data usually implies a need for confidentiality and not authenticated access - what was meant here? Are you using the term authenticated access to mean more that it does? (to this reader:-) From nobody Wed Jun 1 12:55:29 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B929C12D0B3; Wed, 1 Jun 2016 12:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XTyNi6E0TJM; Wed, 1 Jun 2016 12:55:21 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 2B19212B032; Wed, 1 Jun 2016 12:55:21 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id c140so20573904qke.2; Wed, 01 Jun 2016 12:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OhDRGgqVmb21wOI6YlHjoxWWi/95SJQgoRWEyqokSkU=; b=NeYwqZaQhEIcGNgHP1GCrR0cVaPIr3AsbeeWVfP3flCLhxbE5G+ymkwyRU/1uQObcK 17PasyA1VOVZGVaaxE8N67mT/S8bTRwtd41FdLEv1lYmGstsLwpGaT8PMkzk87UeW4Bu s8PDa54CLdvFrmdE8zfWEMhFUoH9j9aZr5MK4BKGGgGLRQHwJKhSuXlJoH4lyHkFzIts PYAqHZY3VvT9AZBbCuTXQ50dumlP/qNhFpMTCXqyUTxqZDy4JMuzBkIzYZZ45xMA06uN KDs1hSAM9TM7IlCiFn8lHo23ocCVbZrZ4AX6+ftYUQY4jVJxdSCUpcg70ydeYcfNLnhN tgZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OhDRGgqVmb21wOI6YlHjoxWWi/95SJQgoRWEyqokSkU=; b=RL3TMZ0FOtIKYLpccVz5AVL/kx5An3zx/YPyuLWlO6R5PzRLmG/MbJ9vF35kqQAYEx VAq6NjkdcppYY+gBB9jDHnfX/txnH8BldzF43Ku9ZZr9Z9cVPoGlIkV6ytYJwNkvTRLh UDX+GFUPBM03ZkB5VFnNk3BeOt8My2aG90pC88rCYnTezR7m7C7VmFSxzUk+RwfgkOlX NiarLRV3u2wa82qREJ8+HNGnUunT+01z7kgPb67sgJoEbadzH3WY52BkJw/TwZyAUu+4 1y20bHLiIWZfevwDR9jDFmfWJ/wpcvVWdFfEJOa9n7YolUgG52luLd/PYE8dTULq+4MF XLdQ== X-Gm-Message-State: ALyK8tIWOdxyC47KCMLOifIYC8mlYY8N6fQswwETIS7211hYK9dr4bxGE9J06tLu8Fmibw== X-Received: by 10.237.51.196 with SMTP id v62mr5637529qtd.101.1464810920236; Wed, 01 Jun 2016 12:55:20 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id 8sm76551qhm.1.2016.06.01.12.55.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 12:55:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (12H143) In-Reply-To: <20160601193224.16192.23638.idtracker@ietfa.amsl.com> Date: Wed, 1 Jun 2016 15:55:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160601193224.16192.23638.idtracker@ietfa.amsl.com> To: Stephen Farrell Archived-At: Cc: "clue-chairs@ietf.org" , "clue@ietf.org" , The IESG , "draft-ietf-clue-data-model-schema@ietf.org" Subject: Re: [clue] Stephen Farrell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 19:55:24 -0000 Sent from my iPhone > On Jun 1, 2016, at 3:32 PM, Stephen Farrell wr= ote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-clue-data-model-schema-15: Discuss >=20 > 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.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 > There may be no change needed here, but I want to check. > This draft defines no security mechanisms and doens't say > how to interoperably use any security mechanisms. For > example, I don't understand how one might (interoperably) > do RBAC or other "advanced" security mechanisms that are > promised in other CLUE documents. [1] Even worse, I don't > get how one could e.g. use XMLENC to encrypt parts of the > schema here, as that'd (I think) almost certainty have to > have been considered in the design of this schema, but > there's no evidence of that. That seems to end up meaning > that the only security mechanisms that one can use with > CLUE and for which one can currently achieve interop are > transport security mechanisms. That all seems to conflict > with text in the security consideration of the CLUE > protocol draft. So my question to discuss is: other than > transport security, what interoperable security > mechanisms are expected to be defined in CLUE, and where > might I find descriptions of those? >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - section 25 says: "Indeed, authenticated access is > strongly advisable, especially if you convey information > about individuals ()..." I don't get the > logic there - it seems incorrect actually. Personal data > usually implies a need for confidentiality and not > authenticated access - what was meant here? Are you using > the term authenticated access to mean more that it does? > (to this reader:-) I had the same trouble and agree with your discuss point. Thanks, Kathleen=20 >=20 >=20 From nobody Wed Jun 1 14:18:54 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1ABE12D0C5; Wed, 1 Jun 2016 14:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=V0gbmkir; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=iUy6ESvc 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 n3oOxP4LD6GM; Wed, 1 Jun 2016 14:18:50 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6BC12B01F; Wed, 1 Jun 2016 14:18:50 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7C3D020B44; Wed, 1 Jun 2016 17:18:49 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 01 Jun 2016 17:18:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=UoByt wmwfKtye8LGef0PdMd5fUw=; b=V0gbmkirOe/mToDu8jkbj/Uh/HC1mso9M/luE NeBFXFXHQWfWEZOFFfZtv3Igvi2iTVDLm7S9y8CxTE5Hz0Acn9bSa5OaY1GE8yP3 6sFTO9s4LUhNg5K5ZhNzQp1QL//1i4uGzzWuniJfshUNjKxAHyD5ZXOk59DSkqCG Jly8Nk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=UoBytwmwfKtye8LGef0PdMd5fUw=; b=iUy6E SvcZzf98dvLnyUah9jxhabxE9xw5dBFu/Dp9rsUB9xUd10r8UZHEAu1ew9OexQJ4 IziXpkAvDSh+lkRnDt1STvzAKbTxNAaPtsfwqbImpYuVtNY0WDROnCKl6TmQR0tp POicqtpKtobsphUol0Xdc6Xdv/SNZLlZ2R9LdM= X-Sasl-enc: quJR/6S9Uddd7olHHEeLLbn60CyTkvzCwpbnIxZwz1RS 1464815929 Received: from dhcp-171-68-20-157.cisco.com (dhcp-171-68-20-157.cisco.com [171.68.20.157]) by mail.messagingengine.com (Postfix) with ESMTPA id 93EB9F2A08; Wed, 1 Jun 2016 17:18:48 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5585E326-FF14-438C-9483-06CBC867A9EC" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20160601193224.16192.23638.idtracker@ietfa.amsl.com> Date: Wed, 1 Jun 2016 14:18:48 -0700 Message-Id: <3F791257-1EE1-4E07-9406-3E036293FC80@cooperw.in> References: <20160601193224.16192.23638.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: clue-chairs@ietf.org, CLUE , IESG , draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Stephen Farrell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 21:18:53 -0000 --Apple-Mail=_5585E326-FF14-438C-9483-06CBC867A9EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 1, 2016, at 12:32 PM, Stephen Farrell = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-clue-data-model-schema-15: Discuss >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 > There may be no change needed here, but I want to check. > This draft defines no security mechanisms and doens't say > how to interoperably use any security mechanisms. For > example, I don't understand how one might (interoperably) > do RBAC or other "advanced" security mechanisms that are > promised in other CLUE documents. [1] Even worse, I don't > get how one could e.g. use XMLENC to encrypt parts of the > schema here, as that'd (I think) almost certainty have to > have been considered in the design of this schema, but > there's no evidence of that. That seems to end up meaning > that the only security mechanisms that one can use with > CLUE and for which one can currently achieve interop are > transport security mechanisms. That all seems to conflict > with text in the security consideration of the CLUE > protocol draft. So my question to discuss is: other than > transport security, what interoperable security > mechanisms are expected to be defined in CLUE, and where > might I find descriptions of those? Note there was no [1] anywhere else in your ballot, but I=E2=80=99m = assuming you are referencing = https://tools.ietf.org/html/draft-ietf-clue-protocol-08#section-10 = . If = not, please correct me. So, the text in that section of the protocol draft is quite new and is = still under discussion in the WG. One of the points of discussion = surrounds whether to take the RBAC paragraph out: https://www.ietf.org/mail-archive/web/clue/current/msg04859.html = https://www.ietf.org/mail-archive/web/clue/current/msg04863.html = In any event, I do not expect there to be any further mechanisms defined = in CLUE to support what is written there. The expectation is that = implementations can use SIP security mechanisms to establish sessions = with other participants authorized to receive CLUE information, and they = can use transport encryption to protect CLUE information in flight. WG = folks should feel free to correct me but there has been no discussion of = any kind of finer-grained protections applied to individual schema = elements AFAIK. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - section 25 says: "Indeed, authenticated access is > strongly advisable, especially if you convey information > about individuals ()..." I don't get the > logic there - it seems incorrect actually. Personal data > usually implies a need for confidentiality and not > authenticated access - what was meant here? Are you using > the term authenticated access to mean more that it does? > (to this reader:-) >=20 Perhaps this would have been clearer if it said =E2=80=9Cauthentication=E2= =80=9D rather than =E2=80=9Cauthenticated access.=E2=80=9D I think the = point here is that it is advisable to authenticate the remote endpoint = before sending a CLUE message containing to that = endpoint, in the same way it=E2=80=99s advisable to authenticate it = before sending media to it. Alissa >=20 --Apple-Mail=_5585E326-FF14-438C-9483-06CBC867A9EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 1, 2016, at 12:32 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Stephen Farrell has entered the following ballot position = for
draft-ietf-clue-data-model-schema-15: Discuss

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.htmlfor 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-data-model-sch= ema/



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------


There may be no = change needed here, but I want to check.
This draft = defines no security mechanisms and doens't say
how to = interoperably use any security mechanisms. For
example, I = don't understand how one might (interoperably)
do RBAC or = other "advanced" security mechanisms that are
promised in = other CLUE documents. [1] Even worse, I don't
get how one = could e.g. use XMLENC to encrypt parts of the
schema here, = as that'd (I think) almost certainty have to
have been = considered in the design of this schema, but
there's no = evidence of that. That seems to end up meaning
that the = only security mechanisms that one can use with
CLUE and = for which one can currently achieve interop are
transport = security mechanisms. That all seems to conflict
with text = in the security consideration of the CLUE
protocol draft. = So my question to discuss is: other than
transport = security, what interoperable security
mechanisms are = expected to be defined in CLUE, and where
might I find = descriptions of those?

Note there was no [1] anywhere else in your = ballot, but I=E2=80=99m assuming you are referencing https://tools.ietf.org/html/draft-ietf-clue-protocol-08#section= -10. If not, please correct me.

So, the text in that section of the protocol draft = is quite new and is still under discussion in the WG. One of the points = of discussion surrounds whether to take the RBAC paragraph = out:


In any event, I do not expect = there to be any further mechanisms defined in CLUE to support what is = written there. The expectation is that implementations can use SIP = security mechanisms to establish sessions with other participants = authorized to receive CLUE information, and they can use transport = encryption to protect CLUE information in flight. WG folks should feel = free to correct me but there has been no discussion of any kind of = finer-grained protections applied to individual schema elements = AFAIK.



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------


- section 25 says: = "Indeed, authenticated access is
strongly advisable, = especially if you convey information
about individuals = (<personalInfo>)..." I don't get the
logic there - = it seems incorrect actually. Personal data
usually implies =  a need for confidentiality and not
authenticated = access - what was meant here? Are you using
the term = authenticated access to mean more that it does?
(to this = reader:-)


Perhaps this would have been clearer if it said = =E2=80=9Cauthentication=E2=80=9D rather than =E2=80=9Cauthenticated = access.=E2=80=9D I think the point here is that it is advisable to = authenticate the remote endpoint before sending a CLUE message = containing <personalInfo> to that endpoint, in the same way it=E2=80= =99s advisable to authenticate it before sending media to = it.

Alissa



= --Apple-Mail=_5585E326-FF14-438C-9483-06CBC867A9EC-- From nobody Wed Jun 1 14:31:54 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6478512D61C; Wed, 1 Jun 2016 14:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 G1j7uS9UBpuk; Wed, 1 Jun 2016 14:31:49 -0700 (PDT) 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 67A1C12B01F; Wed, 1 Jun 2016 14:31:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A3A61BE3F; Wed, 1 Jun 2016 22:31:47 +0100 (IST) 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 XIndf3uIKwwo; Wed, 1 Jun 2016 22:31:45 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6E5C7BE2F; Wed, 1 Jun 2016 22:31:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1464816705; bh=G8uK01sBx32ovzlELYmAewW9m4+lbtMqK+nSpc1i234=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=mf7awu/PIsLjMM0nqHh9FmkH1DTnTqCGoIkLclAdeoCz3vHUSsmAHbaj087KLtDpA 35QWa+etkc95f1LIEA3j+SWABmUoRgMG/uG6mXtYDvKyDQ5agiXLDtbCqWoIzNoLRQ zdaI9QRWWgRfYxFSmNJlG/NiQWUXgz8S9uOckKFI= To: Alissa Cooper References: <20160601193224.16192.23638.idtracker@ietfa.amsl.com> <3F791257-1EE1-4E07-9406-3E036293FC80@cooperw.in> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <574F5441.6090908@cs.tcd.ie> Date: Wed, 1 Jun 2016 22:31:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <3F791257-1EE1-4E07-9406-3E036293FC80@cooperw.in> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010307010607060008010507" Archived-At: Cc: clue-chairs@ietf.org, CLUE , IESG , draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Stephen Farrell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 21:31:52 -0000 This is a cryptographically signed message in MIME format. --------------ms010307010607060008010507 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/06/16 22:18, Alissa Cooper wrote: >=20 >> On Jun 1, 2016, at 12:32 PM, Stephen Farrell >> wrote: >>=20 >> Stephen Farrell has entered the following ballot position for=20 >> draft-ietf-clue-data-model-schema-15: Discuss >>=20 >> 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.) >>=20 >>=20 >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found >> here:=20 >> https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ >> >> >> >> >>=20 ---------------------------------------------------------------------- >> DISCUSS:=20 >> ----------------------------------------------------------------------= >> >> >> >>=20 There may be no change needed here, but I want to check. >> This draft defines no security mechanisms and doens't say how to >> interoperably use any security mechanisms. For example, I don't >> understand how one might (interoperably) do RBAC or other >> "advanced" security mechanisms that are promised in other CLUE >> documents. [1] Even worse, I don't get how one could e.g. use >> XMLENC to encrypt parts of the schema here, as that'd (I think) >> almost certainty have to have been considered in the design of this >> schema, but there's no evidence of that. That seems to end up >> meaning that the only security mechanisms that one can use with=20 >> CLUE and for which one can currently achieve interop are transport >> security mechanisms. That all seems to conflict with text in the >> security consideration of the CLUE protocol draft. So my question >> to discuss is: other than transport security, what interoperable >> security mechanisms are expected to be defined in CLUE, and where=20 >> might I find descriptions of those? >=20 > Note there was no [1] anywhere else in your ballot, but I=E2=80=99m ass= uming > you are referencing > https://tools.ietf.org/html/draft-ietf-clue-protocol-08#section-10 > . > If not, please correct me. Sorry, yes that's the bit. >=20 > So, the text in that section of the protocol draft is quite new and > is still under discussion in the WG. One of the points of discussion > surrounds whether to take the RBAC paragraph out: >=20 > https://www.ietf.org/mail-archive/web/clue/current/msg04859.html > =20 > https://www.ietf.org/mail-archive/web/clue/current/msg04863.html > >=20 > In any event, I do not expect there to be any further mechanisms > defined in CLUE to support what is written there. The expectation is > that implementations can use SIP security mechanisms to establish > sessions with other participants authorized to receive CLUE > information, and they can use transport encryption to protect CLUE > information in flight. WG folks should feel free to correct me but > there has been no discussion of any kind of finer-grained protections > applied to individual schema elements AFAIK. Fair enough. RBAC and selective field confidentiality for bits of this data model seemed a bit of a stretch goal to me too, but I can imagine some situations where that would be wanted/needed. If interop between a randomly chosen clue-device with such things isn't a priority, that's not crazy. I'll clear the discuss anyway and make this a comment. But if folks do want to argue for such interop then we ought chat about it. The selective field confidentiality thing in particular would I think require some changes to this schema if one wanted that kind of interop, so would be something it'd be way better to talk about now and not punt until later. (Arguably, approving this schema amounts to saying that selective-field-confidentiality won't be supported for this version.) >=20 >>=20 >>=20 >> ----------------------------------------------------------------------= >> >>=20 COMMENT: >> ----------------------------------------------------------------------= >> >> >> >>=20 - section 25 says: "Indeed, authenticated access is >> strongly advisable, especially if you convey information about >> individuals ()..." I don't get the logic there - it >> seems incorrect actually. Personal data usually implies a need for >> confidentiality and not authenticated access - what was meant here? >> Are you using the term authenticated access to mean more that it >> does? (to this reader:-) >>=20 >=20 > Perhaps this would have been clearer if it said =E2=80=9Cauthentication= =E2=80=9D > rather than =E2=80=9Cauthenticated access.=E2=80=9D I think the point h= ere is that it > is advisable to authenticate the remote endpoint before sending a > CLUE message containing to that endpoint, in the same > way it=E2=80=99s advisable to authenticate it before sending media to i= t. I suppose. My guess was that maybe the authors were using it as a short-hand for server-auth-TLS. If so, it might be better to say that, but it's a nit really. Cheers, S. >=20 > Alissa >=20 >>=20 >=20 >=20 --------------ms010307010607060008010507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MDEy MTMxNDVaMC8GCSqGSIb3DQEJBDEiBCB+TeBIW080R5oNt+2YOSnksGYMzuPAtAHHxc89qRra sTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBa5iuBGKjy65R4fhEeLy5wBJHQ0F/+imGDA6twUe0CcPzKcNvttU8I qIKNvUPOq2U6Wom03Aa3T8J+j+2fHtbHGFUOzFnK1TLObp2fV3ibuan9QDNAHovuZWo9TP+a X7WXr3eykNvrb4/gvNEMwYhh/dNwFIA80f0YY+P7llK8ZRR34FJX+hC6B1wv41SHLyJ5fk/x QIlHC7WL1ZZ5edC4gu6mPSeVqUm9+o9EP+xAXVeGDvr1squHqHIzUA8pr7qtr/1Gt8tOEfLU /wOUjdCZ0yWygXs/XWgrdLiNigVS4A5dUx3PQl90P0XdE4+9GK0fYS6FXjhUiJWr7UPHryDB AAAAAAAA --------------ms010307010607060008010507-- From nobody Wed Jun 1 15:56:22 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E158212D15A for ; Wed, 1 Jun 2016 15:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NQCKlssbdqL for ; Wed, 1 Jun 2016 15:56:19 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7597312D0C7 for ; Wed, 1 Jun 2016 15:56:19 -0700 (PDT) X-ASG-Debug-ID: 1464821145-05f2756782943c0001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id voovq7TglGohz2AL (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Thu, 02 Jun 2016 00:45:45 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [192.168.178.20] ([151.70.46.236]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u51MjhKN006981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2016 00:45:44 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_1C595AD7-36AB-4345-9358-983CD68218F1" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: Stephen Farrell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) In-Reply-To: <3F791257-1EE1-4E07-9406-3E036293FC80@cooperw.in> Date: Thu, 2 Jun 2016 00:45:43 +0200 Message-Id: References: <20160601193224.16192.23638.idtracker@ietfa.amsl.com> <3F791257-1EE1-4E07-9406-3E036293FC80@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.2104) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1464821145 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.82 X-Barracuda-Spam-Status: No, SCORE=0.82 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE, MIME_QP_LONG_LINE, MIME_QP_LONG_LINE_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.30093 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.82 MIME_QP_LONG_LINE_2 RAW: Quoted-printable line longer than 76 chars Archived-At: Cc: CLUE , IESG , clue-chairs@ietf.org, Stephen Farrell , draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Stephen Farrell's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 22:56:21 -0000 --Apple-Mail=_1C595AD7-36AB-4345-9358-983CD68218F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello everybody, > In any event, I do not expect there to be any further mechanisms = defined in CLUE to support what is written there. The expectation is = that implementations can use SIP security mechanisms to establish = sessions with other participants authorized to receive CLUE information, = and they can use transport encryption to protect CLUE information in = flight. WG folks should feel free to correct me but there has been no = discussion of any kind of finer-grained protections applied to = individual schema elements AFAIK. Indeed! Your summary looks perfect to me.=20 > Perhaps this would have been clearer if it said =E2=80=9Cauthentication=E2= =80=9D rather than =E2=80=9Cauthenticated access.=E2=80=9D I think the = point here is that it is advisable to authenticate the remote endpoint = before sending a CLUE message containing to that = endpoint, in the same way it=E2=80=99s advisable to authenticate it = before sending media to it. Agreed. Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_1C595AD7-36AB-4345-9358-983CD68218F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello everybody,

In any event, I do not expect there to be any further = mechanisms defined in CLUE to support what is written there. The = expectation is that implementations can use SIP security mechanisms to = establish sessions with other participants authorized to receive CLUE = information, and they can use transport encryption to protect CLUE = information in flight. WG folks should feel free to correct me but there = has been no discussion of any kind of finer-grained protections applied = to individual schema elements = AFAIK.

Indeed! Your summary looks perfect to = me. 

Perhaps this would have been clearer if it = said =E2=80=9Cauthentication=E2=80=9D rather than =E2=80=9Cauthenticated = access.=E2=80=9D I think the point here is that it is advisable to = authenticate the remote endpoint before sending a CLUE message = containing <personalInfo> to that endpoint, in the same way it=E2=80= =99s advisable to authenticate it before sending media to = it.

Agreed.

Simon

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

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






= --Apple-Mail=_1C595AD7-36AB-4345-9358-983CD68218F1-- From nobody Wed Jun 1 16:15:39 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5429412D125 for ; Wed, 1 Jun 2016 16:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=fHvfCtZ7; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=TqCZA4HB 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 PW88RcQ3enOR for ; Wed, 1 Jun 2016 16:15:35 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694DC12D0CE for ; Wed, 1 Jun 2016 16:15:35 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C47CC20FEB; Wed, 1 Jun 2016 19:15:34 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 01 Jun 2016 19:15:34 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=VGmt+wMtCyCiETjQShNr6nLGg4U=; b=fHvfCt Z7SJO8HnPL1c8zqEZvXxo4u0DwCsZxfsQsXlLGlGx/z1OzTTEzrLB/ENyVEZ7QcS 8Lerhx4TLdp39TMEGNps3Xk/aWvhtPJve+YRtsY7Jqlls0lw/COqIgP9B6HkOj6E 7UsBr1x8yMx7XkqXg/PRh/5f0hqrnXREPVSv8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=VGmt+wMtCyCiETj QShNr6nLGg4U=; b=TqCZA4HBKWJbB3cd0HihCOmTOI1rVT/q/jaBHHmHK7Glzum Xwth1UseWMS6bCNSYKYNPUbIclUrofWPkpLoieojTc1yuVPHb1EXgnS1J3vXiic8 138kqEZdtdNKH6reCAcyKiQOXSqNnmINTNSiQCu/RTnaHkIbTV76tQ6iWRuA= X-Sasl-enc: 5uHh8Nqx1+aKNbZ61MdMjNsTNRV37OhH5gAaIAphzW4T 1464822934 Received: from dhcp-171-68-20-157.cisco.com (dhcp-171-68-20-157.cisco.com [171.68.20.157]) by mail.messagingengine.com (Postfix) with ESMTPA id 1FCFEF2A4D; Wed, 1 Jun 2016 19:15:34 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <174cc59a-2d87-31a1-6d4d-61f38c712325@nteczone.com> Date: Wed, 1 Jun 2016 16:15:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <571673E9.4050005@alum.mit.edu> <94A3329C-F25B-439E-B6D2-CF6C98D9A3A6@unina.it> <174cc59a-2d87-31a1-6d4d-61f38c712325@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.3124) Archived-At: Cc: clue@ietf.org Subject: Re: [clue] Finishing up Security Considerations for protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 23:15:38 -0000 I agree with Christian=E2=80=99s suggestions. Personally I would leave out the RBAC paragraph as it seems aspirational = and there is nothing specifically in the protocol to support it. I will do a more thorough review when I get the publication request. Alissa > On May 17, 2016, at 5:50 PM, Christian Groves = wrote: >=20 > Hello Simon and Paul, >=20 > In general the text looks OK to me. I've proposed some editorial = updates below mainly to remove things like "we". >=20 > 1st Paragraph replace sentence starting with "Among such = requirements..." with >=20 > "Requirements include: (i) the use of cryptography and authentication; = (ii) protection of all sensitive fields; (iii) mutual authentication = between CLUE endpoints; (iv) the presence of authorization mechanisms; = (v) the presence of native defence mechanisms against malicious = activities such as eavesdropping, selective modification, deletion, = replay (and related combinations thereof). >=20 > 2nd paragraph 1st sentence reword: "The CLUE protocol is an = application-level protocol allowing a Media Producer and a Media = Consumer ..." >=20 > 4th paragraph proposed reword: >=20 > There is extra information carried by the CLUE protocol which is not = associated with the CLUE data model schema and which exposes information = that might be of concern. This information is primarily exchanged = during the options negotiation phase. In the Clue Participant state = machine "Option State", both parties agree on the version and on the = options to be used in the subsequent CLUE messages exchange phase. A = malicious participant might either try to retrieve a detailed footprint = of a specific CLUE protocol implementation during this initial setup = phase, or force the communicating party to use a non-up-to-date version = of the protocol which they know how to break. Indeed, exposing all of = the supported versions and options could conceivably leak information = about the specific implementation of the protocol. In theory an = implementation could choose not to announce all of the versions it = supports if it wants to avoid such leakage, though at the expenses of = interoperability. With respect to the above considerations, it is noted = that the OPTIONS state is only reached after the CLUE data channel has = been successfully set up. This ensures that only authenticated parties = can exchange OPTIONS and related OPTIONS RESPONSE messages and hence = drastically reduces the attack surface which is exposed to malicious = parties. >=20 > 5th paragraph proposed reword: >=20 > The CLUE framework clearly states the requirement to protect CLUE = protocol messages against threats deriving from the presence of a = malicious agent capable to gain access to the CLUE data channel. Such a = requirement is met by the CLUE data channel solution described in = [I-D.ietf-clue-datachannel], which ensures protection from both message = recovery and message tampering. With respect to this last point, any = implementation of the CLUE protocol compliant with the CLUE = specification MUST rely on the exchange of messages which flow on top of = a reliable and ordered SCTP over DTLS transport channel connecting two = CLUE Participants. >=20 > Last paragraph: With respect to the last paragraph I'm abit ambivalent = on it. It doesn't seem to hurt but if we do leave it in then we should = probably add something about the aspect of an endpoint. I assume that = its the endpoint generating protocol messages not a user. The owner of = an endpoint may in fact not be one of the in a conference. >=20 > Regards, Christian >=20 >=20 > On 14/05/2016 12:27 AM, Paul Kyzivat wrote: >> On 5/13/16 7:59 AM, Simon Pietro Romano wrote: >>> Dear Paul and others, >>>=20 >>> I just submitted a revised version of the protocol draft, in which I >>> tried to sketch a thorough Security Considerations section. >>> Please comment on that (the Security Section, which is also = copy-pasted >>> below) and on the document as a whole. >>=20 >> I saw it. This seems to cover the need to address security in the = document. >>=20 >> Where did the last paragraph (re RBAC) come from? ISTM that this is = speculative - not anything that the WG has discussed. I'd like to hear = what others think about this. >>=20 >> Thanks, >> Paul >>=20 >>> Thank you once again for your input and comments, >>>=20 >>> Simon >>>=20 >>> ***************************************** START OF SECURITY >>> CONSIDERATIONS SECTION = ********************************************** >>> As a general consideration, we remark that the CLUE framework (and >>> related protocol) has been conceived at the outset by embracing = the >>> security-by-design paradigm. This entails that a number of >>> requirements have been identified and properly standardized as >>> mandatory within the entire set of documents associated with the = CLUE >>> architecture. Among such requirements we mention the following: = (i) >>> always leave space for criptography and authentication; (ii) get = sure >>> that all sensitive fields can be protected; (iii) envisage mutual >>> authentication between CLUE endpoints; (iv) envisage the presence = of >>> authorization mechanisms; (v) envisage the presence of native = defense >>> mechanisms against malicious activities such as eavesdropping, >>> selective modification, deletion, replay (and related combinations >>> thereof). Hence, security of the single components of the CLUE >>> solution cannot be evaluated independently of the integrated view = of >>> the final architecture. >>>=20 >>> Coming to the details of the CLUE protocol, this is an = application- >>> level protocol allowing a Media Producer and a Media Consumer to >>> negotiate a variegated set of parameters associated with the >>> establishment of a telepresence session. This unavoidably exposes = a >>> CLUE-enabled telepresence system to a number of potential threats, >>> most of which are extensively discussed in the framework document >>> [I-D.ietf-clue-framework]. The security considerations section of >>> the mentioned document actually discusses issues associated with = the >>> setup and management of a telepresence session both in the basic = case >>> involving two CLUE endpoints acting, respectively, as MP and MC, = and >>> in the more advanced scenario envisaging the presence of an MCU. >>>=20 >>> The framework document also mentions that the information carried >>> within CLUE protocol messages might contain sensitive data, which >>> SHOULD hence be accessed only by authenticated endpoints. Security >>> issues associated with the CLUE data model schema are discussed in >>> [I-D.ietf-clue-data-model-schema]. >>>=20 >>> There is indeed some piece of extra information carried by the = CLUE >>> protocol which is not associated with the standard data model and >>> which exposes information that might be of concern. This is >>> primarily what gets exchanged during the options negotiation = phase. >>> =46rom the Clue Participant state machine, we know that in the = OPTIONS >>> state both parties agree on the version and on the options to be = used >>> in the subsequent CLUE messages exchange phase. A malicious >>> participant might either try to retrieve a detailed footprint of a >>> specific CLUE protocol implementation during this initial setup >>> phase, or force the communicating party to stick to a = non-up-to-date >>> version of the protocol which they know how to break. Indeed, >>> exposing all of the supported versions and options could = conceivably >>> leak a bit of information about the specific implementation of the >>> protocol. In theory an implementation could choose not to = announce >>> all of the versions it supports if it wants to avoid such leakage, >>> though at the expenses of interoperability. With respect to the >>> above considerations, we nonetheless remark that the OPTIONS state = is >>> only reached after the CLUE data channel has been successfully set >>> up. This ensures that only authenticated parties can exchange >>> OPTIONS and related OPTIONS RESPONSE messages and hence = drastically >>> reduces the attack surface which is exposed to malicious parties. >>>=20 >>> Coming to the content of the protocol messages themselves, the = CLUE >>> framework clearly states the requirement to protect against = threats >>> deriving from the presence of a malicious agent capable to gain >>> access to the CLUE data channel. Such a requirement is met by the >>> CLUE data channel solution described in = [I-D.ietf-clue-datachannel], >>> which ensures protection from both message recovery and message >>> tampering. With respect to this last point, we once again remark >>> that any implementation of the CLUE protocol which claims to be >>> compliant with the CLUE specification MUST rely on the exchaning = of >>> messages which flow on top of a reliable and ordered SCTP over = DTLS >>> transport channel connecting two CLUE Participants. >>>=20 >>> As a final consideration, we remark that policy-based management = of a >>> CLUE-compliant telepresence architecture, though not in the scope = of >>> the CLUE WG charter, can easily be realized. To the purpose, = common >>> Role-Based Access Control (RBAC) approaches can be leveraged. In >>> RBAC, the following elements are identified: (i) Users; (ii) = Roles; >>> (iii) Objects; (iv) Operations; (v) Permissions. For all of the >>> above elements, a direct mapping exists onto the main CLUE = entities. >>> As an example, RBAC objects map onto CLUE data model objects and = RBAC >>> operations map onto CLUE protocol operations. Future documents = can >>> define an RBAC framework for CLUE, by first focusing on the >>> definition of roles and then specifying the needed permission = policy >>> sets and role policy sets (used to associate policy permission = sets >>> with specific roles). With these policies in place, access to >>> information compliant with the CLUE data model can be = appropriately >>> controlled. As far as assigning users to roles, the Users in the >>> RBAC model relate directly to the element in the CLUE >>> object. The element is comprised of elements >>> representing a specific user in the telepresence system. Each >>> element contains a 'personID' attribute acting as a = unique >>> identifier and a element describing their role in the >>> CLUE session ("presenter", "timekeeper", "attendee", "minute = taker", >>> "translator", "chairman", "vice-chairman") . Thus, each = authorized >>> user can be associated with a well-defined role in the RBAC model. >>>=20 >>> ***************************************** END OF SECURITY = CONSIDERATIONS >>> SECTION ********************************************** >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On 19/apr/2016, at 20:07, Paul Kyzivat >>> > wrote: >>>>=20 >>>> The protocol needs to have a Security Considerations section before = it >>>> can progress. That is the main gating item at this point. >>>>=20 >>>> This should be pretty simple. The following are my thoughts about = what >>>> should be in it: >>>>=20 >>>> - it should reference the security considerations in the framework. >>>> They cover many important issues and those probably don't need to = be >>>> restated as long as they are referenced. >>>>=20 >>>> - it should reference the security considerations in the data = model. >>>> That document has most of the critical data to be concerned with. >>>>=20 >>>> - a reference to the security considerations in the = clue-datachannel >>>> draft will cover the protection of the content of the protocol = messages. >>>>=20 >>>> - There probably should be a brief discussion of the extra data in = the >>>> protocol (not in the data model) that exposes information that = might >>>> be of concern. I think this is primarily in the options = negotiation: >>>> exposing all the versions and options supported could conceivably = leak >>>> a bit of info about the specific software. In theory an = implementation >>>> could choose not to announce all the versions it supports if it = wants >>>> to avoid such leakage, though it would reduce interoperability. And = of >>>> course it will only be relevant when there are multiple versions = and >>>> options. >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>>=20 >>>=20 >>> _\\|//_ >>> ( O-O ) >>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>> Simon Pietro Romano >>> Universita' di Napoli Federico II >>> Computer Engineering Department >>> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >>> e-mail: spromano@unina.it >>> >>>=20 >>> <>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>> oooO >>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>> \ ( ( ) >>> \_) ) / >>> (_/ >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Jun 2 06:14:24 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE7412D6E0; Thu, 2 Jun 2016 06:14:22 -0700 (PDT) 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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160602131422.8923.70109.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2016 06:14:22 -0700 Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-data-model-schema@ietf.org Subject: [clue] Benoit Claise's No Objection on draft-ietf-clue-data-model-schema-15: (with COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 13:14:22 -0000 Benoit Claise has entered the following ballot position for draft-ietf-clue-data-model-schema-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-data-model-schema/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Good discussion between Stefan Winter (OPS DIR) and Simon Pietro Romano. The outcome should be integrated in the next draft version. From nobody Thu Jun 2 08:19:28 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4A712D766 for ; Thu, 2 Jun 2016 08:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6CMBpRyyCwe for ; Thu, 2 Jun 2016 08:19:24 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E15912D763 for ; Thu, 2 Jun 2016 08:19:22 -0700 (PDT) X-ASG-Debug-ID: 1464880759-05f2756741c8730001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id r86lCBOH1a8GXarN (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Thu, 02 Jun 2016 17:19:20 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [192.168.178.20] ([151.70.54.138]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u52FJGST002821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2016 17:19:18 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_299291FF-5E2D-4AF8-A620-99256E6523D0" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [OPS-DIR] OPS-DIR review of draft-ietf-clue-data-model-schema-14 In-Reply-To: <575033F6.9030307@restena.lu> Date: Thu, 2 Jun 2016 17:19:15 +0200 Message-Id: References: <573C4F63.2050008@restena.lu> <574EAAD4.9060409@restena.lu> <11D0C18A-3085-448F-A552-A1D996D52B97@unina.it> <5750226A.3050007@restena.lu> <563531EB-FE97-493B-A38B-6302FCDB5E11@unina.it> <575033F6.9030307@restena.lu> To: Stefan Winter X-Mailer: Apple Mail (2.2104) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1464880760 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.32 X-Barracuda-Spam-Status: No, SCORE=1.32 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE, MIME_QP_LONG_LINE, MIME_QP_LONG_LINE_2, WEIRD_PORT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.30112 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.50 WEIRD_PORT URI: Uses non-standard port number for HTTP 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.82 MIME_QP_LONG_LINE_2 RAW: Quoted-printable line longer than 76 chars Archived-At: Cc: draft-ietf-clue-data-model-schema.all@ietf.org, CLUE Subject: Re: [clue] [OPS-DIR] OPS-DIR review of draft-ietf-clue-data-model-schema-14 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 15:19:27 -0000 --Apple-Mail=_299291FF-5E2D-4AF8-A620-99256E6523D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Looks great. Thanks for the hint. We=E2=80=99ll definitely follow the = suggested path. Simon > On 02/giu/2016, at 15:26, Stefan Winter = wrote: >=20 > Hi, >=20 >>> Of course a cleaner way would be to replace the with = an >>> IANA registry which is then the authoritative source of all = enumerated >>> values. I think that's ultimately the cleanest option. >>=20 >> Can you please expand a bit on this? How should we modify the schema = in >> such a case? >=20 > You turn it into a simple string; with an annotation pointing to the > IANA registry: >=20 > > > > Acceptable values (enumerations) for this type are = managed by IANA in > the "CLUE Schema registry, accessible at TBD-IANA. > > > >=20 > Then, in IANA considerations add a new subsection: >=20 > Registry for acceptable values >=20 > IANA is requested to create a registry of acceptable values for the = the > tag as defined in section ... . The initial values for this > registry are ... ... ... . > New values are assigned by > (your choice of "Expert review - [name the experts]" "specification > required [means: need RFC]") >=20 > Don't forget to add >=20 > IANA is further requested to update this draft with the URL to the new > registry in section ..., marked as "TBD-IANA". >=20 > And then you are done. >=20 > Stefan >=20 >=20 >>=20 >> Thanks, >>=20 >> Simon >>=20 >>>=20 >>> Greetings, >>>=20 >>> Stefan Winter >>>=20 >>>>=20 >>>> Looking forward to your feedback, >>>>=20 >>>> Simon & Roberta >>>>=20 >>>> P.S. A very good summary of some of the most widely deployed >>>> extension approaches (including the two we briefly illustrated in >>>> this mail) can be found, e.g., here: >>>>=20 >>>> http://www.ibm.com/developerworks/library/x-extenum/ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _\\|//_ >>>> ( O-O ) >>>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>>> Simon Pietro Romano >>>> Universita' di Napoli Federico II >>>> Computer Engineering Department >>>> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >>>> e-mail: spromano@unina.it >>>>=20 >>>> <>>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>>> oooO >>>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> \ ( ( ) >>>> \_) ) / >>>> = (_/ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> <0x8A39DC66.asc> >>=20 >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department=20 >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >> >>=20 >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> = (_/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 > --=20 > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de = l'Education Nationale et > de la Recherche > 2, avenue de l'Universit=C3=A9 > L-4365 Esch-sur-Alzette >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 > PGP key updated to 4096 Bit RSA - I will encrypt all mails if the > recipient's key is known to me >=20 > http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66= > <0x8A39DC66.asc> _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_299291FF-5E2D-4AF8-A620-99256E6523D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Looks great. Thanks for the hint. We=E2=80=99ll definitely = follow the suggested path.

Simon

On 02/giu/2016, at 15:26, = Stefan Winter <stefan.winter@restena.lu> wrote:

Hi,

Of course a cleaner way would be to replace the = <documentation> with an
IANA registry which is then = the authoritative source of all enumerated
values. I think = that's ultimately the cleanest option.

Can you please expand a bit on this? How should we modify the = schema in
such a case?

You turn it into a simple string; with an annotation pointing = to the
IANA registry:

<xs:element name=3D=E2=80=9Cview" type=3D"xs:string">
   <xs:annotation>
=        <xs:documentation>
= = Acceptable values (enumerations) for this type are managed by = IANA in
the "CLUE Schema <view> registry, accessible = at TBD-IANA.
=        </xs:documentation>
   </xs:annotation>
</xs:element>

Then, in = IANA considerations add a new subsection:

Registry for acceptable <view> values

IANA is requested to create a registry of acceptable values = for the the
<view> tag as defined in section ... . = The initial values for this
registry are ... ... ... .
New values are assigned by
(your choice of = "Expert review - [name the experts]" "specification
required= [means: need RFC]")

Don't forget to add

IANA is further requested to update this draft = with the URL to the new
registry in section ..., marked as = "TBD-IANA".

And then you are done.

Stefan



Thanks,

Simon


Greetings,

Stefan Winter


Looking forward to your = feedback,

Simon & Roberta

P.S. A very good summary of some of the most = widely deployed
extension approaches (including the two we = briefly illustrated in
this mail) can be found, e.g., = here:

http://www.ibm.com/developerworks/library/x-extenum/




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

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






<0x8A39DC66.asc>

=             &n= bsp;           &nbs= p;  _\\|//_
=             &n= bsp;           &nbs= p;       ( O-O )
=   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ =             &n= bsp;      Simon Pietro Romano
= =             &n= bsp;Universita' di Napoli Federico II
=             &n= bsp;       Computer Engineering = Department
=             Ph= one: +39 081 7683823 -- Fax: +39 081 7683816
=             &n= bsp;           &nbs= p;            =      e-mail: spromano@unina.it
<mailto:spromano@unina.it>

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







--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de = l'Education Nationale et
de la Recherche
2, = avenue de l'Universit=C3=A9
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 = 422473

PGP key updated to 4096 Bit RSA - I = will encrypt all mails if the
recipient's key is known to = me

http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0D= E6A358A39DC66
<0x8A39DC66.a= sc>

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

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






= --Apple-Mail=_299291FF-5E2D-4AF8-A620-99256E6523D0-- From nobody Fri Jun 3 04:16:23 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC7712D0F0 for ; Fri, 3 Jun 2016 04:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv0B4UleH44P for ; Fri, 3 Jun 2016 04:16:20 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F05F12D0D3 for ; Fri, 3 Jun 2016 04:16:20 -0700 (PDT) X-ASG-Debug-ID: 1464951757-05f27567411023a0001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id awFDDac5xbitOadx (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Fri, 03 Jun 2016 13:02:37 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [192.168.178.20] ([151.70.17.237]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u53B2ZcB019013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 13:02:36 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] Kathleen Moriarty's Discuss on draft-ietf-clue-data-model-schema-14: (with DISCUSS) In-Reply-To: <4A74E266-B15A-4449-9258-7AB19449D1C7@gmail.com> Date: Fri, 3 Jun 2016 13:02:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6153C106-3498-4EF3-845F-0D4E9883C407@unina.it> References: <20160531213800.20195.51327.idtracker@ietfa.amsl.com> <45F69808-DBC1-4A03-95B2-7E8357F59034@cooperw.in> <4A74E266-B15A-4449-9258-7AB19449D1C7@gmail.com> To: kathleen.moriarty.ietf@gmail.com X-Mailer: Apple Mail (2.2104) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1464951757 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.30139 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: Cc: CLUE , "clue-chairs@ietf.org" , IESG , "draft-ietf-clue-data-model-schema@ietf.org" Subject: Re: [clue] Kathleen Moriarty's Discuss on draft-ietf-clue-data-model-schema-14: (with DISCUSS) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 11:16:22 -0000 Hello Kathleen, as far as point 2 below is concerned: >>> 2. Schema drafts tend to cover the need for well-formed schemas as = part >>> of the security considerations. Can you add something in about that = (not >>> much is required, but it's good for implementers to know this is >>> important)? You can see two recent examples for guidance: >>> YANG - = https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ >>> IODEF - = https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ =E2=80=A6are you sure this is really needed? This seems definitely = pleonastic to me. This said, if you think we=E2=80=99d better explicitly = mention such a point, would you be ok with the following text (entirely borrowed from the YANG RFC)? "XML parsers need to be robust with respect to malformed documents. = Reading malformed documents from unknown or untrusted sources could = result in an attacker gaining=20 privileges of the user running the XML parser. In an extreme situation, = the entire machine could be compromised.=E2=80=9D Thanks, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ From nobody Fri Jun 3 05:41:23 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4A112D120; Fri, 3 Jun 2016 05:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 p83W2RHzuq7L; Fri, 3 Jun 2016 05:41:15 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 85D3A12D174; Fri, 3 Jun 2016 05:41:15 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id 23so10818175qtq.0; Fri, 03 Jun 2016 05:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=17sDG90YmuW1Vv7MKzlvtW5zYC3NzArJZ1Bz8v4PL4M=; b=t1b7+Nk2lYdnLANu6dGsifzFJFhh7B/+VADkDIcsZ7o6AoYnI9nrz1DF/hkpVPPTJA ebMuI13e1Cn1HWdNx/GBWy0i/QFEA8avOuxJrTHsmDxvoxkl13sYHZPca5+anoh1rCse kD5WtRm39ALJnTc5gAZezRfE+6twndnS6vsViW7ADWcdErYe8tyMbIjwj4OU3E4ZbZve aqlvO6dYE4T2gakPwjmpuL/GleFgYRa0EBrqdQQGpMlarju6ohtgMnm4o4ZM4vlhsqB0 Ar1vSlds7k4N7DwktAL5Ng1Un2vN+KgPFiXAAuUnIcfIWC/P9Gk3vrNzevh9Khms+unG y8RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=17sDG90YmuW1Vv7MKzlvtW5zYC3NzArJZ1Bz8v4PL4M=; b=JvInNvc29840XgrHV5dgZLRQVpZ8FCAJVvfbcsyxpAbP1eLmNiCfvLYnap7QKwA3F1 JqwN4x8cQAD/2etW+LWwFMy73j6cct2Tc7Xf/cwCAbnyoBuJeJcbR14YO7m0A7xxRvl3 c+C7MZ2tko1ZDir8kaYTy+T2znWecSi1Ga6nqXjs2vUeYWhPrW/erikjIYs0qG5NtSUM FnZDvyW33+NACGsqiRqtF0yAGlI6JWUX7ILsPq5dSHoJoF/r4XW2Rz2Rw2DjjmNbzDQu Z+tNUdpKBQ1ZJ6tHjUP/PYZhdVNoEwb28F2VnQyzFk3WAAqHFVByFQh84XoiNlxGTND5 swKw== X-Gm-Message-State: ALyK8tJFw9ISZzuvOwoC29eFxD4nCQZVx/3cjbhIAvhzYzIMV8le/udHjolkMdRXi6R3Qw== X-Received: by 10.200.52.218 with SMTP id x26mr2972845qtb.65.1464957674623; Fri, 03 Jun 2016 05:41:14 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id 125sm983814qki.30.2016.06.03.05.41.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Jun 2016 05:41:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (12H143) In-Reply-To: <6153C106-3498-4EF3-845F-0D4E9883C407@unina.it> Date: Fri, 3 Jun 2016 08:41:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7016B96C-B85B-4F1C-B599-8DDDDB043DAF@gmail.com> References: <20160531213800.20195.51327.idtracker@ietfa.amsl.com> <45F69808-DBC1-4A03-95B2-7E8357F59034@cooperw.in> <4A74E266-B15A-4449-9258-7AB19449D1C7@gmail.com> <6153C106-3498-4EF3-845F-0D4E9883C407@unina.it> To: Simon Pietro Romano Archived-At: Cc: CLUE , "clue-chairs@ietf.org" , IESG , "draft-ietf-clue-data-model-schema@ietf.org" Subject: Re: [clue] Kathleen Moriarty's Discuss on draft-ietf-clue-data-model-schema-14: (with DISCUSS) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 12:41:18 -0000 Sent from my iPhone > On Jun 3, 2016, at 7:02 AM, Simon Pietro Romano wrote:= >=20 > Hello Kathleen, >=20 > as far as point 2 below is concerned: >=20 >>>> 2. Schema drafts tend to cover the need for well-formed schemas as part= >>>> of the security considerations. Can you add something in about that (n= ot >>>> much is required, but it's good for implementers to know this is >>>> important)? You can see two recent examples for guidance: >>>> YANG - https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ >>>> IODEF - https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ >=20 > =E2=80=A6are you sure this is really needed? This seems definitely pleonas= tic to me. This said, if you think we=E2=80=99d better explicitly mention su= ch a point, would you be ok with the following text > (entirely borrowed from the YANG RFC)? >=20 > "XML parsers need to be robust with respect to malformed documents. Readin= g malformed documents from unknown or untrusted sources could result in an a= ttacker gaining=20 > privileges of the user running the XML parser. In an extreme situation, th= e entire machine could be compromised.=E2=80=9D Yes, this would be very good. I liked the text in that document, hence the r= eference. Thanks, Kathleen=20 >=20 > Thanks, >=20 > Simon >=20 >=20 >=20 >=20 >=20 > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department=20 > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it >=20 > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ >=20 >=20 >=20 >=20 >=20 >=20 From nobody Fri Jun 3 06:11:52 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486A112D687 for ; Fri, 3 Jun 2016 06:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRxZYszb9vwe for ; Fri, 3 Jun 2016 06:11:49 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27AD912D0F7 for ; Fri, 3 Jun 2016 06:11:49 -0700 (PDT) X-ASG-Debug-ID: 1464959506-05f275679410bd30001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id NQIOqxxLqxF2P1PG (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Fri, 03 Jun 2016 15:11:46 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [192.168.178.20] ([151.70.17.237]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u53DBg5A000529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 15:11:43 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: Alexey Melnikov's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) In-Reply-To: <20160601074658.16192.65128.idtracker@ietfa.amsl.com> Date: Fri, 3 Jun 2016 15:11:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3568EEC4-B24B-4E8F-91EC-528D7489977E@unina.it> References: <20160601074658.16192.65128.idtracker@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.2104) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1464959506 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.30141 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, The IESG , draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Alexey Melnikov's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 13:11:51 -0000 Hello Alexey, please find in-line our answers to your comments (preceded by = [spromano]). > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This is generally a well written document, but I have a couple of very > small points that need to be fixed: >=20 > Abstract: I have no CLUE what you are talking about. Abstracts should = be > self contained, i.e. being understandable on its own. The Introduction > section has more relevant text which you might want to copy here. [spromano] Got it. What about the following amended abstract? = **************************************************************************= *** This document provides an XML schema file=20 for the definition of CLUE data model types. the term 'CLUE' stands for=20= "ControLling mUltiple streams for tElepresence" and is the name of=20 the IETF working group in which this document, as well as other=20 companion documents, has been developed. The document defines a coherent structure for information associated with the description of a=20 telepresence session.=20 = **************************************************************************= *** > In 11.13: you need to have a Normative Reference to the language tag > document here (RFC 5646) when you describe the "lang" attribute. [spromano] Done. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > In 11.24.1: A reference to xCard would be good to have here. [spromano] Done (the mentioned text is now in Section 16.1, btw). > In 16.30: >=20 > MIME type name typo on the Subject line. [spromano] Typo corrected. > "Application that use this media type: none ?" >=20 > I don't think this is correct. Please provide some examples of > applications that would be using this media type. If no applications = are > going to be using this media type, there is no need to register it = ;-). [spromano] Corrected. We put "CLUE-capable telepresence systems=E2=80=9D = there. Does this work for you? Cheers, Simon & Roberta _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ From nobody Fri Jun 3 06:46:24 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE6F12D188 for ; Fri, 3 Jun 2016 06:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bk8QQqACdM2M for ; Fri, 3 Jun 2016 06:46:21 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3C112D187 for ; Fri, 3 Jun 2016 06:46:20 -0700 (PDT) X-ASG-Debug-ID: 1464959546-05f275679410bdd0001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id Ct23vbnfX8n3wpu8 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Fri, 03 Jun 2016 15:12:26 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [192.168.178.20] ([151.70.17.237]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u53DBg5B000529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 15:12:24 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_A5C17CDA-42AC-4E43-9710-23F934616D71" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] Kathleen Moriarty's Discuss on draft-ietf-clue-data-model-schema-14: (with DISCUSS) In-Reply-To: <7016B96C-B85B-4F1C-B599-8DDDDB043DAF@gmail.com> Date: Fri, 3 Jun 2016 15:12:24 +0200 Message-Id: References: <20160531213800.20195.51327.idtracker@ietfa.amsl.com> <45F69808-DBC1-4A03-95B2-7E8357F59034@cooperw.in> <4A74E266-B15A-4449-9258-7AB19449D1C7@gmail.com> <6153C106-3498-4EF3-845F-0D4E9883C407@unina.it> <7016B96C-B85B-4F1C-B599-8DDDDB043DAF@gmail.com> To: kathleen.moriarty.ietf@gmail.com X-Mailer: Apple Mail (2.2104) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1464959546 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.30141 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: CLUE , "clue-chairs@ietf.org" , IESG , "draft-ietf-clue-data-model-schema@ietf.org" Subject: Re: [clue] Kathleen Moriarty's Discuss on draft-ietf-clue-data-model-schema-14: (with DISCUSS) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 13:46:23 -0000 --Apple-Mail=_A5C17CDA-42AC-4E43-9710-23F934616D71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Perfect. Version -16 of the draft will embed the mentioned paragraph. Thanx, Simon & Roberta > On 03/giu/2016, at 14:41, kathleen.moriarty.ietf@gmail.com wrote: >=20 >=20 >=20 > Sent from my iPhone >=20 >> On Jun 3, 2016, at 7:02 AM, Simon Pietro Romano = wrote: >>=20 >> Hello Kathleen, >>=20 >> as far as point 2 below is concerned: >>=20 >>>>> 2. Schema drafts tend to cover the need for well-formed schemas as = part >>>>> of the security considerations. Can you add something in about = that (not >>>>> much is required, but it's good for implementers to know this is >>>>> important)? You can see two recent examples for guidance: >>>>> YANG - = https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ >>>>> IODEF - = https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ >>=20 >> =E2=80=A6are you sure this is really needed? This seems definitely = pleonastic to me. This said, if you think we=E2=80=99d better explicitly = mention such a point, would you be ok with the following text >> (entirely borrowed from the YANG RFC)? >>=20 >> "XML parsers need to be robust with respect to malformed documents. = Reading malformed documents from unknown or untrusted sources could = result in an attacker gaining=20 >> privileges of the user running the XML parser. In an extreme = situation, the entire machine could be compromised.=E2=80=9D >=20 > Yes, this would be very good. I liked the text in that document, = hence the reference. >=20 > Thanks, > Kathleen=20 >=20 >>=20 >> Thanks, >>=20 >> Simon >>=20 >>=20 >>=20 >>=20 >>=20 >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department=20 >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >>=20 >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> = (_/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_A5C17CDA-42AC-4E43-9710-23F934616D71 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Perfect. Version -16 of the draft will embed the mentioned = paragraph.

Thanx,

Simon & Roberta

On = 03/giu/2016, at 14:41, kathleen.moriarty.ietf@gmail.com wrote:



Sent from my iPhone

On Jun 3, 2016, at 7:02 AM, Simon Pietro Romano = <spromano@unina.it> wrote:

Hello Kathleen,

as far as point = 2 below is concerned:

2. Schema drafts tend to cover the need for = well-formed schemas as part
of the security = considerations.  Can you add something in about that (not
much is required, but it's good for implementers to know this = is
important)?  You can see two recent examples for = guidance:
YANG - https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/<= /a>
IODEF - https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/

=E2=80=A6are you sure this is really needed? This seems = definitely pleonastic to me. This said, if you think we=E2=80=99d better = explicitly mention such a point, would you be ok with the following = text
(entirely borrowed from the YANG RFC)?

"XML parsers need to be robust with respect to = malformed documents. Reading malformed documents from unknown or = untrusted sources could result in an attacker gaining
privileges of the user running the XML parser. In an extreme = situation, the entire machine could be compromised.=E2=80=9D

Yes, this would be very good. =  I liked the text in that document, hence the reference.

Thanks,
Kathleen


Thanks,

Simon





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

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







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

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






= --Apple-Mail=_A5C17CDA-42AC-4E43-9710-23F934616D71-- From nobody Fri Jun 3 07:02:45 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FD312D191; Fri, 3 Jun 2016 07:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=NSEWkGQ7; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=AKnuFmV4 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 YMS-f4pwWrNa; Fri, 3 Jun 2016 07:02:42 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D6E12D10F; Fri, 3 Jun 2016 07:02:42 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B2F0C20F27; Fri, 3 Jun 2016 10:02:41 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Fri, 03 Jun 2016 10:02:41 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=H+QRXYqRysJeVCUhJMuf0KBZcDo=; b=NSEWkG Q7AI+UofatGwHBRrOweJDsaCAEgcO46gdYFvzbuTuG2OTcPMGUJg+9J0FvSWkDro DhWqVKktFPlto7mjiAjDrI3yYMVDxrDX65uPAjuuiuWIY0TZqUe5yU9I74KWZvQP BekPV3SmTxOOlwIj0J2t2UNIIh07Q8W7z6//o= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=H+QRXYqRysJeVCU hJMuf0KBZcDo=; b=AKnuFmV4l8Hlo8RkrQX8C7ny46eySXSforbBr2lDPklJtN6 /G0lxF0OtS4cHW7OdqsHOt3D0Bxo2uUsXNp6Y6x6nSJpwCCAR9Gi3aFSvFIKjEEj 2VwPTUMhcWyABsAumJI6aujF1FEgaDOa+x4OdnRCPuHoM3Ie9QcL7BZ5G2eI= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 789B5A87E7; Fri, 3 Jun 2016 10:02:41 -0400 (EDT) Message-Id: <1464962561.2590545.627005033.085F0AF6@webmail.messagingengine.com> X-Sasl-Enc: rLgmeF/rVxMEfDQrleOYHahM8lRbR73Gz2D3/tmPfMEQ 1464962561 From: Alexey Melnikov To: Simon Pietro Romano MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-38f217ef In-Reply-To: <3568EEC4-B24B-4E8F-91EC-528D7489977E@unina.it> References: <20160601074658.16192.65128.idtracker@ietfa.amsl.com> <3568EEC4-B24B-4E8F-91EC-528D7489977E@unina.it> Date: Fri, 03 Jun 2016 15:02:41 +0100 Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, The IESG , draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Alexey Melnikov's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 14:02:44 -0000 Hi Simon, On Fri, Jun 3, 2016, at 02:11 PM, Simon Pietro Romano wrote: > Hello Alexey, >=20 > please find in-line our answers to your comments (preceded by > [spromano]). >=20 > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > >=20 > > This is generally a well written document, but I have a couple of very > > small points that need to be fixed: > >=20 > > Abstract: I have no CLUE what you are talking about. Abstracts should be > > self contained, i.e. being understandable on its own. The Introduction > > section has more relevant text which you might want to copy here. >=20 > [spromano] Got it. What about the following amended abstract? > > *************************************************************************= **** > This document provides an XML schema file=20 > for the definition of CLUE data model types. the term 'CLUE' stands for=20 > "ControLling mUltiple streams for tElepresence" and is the name of=20 > the IETF working group in which this document, as well as other=20 > companion documents, has been developed. The document defines a coherent > structure for information associated with the description of a=20 > telepresence session.=20 > *************************************************************************= **** This is much better. I am not convinced that the acronym CLUE is going to have much relevance after the WG is closed, but this is not a reason to block publication of this document. =20 > > In 11.13: you need to have a Normative Reference to the language tag > > document here (RFC 5646) when you describe the "lang" attribute. >=20 > [spromano] Done. >=20 > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > >=20 > > In 11.24.1: A reference to xCard would be good to have here. >=20 > [spromano] Done (the mentioned text is now in Section 16.1, btw). >=20 > > In 16.30: > >=20 > > MIME type name typo on the Subject line. >=20 > [spromano] Typo corrected. Thank you for fixing these. > > "Application that use this media type: none ?" > >=20 > > I don't think this is correct. Please provide some examples of > > applications that would be using this media type. If no applications are > > going to be using this media type, there is no need to register it ;-). >=20 > [spromano] Corrected. We put "CLUE-capable telepresence systems=E2=80=9D = there. > Does this work for you? Yes. Best Regards, Alexey From nobody Fri Jun 3 07:49:09 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EAD12D6BE for ; Fri, 3 Jun 2016 07:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKYTRb3KGBm1 for ; Fri, 3 Jun 2016 07:49:06 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.206]) (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 6EAE312D510 for ; Fri, 3 Jun 2016 07:49:06 -0700 (PDT) Received: from [216.82.242.46] by server-14.bemta-8.messagelabs.com id 3F/18-29672-1E891575; Fri, 03 Jun 2016 14:49:05 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCKsWRWlGSWpSXmKPExsXS88lhlu6DGYH hBpffaFrsP3WZ2WLjTm0HJo+ds+6yeyxZ8pMpgCmKNTMvKb8igTVj44+njAXrkyuaP+9nbGA8 GN/FyMUhJLCZUeJRy0xWCGcJo8SRzV+Yuxg5OdgETCTe/LzHBGKLCPhJnJ52gB3EZhFQkWh8f AeohoNDWMBdon9JCUSJh8TSVX/ZIWwjiYmXHrKC2LwCgRKrD7eB2UICARKTVl4HG8kJFL8zZw OYzSggJvH91Bowm1lAXOLWk/lgtoSAiMTDi6fZIGxRiZeP/7FC1ItK3GlfzwhyM7NAD6PE4p6 5jBDLBCVOznzCArFMXaJj7ya2CYzCs5DMnYWsZxaSHoiiKImPxyDizAJaElPXvoKKy0tsfzuH eRbQz8wCmhLHLitBhLUlli18zQxhW0vM+HWQDcJWlJjS/ZAdwjaVeH30I+MCRu5VjBrFqUVlq UW6hqZ6SUWZ6RkluYmZObqGBhZ6uanFxYnpqTmJScV6yfm5mxiBsVvPwMC4g/HAc/dDjJIcTE qivOfPBoQL8SXlp1RmJBZnxBeV5qQWH2KU4eBQkuDVBaYCIcGi1PTUirTMHGASgUlLcPAoifC qg6R5iwsSc4sz0yFSpxgVpcR5NUESAiCJjNI8uDZY4rrEKCslzMvIwMAgxFOQWpSbWYIq/4pR nINRSZiXDWQKT2ZeCdz0V0CLmYAWFzzyB1lckoiQkmpglN3h3pAiP3Pfv5Un4kR+BKf47PJwn HD27aTAihaZD4pOaZZ+GRxVfgx79+5aufjhh8DC+rlJS5iuGHpuXPXs2DnV0jzXVY0y35tcNh exPBGLbPxXuT949lHFqlk+b9oq7IJ63l68mfk7xksuemPAsb8ZvV6T//vfsuRZ6zarWK1iDlf st94JSizFGYmGWsxFxYkAW/sm0lcDAAA= X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-7.tower-96.messagelabs.com!1464965343!6414997!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19080 invoked from network); 3 Jun 2016 14:49:04 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-7.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 3 Jun 2016 14:49:04 -0000 Received: from SACWPHUBCAS01V.polycom.com (10.236.3.231) by crpehubprd02.polycom.com (10.236.0.154) with Microsoft SMTP Server (TLS) id 8.3.389.2; Fri, 3 Jun 2016 07:49:03 -0700 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.191]) by SACWPHUBCAS01V.polycom.com ([fe80::446e:1fee:6a30:8642%12]) with mapi; Fri, 3 Jun 2016 07:49:02 -0700 From: "Duckworth, Mark" To: Daniel Burnett , "clue@ietf.org" Date: Fri, 3 Jun 2016 07:49:01 -0700 Thread-Topic: [clue] WGLC for draft-ietf-clue-rtp-mapping-07 ends 4 June Thread-Index: AdGznpMmz76pV9ZzQmabRzOcENclxQKCG26Q Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52FC19106B1DD@CRPMBOXPRD08.polycom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_006B_01D1BD85.89CC6970" MIME-Version: 1.0 Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-07 ends 4 June X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 14:49:08 -0000 ------=_NextPart_000_006B_01D1BD85.89CC6970 Content-Type: multipart/alternative; boundary="----=_NextPart_001_006C_01D1BD85.89CC6970" ------=_NextPart_001_006C_01D1BD85.89CC6970 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I reviewed the changes, it looks good. I support this going forward. Mark From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Daniel Burnett Sent: Saturday, May 21, 2016 4:21 PM To: clue@ietf.org Subject: [clue] WGLC for draft-ietf-clue-rtp-mapping-07 ends 4 June This message announces the start of a 2 week WGLC for draft-ietf-clue-rtp-mapping to review the updated draft. The last call will end at midnight on Saturday, 4 June 2016. PLEASE REVIEW NOW. -- Dan (for the Chairs) ------=_NextPart_001_006C_01D1BD85.89CC6970 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I reviewed the changes, it looks good. I support this going = forward.

Mark

 

From:<= /b> = clue [mailto:clue-bounces@ietf.org] On Behalf Of Daniel = Burnett
Sent: Saturday, May 21, 2016 4:21 PM
To: = clue@ietf.org
Subject: [clue] WGLC for = draft-ietf-clue-rtp-mapping-07 ends 4 = June

 

This message announces the start of a 2 = week WGLC for draft-ietf-clue-rtp-mapping to review the = updated draft. The last call will end at midnight on = Saturday, 4 June 2016.

PLEASE REVIEW = NOW.

 

-- Dan (for the = Chairs)

------=_NextPart_001_006C_01D1BD85.89CC6970-- ------=_NextPart_000_006B_01D1BD85.89CC6970 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUEjCCBQ0w ggL1oAMCAQICEBrVY02YeFKcQ+zVfznU/o4wDQYJKoZIhvcNAQEFBQAwGTEXMBUGA1UEAxMOUG9s eWNvbS1Sb290Q0EwHhcNMTMxMTA0MTg1NzA2WhcNMjMxMTA0MTkwNjU4WjAZMRcwFQYDVQQDEw5Q b2x5Y29tLVJvb3RDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMzj+6krY3OF7mtq +O2/yC5heUML7DFZn2cp0Mkp/vos7TDrysGdPDdEIK+zYvZQZs6TrGzPh0XXnEpMcHE7V4nD5zN3 VX0+Zg46w0wCHdkgq/GV3EKlyg0AsX8LgooGlUMeuUNpe+sT0WBl3mXB97TUw7mnRLY1m/IAlyFv 4XO8LfQ1L03vfLBRAVft7xc9Okm6DbHrPxFx9VKpgIkSIUvIx/BK0zXBa/0arWW3tfimfY9t5KdJ Wqb68E8Nb0bD8S0Ve0O76TCR4dVE/HmVj6YrauGcUGfvB4yT+bOOCGlsOw3NoHW2G9PZJF9B9PvV cWzv9Jw3AlzGU2sQMbVD1ZiiRgkG47bvqvi/tg38vWEDMj1lzSpMp/FhC8YrSaGb4YwjM52w9MXM DNypbOFZ/0WjrykwuGB1P9Ga38nRlaMkMJ3lE7P1pQMgxElO5uE+1TI5kTJ9mIGgQtQb57w4vkkJ kHNKjmqzOo3IFkhEIUS3ARPkYG4HWzP7xtmcYBoEx4QwpbxYQKKcxN9h/zuv9LYc79WvnF+i+aj0 1YJKoldsPnIXhG3HullYVQb+v19q8cqm0OGUEq7e2wY72H6JiT6YFc5kZitpZ65L5d1OGVLyFO6b iC79ARA9eBE5L3g9zF/du+U1k9L6LWW3VaHr3ZDCECU8ZX5QeBrqv2aTb0VNAgMBAAGjUTBPMAsG A1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSMD03mpjCj/UgRICWESaXA53z3 0TAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAAOCAgEAs02vFW5Je6895ZBWadxy5vxR z2imWk97qU2sMFSMnmf9QeqPwdawGO33zWr1sSQr8d67AHQc+3ihZuoAaeQAAC6Lww9r17Q3vVqg 7Qge86101Xw1fjXqTFUnWTxBK0S7re7pMqWlqaFgFQOHBMLnrM9z+NQIyDh7st9JjA+bRfFwErQ9 5CziXu+o/4q7eDBP1WaI0yKkEcOQ2LyPuCCE4hcshcJABiSYPax8nW71foHb+bv92IYvYXu2Wpa6 VgnxYqdi2k0Yk8CDiYalVsc+7QH0euQ1YIcovPbpZ02AirLqiiy6XB9i8OKfuapKSftsdfjLKqwI L7lKqz/4uAheETQsORVEh4IT0P8RRaIgHBOBVz/DOW+/IiiYagOJIYqbwGIFImQ7uOLNCoP5qY4y PLUZhmHFnnr7xtz4gv455KP9cwtPYcAarc/IB7WkTmEhFYa19k4jXlZ19AZIO/SPhvV7qz50zqB+ pCReRB5fXnf3qhRSw2WpRD4xr/q8OrWTfQRdXaooTJ14tRziqjEWLz4nPQKbE45aAjgwO0Rp6k5J tWGPhCxmuru/iqVES98VbjuAoo2qYZk7eNrqcnMuSxgqU0bgyie/R/FfMcbsw6rAh7T+qfBSxVIQ tpiqPwtZR5kdi6af3vf4w9q1PvEGrNipAjKEN2HW73558qGfPMowggZ5MIIEYaADAgECAhNuAAAA AgUmZh85ZflDAAAAAAACMA0GCSqGSIb3DQEBBQUAMBkxFzAVBgNVBAMTDlBvbHljb20tUm9vdENB MB4XDTEzMTEwNDE5MTM1MFoXDTIzMTEwNDE5MDY1OFowSDETMBEGCgmSJomT8ixkARkWA2NvbTEX MBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAOZhKwn7h/qKsHx8zQQPT356Og5GOOJ26SKfzS6dIZaD NjFIhS/5QRd3HZ9I1qFD8faDfpIHL+NzC0xqYJUZsEKntD+cCj99nx33t9D6GCmsEEngeLV0FO/u DlDcCXVJNJWS65E05vKyWFPlIRegDs+E73mNh3dHZ53mgrsCFd8PnX5Zm6zm+dAinDTUreXzSuzT si5yuZ10jHdEoin3bQyYQfAe4nR7BiqcQzYnD+JgU+NrZZ555xMdwVtRhjIFuFHwCN1BgWL8+cmI PTmW3bS/irYkbUn/IYFXGJIdgeZTzsp22+OPChBkCBiy86d9RaM6qvOV/ZLmq0bj4souN1cNBg0g ZnYIgTypQY/5Ew99FJJDor4TH1R5YNtqgwxBiSZSc0WSKy8WBrcUpBM+FP1gETY2sqZh2ApFkhU1 7BBLXcEwu6dnSO9Y5u0zJfOTKPesVaeGTfvzTEcm6A8xKO6V+ai/zhu3egbv4SmlPGiMENMPsWRy cG0c73xz/w9RwpWpImjIcE3+XA9rPhIdNj2KN4sbMJvvN5/ZLJHRScE5F3pltq2sFLyPSqhukYVY NRVXmdJ14FCArDqlrREeWLA2tP4ir0WeFeX6KgU+QrmWvdw1hJZ9/lPkiqDvuBWvDVyON0u/Dvi3 p6RJmWJlC5F8ajRegnM+BAYfokRZkvOHAgMBAAGjggGJMIIBhTAQBgkrBgEEAYI3FQEEAwIBADAd BgNVHQ4EFgQUcIfA57S89xZAbs9iT83FhcVNeekwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEw CwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUjA9N5qYwo/1IESAlhEml wOd899EwbwYDVR0fBGgwZjBkoGKgYIYuaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtpL1BvbHlj b20tUm9vdENBLmNybIYuaHR0cDovL2NkcDIucG9seWNvbS5jb20vcGtpL1BvbHljb20tUm9vdENB LmNybDCBhgYIKwYBBQUHAQEEejB4MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMS5wb2x5Y29tLmNv bS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMi5wb2x5Y29t LmNvbS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQDAITSF89YEDKMA zqteWVdg8IqzdMHSHIJGybNrbe1UJj6trSldu42wcgjYLgJrTIDEUEX2Qp1xywpv+zpVAE1bVoek 6ot846XEIiOTofJYnwACZNnCLJ3ijG2iuBCSJjPc6FzwCF/2DMR0erdh8PNhEnl3xDRNyqVOy+DC mlLssSjPgej1UxM4yaDZZUCBrkv1dB3a4qkTbMPFBj5CkC5gPnyKTRW7iUFMKr0pXvByGPHCtRbu ShXAcoSdVH2f8cLUfJ8raVMWu1ynjOMcvlagDaZAcbzLSc8hzhxJNC6Wel9U1uFyEaYGodJTMxzv e5zRU5wZod5kPaEThCKq12Fr9Sz/dYYp4Rup/SymTS4A46qMIrOi6i3icxa3SYAhsCeALdcrgCH4 +cCtKiEE1UpqIfJq8P/+FE6cnfHyGaXD+wn4BTA5BrUBg900HNVNf1Y6BDMqaXDeAPKbiSb5FDot PjAW0v7GLoshHMr+951EdhaFNSUyOV8CoSx9b9BjlYpjJV+QtiaqJLn9UlNOa987Fg9dIY4vrfqH q9kCVr+sVpQsZ6DC17bE7etrHPevRny/EcLmuJY1RD56gPAyePHFs1GEhmKVW9ZlLWtNs79G6wSf ZRnr3vRAtr7v0zWyjfvn52HWM4kbXedjCa/q9boJMVqK+8DJawhrrn38Liw7oDCCCIAwggZooAMC AQICE2sAANv9iRUGFNx/sYkAAAAA2/0wDQYJKoZIhvcNAQELBQAwSDETMBEGCgmSJomT8ixkARkW A2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTAe Fw0xNjAyMTYxNzI1NTlaFw0xNzAyMTUxNzI1NTlaMIGnMRMwEQYKCZImiZPyLGQBGRYDY29tMRcw FQYKCZImiZPyLGQBGRYHcG9seWNvbTEPMA0GA1UECxMGUGVvcGxlMRIwEAYDVQQLEwlFbXBsb3ll ZXMxDTALBgNVBAsTBE5BTEExGDAWBgNVBAMTD0R1Y2t3b3J0aCwgTWFyazEpMCcGCSqGSIb3DQEJ ARYaTWFyay5EdWNrd29ydGhAcG9seWNvbS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDUKfyJTxXkwEsUnHz/9m3k1jNMh31VSjpcboNOXMLE7ERqwC+KdVON0NLHp5ctN4kWewuu YDOuS+Qhp/Pm/+T2acQ0cqw+oY3nvKl7erYfC5Ul0EATlD3aUTGz34L2iKttOm9YID2GylBH9670 PHQ7n3YqC5sh1C7l2S4CznZz5c4ATRw1VtAzWskinzwYWKeiJV2ybr4JU9EM5QAGqM84jFXV2kN2 3CGKmAWlo6GIXstg82hfTkfubmgW9BQ+iyHEfwP1DIvdLh4tsyrgHoz+qomNaXmG+jUiP5CktXDF KueQLciDeg9HyxGh7AgtTvdMtI3KZUFCDyKDN4k0ux/5AgMBAAGjggQBMIID/TA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiGpOVThtjlcoO1gRiEnaYag+m7OimFw9RYg9ngHQIBZAIBBzApBgNV HSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwCwYDVR0PBAQDAgWgMDUGCSsG AQQBgjcVCgQoMCYwCgYIKwYBBQUHAwIwCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDBDBEBgkqhkiG 9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZI hvcNAwcwHQYDVR0OBBYEFBENjiHBionI5U/bTdJlzr9d3XeNMB8GA1UdIwQYMBaAFHCHwOe0vPcW QG7PYk/NxYXFTXnpMIIBOgYDVR0fBIIBMTCCAS0wggEpoIIBJaCCASGGgbxsZGFwOi8vL0NOPVBv bHljb20tU1VCQ0EwMSxDTj12d2NvbG9zdWJjYTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXBvbHljb20sREM9Y29tP2Nl cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludIYvaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtpL1BvbHljb20tU1VCQ0EwMS5jcmyGL2h0 dHA6Ly9jZHAyLnBvbHljb20uY29tL3BraS9Qb2x5Y29tLVNVQkNBMDEuY3JsMIIBPQYIKwYBBQUH AQEEggEvMIIBKzCBrgYIKwYBBQUHMAKGgaFsZGFwOi8vL0NOPVBvbHljb20tU1VCQ0EwMSxDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz1wb2x5Y29tLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTA7BggrBgEFBQcwAoYvaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtp L1BvbHljb20tU1VCQ0EwMS5jcnQwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZHAyLnBvbHljb20uY29t L3BraS9Qb2x5Y29tLVNVQkNBMDEuY3J0MEgGA1UdEQRBMD+gIQYKKwYBBAGCNxQCA6ATDBFtYXJr ZEBwb2x5Y29tLmNvbYEaTWFyay5EdWNrd29ydGhAcG9seWNvbS5jb20wDQYJKoZIhvcNAQELBQAD ggIBAHSlqpzE3JJ6cwdt2ve4eLY7IBfvrGjyFRQRfUgHg7SpxJVjB1jIZY7xXeGcBozQDSO6nQF6 KN3s+Mhy1GgH0tRMZBqefwZaT0taRdMHH/bXxDE4Qf8BRMXNIPZPb+2CV4ldFakuT1VZwmg1Gdtc ZU41o/zXYUBkzjPRX4DaEBWDsxI8Z3OX0lz3Kps3CocagYE+sjTaPIEFF3Gztyw5I8fS/nMnrSq3 G91bqqWE0teuGfBdt6tKqavJ0qHobkOQRV2bQi6OPzLZg8a1IaSZMviUDgzj/VASvw7phEUScEVf VqAvoru/7TWREyoc/lSvsd+PTpMeOjLUDre/FAbRGpN9Sx8FuBgvvb3wYdIMg/R8tIaQ8tqaAG/3 dSa9IeRfWOrcAOuc8TUieSDsTqugStWtKVsO8dCcZtdaPpL0deSjjEF+Ep9ZfqufhibQyFGNTjRK VwgxCQc+owwJx69vo2oDlzwWYhASQmwXVW9eiSWnvvMhvAny5dftCFaV47mSyQimkQ3k/rsX2Cg9 qbeuI0dSSD5c5pgE6z3jkF8ISL/1WitwCtG5Yqqp7Q8G2a35smlSVRzc1WTAiy6jZHSPZsbnRu5Y 9BnsB/TOcmKt9kAn6VUAC4j+Rq7MokZJzmj0sKNMH4qz3bo6ZMImkGS3xCLyvsK4iilg1Me67dlz bbJ1MYIDXzCCA1sCAQEwXzBIMRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYH cG9seWNvbTEYMBYGA1UEAxMPUG9seWNvbS1TVUJDQTAxAhNrAADb/YkVBhTcf7GJAAAAANv9MAkG BSsOAwIaBQCgggHVMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MDYwMzE0NDkwMVowIwYJKoZIhvcNAQkEMRYEFD6xWRMU3UnsdEfDNXMWPr6IhzyoMG4GCSsGAQQB gjcQBDFhMF8wSDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20x GDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMQITawAA2/2JFQYU3H+xiQAAAADb/TBwBgsqhkiG9w0B CRACCzFhoF8wSDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20x GDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMQITawAA2/2JFQYU3H+xiQAAAADb/TCBkwYJKoZIhvcN AQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQAUQwxcS3AUrETutUjc FRkU9Kmo+MafH/h8thHVpHBzqHcJvCRLuWE4uomNYvTuLTHNk2Y4vQ7Ivgv2qEzY3zvi1MIsOwsj yzqJQoKE7T3UG82+dUWOirkS+BzDpl90JWqeOAHFBbTGoVAmibfa4bCX75ue+3pB3gk1ymMsR/3E aZzV54ApfZTZT6dgPMNPfheTXavQZvtjNb2EBwuGFL9/3LJ5VnAfvrJ+DhrcIW1V9voPL4HbVLtR TeDv+AuXpMcgCZmSgZkslLOWdxHCCckWnP2mHpz8WKNRxRo9SgvGoUTuO1vzUVVQVfN0lqCgbwcU FRv0Xzne4uFtw4w2u6eEAAAAAAAA ------=_NextPart_000_006B_01D1BD85.89CC6970-- From nobody Fri Jun 3 09:39:38 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BF712D51B for ; Fri, 3 Jun 2016 09:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppYxZ6ERoX9V for ; Fri, 3 Jun 2016 09:39:35 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 8B5B612B00C for ; Fri, 3 Jun 2016 09:39:35 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by comcast with SMTP id 8s5gbuD3EnIc78s8EbSMGC; Fri, 03 Jun 2016 16:39:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464971974; bh=cvV7j29OZe3gdNY0ayCArleaWSStYAmMHBA4UVSuzOE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=lRfXYon7Xdk/mgk6HS/IcPF9favSMzoz0zRfti2IT9dXPEmjhOfwiPLy1AHeU+Coy oq7Ywz63hw4ebhY4v09m8TArsVCR22nrpA8uC68oSSk3X5UaCoQFJHB3nTFAmg/+WQ UcvVqx30EknwmAX0pcCP/+rpC/ecJuqBVZWRu6HQ/jFkuGncIYVS4Psp8C89D9xovc n1URXtiuJFEXUm4N0FicOTezpbdpZejVjTBzqgBpGCSzM/4sv7zAS6NRiSyGIHw5xb nLjV5ZSXRuDdVG+Hkf2aMvL0Umn6kjpHPnmHN3lnPxbvVyQMcZvzk3x3rQ/J1Uefsk o4jOCFMloHS0w== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-10v.sys.comcast.net with comcast id 2Gfa1t00C3KdFy101GfafN; Fri, 03 Jun 2016 16:39:34 +0000 To: clue@ietf.org References: From: Paul Kyzivat Message-ID: <60d98730-8908-ec10-d200-c609ce11dd29@alum.mit.edu> Date: Fri, 3 Jun 2016 12:39:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-07 ends 4 June X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 16:39:37 -0000 On 5/21/16 4:20 PM, Daniel Burnett wrote: > This message announces the start of a 2 week WGLC for > draft-ietf-clue-rtp-mapping to review the updated draft. The last call > will end at midnight on Saturday, 4 June 2016. > > PLEASE REVIEW NOW. Its been a long time since I read this document all the way through, so I just did so. Note that I am far from an RTP expert, so my qualifications for reviewing this document are limited. The following covers mostly stuff that doesn't require too much understanding of RTP. All of the following seem to be to be "quick fix" things. Aside from these I think the document is ready to go. * Section 4: The 2nd to last paragraph begins with "isAlternately". Clearly the "is" needs to be removed. * Section 4.1: The sentence "[I-D.ietf-mmusic-sdp-bundle-negotiation] how to associate a received RTP stream with the m-line describing it." doesn't parse. It is missing a word. I think "specifies" should be inserted prior to "how to associate". Then, in "The assumption in the work is that...", it isn't clear what "the work" refers to. Is it CLUE, or BUNDLE? I think it means CLUE. So perhaps change to "The assumption in CLUE is that...". I'll also note that "[I-D.ietf-mmusic-sdp-bundle-negotiation]" is rather unwieldy to read. It would be helpful to change the references to something more concise, such as [BUNDLE]. (xml2rfc supports this.) The following one-sentence paragraph: SDP Source attribute [RFC5576] mechanisms to describe specific attributes of RTP sources based on their SSRC. isn't a complete sentence. I don't have a particular fix to suggest. Then the sentence: The recommended support of the simulcast case is to use [I-D.ietf-mmusic-sdp-simulcast] needs a period at the end. * Section 4.2: The intro to this section: This section lists, more briefly, the requirements a media architecture for Clue telepresence needs to achieve, summarizing the discussion of previous sections. doesn't seem appropriate now that the work done. Also, I don't think it really summarizes discussion in prior sections. Perhaps something like the following would be better: "This section lists the CLUE media requirements that guided the development of this RTP mapping document." * Section 4.5: The recommendation is that CLUE endpoints using SSRC multiplexing MUST support [I-D.ietf-mmusic-sdp-bundle-negotiation] and use the SDP mid attribute for mapping. I read this as being a bit stronger than I think is intended. I think the intent is that all CLUE endpoints support BUNDLE (for interoperability), but that they need not offer it. And they only need to use mid when they are using BUNDLE. If they are not using BUNDLE then use of mid is optional. * Section 5: The statement "The solutions described in this document are believed to meet these requirements" seems a bit weak in a completed document. Any doubts as to whether the requirements have been met should have been raised and resolved now. So can we omit this? Should all the requirements be listed in this section, with an explanation of how each is met? * Section 9: Shouldn't there be two things registered here? Both the RTP header extension and the RTCP SDES item. * Nits: There are a few outdated references. Thanks, Paul From nobody Fri Jun 3 10:19:17 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC08712D751; Fri, 3 Jun 2016 10:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7onMBqA2uE00; Fri, 3 Jun 2016 10:19:10 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 2578212D763; Fri, 3 Jun 2016 10:19:06 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id c127so86386493ywb.1; Fri, 03 Jun 2016 10:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Uc7Y4t16o0qPgmD2YFhZyCvFcmCQ+NL5VlcQHwap/yI=; b=ZqiKVo5kDjIGLnyLjTusiD8hWC0lysBm6f0JahQq8P2FudN3BaagKfu/5fEtB1DYh9 wQn+wwxVTw0TMmYP8c0jGL/KdGx46fyk3Oi7FRc0zjX/GVdKUUOeehQw+OPjukR45pGb 0VIHQdFqPaqzETqfrHjYZH8mp5QrxABeMbZFJNrfrjcrzOgiOJrwv6nqGUCUUjJkLus0 k0G/GVAxRrAUUfrTryT4AtQhNtXWpWMYgVDUO84JKQ6ni+4y9gxsmOt2Zu0PjPq/keP0 l7zlLNd9atr8f3Ivk1ZrmFKTHaR8OdfTdjTp16C1dHAUoDGi23pWzoubvyn594W4NVZ4 k6RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Uc7Y4t16o0qPgmD2YFhZyCvFcmCQ+NL5VlcQHwap/yI=; b=c8DW+bh0c9ksDrs/3aspCDaqirY+KJiRiuchUB3cUGxqRRcZX9q5RqdFqZxHip8UCs es8FvZ3diAkHuoQCoBGz7cxfpgVURL/qG8NEWSv5RDJKwFKYEVI0mLsJFdFVHeFFHozX 1D8JaPIp7t/zg4/OB7raT6O+OSKzG4QB1Z9rfv7YGywBZzt8HDqzhNS7v/0zp779d41f zi+RbfpvVEpKnWD+AR6pTYunMhuADFRC8ePYapFI9cF+TfUM0E5oVmsXsgL+D8BffRsh FmQfgIPHUcAvjLEXNvVj5i2ge/l9ZdC3y5ET1g5HpciQC5/rlkl0ar6i1bbXCsGFZuc8 aOaQ== X-Gm-Message-State: ALyK8tK7IN3td7zJAN1QGdsZcAGSURJ+dxD8GuA/2jRTX76o6uSlpNqcVYs2fBSJjKYv62P1xJ3K5Kv5LnC/3Q== X-Received: by 10.129.71.3 with SMTP id u3mr3127781ywa.143.1464974345432; Fri, 03 Jun 2016 10:19:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.203.139 with HTTP; Fri, 3 Jun 2016 10:19:04 -0700 (PDT) In-Reply-To: <1464962561.2590545.627005033.085F0AF6@webmail.messagingengine.com> References: <20160601074658.16192.65128.idtracker@ietfa.amsl.com> <3568EEC4-B24B-4E8F-91EC-528D7489977E@unina.it> <1464962561.2590545.627005033.085F0AF6@webmail.messagingengine.com> From: Spencer Dawkins at IETF Date: Fri, 3 Jun 2016 12:19:04 -0500 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a114d729a770153053462ebf6 Archived-At: Cc: clue@ietf.org, The IESG , clue-chairs@ietf.org, draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Alexey Melnikov's Discuss on draft-ietf-clue-data-model-schema-15: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:19:13 -0000 --001a114d729a770153053462ebf6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Not my Discuss, but ... On Fri, Jun 3, 2016 at 9:02 AM, Alexey Melnikov wrote: > Hi Simon, > > On Fri, Jun 3, 2016, at 02:11 PM, Simon Pietro Romano wrote: > > Hello Alexey, > > > > please find in-line our answers to your comments (preceded by > > [spromano]). > > > > > ---------------------------------------------------------------------= - > > > DISCUSS: > > > ---------------------------------------------------------------------= - > > > > > > This is generally a well written document, but I have a couple of ver= y > > > small points that need to be fixed: > > > > > > Abstract: I have no CLUE what you are talking about. Abstracts should > be > > > self contained, i.e. being understandable on its own. The Introductio= n > > > section has more relevant text which you might want to copy here. > > > > [spromano] Got it. What about the following amended abstract? > > > > > *************************************************************************= **** > > This document provides an XML schema file > > for the definition of CLUE data model types. the term 'CLUE' stands for > > "ControLling mUltiple streams for tElepresence" and is the name of > > the IETF working group in which this document, as well as other > > companion documents, has been developed. The document defines a coheren= t > > structure for information associated with the description of a > > telepresence session. > > > *************************************************************************= **** > > This is much better. I am not convinced that the acronym CLUE is going > to have much relevance after the WG is closed, but this is not a reason > to block publication of this document. Is there a name for the output of the CLUE working group? I did participate in CLUE before joining the IESG, but I don't remember one. I know we usually pull RFC references to IETF working groups (which conclude, while RFCs remain unchanged until the earth is swallowed by the sun), but it would be nice to have a way to refer to what the working group did before it concluded. If not, maybe "... and is the name of a telepresence technology developed in the IETF"? Spencer, just trying to be helpful ... > > > In 11.13: you need to have a Normative Reference to the language tag > > > document here (RFC 5646) when you describe the "lang" attribute. > > > > [spromano] Done. > > > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > > > > > > In 11.24.1: A reference to xCard would be good to have here. > > > > [spromano] Done (the mentioned text is now in Section 16.1, btw). > > > > > In 16.30: > > > > > > MIME type name typo on the Subject line. > > > > [spromano] Typo corrected. > > Thank you for fixing these. > > > > "Application that use this media type: none ?" > > > > > > I don't think this is correct. Please provide some examples of > > > applications that would be using this media type. If no applications > are > > > going to be using this media type, there is no need to register it ;-= ). > > > > [spromano] Corrected. We put "CLUE-capable telepresence systems=E2=80= =9D there. > > Does this work for you? > > Yes. > > Best Regards, > Alexey > > --001a114d729a770153053462ebf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Not my Discuss, but ...

On Fri, Jun 3, 2016 at 9:02 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Hi Simon,

On Fri, Jun 3, 2016, at 02:11 PM, Simon Pietro Romano wrote:
> Hello Alexey,
>
> please find in-line our answers to your comments (preceded by
> [spromano]).
>
> > -----------------------------------------------------------------= -----
> > DISCUSS:
> > -----------------------------------------------------------------= -----
> >
> > This is generally a well written document, but I have a couple of= very
> > small points that need to be fixed:
> >
> > Abstract: I have no CLUE what you are talking about. Abstracts sh= ould be
> > self contained, i.e. being understandable on its own. The Introdu= ction
> > section has more relevant text which you might want to copy here.=
>
> [spromano] Got it. What about the following amended abstract?
>
> **********************************************************************= *******
> This document provides an XML schema file
> for the definition of CLUE data model types. the term 'CLUE' s= tands for
> "ControLling mUltiple streams for tElepresence" and is the n= ame of
> the IETF working group in which this document, as well as other
> companion documents, has been developed. The document defines a cohere= nt
> structure for information associated with the description of a
> telepresence session.
> **********************************************************************= *******

This is much better. I am not convinced that the acronym CLUE is goi= ng
to have much relevance after the WG is closed, but this is not a reason
to block publication of this document.

Is t= here a name for the output of the CLUE working group? I did participate in = CLUE before joining the IESG, but I don't remember one.

<= /div>
I know we usually pull RFC references to IETF working groups (whi= ch conclude, while RFCs remain unchanged until the earth is swallowed by th= e sun), but it would be nice to have a way to refer to what the working gro= up did before it concluded.

If not, maybe "..= . and is the name of a telepresence technology developed in the IETF"?=

Spencer, just trying to be helpful ...
= =C2=A0
> > In 11= .13: you need to have a Normative Reference to the language tag
> > document here (RFC 5646) when you describe the "lang" a= ttribute.
>
> [spromano] Done.
>
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > In 11.24.1: A reference to xCard would be good to have here.
>
> [spromano] Done (the mentioned text is now in Section 16.1, btw).
>
> > In 16.30:
> >
> > MIME type name typo on the Subject line.
>
> [spromano] Typo corrected.

Thank you for fixing these.

> > "Application that use this media type: none ?"
> >
> > I don't think this is correct. Please provide some examples o= f
> > applications that would be using this media type. If no applicati= ons are
> > going to be using this media type, there is no need to register i= t ;-).
>
> [spromano] Corrected. We put "CLUE-capable telepresence systems= =E2=80=9D there.
> Does this work for you?

Yes.

Best Regards,
Alexey


--001a114d729a770153053462ebf6-- From nobody Fri Jun 3 12:06:32 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 298C812D7BE; Fri, 3 Jun 2016 12:06:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160603190629.1502.66915.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2016 12:06:29 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-data-model-schema-16.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 19:06:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : An XML Schema for the CLUE data model Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-data-model-schema-16.txt Pages : 77 Date : 2016-06-03 Abstract: This document provides an XML schema file for the definition of CLUE data model types. The term "CLUE" stands for "ControLling mUltiple streams for tElepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed. The document defines a coherent structure for information associated with the description of a telepresence scenario. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-16 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 Fri Jun 3 12:10:52 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DBD12D7D1 for ; Fri, 3 Jun 2016 12:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id su9rnnxfLyPZ for ; Fri, 3 Jun 2016 12:10:47 -0700 (PDT) Received: from brc1.unina.it (antispam.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE7912B036 for ; Fri, 3 Jun 2016 12:10:47 -0700 (PDT) X-ASG-Debug-ID: 1464981043-05ce3705b4194270001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id 5F9NlJss5mvJOJHC (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Fri, 03 Jun 2016 21:10:44 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [192.168.178.20] ([151.70.17.237]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id u53JAflI025728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 21:10:42 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_51A8FB0B-3AC4-42CF-BECB-66A7615E8F0A" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [OPS-DIR] OPS-DIR review of draft-ietf-clue-data-model-schema-14 In-Reply-To: Date: Fri, 3 Jun 2016 21:10:41 +0200 Message-Id: <88D1F4AE-A205-439D-9FD6-104299846FF5@unina.it> References: <573C4F63.2050008@restena.lu> <574EAAD4.9060409@restena.lu> <11D0C18A-3085-448F-A552-A1D996D52B97@unina.it> <5750226A.3050007@restena.lu> <563531EB-FE97-493B-A38B-6302FCDB5E11@unina.it> <575033F6.9030307@restena.lu> To: Stefan Winter X-Mailer: Apple Mail (2.2104) X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1464981044 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE, WEIRD_PORT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.30147 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.50 WEIRD_PORT URI: Uses non-standard port number for HTTP 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: draft-ietf-clue-data-model-schema.all@ietf.org, CLUE Subject: Re: [clue] [OPS-DIR] OPS-DIR review of draft-ietf-clue-data-model-schema-14 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 19:10:51 -0000 --Apple-Mail=_51A8FB0B-3AC4-42CF-BECB-66A7615E8F0A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Stefan, as anticipated, version -16 of the draft (which has just been posted) = contains the modifications you suggested. Would you mind having a look = at it in order to double-check whether or not the applied modifications = are OK? Thanks a lot once again for your advice! Cheers, Simon & Roberta P.S. BTW, version -16 of the schema file has been uploaded here: http://wpage.unina.it/spromano/CLUE/DataModel/DataModel-16.xsd = > On 02/giu/2016, at 17:19, Simon Pietro Romano = wrote: >=20 > Looks great. Thanks for the hint. We=E2=80=99ll definitely follow the = suggested path. >=20 > Simon >=20 >> On 02/giu/2016, at 15:26, Stefan Winter > wrote: >>=20 >> Hi, >>=20 >>>> Of course a cleaner way would be to replace the = with an >>>> IANA registry which is then the authoritative source of all = enumerated >>>> values. I think that's ultimately the cleanest option. >>>=20 >>> Can you please expand a bit on this? How should we modify the schema = in >>> such a case? >>=20 >> You turn it into a simple string; with an annotation pointing to the >> IANA registry: >>=20 >> >> >> >> Acceptable values (enumerations) for this type are = managed by IANA in >> the "CLUE Schema registry, accessible at TBD-IANA. >> >> >> >>=20 >> Then, in IANA considerations add a new subsection: >>=20 >> Registry for acceptable values >>=20 >> IANA is requested to create a registry of acceptable values for the = the >> tag as defined in section ... . The initial values for this >> registry are ... ... ... . >> New values are assigned by >> (your choice of "Expert review - [name the experts]" "specification >> required [means: need RFC]") >>=20 >> Don't forget to add >>=20 >> IANA is further requested to update this draft with the URL to the = new >> registry in section ..., marked as "TBD-IANA". >>=20 >> And then you are done. >>=20 >> Stefan >>=20 >>=20 >>>=20 >>> Thanks, >>>=20 >>> Simon >>>=20 >>>>=20 >>>> Greetings, >>>>=20 >>>> Stefan Winter >>>>=20 >>>>>=20 >>>>> Looking forward to your feedback, >>>>>=20 >>>>> Simon & Roberta >>>>>=20 >>>>> P.S. A very good summary of some of the most widely deployed >>>>> extension approaches (including the two we briefly illustrated in >>>>> this mail) can be found, e.g., here: >>>>>=20 >>>>> http://www.ibm.com/developerworks/library/x-extenum/ = >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _\\|//_ >>>>> ( O-O ) >>>>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> Simon Pietro Romano >>>>> Universita' di Napoli Federico II >>>>> Computer Engineering Department >>>>> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >>>>> e-mail: spromano@unina.it >>>>>=20 >>>>> <>>>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>>>> oooO >>>>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> \ ( ( ) >>>>> \_) ) / >>>>> = (_/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> <0x8A39DC66.asc> >>>=20 >>> _\\|//_ >>> ( O-O ) >>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>> Simon Pietro Romano >>> Universita' di Napoli Federico II >>> Computer Engineering Department=20 >>> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >>> e-mail: spromano@unina.it = >>> > >>>=20 >>> <>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>> oooO >>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>> \ ( ( ) >>> \_) ) / >>> = (_/ >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >> --=20 >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de = l'Education Nationale et >> de la Recherche >> 2, avenue de l'Universit=C3=A9 >> L-4365 Esch-sur-Alzette >>=20 >> Tel: +352 424409 1 >> Fax: +352 422473 >>=20 >> PGP key updated to 4096 Bit RSA - I will encrypt all mails if the >> recipient's key is known to me >>=20 >> http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC6= 6 >> <0x8A39DC66.asc> >=20 > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico = II > Computer Engineering Department=20 > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it = >=20 > < idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( = ( ) > \_) ) = / > = (_/ >=20 >=20 >=20 >=20 >=20 >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_51A8FB0B-3AC4-42CF-BECB-66A7615E8F0A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello Stefan,

as anticipated, version -16 of the draft (which has just been = posted) contains the modifications you suggested. Would you mind having = a look at it in order to double-check whether or not the applied = modifications are OK? Thanks a lot once again for your advice!

Cheers,

Simon & = Roberta

P.S. = BTW, version -16 of the schema file has been uploaded here:

http://wpage.unina.it/spromano/CLUE/DataModel/DataModel-16.xsd<= /a>


On 02/giu/2016, at 17:19, Simon Pietro Romano = <spromano@unina.it> wrote:

Looks great. = Thanks for the hint. We=E2=80=99ll definitely follow the suggested = path.

Simon

On 02/giu/2016, at 15:26, Stefan Winter = <stefan.winter@restena.lu> wrote:

Hi,

Of course a cleaner way would be to replace the = <documentation> with an
IANA registry which is then = the authoritative source of all enumerated
values. I think = that's ultimately the cleanest option.

Can you please expand a bit on this? How should we modify the = schema in
such a case?

You turn it into a simple string; with an annotation pointing = to the
IANA registry:

<xs:element name=3D=E2=80=9Cview" type=3D"xs:string">
   <xs:annotation>
=        <xs:documentation>
= = Acceptable values (enumerations) for this type are managed by = IANA in
the "CLUE Schema <view> registry, accessible = at TBD-IANA.
=        </xs:documentation>
   </xs:annotation>
</xs:element>

Then, in = IANA considerations add a new subsection:

Registry for acceptable <view> values

IANA is requested to create a registry of acceptable values = for the the
<view> tag as defined in section ... . = The initial values for this
registry are ... ... ... .
New values are assigned by
(your choice of = "Expert review - [name the experts]" "specification
required= [means: need RFC]")

Don't forget to add

IANA is further requested to update this draft = with the URL to the new
registry in section ..., marked as = "TBD-IANA".

And then you are done.

Stefan



Thanks,

Simon


Greetings,

Stefan Winter


Looking forward to your = feedback,

Simon & Roberta

P.S. A very good summary of some of the most = widely deployed
extension approaches (including the two we = briefly illustrated in
this mail) can be found, e.g., = here:

http://www.ibm.com/developerworks/library/x-extenum/




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

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






<0x8A39DC66.asc>

=             &n= bsp;           &nbs= p;  _\\|//_
=             &n= bsp;           &nbs= p;       ( O-O )
=   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ =             &n= bsp;      Simon Pietro Romano
= =             &n= bsp;Universita' di Napoli Federico II
=             &n= bsp;       Computer Engineering = Department
=             Ph= one: +39 081 7683823 -- Fax: +39 081 7683816
=             &n= bsp;           &nbs= p;            =      e-mail: spromano@unina.it
<mailto:spromano@unina.it>

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







--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de = l'Education Nationale et
de la Recherche
2, = avenue de l'Universit=C3=A9
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 = 422473

PGP key updated to 4096 Bit RSA - I = will encrypt all mails if the
recipient's key is known to = me

http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0D= E6A358A39DC66
<0x8A39DC66.asc>

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

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







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

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






= --Apple-Mail=_51A8FB0B-3AC4-42CF-BECB-66A7615E8F0A-- From nobody Fri Jun 3 12:12:43 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECCC12D7BB for ; Fri, 3 Jun 2016 12:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg36ZC6PUYte for ; Fri, 3 Jun 2016 12:12:35 -0700 (PDT) Received: from brc1.unina.it (antispam.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A959A12D0A8 for ; Fri, 3 Jun 2016 12:12:34 -0700 (PDT) X-ASG-Debug-ID: 1464981152-05ce3705b8194520001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id 1kb48VDVaZNfes9Z (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 03 Jun 2016 21:12:32 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [192.168.178.20] ([151.70.17.237]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id u53JCVML025850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Jun 2016 21:12:32 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] I-D Action: draft-ietf-clue-data-model-schema-16.txt In-Reply-To: <20160603190629.1502.66915.idtracker@ietfa.amsl.com> Date: Fri, 3 Jun 2016 21:12:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3A57FEC8-1CF3-40EA-A749-FE23099303D0@unina.it> References: <20160603190629.1502.66915.idtracker@ietfa.amsl.com> To: CLUE X-Mailer: Apple Mail (2.2104) X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1464981152 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.30147 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-data-model-schema-16.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 19:12:41 -0000 Hello everybody, version -16 of the data model draft is out. Here is a short summary of = the diff with the previous version of the document: "Applied modifications as per the following reviews: (i) Alexey = Melnikov's discuss and comments (abstract amendments, typo corrections, = insertion of references, etc.); (ii) Kathleen Moriarty's discuss and = comments (amendments to the Security Considerations section); (iii) = Stefan Winter's OPS-DIR review (use of enumerated types in the = schema).=E2=80=9D Cheers, Simon & Roberta > On 03/giu/2016, at 21:06, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the ControLling mUltiple streams for = tElepresence of the IETF. >=20 > Title : An XML Schema for the CLUE data model > Authors : Roberta Presta > Simon Pietro Romano > Filename : draft-ietf-clue-data-model-schema-16.txt > Pages : 77 > Date : 2016-06-03 >=20 > Abstract: > This document provides an XML schema file for the definition of CLUE > data model types. The term "CLUE" stands for "ControLling mUltiple > streams for tElepresence" and is the name of the IETF working group > in which this document, as well as other companion documents, has > been developed. The document defines a coherent structure for > information associated with the description of a telepresence > scenario. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-16 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-data-model-schema-16= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ From nobody Fri Jun 3 12:31:58 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B96D12D940 for ; Fri, 3 Jun 2016 12:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8iolqtOdoao for ; Fri, 3 Jun 2016 12:31:55 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 4F3A312D944 for ; Fri, 3 Jun 2016 12:31:55 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by comcast with SMTP id 8uoKbuSYonIc78up0bSzNU; Fri, 03 Jun 2016 19:31:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464982314; bh=USQFnL7eElfDtVUZWKpV8w4tJZ1yePVTE+5H4nVkUVw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=fI9H9danHM6gOjk/Zwejo2D1GqslW1keU1+P5qVjqSKsMNFRanbgzNLedkbS6l2Xg Kd6kukgkI2Kyqu843t8Pyl187NFvENaPhyVaf6jIJnjUxKawV9o2ll84iA6GmH4uBC cpT9qRIdiC7RDB3xwIFx+XsLqMjXkCjw888t8Gfz/PrnX8TXD63wKbBWX/VWNyz0/t LhNbXSiQTCEmcfeV2QTKyA19Z4OeLA0sK7HOxslcSKDdSyh5nkitx6mRYA/a0MCt7g zKk9c4ozi2l9A3SnwA1HsEsdd/Z4y1Vr/NCncMuOzSo8FzjQuO4OA33A4UrCLV8tpb tRcTUm7jKJSuA== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with comcast id 2KXt1t0103KdFy101KXuv8; Fri, 03 Jun 2016 19:31:54 +0000 To: clue@ietf.org References: <20160603190629.1502.66915.idtracker@ietfa.amsl.com> <3A57FEC8-1CF3-40EA-A749-FE23099303D0@unina.it> From: Paul Kyzivat Message-ID: Date: Fri, 3 Jun 2016 15:31:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <3A57FEC8-1CF3-40EA-A749-FE23099303D0@unina.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-data-model-schema-16.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 19:31:57 -0000 This looks good, except for one thing: While I like the new IANA registries, I'm a little concerned about the criteria for adding new values. As written it requires only Expert Review. That means that when new new values are approved there will be only the registry entry to describe what they are. There won't be anything to define the semantics of the new entries. I'm inclined to think we should require a document, and for the registry to reference it. IIRC that implies expert review as well. Also, I guess we probably need to include templates for the registries, and some info for IANA to populate them with the initial values. Thanks, Paul On 6/3/16 3:12 PM, Simon Pietro Romano wrote: > Hello everybody, > > version -16 of the data model draft is out. Here is a short summary of the diff with the previous version of the document: > > "Applied modifications as per the following reviews: (i) Alexey Melnikov's discuss and comments (abstract amendments, typo corrections, insertion of references, etc.); (ii) Kathleen Moriarty's discuss and comments (amendments to the Security Considerations section); (iii) Stefan Winter's OPS-DIR review (use of enumerated types in the schema).” > > Cheers, > > Simon & Roberta > >> On 03/giu/2016, at 21:06, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. >> >> Title : An XML Schema for the CLUE data model >> Authors : Roberta Presta >> Simon Pietro Romano >> Filename : draft-ietf-clue-data-model-schema-16.txt >> Pages : 77 >> Date : 2016-06-03 >> >> Abstract: >> This document provides an XML schema file for the definition of CLUE >> data model types. The term "CLUE" stands for "ControLling mUltiple >> streams for tElepresence" and is the name of the IETF working group >> in which this document, as well as other companion documents, has >> been developed. The document defines a coherent structure for >> information associated with the description of a telepresence >> scenario. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-16 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-16 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sun Jun 5 03:44:42 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A75912B04A; Sun, 5 Jun 2016 03:44:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160605104438.23029.9876.idtracker@ietfa.amsl.com> Date: Sun, 05 Jun 2016 03:44:38 -0700 Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-data-model-schema@ietf.org Subject: [clue] Alexey Melnikov's Discuss on draft-ietf-clue-data-model-schema-16: (with DISCUSS) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 10:44:38 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-clue-data-model-schema-16: Discuss 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-data-model-schema/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for updating the document. However one of the changes looks incorrect to me: You incorrectly using RFC 2119 as a reference for language tags instead of RFC 5646. In 11.13: you need to have a Normative Reference to the language tag document here (RFC 5646) when you describe the "lang" attribute. From nobody Sun Jun 5 03:52:46 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F267012B044; Sun, 5 Jun 2016 03:52:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160605105242.22967.21985.idtracker@ietfa.amsl.com> Date: Sun, 05 Jun 2016 03:52:42 -0700 Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-data-model-schema@ietf.org Subject: [clue] Alexey Melnikov's Discuss on draft-ietf-clue-data-model-schema-16: (with DISCUSS) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 10:52:43 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-clue-data-model-schema-16: Discuss 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-data-model-schema/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for updating the document. However one of the changes looks incorrect to me: You incorrectly using RFC 2119 as a reference for language tags instead of RFC 5646. The following changes will address my concern: In 11.3 replace: OLD: Such an attribute is compliant with [RFC2119]. NEW: Such an attribute is compliant with the Language-Tag ABNF production from [RFC5646]. In 11.5 replace: OLD: Each such element has to be compliant with [RFC2119]. NEW: Each such element has to be compliant with the Language-Tag ABNF production from [RFC5646]. From nobody Sun Jun 5 12:46:22 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E560C12D18F for ; Sun, 5 Jun 2016 12:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q6Szu73x_Wv for ; Sun, 5 Jun 2016 12:46:19 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8515D12D0E2 for ; Sun, 5 Jun 2016 12:46:19 -0700 (PDT) X-ASG-Debug-ID: 1465155167-05f27567411bf2c0001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id ozqB3yzGChsUJ8bb (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Sun, 05 Jun 2016 21:32:47 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [1.41.6.244] ([37.227.155.116]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u55JWi6e018404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Jun 2016 21:32:45 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <20160605105242.22967.21985.idtracker@ietfa.amsl.com> References: <20160605105242.22967.21985.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----JB65A4NECFB945TL91ZX1FUKVIXPZM" Content-Transfer-Encoding: 8bit From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] Alexey Melnikov's Discuss on draft-ietf-clue-data-model-schema-16: (with DISCUSS) Date: Sun, 05 Jun 2016 21:32:54 +0200 To: Alexey Melnikov , The IESG Message-ID: <85628230-D1BD-4DAE-A15C-FF887619A514@unina.it> X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1465155167 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 1.41.6.244 as permitted sender) X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, BSF_SPF_SOFTFAIL, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.30192 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-data-model-schema@ietf.org Subject: Re: [clue] Alexey Melnikov's Discuss on draft-ietf-clue-data-model-schema-16: (with DISCUSS) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 19:46:21 -0000 ------JB65A4NECFB945TL91ZX1FUKVIXPZM Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Oops...sorry for the mistake. We'll update the reference in version -17. Simon Il 05 Giugno 2016 12:52:42 CEST, Alexey Melnikov ha scritto: >Alexey Melnikov has entered the following ballot position for >draft-ietf-clue-data-model-schema-16: Discuss > >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-data-model-schema/ > > > >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >Thank you for updating the document. However one of the changes looks >incorrect to me: > >You incorrectly using RFC 2119 as a reference for language tags instead >of RFC 5646. The following changes will address my concern: > >In 11.3 replace: > >OLD: > Such an attribute is compliant with [RFC2119]. > >NEW: > Such an attribute is compliant with the Language-Tag ABNF production >from [RFC5646]. > >In 11.5 replace: > >OLD: > Each such element has to be compliant with [RFC2119]. > >NEW: > Each such element has to be compliant with the Language-Tag ABNF >production from [RFC5646]. > > > > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue ------JB65A4NECFB945TL91ZX1FUKVIXPZM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Oops...sorry for the mistake. We'll update the reference in version -17.

Simon

Il 05 Giugno 2016 12:52:42 CEST, Alexey Melnikov <aamelnikov@fastmail.fm> ha scritto:
Alexey Melnikov has entered the following ballot position for
draft-ietf-clue-data-model-schema-16: Discuss

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-data-model-schema/




DISCUSS:


Thank you for updating the document. However one of the changes looks
incorrect to me:

You incorrectly usin
 g RFC
2119 as a reference for language tags instead
of RFC 5646. The following changes will address my concern:

In 11.3 replace:

OLD:
  Such an attribute is compliant with [RFC2119].

NEW:
  Such an attribute is compliant with the Language-Tag ABNF production
from [RFC5646].

In 11.5 replace:

OLD:
  Each such element has to be compliant with [RFC2119].

NEW:
  Each such element has to be compliant with the Language-Tag ABNF
production from [RFC5646].





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

------JB65A4NECFB945TL91ZX1FUKVIXPZM-- From nobody Mon Jun 6 00:16:31 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D338012B02E; Mon, 6 Jun 2016 00:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWvdIhUOE-GI; Mon, 6 Jun 2016 00:16:24 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (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 0EF4612B078; Mon, 6 Jun 2016 00:16:24 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 6C7FB412DD; Mon, 6 Jun 2016 09:16:21 +0200 (CEST) To: Simon Pietro Romano References: <573C4F63.2050008@restena.lu> <574EAAD4.9060409@restena.lu> <11D0C18A-3085-448F-A552-A1D996D52B97@unina.it> <5750226A.3050007@restena.lu> <563531EB-FE97-493B-A38B-6302FCDB5E11@unina.it> <575033F6.9030307@restena.lu> <88D1F4AE-A205-439D-9FD6-104299846FF5@unina.it> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <57552345.9030004@restena.lu> Date: Mon, 6 Jun 2016 09:16:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <88D1F4AE-A205-439D-9FD6-104299846FF5@unina.it> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HLqBN5lIcWQ6mF7DmmDDWTPRDj8xLAnou" Archived-At: Cc: draft-ietf-clue-data-model-schema.all@ietf.org, CLUE , ops-dir@ietf.org Subject: Re: [clue] [OPS-DIR] OPS-DIR review of draft-ietf-clue-data-model-schema-14 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 07:16:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HLqBN5lIcWQ6mF7DmmDDWTPRDj8xLAnou Content-Type: multipart/mixed; boundary="NMb9Jbd4g63reuK52fBwE9oPUCoTOuaSo" From: Stefan Winter To: Simon Pietro Romano Cc: draft-ietf-clue-data-model-schema.all@ietf.org, CLUE , ops-dir@ietf.org Message-ID: <57552345.9030004@restena.lu> Subject: Re: [OPS-DIR] OPS-DIR review of draft-ietf-clue-data-model-schema-14 References: <573C4F63.2050008@restena.lu> <574EAAD4.9060409@restena.lu> <11D0C18A-3085-448F-A552-A1D996D52B97@unina.it> <5750226A.3050007@restena.lu> <563531EB-FE97-493B-A38B-6302FCDB5E11@unina.it> <575033F6.9030307@restena.lu> <88D1F4AE-A205-439D-9FD6-104299846FF5@unina.it> In-Reply-To: <88D1F4AE-A205-439D-9FD6-104299846FF5@unina.it> --NMb9Jbd4g63reuK52fBwE9oPUCoTOuaSo Content-Type: multipart/mixed; boundary="------------060606070909030000060503" This is a multi-part message in MIME format. --------------060606070909030000060503 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, In 11.13 you introduced a new sentence: "Such an attribute is compliant with [RFC2119]." RFC2119 is not at all about XML attributes. Can you double-check the RFC number you reference, please? (similar in 11.15) Other than that, I'm okay with the document now. Greetings, Stefan Winter Am 03.06.2016 um 21:10 schrieb Simon Pietro Romano: > Hello Stefan, >=20 > as anticipated, version -16 of the draft (which has just been posted) > contains the modifications you suggested. Would you mind having a look > at it in order to double-check whether or not the applied modifications= > are OK? Thanks a lot once again for your advice! >=20 > Cheers, >=20 > Simon & Roberta >=20 > P.S. BTW, version -16 of the schema file has been uploaded here: >=20 > http://wpage.unina.it/spromano/CLUE/DataModel/DataModel-16.xsd >=20 >=20 >> On 02/giu/2016, at 17:19, Simon Pietro Romano > > wrote: >> >> Looks great. Thanks for the hint. We=E2=80=99ll definitely follow the >> suggested path. >> >> Simon >> >>> On 02/giu/2016, at 15:26, Stefan Winter >> > wrote: >>> >>> Hi, >>> >>>>> Of course a cleaner way would be to replace the wit= h an >>>>> IANA registry which is then the authoritative source of all enumera= ted >>>>> values. I think that's ultimately the cleanest option. >>>> >>>> Can you please expand a bit on this? How should we modify the schema= in >>>> such a case? >>> >>> You turn it into a simple string; with an annotation pointing to the >>> IANA registry: >>> >>> >>> >>> >>> Acceptable values (enumerations) for this type are managed by IANA in= >>> the "CLUE Schema registry, accessible at TBD-IANA. >>> >>> >>> >>> >>> Then, in IANA considerations add a new subsection: >>> >>> Registry for acceptable values >>> >>> IANA is requested to create a registry of acceptable values for the t= he >>> tag as defined in section ... . The initial values for this >>> registry are ... ... ... . >>> New values are assigned by >>> (your choice of "Expert review - [name the experts]" "specification >>> required [means: need RFC]") >>> >>> Don't forget to add >>> >>> IANA is further requested to update this draft with the URL to the ne= w >>> registry in section ..., marked as "TBD-IANA". >>> >>> And then you are done. >>> >>> Stefan >>> >>> >>>> >>>> Thanks, >>>> >>>> Simon >>>> >>>>> >>>>> Greetings, >>>>> >>>>> Stefan Winter >>>>> >>>>>> >>>>>> Looking forward to your feedback, >>>>>> >>>>>> Simon & Roberta >>>>>> >>>>>> P.S. A very good summary of some of the most widely deployed >>>>>> extension approaches (including the two we briefly illustrated in >>>>>> this mail) can be found, e.g., here: >>>>>> >>>>>> http://www.ibm.com/developerworks/library/x-extenum/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _\\|//_ >>>>>> ( O-O ) >>>>>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>> Simon Pietro Romano >>>>>> Universita' di Napoli Federico II >>>>>> Computer Engineering Department >>>>>> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >>>>>> e-mail: spromano@unina.it= >>>>>> >>>>>> >>>>>> <>>>>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>>>>> oooO >>>>>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>> \ ( ( ) >>>>>> \_) ) / >>>>>> = (_/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> <0x8A39DC66.asc> >>>> >>>> _\\|//_ >>>> ( O-O ) >>>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>>> Simon Pietro Romano >>>> Universita' di Napoli Federico II >>>> Computer Engineering Department >>>> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >>>> e-mail: spromano@unina.it >>>> >>>> >>>> >>>> <>>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>>> oooO >>>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> \ ( ( ) >>>> \_) ) / >>>> = (_/ >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> --=20 >>> Stefan WINTER >>> Ingenieur de Recherche >>> Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Educa= tion Nationale et >>> de la Recherche >>> 2, avenue de l'Universit=C3=A9 >>> L-4365 Esch-sur-Alzette >>> >>> Tel: +352 424409 1 >>> Fax: +352 422473 >>> >>> PGP key updated to 4096 Bit RSA - I will encrypt all mails if the >>> recipient's key is known to me >>> >>> http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39D= C66 >>> <0x8A39DC66.asc> >> >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department=20 >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >> >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> = (_/ >> >> >> >> >> >> >=20 > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department=20 > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > >=20 > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > = (_/ >=20 >=20 >=20 >=20 >=20 >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------060606070909030000060503 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------060606070909030000060503-- --NMb9Jbd4g63reuK52fBwE9oPUCoTOuaSo-- --HLqBN5lIcWQ6mF7DmmDDWTPRDj8xLAnou Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXVSNFAAoJEMDeajWKOdxmhT0QAK3kBff6BM0dyeqZxNzkdIvh 9PDYdEO+mxGs5QdHOGOh6eqXjbr0el0YrDg9HNP/gg2pHCEScy3BGOiJGGuDFA5A Vh6VeKZUqOXJ3i43HmxXwiIYZ7PfcuBS1zSFEX77mg+lYHmqM2WXiBMIAxeJHNQ4 MYdaAgHR27CoB5oXUYvJMlk2wHHs24P1SjHC6fxeGupjq57yv5V/DCtaUPRnZ6dQ Nz9tlssaMnL7Mpq4n7tjK1v9Mzuk7o2lJCrM8gzGw5zWyIsS4o17gN0gWwS27wvy kX8I0har36b/DDZLNmvdl3oPy4cDnRomlm1lrl0LNHyaxMm3HljeH5QQFZQkKBF/ igJTGhGoPjwhhPP/0O0EguOZoTzdTATAWQhpwmOwzwRlJajXFYhbW7l/97QxT5c2 HP7rrNguhyC94Ej68hl6uabO8ENQWHUYtOs5c/NHE//V5oPBciPLlGYLECrjh0ng YkNbuTjS44ekW3R5164Kw/JH7EGq2XB7J5XcOBF1vHtXgZZv6s5OOVwuyzkSGaiX kKQ5/CDyUO9dUXQ3GI3GWFoD/9ZYJSsDK6koMGSZv3WJK+qShxy+Qyykv/vua1HB qZIOMH6ZiCPMsY4ux/VEH9qNJWnxLyxbnHiNaJJkjHYBS1VIS1SR8nP1syQ5a5IK T4GMRUZ2/Lm+IFERrje7 =g/Yn -----END PGP SIGNATURE----- --HLqBN5lIcWQ6mF7DmmDDWTPRDj8xLAnou-- From nobody Mon Jun 6 19:09:01 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BF712D980 for ; Mon, 6 Jun 2016 19:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAY1vWTCV6x0 for ; Mon, 6 Jun 2016 19:08:57 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1E812D97C for ; Mon, 6 Jun 2016 19:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qymZoZ9aCY/yarX7VzW1sm2kNUVxNBgsMziW0xe9+70=; b=FrGTaLxNA0z5JEAtpCXCUR+O7M UQCm1u2hpz9hubknDTHIzMh4JAjyemh363kPkYMh5fQ/YRQwN56kkXtyfLaCORqxfkz/fV4z5oOBN /asJty9qON9gvWLeigBOdork4WYpHgF1zfkGzouszCx5V/JF9oa7EholhPpY4xqqojEWYdVPqkelT jn5zHw2XL8fsJEkEUAj3MPgkgYMMsbzPD36bCfiw9AKrfvhBri0P0l9c7wYf+0hBCYdNicbbxyJDy MV6aQowPwDzVpBLrOGETo+yulE8hZdja7vBdUJu8yyfXQfCwal3YVQVnzFTZH/8UAMcFZL0+w4UZF JdeJvzdg==; Received: from ppp118-209-50-138.lns20.mel4.internode.on.net ([118.209.50.138]:56079 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bA6Rq-0017Ae-2n for clue@ietf.org; Tue, 07 Jun 2016 12:08:54 +1000 To: clue@ietf.org References: <20160603190629.1502.66915.idtracker@ietfa.amsl.com> <3A57FEC8-1CF3-40EA-A749-FE23099303D0@unina.it> From: Christian Groves Message-ID: <58d9e1dd-0e89-2690-9f0d-1141c09de075@nteczone.com> Date: Tue, 7 Jun 2016 12:08:52 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-data-model-schema-16.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 02:09:00 -0000 I agree RFC5226 talks about that documentation and review criteria should be provided when setting up the registry. Regards, Christian On 4/06/2016 5:31 AM, Paul Kyzivat wrote: > This looks good, except for one thing: > > While I like the new IANA registries, I'm a little concerned about the > criteria for adding new values. As written it requires only Expert > Review. That means that when new new values are approved there will be > only the registry entry to describe what they are. There won't be > anything to define the semantics of the new entries. > > I'm inclined to think we should require a document, and for the > registry to reference it. IIRC that implies expert review as well. > > Also, I guess we probably need to include templates for the > registries, and some info for IANA to populate them with the initial > values. > > Thanks, > Paul > > On 6/3/16 3:12 PM, Simon Pietro Romano wrote: >> Hello everybody, >> >> version -16 of the data model draft is out. Here is a short summary >> of the diff with the previous version of the document: >> >> "Applied modifications as per the following reviews: (i) Alexey >> Melnikov's discuss and comments (abstract amendments, typo >> corrections, insertion of references, etc.); (ii) Kathleen Moriarty's >> discuss and comments (amendments to the Security Considerations >> section); (iii) Stefan Winter's OPS-DIR review (use of enumerated >> types in the schema).” >> >> Cheers, >> >> Simon & Roberta >> >>> On 03/giu/2016, at 21:06, internet-drafts@ietf.org wrote: >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the ControLling mUltiple streams for >>> tElepresence of the IETF. >>> >>> Title : An XML Schema for the CLUE data model >>> Authors : Roberta Presta >>> Simon Pietro Romano >>> Filename : draft-ietf-clue-data-model-schema-16.txt >>> Pages : 77 >>> Date : 2016-06-03 >>> >>> Abstract: >>> This document provides an XML schema file for the definition of CLUE >>> data model types. The term "CLUE" stands for "ControLling mUltiple >>> streams for tElepresence" and is the name of the IETF working group >>> in which this document, as well as other companion documents, has >>> been developed. The document defines a coherent structure for >>> information associated with the description of a telepresence >>> scenario. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-16 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-16 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> (_/ >> >> >> >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Jun 7 13:02:46 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF2812D528 for ; Tue, 7 Jun 2016 13:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHoBBkbaz6ct for ; Tue, 7 Jun 2016 13:02:42 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C8212D513 for ; Tue, 7 Jun 2016 13:02:42 -0700 (PDT) Received: from [82.132.237.156] (port=56095 helo=[172.20.10.2]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bANCx-0005Ud-TK; Tue, 07 Jun 2016 21:02:40 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Tue, 7 Jun 2016 21:02:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Daniel Burnett X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "clue@ietf.org" Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-07 ends 4 June X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 20:02:44 -0000 > On 21 May 2016, at 21:20, Daniel Burnett = wrote: >=20 > This message announces the start of a 2 week WGLC for = draft-ietf-clue-rtp-mapping to review the updated draft. The last call = will end at midnight on Saturday, 4 June 2016. >=20 > PLEASE REVIEW NOW. Apologies for the late review. I=E2=80=99ve read this draft, and have a = number of comments, mostly from an RTP perspective: Section 3, paragraph starting =E2=80=9CIn the Selective Forwarding = Middlebox (SFM) [RFC7667] topology=E2=80=9D: This paragraph seems = inconsistent. It starts by saying =E2=80=9Cevery original source is = maintained with an independent RTP identity to every receiver, = maintaining separate decoding state=E2=80=9C, which suggests each source = is passed through as an SSRC, but concludes =E2=80=9C[t]he sender may = turn the projected sources on and off at any time, depending on which = sources it thinks are most relevant for the receiver; this is the = primary reason why this topology must act as an RTP mixer=E2=80=9D, = which (if =E2=80=9Cthe sender=E2=80=9D actually means the middlebox) = suggests the sources are projected as CSRCs on a stream generated by the = middlebox (if =E2=80=9Cthe sender=E2=80=9D means the original sender, = then I don=E2=80=99t understand the intent). Section 3, bullet 1 (=E2=80=9CThe middlebox may either use=E2=80=9D): in = both cases, should this mandate that the middlebox generates RTCP for = the streams it=E2=80=99s distributing? Section 3, bullet 2 (=E2=80=9CThe middlebox terminates=E2=80=9D): does = this need to specify that the middlebox forwards/rewrites RTCP for each = source distributed as a CSRC? Section 4, 2nd paragraph, seems to confuse RTP sessions with signalling = contexts. The RTP session is always distinguished by having a shared = SSRC/CSRC space. This doesn=E2=80=99t change due to the signalling, = although the signalling determines which RTP flows are visible at a = particular participant, and hence share an SSRC space and form a single = RTP session. Section 4: what is meant by =E2=80=9Csession multiplexing=E2=80=9D and = =E2=80=9CSSRC multiplexing=E2=80=9D? I strongly suggest avoiding these = terms, since they don=E2=80=99t have a clear definition.=20 Section 4: what is a static SSRC? Should this be =E2=80=9Can SSRC = signalled using the a=3Dssrc: line [RFC 5576]=E2=80=9D? In general, I find Section 4 very difficult to follow, and am not sure I = could implement it from the text. It might be easier to read if the = review of related documents and requirements are moved to an appendix, = and the main text simply gives a statement of what should be done. Section 4.5: the requirement that endpoints =E2=80=9CMUST support and = use=E2=80=9D BUNDLE and a=3Dmid is vague. What is being bundled, and = when?=20 Section 4.5: what do middleboxes do? I=E2=80=99m surprised there is no = requirement here.=20 Section 5: as with section 4, this might be clearer if the requirements = for the solution were separated from the discussion of what an = implementation has to do. Section 6: it=E2=80=99s not clear how CaptureId relates to mid, why both = are needed, and how this relates to the mechanisms in section 4? I = haven=E2=80=99t followed all the details of CLUE, so perhaps this just = needs a reference to an appropriate definition/discussion in one of the = other documents? Colin --=20 Colin Perkins https://csperkins.org/ From nobody Wed Jun 8 08:31:29 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A50C412D941; Wed, 8 Jun 2016 08:31:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160608153128.20035.23504.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2016 08:31:28 -0700 Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-data-model-schema@ietf.org Subject: [clue] Kathleen Moriarty's No Objection on draft-ietf-clue-data-model-schema-16: (with COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 15:31:29 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-clue-data-model-schema-16: 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-data-model-schema/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my prior discuss comments. From nobody Wed Jun 8 11:36:10 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7DE12D0A1 for ; Wed, 8 Jun 2016 11:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=bNj4WAPd; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=sYzYfRmH 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 YzB2zBuWHZ3I for ; Wed, 8 Jun 2016 11:36:07 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294351200A0 for ; Wed, 8 Jun 2016 11:36:07 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8ABAD213AE; Wed, 8 Jun 2016 14:36:06 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 08 Jun 2016 14:36:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=CypMO Izs5w3dXaAmwlXVvdbbDHQ=; b=bNj4WAPdrEy5Or+Tc/o8taRn1OCGmEPTee5qi 6L7JviZMIgFz39B3tPh34v+GYCkLCxGyWU+o1BUUVe55y0u5hml7unYk8Xy4SZa7 C3yjnM60rII3ddCKGs1ePtl6jI/cL5uSxH8tpoyh62jVI4/yPMETlry0NQj3IYUR 7rAhtc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=CypMOIzs5w3dXaAmwlXVvdbbDHQ=; b=sYzYf RmHdv+fDrpLSO0MIwLv0WRG3S/ShuAFm/0fEmaNPkoUh6zyy54E1YQ60lvK9DcLp vbiVbObHOFPBimAhD0rJaDASOGh2/OaQmaY1kQRqFTJbnbo0kt1NCOgtQ/a7P7np V/b4WTHMbMLc1PQuWVlfTJVOiq9ZhAjmxjfNx8= X-Sasl-enc: cdCK0nPffEOhU7UxT4h2MOMgsSYGAg5PwSHAdwX9ODzx 1465410965 Received: from dhcp-171-68-20-12.cisco.com (dhcp-171-68-20-12.cisco.com [171.68.20.12]) by mail.messagingengine.com (Postfix) with ESMTPA id A7EFAF29FC; Wed, 8 Jun 2016 14:36:05 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F30FC80F-B480-42C0-8C9A-2F8E09C49346" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <58d9e1dd-0e89-2690-9f0d-1141c09de075@nteczone.com> Date: Wed, 8 Jun 2016 11:36:05 -0700 Message-Id: References: <20160603190629.1502.66915.idtracker@ietfa.amsl.com> <3A57FEC8-1CF3-40EA-A749-FE23099303D0@unina.it> <58d9e1dd-0e89-2690-9f0d-1141c09de075@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.3124) Archived-At: Cc: CLUE Subject: Re: [clue] I-D Action: draft-ietf-clue-data-model-schema-16.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 18:36:09 -0000 --Apple-Mail=_F30FC80F-B480-42C0-8C9A-2F8E09C49346 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 6, 2016, at 7:08 PM, Christian Groves = wrote: >=20 > I agree RFC5226 talks about that documentation and review criteria = should be provided when setting up the registry. Yep. I would recommend reading through = https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-16 = to see = the most up-to-date guidance on what needs to be included when creating = a new registry. (I know it=E2=80=99s a draft but the content needed for = this purpose is stable enough.) Alissa >=20 > Regards, Christian >=20 >=20 > On 4/06/2016 5:31 AM, Paul Kyzivat wrote: >> This looks good, except for one thing: >>=20 >> While I like the new IANA registries, I'm a little concerned about = the criteria for adding new values. As written it requires only Expert = Review. That means that when new new values are approved there will be = only the registry entry to describe what they are. There won't be = anything to define the semantics of the new entries. >>=20 >> I'm inclined to think we should require a document, and for the = registry to reference it. IIRC that implies expert review as well. >>=20 >> Also, I guess we probably need to include templates for the = registries, and some info for IANA to populate them with the initial = values. >>=20 >> Thanks, >> Paul >>=20 >> On 6/3/16 3:12 PM, Simon Pietro Romano wrote: >>> Hello everybody, >>>=20 >>> version -16 of the data model draft is out. Here is a short summary = of the diff with the previous version of the document: >>>=20 >>> "Applied modifications as per the following reviews: (i) Alexey = Melnikov's discuss and comments (abstract amendments, typo corrections, = insertion of references, etc.); (ii) Kathleen Moriarty's discuss and = comments (amendments to the Security Considerations section); (iii) = Stefan Winter's OPS-DIR review (use of enumerated types in the = schema).=E2=80=9D >>>=20 >>> Cheers, >>>=20 >>> Simon & Roberta >>>=20 >>>> On 03/giu/2016, at 21:06, internet-drafts@ietf.org wrote: >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>> This draft is a work item of the ControLling mUltiple streams for = tElepresence of the IETF. >>>>=20 >>>> Title : An XML Schema for the CLUE data model >>>> Authors : Roberta Presta >>>> Simon Pietro Romano >>>> Filename : draft-ietf-clue-data-model-schema-16.txt >>>> Pages : 77 >>>> Date : 2016-06-03 >>>>=20 >>>> Abstract: >>>> This document provides an XML schema file for the definition of = CLUE >>>> data model types. The term "CLUE" stands for "ControLling = mUltiple >>>> streams for tElepresence" and is the name of the IETF working = group >>>> in which this document, as well as other companion documents, has >>>> been developed. The document defines a coherent structure for >>>> information associated with the description of a telepresence >>>> scenario. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ >>>>=20 >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-16 >>>>=20 >>>> A diff from the previous version is available at: >>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-data-model-schema-16 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of = submission >>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>>=20 >>>=20 >>> _\\|//_ >>> ( O-O ) >>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>> Simon Pietro Romano >>> Universita' di Napoli Federico II >>> Computer Engineering Department >>> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >>> e-mail: spromano@unina.it >>>=20 >>> <>> idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte. >>> oooO >>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>> \ ( ( ) >>> \_) ) / >>> (_/ >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>>=20 >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --Apple-Mail=_F30FC80F-B480-42C0-8C9A-2F8E09C49346 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 6, 2016, at 7:08 PM, Christian Groves <Christian.Groves@nteczone.com> wrote:

I = agree RFC5226 talks about that documentation and review criteria should = be provided when setting up the registry.




Regards, = Christian


On 4/06/2016 5:31 = AM, Paul Kyzivat wrote:
This looks good, except for one thing:

While I like the new IANA registries, I'm a little concerned = about the criteria for adding new values. As written it requires only = Expert Review. That means that when new new values are approved there = will be only the registry entry to describe what they are. There won't = be anything to define the semantics of the new entries.

I'm inclined to think we should require a document, and for = the registry to reference it. IIRC that implies expert review as = well.

Also, I guess we probably need to = include templates for the registries, and some info for IANA to populate = them with the initial values.

=    Thanks,
   Paul

On 6/3/16 3:12 PM, Simon Pietro Romano = wrote:
Hello = everybody,

version -16 of the data model = draft is out. Here is a short summary of the diff with the previous = version of the document:

"Applied = modifications as per the following reviews: (i) Alexey Melnikov's = discuss and comments (abstract amendments, typo corrections, insertion = of references, etc.); (ii) Kathleen Moriarty's discuss and comments = (amendments to the Security Considerations section); (iii) Stefan = Winter's OPS-DIR review (use of enumerated types in the schema).=E2=80=9D<= br class=3D"">
Cheers,

Simon = & Roberta

On 03/giu/2016, at 21:06, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the = on-line Internet-Drafts directories.
This draft is a work = item of the ControLling mUltiple streams for tElepresence of the = IETF.

=       Title =           : An XML = Schema for the CLUE data model
=       Authors =         : Roberta Presta
=             &n= bsp;           Simo= n Pietro Romano
   Filename =        : = draft-ietf-clue-data-model-schema-16.txt
=    Pages =           : 77
   Date =            : = 2016-06-03

Abstract:
=  This document provides an XML schema file for the definition of = CLUE
 data model types.  The term "CLUE" stands = for "ControLling mUltiple
 streams for tElepresence" = and is the name of the IETF working group
 in which = this document, as well as other companion documents, has
=  been developed.  The document defines a coherent structure = for
 information associated with the description of = a telepresence
 scenario.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-sch= ema/

There's also a htmlized version = available at:
https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-1= 6

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-data-model-= schema-16


Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


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

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






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


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

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

= --Apple-Mail=_F30FC80F-B480-42C0-8C9A-2F8E09C49346-- From nobody Wed Jun 8 11:54:40 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BAC12B00B for ; Wed, 8 Jun 2016 11:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGMD1WY7urJM for ; Wed, 8 Jun 2016 11:54:36 -0700 (PDT) Received: from brc1.unina.it (brc1.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A482E12D159 for ; Wed, 8 Jun 2016 11:54:35 -0700 (PDT) X-ASG-Debug-ID: 1465412072-05ce3705b63d0830001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id c9ZJ8eDzORkaNCaO (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Wed, 08 Jun 2016 20:54:32 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from android-1ca95d607d90d7ed.fritz.box ([151.70.59.93]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id u58IsTWE002601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jun 2016 20:54:30 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <20160603190629.1502.66915.idtracker@ietfa.amsl.com> <3A57FEC8-1CF3-40EA-A749-FE23099303D0@unina.it> <58d9e1dd-0e89-2690-9f0d-1141c09de075@nteczone.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----UN2BX9WY7V83BZZP008E4WXNNDURU2" Content-Transfer-Encoding: 8bit From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] I-D Action: draft-ietf-clue-data-model-schema-16.txt Date: Wed, 08 Jun 2016 20:54:42 +0200 To: Alissa Cooper , Christian Groves Message-ID: X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1465412072 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 151.70.59.93 as permitted sender) X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, BSF_SPF_SOFTFAIL, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.30277 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: Cc: CLUE Subject: Re: [clue] I-D Action: draft-ietf-clue-data-model-schema-16.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 18:54:39 -0000 ------UN2BX9WY7V83BZZP008E4WXNNDURU2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Ok. We'll do that. Thanks, Simon Il 08 Giugno 2016 20:36:05 CEST, Alissa Cooper ha scritto: > >> On Jun 6, 2016, at 7:08 PM, Christian Groves > wrote: >> >> I agree RFC5226 talks about that documentation and review criteria >should be provided when setting up the registry. > >Yep. I would recommend reading through >https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-16 > to see >the most up-to-date guidance on what needs to be included when creating >a new registry. (I know it’s a draft but the content needed for this >purpose is stable enough.) > >Alissa > >> >> Regards, Christian >> >> >> On 4/06/2016 5:31 AM, Paul Kyzivat wrote: >>> This looks good, except for one thing: >>> >>> While I like the new IANA registries, I'm a little concerned about >the criteria for adding new values. As written it requires only Expert >Review. That means that when new new values are approved there will be >only the registry entry to describe what they are. There won't be >anything to define the semantics of the new entries. >>> >>> I'm inclined to think we should require a document, and for the >registry to reference it. IIRC that implies expert review as well. >>> >>> Also, I guess we probably need to include templates for the >registries, and some info for IANA to populate them with the initial >values. >>> >>> Thanks, >>> Paul >>> >>> On 6/3/16 3:12 PM, Simon Pietro Romano wrote: >>>> Hello everybody, >>>> >>>> version -16 of the data model draft is out. Here is a short summary >of the diff with the previous version of the document: >>>> >>>> "Applied modifications as per the following reviews: (i) Alexey >Melnikov's discuss and comments (abstract amendments, typo corrections, >insertion of references, etc.); (ii) Kathleen Moriarty's discuss and >comments (amendments to the Security Considerations section); (iii) >Stefan Winter's OPS-DIR review (use of enumerated types in the >schema).” >>>> >>>> Cheers, >>>> >>>> Simon & Roberta >>>> >>>>> On 03/giu/2016, at 21:06, internet-drafts@ietf.org wrote: >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >directories. >>>>> This draft is a work item of the ControLling mUltiple streams for >tElepresence of the IETF. >>>>> >>>>> Title : An XML Schema for the CLUE data model >>>>> Authors : Roberta Presta >>>>> Simon Pietro Romano >>>>> Filename : draft-ietf-clue-data-model-schema-16.txt >>>>> Pages : 77 >>>>> Date : 2016-06-03 >>>>> >>>>> Abstract: >>>>> This document provides an XML schema file for the definition of >CLUE >>>>> data model types. The term "CLUE" stands for "ControLling >mUltiple >>>>> streams for tElepresence" and is the name of the IETF working >group >>>>> in which this document, as well as other companion documents, has >>>>> been developed. The document defines a coherent structure for >>>>> information associated with the description of a telepresence >>>>> scenario. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> >https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ >>>>> >>>>> There's also a htmlized version available at: >>>>> https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-16 >>>>> >>>>> A diff from the previous version is available at: >>>>> >https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-16 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >submission >>>>> until the htmlized version and diff are available at >tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> _\\|//_ >>>> ( O-O ) >>>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>>> Simon Pietro Romano >>>> Universita' di Napoli Federico II >>>> Computer Engineering Department >>>> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >>>> e-mail: spromano@unina.it >>>> >>>> <>>> idioti. Ci rifletto un istante; e mi scoraggio>>. >Magritte. >>>> oooO >>>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> \ ( ( ) >>>> \_) ) / >>>> (_/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > > >------------------------------------------------------------------------ > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue ------UN2BX9WY7V83BZZP008E4WXNNDURU2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ok. We'll do that.

Thanks,

Simon

Il 08 Giugno 2016 20:36:05 CEST, Alissa Cooper <alissa@cooperw.in> ha scritto:

On Jun 6, 2016, at 7:08 PM, Christian Groves <Christian.Groves@nteczone.com> wrote:

I agree RFC5226 talks about that documentation and review criteria should be provided when setting up the registry.

Yep. I would recommend reading through https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-16 to see the most up-to-date guidance on what needs to be included when creating a new registry. (I know it’s a draft but the content needed for this purpose is stable enough.)

Alissa


Regards, Chris tian


On 4/06/2016 5:31 AM, Paul Kyzivat wrote:
This looks good, except for one thing:

While I like the new IANA registries, I'm a little concerned about the criteria for adding new values. As written it requires only Expert Review. That means that when new new values are approved there will be only the registry entry to describe what they are. There won't be anything to define the semantics of the new entries.

I'm inclined to think we should require a document, and for the registry to reference it. IIRC that implies expert review as well.

Also, I guess we probably need to include templates for the registries, and some info for IANA to populate them with the initial values.

   Thanks,
   Paul

On 6/3/16 3:12 PM, Simon Pietro Romano wrote:
Hello everybody,

version -16 of the data model draft is out. Here is a short summary of the diff with the previous version of the document:

"Applied modifications as per the following reviews: (i) Alexey Melnikov's discuss and comments (abstract amendments, typo corrections, insertion of references, etc.); (ii) Kathleen Moriarty's discuss and comments (amendments to the Security Considerations section); (iii) Stefan Winter's OPS-DIR review (use of enumerated types in the schema).”

Cheers,

Simon & Roberta

On 03/giu/2016, at 21:06, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of th e ControLling mUltiple streams for tElepresence of the IETF.

      Title           : An XML Schema for the CLUE data model
      Authors         : Roberta Presta
                        Simon Pietro Romano
   Filename        : draft-ietf-clue-data-model-schema-16.txt
   Pages           : 77
   Date            : 2016-06-03

Abstract:
 This document provides an XML schema file for the definition of CLUE
 data model types.  The term "CLUE" stands for "ControLling mUltiple
 streams for tElepresence" and is the name of the IETF working group
 in which this document, as well as other companion documents, has
 been developed.  The document defines a coherent structure for
 information associated with the description of a telepresence
 scenario.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-16


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


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

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






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


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

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


clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue
------UN2BX9WY7V83BZZP008E4WXNNDURU2-- From nobody Thu Jun 9 23:28:45 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A755312D59E for ; Thu, 9 Jun 2016 23:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZEwpaY1TJWh for ; Thu, 9 Jun 2016 23:28:41 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3FF12B056 for ; Thu, 9 Jun 2016 23:28:41 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id k184so970849wme.1 for ; Thu, 09 Jun 2016 23:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=I0eKGwzCuGkVee5tOoheTqE2KC5NOAYGimNYbKCETUM=; b=FMK4m7pCJevlOh20M0DYvsv3hX1O5Qsug3/qkyEwqJqXDshPgVG3ns40kbA/HyN1M6 yR0kKCcKzZ9A+Vb4YLe3gQramZYcaOE2UVtb1JS4JcQpP+hYck+hhv9Yirp6cnsgIlIM 63qV0tdq59MEyDTrZB1zPCdMg30X9XqumbJWaW0fXTm/cHsZF9uQJ+FHIescIjVIrO/9 5ntTTl/pX2pIvYb/DcuPrfZvWhRJlAvNRbN5kahMPZctURm+34RZbrz5fti7TNPIHHxH E7OkBHdZYuyHNOAJTcqVukGDOtThPgpdbtmbmO+5ifWsUOEyJP53Rd/N2jmewF7rI73F E6/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=I0eKGwzCuGkVee5tOoheTqE2KC5NOAYGimNYbKCETUM=; b=b8IZHbuBv6pFnaCX1mwXpXwUaTKthWpbN3OUh/+lAS3kEhJQXe7RvNa4t2TwDIoYcx 6+Ge7j9s7HdKi2QlYyGO7xyUMkGU4k3lSRyCWdA0z27eYFNGoE3AMkMFjKkmXB2TVImx mVD/kjXiz0EbePIiv+33fVfscHuIaiw8A1RdOOBFdZ+E+y9l284PQPxHiFsz6j55YtIM 6rK1ELSUBXdzQmEmQqEO/TBtKOpTcelcfuIuiTCWVrdTEEr9GzMt6BApK6b0/m8wq8fP MlUFyOMPG1t6tbamgw0NgVBKqDKNi1ZVE48U/Z4Yd4tNMUlAvjOOzhcDMMRFJ1Dhg0iH eCAw== X-Gm-Message-State: ALyK8tKgm4dg9Jwi4F7ENXPzfvIyKt18WSbzOnFEBKEIogW8Kq7IEhJF3jt8BOEmhdoO+Q== X-Received: by 10.28.227.11 with SMTP id a11mr987614wmh.100.1465540120005; Thu, 09 Jun 2016 23:28:40 -0700 (PDT) Received: from RoniPC (bzq-79-179-194-235.red.bezeqint.net. [79.179.194.235]) by smtp.gmail.com with ESMTPSA id dd7sm10654800wjb.22.2016.06.09.23.28.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2016 23:28:38 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <60d98730-8908-ec10-d200-c609ce11dd29@alum.mit.edu> In-Reply-To: <60d98730-8908-ec10-d200-c609ce11dd29@alum.mit.edu> Date: Fri, 10 Jun 2016 09:27:18 +0300 Message-ID: <0bb201d1c2e1$24cfbfc0$6e6f3f40$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKGQfWVXbgnidECxz21Z79/VZWM4QLnAR89nmIDSJA= Content-Language: he Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-07 ends 4 June X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 06:28:44 -0000 Hi Paul, Thanks, see inline Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, June 03, 2016 7:40 PM > To: clue@ietf.org > Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-07 ends 4 June > > On 5/21/16 4:20 PM, Daniel Burnett wrote: > > This message announces the start of a 2 week WGLC for > > draft-ietf-clue-rtp-mapping to review the updated draft. The last call > > will end at midnight on Saturday, 4 June 2016. > > > > PLEASE REVIEW NOW. > > Its been a long time since I read this document all the way through, so I just > did so. > > Note that I am far from an RTP expert, so my qualifications for reviewing this > document are limited. The following covers mostly stuff that doesn't require > too much understanding of RTP. > > All of the following seem to be to be "quick fix" things. Aside from these I > think the document is ready to go. > > * Section 4: > > The 2nd to last paragraph begins with "isAlternately". Clearly the "is" > needs to be removed. [Roni Even] OK > > * Section 4.1: > > The sentence "[I-D.ietf-mmusic-sdp-bundle-negotiation] how to associate a > received RTP stream with the m-line describing it." doesn't parse. It is missing > a word. I think "specifies" should be inserted prior to "how to associate". > [Roni Even] OK > Then, in "The assumption in the work is that...", it isn't clear what "the work" > refers to. Is it CLUE, or BUNDLE? I think it means CLUE. So perhaps change > to "The assumption in CLUE is that...". [Roni Even] The work is bundle in this case, changed it. > > I'll also note that "[I-D.ietf-mmusic-sdp-bundle-negotiation]" is rather > unwieldy to read. It would be helpful to change the references to something > more concise, such as [BUNDLE]. (xml2rfc supports this.) [Roni Even] This will change to the RFC number. > > The following one-sentence paragraph: > > SDP Source attribute [RFC5576] mechanisms to describe specific > attributes of RTP sources based on their SSRC. > > isn't a complete sentence. I don't have a particular fix to suggest. [Roni Even] Added provide mechanisms > > Then the sentence: > > The recommended support of the simulcast case is to use > [I-D.ietf-mmusic-sdp-simulcast] > > needs a period at the end. [Roni Even] OK > > * Section 4.2: > > The intro to this section: > > This section lists, more briefly, the requirements a media > architecture for Clue telepresence needs to achieve, summarizing the > discussion of previous sections. > > doesn't seem appropriate now that the work done. Also, I don't think it really > summarizes discussion in prior sections. Perhaps something like the following > would be better: > > "This section lists the CLUE media requirements that guided the development > of this RTP mapping document." [Roni Even] OK > > * Section 4.5: > > The recommendation is that CLUE endpoints using SSRC multiplexing > MUST support [I-D.ietf-mmusic-sdp-bundle-negotiation] and use the SDP > mid attribute for mapping. > > I read this as being a bit stronger than I think is intended. I think the intent is > that all CLUE endpoints support BUNDLE (for interoperability), but that they > need not offer it. And they only need to use mid when they are using > BUNDLE. If they are not using BUNDLE then use of mid is optional. [Roni Even] I am not sure, what it says is that if when using SSRC multiplexing it must be done using bundle > > * Section 5: > > The statement "The solutions described in this document are believed to > meet these requirements" seems a bit weak in a completed document. Any > doubts as to whether the requirements have been met should have been > raised and resolved now. So can we omit this? [Roni Even] I remove "are believed to" > > Should all the requirements be listed in this section, with an explanation of > how each is met? [Roni Even] The section discuss the ones that were discussed and needed clarifications > > * Section 9: > > Shouldn't there be two things registered here? Both the RTP header > extension and the RTCP SDES item. [Roni Even] both are there. > > * Nits: > > There are a few outdated references. [Roni Even] Can be done later > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Jun 10 11:49:04 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A802912D095 for ; Fri, 10 Jun 2016 11:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=1dOW032g; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=n+5Bm0lf 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 rXRCtuFB9hWG for ; Fri, 10 Jun 2016 11:49:00 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF84A12B047 for ; Fri, 10 Jun 2016 11:49:00 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 3BD6A20964 for ; Fri, 10 Jun 2016 14:48:59 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Fri, 10 Jun 2016 14:48:59 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=Crf aunAm3f6rfKO9AdLWJtLN0Jk=; b=1dOW032g+eJP0ZmfAFLqclJV3VzzHroaPK2 1CjctTJwLjHx5cz9zpXEw5lOsNSNCv/I3d0eZq5t41eDerdchtW4WhHucam5ZKIg DznqHn2Dex4l8xVx+gWei/6cu0MSBuspqWe22PNzykLV4ZWG+ZJONVgqHt0lrdUN BQwMqfSU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=CrfaunAm3f6rfKO9AdLWJtLN0Jk=; b=n+5Bm 0lf+VtKd1qjEM2O4cWdIPN8UQkZI1ZgYDyi8tVY/Md3+gLBZrInc73rTk56eKYy+ f6q1C6M1cfgBdvhy/HpygX69Dkn/HQV9XAE81Fs4oWDIbe5wKaeYGHE4BuzQ4tuZ orT9NhmsZjrSqRom79Pk7Hwm2gWncuffYrSnHk= X-Sasl-enc: tjIZjS4QE1q0yZp5oI7wJTaICmmMs6+UfuwvoFT77SQP 1465584538 Received: from dhcp-171-68-20-136.cisco.com (dhcp-171-68-20-136.cisco.com [171.68.20.136]) by mail.messagingengine.com (Postfix) with ESMTPA id C0AB9CCDAC for ; Fri, 10 Jun 2016 14:48:58 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7C34ECF9-51B4-4E0C-B24B-508C468ABCA0@cooperw.in> Date: Fri, 10 Jun 2016 11:48:58 -0700 To: CLUE Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [clue] AD evaluation: draft-ietf-clue-datachannel X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 18:49:03 -0000 I have reviewed this document in preparation for IETF last call. I think = it is almost ready. I have a couple of questions I'd like to discuss = first and some nits that should be resolved together with any last call = comments. I will note that the security considerations here ultimately rely on = draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch, which = are not finished yet. This means it is hard to fully evaluate this spec = at this time. We can proceed with IETF LC after discussion of the = questions below, but I would suggest either not proceeding further than = that until those documents are done, or developing specific text for = this document that documents the security considerations if you don't = want to wait. Questions: 1) In Section 3.2.5, the text says "Other features of [RFC5061] MUST NOT = be used." Can you clarify what "other features" this is in reference to? = Is this just about the ability to set a primary IP address, or something = else? I think it would help to be more specific here. 2) I think Section 3.3 needs to be more clear about whether it is = specifying things for all WebRTC data channels, or just for CLUE data = channels. 3.3.1 uses the term WebRTC data channel when I would have = expected it to use the term CLUE data channel. 3) IF DCEP is out of scope, why do you then say that this specification = relies on the security properties of draft-ietf-rtcweb-data-protocol? Nits: - Sec. 1 I find it a bit odd to say that DCEP is out of scope here but not = mention that negotiation of the CLUE data channel is defined in = draft-ietf-clue-signaling. I think at a minimum a reference to the = signaling doc is needed, and would also recommend dropping the note = about DCEP unless you think you really need it. - Sec 3.2.3 s/A CLUE entity MUST NOT use the partial reliability and limited = retransmission SCTP extensions/A CLUE entity MUST NOT use the partial = reliability or limited retransmission SCTP extensions Thanks, Alissa= From nobody Sat Jun 11 10:25:35 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A6912D81A for ; Sat, 11 Jun 2016 10:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVQ1xMR3s5QT for ; Sat, 11 Jun 2016 10:25:32 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 5D2C712D7EF for ; Sat, 11 Jun 2016 10:25:32 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-07v.sys.comcast.net with SMTP id BmdebwFwdrtfLBmf5bSJyZ; Sat, 11 Jun 2016 17:25:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465665931; bh=H/UKGckIFsNAk0gXjY/G1U7LroejZ9AA0m1BbR3aClA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=XgAoRTzMe/UHdD3KrB7g5Bi2pn2qXSmzV33HdKhNU13j/6AxyLTwaxAEjbdhdUUW6 jb1wVHLn1Pvaoi5hLJFNfnawhaM7n9jLEJC7WhpZ/rx8z1X5I655qTlxXcjUQ593dF jLqcOMUgZDgmhcNMWzPD2pMRNlon37ACa8A9cYlWlNIg4prub3cXuQ0VpAKfQy81zp Qf26Zo5YBHj8CA3DJflEOjseqcrrnNQ/vFEJountV9GVxtI0dovzatuJb+fktkpHbR gJwObUUrWwJ5f7IRn2uWvJ/L05wSFM1aKFhI36VOHML3uO6mCaOoFygdUnKpDPvrcV mYoOVC7Q5ptkw== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with comcast id 5VRX1t0013KdFy101VRXZw; Sat, 11 Jun 2016 17:25:31 +0000 To: Roni Even , clue@ietf.org References: <60d98730-8908-ec10-d200-c609ce11dd29@alum.mit.edu> <0bb201d1c2e1$24cfbfc0$6e6f3f40$@gmail.com> From: Paul Kyzivat Message-ID: <8cdffb0f-70a2-b0fe-dbfe-fd65b353dcb6@alum.mit.edu> Date: Sat, 11 Jun 2016 13:25:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <0bb201d1c2e1$24cfbfc0$6e6f3f40$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-07 ends 4 June X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 17:25:33 -0000 Roni, I've trimmed this to the ones I wanted to follow up on. All else is fine. On 6/10/16 2:27 AM, Roni Even wrote: >> I'll also note that "[I-D.ietf-mmusic-sdp-bundle-negotiation]" is rather >> unwieldy to read. It would be helpful to change the references to > something >> more concise, such as [BUNDLE]. (xml2rfc supports this.) > [Roni Even] This will change to the RFC number. OK, that didn't dawn on me. >> * Section 4.5: >> >> The recommendation is that CLUE endpoints using SSRC multiplexing >> MUST support [I-D.ietf-mmusic-sdp-bundle-negotiation] and use the SDP >> mid attribute for mapping. >> >> I read this as being a bit stronger than I think is intended. I think the > intent is >> that all CLUE endpoints support BUNDLE (for interoperability), but that > they >> need not offer it. And they only need to use mid when they are using >> BUNDLE. If they are not using BUNDLE then use of mid is optional. > [Roni Even] I am not sure, what it says is that if when using SSRC > multiplexing it must be done using bundle OK, I take it back. I haven't thought about this for awhile and was a little muddled. >> * Section 9: >> >> Shouldn't there be two things registered here? Both the RTP header >> extension and the RTCP SDES item. > [Roni Even] both are there. Sorry, I didn't look close enough and thought all that text was about the captureid. I think it would be helpful to break these into two subsections so that it is very clear that there are two actions called for. Thanks, Paul From nobody Sun Jun 12 10:42:02 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E81212D0F9 for ; Sun, 12 Jun 2016 10:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4RDEr3Eqaer for ; Sun, 12 Jun 2016 10:41:59 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED9612B060 for ; Sun, 12 Jun 2016 10:41:58 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-31-575d9ee4aea2 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3D.E8.27088.4EE9D575; Sun, 12 Jun 2016 19:41:56 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0294.000; Sun, 12 Jun 2016 19:41:56 +0200 From: Christer Holmberg To: Alissa Cooper , CLUE Thread-Topic: [clue] AD evaluation: draft-ietf-clue-datachannel Thread-Index: AQHRw0jEzMDcqoc03UWFCfk39MSmIJ/mDfyg Date: Sun, 12 Jun 2016 17:41:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B3804C7E2@ESESSMB209.ericsson.se> References: <7C34ECF9-51B4-4E0C-B24B-508C468ABCA0@cooperw.in> In-Reply-To: <7C34ECF9-51B4-4E0C-B24B-508C468ABCA0@cooperw.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7uu6TebHhBlcPmFpMP/OX0WL/qcvM DkweX568ZPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG8bfTGQtOylcs/ZbewDhVsouRk0NCwESi 48h7ZghbTOLCvfVsXYxcHEICRxgl2nbcZ4VwljBKzH01G6iKg4NNwEKi+582SIOIgLXEkgfr GEFsYQE7icnTTjBCxO0lvjcuZIGwjSQ+NX1lB7FZBFQluvYcB7N5BXwlvrx+DlYvJGAr8fPN BFYQmxNozodzi8EOYgQ66PupNUwgNrOAuMStJ/OZIA4VkFiy5zzU0aISLx//Y4WwlSQalzxh hajXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkbR4tTipNx0 IyO91KLM5OLi/Dy9vNSSTYzAKDm45bfBDsaXzx0PMQpwMCrx8D7ojAkXYk0sK67MPcQowcGs JMLrPjs2XIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU1ILUIpgsEwenVANj 6c0s2UMHVHoDvtyu0aqNqbmw36bRzaPx09R1HctNHuy6suqQkEaH/sP9z17ZS8lw55Wquq2L iXTTzPjLG2Z5WU7sV3jxohqWJfaGuU4Wc8Mq16qd/MnkV2a/p6gtL+5C4KIwwbQNuXOldQP/ JG498+HiQ2Nl/WtLy9IC5jWWTX90LyvgeoESS3FGoqEWc1FxIgDzcl26jgIAAA== Archived-At: Subject: Re: [clue] AD evaluation: draft-ietf-clue-datachannel X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 17:42:01 -0000 Hi Alissa, Thanks for your comments! See inline. > I will note that the security considerations here ultimately rely on draf= t-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch, which are not f= inished yet. This > means it is hard to fully evaluate this spec at this time. We can proceed= with IETF LC after discussion of the questions below, but I would suggest = either not > proceeding further than that until those documents are done, or developin= g specific text for this document that documents the security consideration= s if you don't want to wait. I am ok waiting for the generic rtcweb-security drafts to be finished. Afte= r that it will be easier to see what/if CLUE data channel specific security= text we need to add. ------------- Questions: 1) In Section 3.2.5, the text says "Other features of [RFC5061] MUST NOT be= used." Can you clarify what "other features" this is in reference to? Is t= his just about the ability to set a primary IP address, or something else? = I think it would help to be more specific here. The text refers to the new 'Supported Extensions Parameter' parameter, a ge= neric mechanism for signalling support of SCTP extensions, defined in RFC 5= 061. I more or less copied the text from draft-ietf-rtcweb-data-channel: "o The dynamic address reconfiguration extension defined in [RFC5061] MUST be used to signal the support of the stream reset extension defined in [RFC6525]. Other features of [RFC5061] are OPTIONAL." So, I guess we could simply refer to that text, and say something like: "As defined in [ref-to-draft-rtcweb-data-channel], the dynamic address = reconfiguration extension=20 ('Supported Extensions Parameter' parameter) defined in [RFC5061] must= be used to signal the=20 support of the stream reset extension defined in [RFC6525]. Other feat= ures of [RFC5061] MUST NOT be used for CLUE data channels." Now, if you think that the 'Supported Extensions Parameter' parameter shall= be spelt out explicitly, I guess that comment should also be given for dra= ft-ietf-rtcweb-data-channel. ------------- 2) I think Section 3.3 needs to be more clear about whether it is specifyin= g things for all WebRTC data channels, or just for CLUE data channels. 3.3.= 1 uses the term WebRTC data channel when I would have expected it to use th= e term CLUE data channel. I can change to "CLUE data channel" in section 3.3.1. In section 3.3.1.1 I think we shall keep "WebRTC data channel", because the= text is about WebRTC data channels in general. ------------- > 3) IF DCEP is out of scope, why do you then say that this specification r= elies on the security properties of draft-ietf-rtcweb-data-protocol? DCEP used to be in scope, and when we made it out of scope it seems like I = forgot to remove the text from the security considerations. I will remove t= he text. ------------- Nits: > - Sec. 1 > > I find it a bit odd to say that DCEP is out of scope here but not mention= that negotiation of the CLUE data channel is defined in=20 > draft-ietf-clue-signaling. I think at a minimum a reference to the signal= ing doc is needed, and would also recommend dropping=20 > the note about DCEP unless you think you really need it. The negotiating of the CLUE data channel is defined in draft-ietf-mmusic-da= ta-channel-sdpneg, which the does does reference. draft-ietf-clue-signaling is more about negotiating the CLUE session in gen= eral. I suggest to keep the test as it is. ------------- > - Sec 3.2.3 > > s/A CLUE entity MUST NOT use the partial reliability and limited retransm= ission SCTP extensions/A CLUE entity MUST NOT use the partial reliability o= r limited retransmission SCTP extensions Will fix as suggested. ------------- I've created a pull request with the suggested changes: https://github.com/cdh4u/draft-clue-datachannel/tree/alissa_comments Thanks! Regards, Christer From nobody Mon Jun 20 10:48:04 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E321712D8DD for ; Mon, 20 Jun 2016 10:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=tYi/Iiqu; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=ioE1jVxQ 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 EKV07502XdMa for ; Mon, 20 Jun 2016 10:48:02 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FEA712D814 for ; Mon, 20 Jun 2016 10:48:02 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8A97B2046C; Mon, 20 Jun 2016 13:48:01 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 20 Jun 2016 13:48:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=qeCOx6FFCpBxLyg9bHmSULHKowU=; b=tYi/Ii quXMYqVsjHTlagiV63kQW3T+MfsDjSFgH3zYmwyPVrIGnZjk1N0/Xfqu1vbT8NA6 oJANrL3Lu+FW/Tmkxjg6R3i45LaXMb66or9aAHyzGLdnHni5NFDE+a5JGanm4vyr 5lxCzLeczZO4sEaCGNTOfBSxmTwRVIM5gtuQY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=qeCOx6FFCpBxLyg 9bHmSULHKowU=; b=ioE1jVxQM1fqPnLjk1/1HO9gaIYZkP6eiBYXrUvBOGvOBh3 tTcfs7AHnsu3lu3aQ+l2GVh4RsX7YsiUR02UvdAbr9bXLaXCI7idxKN4X7+XcJk/ iCJU88yggpecu4U8tEftpJK05cin4w5aNy2fKAfnPT4fkfGNLx4iqSi2U1dk= X-Sasl-enc: tR/Hgj/LKwxz7jVwEZNqEReuiVpomXDXnDMiDArUNJX7 1466444881 Received: from [10.35.132.59] (unknown [128.107.241.161]) by mail.messagingengine.com (Postfix) with ESMTPA id D547DCCDB9; Mon, 20 Jun 2016 13:48:00 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <7594FB04B1934943A5C02806D1A2204B3804C7E2@ESESSMB209.ericsson.se> Date: Mon, 20 Jun 2016 10:48:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C34ECF9-51B4-4E0C-B24B-508C468ABCA0@cooperw.in> <7594FB04B1934943A5C02806D1A2204B3804C7E2@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: CLUE Subject: Re: [clue] AD evaluation: draft-ietf-clue-datachannel X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 17:48:04 -0000 Thanks Christer, this all looks good. One comment below. > On Jun 12, 2016, at 10:41 AM, Christer Holmberg = wrote: >=20 > Hi Alissa, >=20 > Thanks for your comments! See inline. >=20 >> I will note that the security considerations here ultimately rely on = draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch, which = are not finished yet. This >> means it is hard to fully evaluate this spec at this time. We can = proceed with IETF LC after discussion of the questions below, but I = would suggest either not >> proceeding further than that until those documents are done, or = developing specific text for this document that documents the security = considerations if you don't want to wait. >=20 > I am ok waiting for the generic rtcweb-security drafts to be finished. = After that it will be easier to see what/if CLUE data channel specific = security text we need to add. Ok. If anyone else disagrees, please speak up. Otherwise I think you can = publish a revision and I=E2=80=99ll change the state to indicate that = we=E2=80=99re waiting on an external document. Thanks, Alissa >=20 > ------------- >=20 > Questions: >=20 > 1) In Section 3.2.5, the text says "Other features of [RFC5061] MUST = NOT be used." Can you clarify what "other features" this is in reference = to? Is this just about the ability to set a primary IP address, or = something else? I think it would help to be more specific here. >=20 > The text refers to the new 'Supported Extensions Parameter' parameter, = a generic mechanism for signalling support of SCTP extensions, defined = in RFC 5061. >=20 > I more or less copied the text from draft-ietf-rtcweb-data-channel: >=20 > "o The dynamic address reconfiguration extension defined in = [RFC5061] > MUST be used to signal the support of the stream reset extension > defined in [RFC6525]. Other features of [RFC5061] are OPTIONAL." >=20 > So, I guess we could simply refer to that text, and say something = like: >=20 > "As defined in [ref-to-draft-rtcweb-data-channel], the dynamic = address reconfiguration extension=20 > ('Supported Extensions Parameter' parameter) defined in [RFC5061] = must be used to signal the=20 > support of the stream reset extension defined in [RFC6525]. Other = features of [RFC5061] > MUST NOT be used for CLUE data channels." >=20 > Now, if you think that the 'Supported Extensions Parameter' parameter = shall be spelt out explicitly, I guess that comment should also be given = for draft-ietf-rtcweb-data-channel. >=20 > ------------- >=20 > 2) I think Section 3.3 needs to be more clear about whether it is = specifying things for all WebRTC data channels, or just for CLUE data = channels. 3.3.1 uses the term WebRTC data channel when I would have = expected it to use the term CLUE data channel. >=20 > I can change to "CLUE data channel" in section 3.3.1. >=20 > In section 3.3.1.1 I think we shall keep "WebRTC data channel", = because the text is about WebRTC data channels in general. >=20 > ------------- >=20 >> 3) IF DCEP is out of scope, why do you then say that this = specification relies on the security properties of = draft-ietf-rtcweb-data-protocol? >=20 > DCEP used to be in scope, and when we made it out of scope it seems = like I forgot to remove the text from the security considerations. I = will remove the text. >=20 > ------------- >=20 > Nits: >=20 >> - Sec. 1 >>=20 >> I find it a bit odd to say that DCEP is out of scope here but not = mention that negotiation of the CLUE data channel is defined in=20 >> draft-ietf-clue-signaling. I think at a minimum a reference to the = signaling doc is needed, and would also recommend dropping=20 >> the note about DCEP unless you think you really need it. >=20 > The negotiating of the CLUE data channel is defined in = draft-ietf-mmusic-data-channel-sdpneg, which the does does reference. >=20 > draft-ietf-clue-signaling is more about negotiating the CLUE session = in general. >=20 > I suggest to keep the test as it is. >=20 > ------------- >=20 >> - Sec 3.2.3 >>=20 >> s/A CLUE entity MUST NOT use the partial reliability and limited = retransmission SCTP extensions/A CLUE entity MUST NOT use the partial = reliability or limited retransmission SCTP extensions >=20 > Will fix as suggested. >=20 > ------------- >=20 > I've created a pull request with the suggested changes: >=20 > https://github.com/cdh4u/draft-clue-datachannel/tree/alissa_comments >=20 > Thanks! >=20 > Regards, >=20 > Christer From nobody Tue Jun 21 02:25:34 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEF812B04D for ; Tue, 21 Jun 2016 02:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mpHnWW0liQR for ; Tue, 21 Jun 2016 02:25:31 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916B012B035 for ; Tue, 21 Jun 2016 02:25:30 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-3b-576908080095 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8E.B6.12516.80809675; Tue, 21 Jun 2016 11:25:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0294.000; Tue, 21 Jun 2016 11:25:27 +0200 From: Christer Holmberg To: Alissa Cooper Thread-Topic: [clue] AD evaluation: draft-ietf-clue-datachannel Thread-Index: AQHRw0jEzMDcqoc03UWFCfk39MSmIJ/mDfyggAyBsACAATlHgA== Date: Tue, 21 Jun 2016 09:25:27 +0000 Message-ID: References: <7C34ECF9-51B4-4E0C-B24B-508C468ABCA0@cooperw.in> <7594FB04B1934943A5C02806D1A2204B3804C7E2@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7qy4HR2a4QcMeYYvpZ/4yWuw/dZnZ gcnjy5OXTB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYNTO2YIFaxd43s9kbGL/LdTFyckgImEic eriWHcIWk7hwbz1bFyMXh5DAEUaJay0LmSGcJYwS245+Yupi5OBgE7CQ6P6nDdIgIqAqcfXY DzYQm1lAQmLVxQ+MILawgJ3Em1872CFq7CW+Ny5kAWkVEXCSWHFAHSTMAtT6/fdjsFZeASuJ t3OPsEKs2soo8bT5NzNIghNozs+f38FsRqDjvp9awwSxS1zi1pP5TBBHC0gs2XOeGcIWlXj5 +B8riC0qoCfx5d48RpC9EgJKEtO2pkG06kncmDoF6mRribfTrrBC2NoSyxa+Zoa4R1Di5Mwn LBMYJWYh2TYLSfssJO2zkLTPQtK+gJF1FaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZgDB7c 8lt3B+Pq146HGAU4GJV4eBX0M8KFWBPLiitzDzFKcDArifBasWeGC/GmJFZWpRblxxeV5qQW H2KU5mBREuf1f6kYLiSQnliSmp2aWpBaBJNl4uCUamBckvaq5LXCplmri8VfxGr89Q/SEz5+ +fraO+4zxRa/k3x+695N43UcTypPnbvnVnbNx5iz67pEkI/EXf/sXQd5c2qn/A6vWfRATdGt +qZL2N9rHcVbrWJ69dkcn4au6vi3KDbZoPchZ7N1V62YkGHKn8mOwa84/kfzOT8Qy32UoeY+ q25Tr5gSS3FGoqEWc1FxIgCuBO8wvQIAAA== Archived-At: Cc: CLUE Subject: Re: [clue] AD evaluation: draft-ietf-clue-datachannel X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 09:25:33 -0000 Hi, I=B9ll fix the other things, and submit a new version. Thanks! Regards, Christer On 20/06/16 20:48, "Alissa Cooper" wrote: >Thanks Christer, this all looks good. One comment below. > >> On Jun 12, 2016, at 10:41 AM, Christer Holmberg >> wrote: >>=20 >> Hi Alissa, >>=20 >> Thanks for your comments! See inline. >>=20 >>> I will note that the security considerations here ultimately rely on >>>draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch, which >>>are not finished yet. This >>> means it is hard to fully evaluate this spec at this time. We can >>>proceed with IETF LC after discussion of the questions below, but I >>>would suggest either not >>> proceeding further than that until those documents are done, or >>>developing specific text for this document that documents the security >>>considerations if you don't want to wait. >>=20 >> I am ok waiting for the generic rtcweb-security drafts to be finished. >>After that it will be easier to see what/if CLUE data channel specific >>security text we need to add. > >Ok. If anyone else disagrees, please speak up. Otherwise I think you can >publish a revision and I=B9ll change the state to indicate that we=B9re >waiting on an external document. > >Thanks, >Alissa > > >>=20 >> ------------- >>=20 >> Questions: >>=20 >> 1) In Section 3.2.5, the text says "Other features of [RFC5061] MUST >>NOT be used." Can you clarify what "other features" this is in reference >>to? Is this just about the ability to set a primary IP address, or >>something else? I think it would help to be more specific here. >>=20 >> The text refers to the new 'Supported Extensions Parameter' parameter, >>a generic mechanism for signalling support of SCTP extensions, defined >>in RFC 5061. >>=20 >> I more or less copied the text from draft-ietf-rtcweb-data-channel: >>=20 >> "o The dynamic address reconfiguration extension defined in [RFC5061] >> MUST be used to signal the support of the stream reset extension >> defined in [RFC6525]. Other features of [RFC5061] are OPTIONAL." >>=20 >> So, I guess we could simply refer to that text, and say something like: >>=20 >> "As defined in [ref-to-draft-rtcweb-data-channel], the dynamic >>address reconfiguration extension >> ('Supported Extensions Parameter' parameter) defined in [RFC5061] >>must be used to signal the >> support of the stream reset extension defined in [RFC6525]. Other >>features of [RFC5061] >> MUST NOT be used for CLUE data channels." >>=20 >> Now, if you think that the 'Supported Extensions Parameter' parameter >>shall be spelt out explicitly, I guess that comment should also be given >>for draft-ietf-rtcweb-data-channel. >>=20 >> ------------- >>=20 >> 2) I think Section 3.3 needs to be more clear about whether it is >>specifying things for all WebRTC data channels, or just for CLUE data >>channels. 3.3.1 uses the term WebRTC data channel when I would have >>expected it to use the term CLUE data channel. >>=20 >> I can change to "CLUE data channel" in section 3.3.1. >>=20 >> In section 3.3.1.1 I think we shall keep "WebRTC data channel", because >>the text is about WebRTC data channels in general. >>=20 >> ------------- >>=20 >>> 3) IF DCEP is out of scope, why do you then say that this >>>specification relies on the security properties of >>>draft-ietf-rtcweb-data-protocol? >>=20 >> DCEP used to be in scope, and when we made it out of scope it seems >>like I forgot to remove the text from the security considerations. I >>will remove the text. >>=20 >> ------------- >>=20 >> Nits: >>=20 >>> - Sec. 1 >>>=20 >>> I find it a bit odd to say that DCEP is out of scope here but not >>>mention that negotiation of the CLUE data channel is defined in >>> draft-ietf-clue-signaling. I think at a minimum a reference to the >>>signaling doc is needed, and would also recommend dropping >>> the note about DCEP unless you think you really need it. >>=20 >> The negotiating of the CLUE data channel is defined in >>draft-ietf-mmusic-data-channel-sdpneg, which the does does reference. >>=20 >> draft-ietf-clue-signaling is more about negotiating the CLUE session in >>general. >>=20 >> I suggest to keep the test as it is. >>=20 >> ------------- >>=20 >>> - Sec 3.2.3 >>>=20 >>> s/A CLUE entity MUST NOT use the partial reliability and limited >>>retransmission SCTP extensions/A CLUE entity MUST NOT use the partial >>>reliability or limited retransmission SCTP extensions >>=20 >> Will fix as suggested. >>=20 >> ------------- >>=20 >> I've created a pull request with the suggested changes: >>=20 >> https://github.com/cdh4u/draft-clue-datachannel/tree/alissa_comments >>=20 >> Thanks! >>=20 >> Regards, >>=20 >> Christer > From nobody Tue Jun 21 03:01:02 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BBD12D0AD; Tue, 21 Jun 2016 03:01:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160621100100.17043.66939.idtracker@ietfa.amsl.com> Date: Tue, 21 Jun 2016 03:01:00 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-datachannel-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 10:01:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : CLUE Protocol data channel Author : Christer Holmberg Filename : draft-ietf-clue-datachannel-13.txt Pages : 14 Date : 2016-06-21 Abstract: This document defines how to use the WebRTC data channel mechanism in order to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol messages between two CLUE entities. The document defines how to describe the SCTPoDTLS association used to realize the CLUE data channel using the Session Description Protocol (SDP), and defines usage of SDP-based "SCTP over DTLS" data channel negotiation mechanism for establishing a CLUE data channel. Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer procedures for negotiating usage of a CLUE data channel, are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-datachannel-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-datachannel-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 21 03:03:02 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6167312D093 for ; Tue, 21 Jun 2016 03:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DaWfOqSv_dx for ; Tue, 21 Jun 2016 03:02:59 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715F912B044 for ; Tue, 21 Jun 2016 03:02:59 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-84-576910d15de0 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 26.2B.27088.1D019675; Tue, 21 Jun 2016 12:02:57 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0294.000; Tue, 21 Jun 2016 12:02:56 +0200 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Draft new version: draft-clue-data-channel-13 Thread-Index: AQHRy6QVTjIVVvIOX0eA4T0TW3uZXQ== Date: Tue, 21 Jun 2016 10:02:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D38EEC65B2FEchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2J7iO5FgcxwgxktUhbTz/xltJg57QOr xf5Tl5kdmD2+PHnJ5LFkyU8mjy+XP7MFMEdx2aSk5mSWpRbp2yVwZczf8pytoIGnYlbbLbYG xkNcXYycHBICJhJLFn5nhbDFJC7cW8/WxcjFISRwhFHiwsZ9jBDOEiDnz1fmLkYODjYBC4nu f9ogDSICyhJHN/ezgdjMAhkSPyb9ARskLGAmcXxbCyNEjbXE3s0T2CFsPYmzG/6D1bMIqEpM 2vAVLM4rYCWx8OQysDgj0BHfT61hgpgpLnHryXwmiOMEJJbsOc8MYYtKvHz8D2yXKNDML/fm MYKcJiGgKLG8Xw6iNV7i+ud2RojxghInZz5hmcAoMgvJ1FlIymYhKYOIG0i8PzefGcLWlli2 8DWUrS+x8ctZRgjbWmLK6lfsyGoWMHKsYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAiMwINb fhvsYHz53PEQowAHoxIPr4J+RrgQa2JZcWXuIUYJDmYlEd633JnhQrwpiZVVqUX58UWlOanF hxilOViUxHn9XyqGCwmkJ5akZqemFqQWwWSZODilGhjlt5X8FfD/brp9q9yzL4JC/szxcR5/ ivfHy30/ceG9uIC+iuwSLXYN448hCVfYpE9J6ynZNp7iuHBotUjGloLrG7LaHC+sdXzl8Ls/ z3DD4ls54fcKOx9l+lo4WWxRC1zNKj5vEtOjNbuNZ3byn/sqaXjabeInt2qnZ7f+ZiguvLWD nT/oopASS3FGoqEWc1FxIgABLCX8vAIAAA== Archived-At: Cc: "clue-chairs@tools.ietf.org" Subject: [clue] Draft new version: draft-clue-data-channel-13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 10:03:01 -0000 --_000_D38EEC65B2FEchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Based on Alissa=92s comments, I=92ve submitted a new version (-13) of the C= LUE data channel draft. Note that the comment regarding the Security Considerations is still pendin= g. GitHub: https://github.com/cdh4u/draft-clue-datachannel (personal repo) Regards, Christer --_000_D38EEC65B2FEchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Based on Alissa=92s comments, I=92ve submitted a new version (-13) of = the CLUE data channel draft.

Note that the comment regarding the Security Considerations is still p= ending.


Regards,

Christer
--_000_D38EEC65B2FEchristerholmbergericssoncom_--