From nobody Tue Aug 9 09:22: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 9E05612D60E for ; Tue, 9 Aug 2016 09:22:10 -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=r3JYWWZu; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=AUt3eBs8 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 1C56HeRjmoDn for ; Tue, 9 Aug 2016 09:22: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 0D80212D5FB for ; Tue, 9 Aug 2016 09:22:07 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5D55020572 for ; Tue, 9 Aug 2016 12:22:06 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 09 Aug 2016 12:22:06 -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=4P/ iL7/mJmZ9M1RbeF2pj+yiBLM=; b=r3JYWWZuxkjHZXWv4Ce0vgF18VQ5IDZAWEh BpTbFvJxSM7/g87IrnbOvJYo4afKM0xKE1qcWeBJJU+muMwLEV0Y0vaeE+24PJJT Zw8HHMPDIi/LqS5wj0qhBHWXSHgJy/rCjSVwzjG8wGOawV0xqBumc41qUzG6PKHL nUhsj23k= 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=4P/iL7/mJmZ9M1RbeF2pj+yiBLM=; b=AUt3e Bs8md5svdZ+QfokbBOyLA8D0Y/LLNxdlmIxgTdbIqgNAKw9MP5dxsF2H3XGPsn4K 9P2QmxjrRle2mAcwV1SP8rpJObFSlgjQnBEmeFMbrJf0K4MpG7uRILG0gw0lGYB3 +FNeuhy5P0HSgYipq+StbAmI1X4Ls5jB8tk5jI= X-Sasl-enc: M+ZcxuKq3FYttuZQesyWKgtiBucVTAEGV8YeDvz/qfpQ 1470759725 Received: from dhcp-171-68-20-114.cisco.com (dhcp-171-68-20-114.cisco.com [171.68.20.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 9C6E3F285F for ; Tue, 9 Aug 2016 12:22:05 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 9 Aug 2016 09:22:04 -0700 To: CLUE Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [clue] CLUE chair change 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, 09 Aug 2016 16:22:10 -0000 Hi all, Dan Burnett has stepped down as CLUE co-chair due to other time = commitments. Paul and Roni will be picking up the remaining documents to = shepherd to completion. This group is in the home stretch so hopefully = we=E2=80=99ll see the work come to a timely conclusion. Alissa= From nobody Tue Aug 9 12:05:06 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 F057812D189; Tue, 9 Aug 2016 12:05:02 -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.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147076950298.30604.1456018610136314437.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2016 12:05:02 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-datachannel-14.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, 09 Aug 2016 19:05:04 -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-14.txt Pages : 14 Date : 2016-08-09 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-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-datachannel-14 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 Sat Aug 13 05:06:19 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5BA12D5BF for ; Sat, 13 Aug 2016 05:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247, 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 pXG0hV4qApue for ; Sat, 13 Aug 2016 05:06:16 -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 BEB6A12D5B9 for ; Sat, 13 Aug 2016 05:06:15 -0700 (PDT) X-ASG-Debug-ID: 1471089971-05f27567b11c12b10001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id RlaOh0fgDeqbAJ8n (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Sat, 13 Aug 2016 14:06:11 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from simons-mbp.fritz.box ([151.53.117.101]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u7DC6912032022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Aug 2016 14:06:10 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_141B436A-3679-43E3-A026-77A6F13878C4" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] Finishing up Security Considerations for protocol In-Reply-To: <174cc59a-2d87-31a1-6d4d-61f38c712325@nteczone.com> Date: Sat, 13 Aug 2016 14:06:09 +0200 Message-Id: <5692AD65-3465-4BEB-BC1F-73BC9DD9E237@unina.it> 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) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1471089971 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 151.53.117.101 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.31981 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: Cc: clue@ietf.org Subject: Re: [clue] 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: Sat, 13 Aug 2016 12:06:18 -0000 --Apple-Mail=_141B436A-3679-43E3-A026-77A6F13878C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Christian, please see answers in-line. > On 18 May 2016, at 02:50, 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=E2=80=9D. [spromano] Thanks a lot! > 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). [spromano] Done. > 2nd paragraph 1st sentence reword: "The CLUE protocol is an = application-level protocol allowing a Media Producer and a Media = Consumer =E2=80=A6" [spromano] Done. > 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. [spromano] Done. > 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. [spromano] Paragraph removed as per the related mailing list discussion. Cheers, 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=_141B436A-3679-43E3-A026-77A6F13878C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello Christian,

please see answers in-line.


On 18 May 2016, at 02:50, Christian Groves <Christian.Groves@nteczone.com> wrote:

Hello = Simon and Paul,

In general the text looks = OK to me. I've proposed some editorial updates below mainly to remove = things like "we=E2=80=9D.

[spromano] Thanks a lot!

1st Paragraph replace sentence starting with "Among such = requirements..." with

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

[spromano] Done.

2nd paragraph = 1st sentence reword: "The CLUE protocol is an application-level protocol = allowing a Media Producer and a Media Consumer =E2=80=A6"

[spromano] = Done.

4th paragraph proposed reword:

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.

[spromano] Done.


5th paragraph proposed reword:

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.

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 <people> in a conference.

[spromano] = Paragraph removed as per the related mailing list = discussion.


Cheers,

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=_141B436A-3679-43E3-A026-77A6F13878C4-- From nobody Sat Aug 13 05:07: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 9597812D0C7; Sat, 13 Aug 2016 05:07:40 -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.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147109006060.15052.2923637511144053272.idtracker@ietfa.amsl.com> Date: Sat, 13 Aug 2016 05:07:40 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-protocol-09.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 12:07:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : CLUE protocol Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-protocol-09.txt Pages : 56 Date : 2016-08-13 Abstract: The CLUE protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE working group. A companion document delves into CLUE signaling details, as well as on the SIP/ SDP session establishment phase. CLUE messages flow upon the CLUE data channel, based on reliable and ordered SCTP over DTLS transport. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-protocol-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Aug 13 05:09:21 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 B061712D1BD for ; Sat, 13 Aug 2016 05:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247, 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 7VlfYJO1khSU for ; Sat, 13 Aug 2016 05:09:17 -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 463BE12D0C7 for ; Sat, 13 Aug 2016 05:09:17 -0700 (PDT) X-ASG-Debug-ID: 1471090154-05f27567941c138c0001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id ygsbNCcwgXSGFDSG (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Sat, 13 Aug 2016 14:09:14 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from simons-mbp.fritz.box ([151.53.117.101]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u7DC9Dg1032165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Aug 2016 14:09:13 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_FE7B166E-F36C-4285-868D-82DBFF41DD14" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] Finishing up Security Considerations for protocol In-Reply-To: Date: Sat, 13 Aug 2016 14:09:13 +0200 Message-Id: <65077319-3CF8-46A6-97BE-3C80685B84B0@unina.it> References: <571673E9.4050005@alum.mit.edu> <94A3329C-F25B-439E-B6D2-CF6C98D9A3A6@unina.it> <79B5EFE2-761E-4351-AD73-88A200C0F6E9@unina.it> To: Paul Kyzivat X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1471090154 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 151.53.117.101 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.31981 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: Cc: clue@ietf.org Subject: Re: [clue] 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: Sat, 13 Aug 2016 12:09:19 -0000 --Apple-Mail=_FE7B166E-F36C-4285-868D-82DBFF41DD14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Done! 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~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ > On 29 Jul 2016, at 20:32, Paul Kyzivat wrote: >=20 > Simon, >=20 > Can we get this done now? I believe Alissa is simply waiting for the = remaining few changes we already discussed. Then we can wrap this up. >=20 > Thanks, > Paul >=20 > On 5/13/16 12:20 PM, Paul Kyzivat wrote: >> On 5/13/16 12:12 PM, Simon Pietro Romano wrote: >>>> 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 >>> You=E2=80=99re right. This actually comes from far away in the past! = It digs >>> its roots in the disucssions we had at the time of the XCON WG and = is >>> in fact something that I added to the CCMP document, too. >>> I personally bend towards role-based access control when it comes to >>> policy-based managament and I thought this might be a useful piece = of >>> information for an interested reader. Though, I agree with >>> you that we never discussed this within CLUE (which is btw clearly >>> stated in the document). If you deem it useless, we can just remove >>> that paragraph. >>=20 >> Lets wait and see what others (including Alissa) think. >>=20 >> Thanks, >> Paul >>=20 >>> Thanks, >>>=20 >>> Simon >>>=20 >>>>=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 >>>>=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 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >=20 >=20 --Apple-Mail=_FE7B166E-F36C-4285-868D-82DBFF41DD14 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Done!

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~~~~~~~~~~~~~~~~~~~~~~~~~
=               =    \ (            (   = )
=               =                   =   \_)          ) /
                =                     =                     =               =  (_/



On 29 Jul 2016, at 20:32, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Simon,

Can we get this done now? = I believe Alissa is simply waiting for the remaining few changes we = already discussed. Then we can wrap this up.

= Thanks,
Paul

On 5/13/16 12:20 PM, Paul Kyzivat wrote:
On 5/13/16 12:12 PM, = Simon Pietro Romano wrote:
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.

You=E2=80=99re right. This actually comes from far away in = the past! It digs
its roots in the disucssions we had at = the time of the XCON WG and is
in fact something that I = added to the CCMP document, too.
I personally bend towards = role-based access control when it comes to
policy-based = managament and I thought this might be a useful piece of
information for an interested reader. Though, I agree with
you that we never discussed this within CLUE (which is btw = clearly
stated in the document). If you deem it useless, = we can just remove
that paragraph.

Lets wait and see what others = (including Alissa) think.

=    Thanks,
   Paul

Thanks,

Simon


   Thanks,
   Paul

Thank you once again for = your input and comments,

Simon

***************************************** = 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.

 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.

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

 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.

 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.

 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 = <people> element in the CLUE
 object. =  The <people> element is comprised of <person> = elements
 representing a specific user in the = telepresence system.  Each
 <person> = element contains a 'personID' attribute acting as a unique
=  identifier and a <personType> 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.

***************************************** END OF SECURITY
CONSIDERATIONS
SECTION = **********************************************





On 19/apr/2016, at = 20:07, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzivat@alum.mit.edu>> wrote:

The protocol needs to have a Security = Considerations section before it
can progress. That is the = main gating item at this point.

This should = be pretty simple. The following are my thoughts about what
should be in it:

- it should = reference the security considerations in the framework.
They= cover many important issues and those probably don't need to be
restated as long as they are referenced.

- it should reference the security considerations in the data = model.
That document has most of the critical data to be = concerned with.

- a reference to the = security considerations in the clue-datachannel
draft will = cover the protection of the content of the protocol
messages.

- There probably = should be a brief discussion of the extra data in the
protocol (not in the data model) that exposes information = that might
be of concern. I think this is primarily in the = options negotiation:
exposing all the versions and options = supported could conceivably leak
a bit of info about the = specific software. In theory an implementation
could = choose not to announce all the versions it supports if it wants
to avoid such leakage, though it would reduce = interoperability. And of
course it will only be relevant = when there are multiple versions and
options.

Thanks,
Paul

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


=             &n= bsp;           &nbs= p; _\\|//_
=             &n= bsp;           &nbs= p;      ( O-O )
=  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
=             &n= bsp;     Simon Pietro Romano
=             Un= iversita' 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
<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;       (_/









=             &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;       (_/



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



= --Apple-Mail=_FE7B166E-F36C-4285-868D-82DBFF41DD14-- From nobody Sat Aug 13 05:48:41 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 B77E712B069; Sat, 13 Aug 2016 05:48:36 -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.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147109251674.15048.16408337985362563751.idtracker@ietfa.amsl.com> Date: Sat, 13 Aug 2016 05:48:36 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-data-model-schema-17.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: Sat, 13 Aug 2016 12:48:37 -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-17.txt Pages : 77 Date : 2016-08-13 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-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 15 08:25:59 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 CC14A12D6B9; Mon, 15 Aug 2016 08:25:57 -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.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147127475781.31551.8380216516681738253.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2016 08:25:57 -0700 Archived-At: Cc: clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-data-model-schema@ietf.org Subject: [clue] Alexey Melnikov's No Objection on draft-ietf-clue-data-model-schema-17: (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: Mon, 15 Aug 2016 15:25:58 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-clue-data-model-schema-17: 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 DISCUSS. From nobody Mon Aug 15 09:08:06 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 5E1E812D0E0; Mon, 15 Aug 2016 09:08:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147127728536.31551.14815246426072950511.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2016 09:08:05 -0700 Archived-At: Cc: clue@ietf.org, The IESG , clue-chairs@ietf.org, draft-ietf-clue-data-model-schema@ietf.org, rfc-editor@rfc-editor.org Subject: [clue] Protocol Action: 'An XML Schema for the CLUE data model' to Proposed Standard (draft-ietf-clue-data-model-schema-17.txt) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 16:08:05 -0000 The IESG has approved the following document: - 'An XML Schema for the CLUE data model' (draft-ietf-clue-data-model-schema-17.txt) as Proposed Standard This document is the product of the ControLling mUltiple streams for tElepresence Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ Technical Summary: This document provides an XML schema file for the definition of CLUE data model types defined in the CLUE framework document. Working Group Summary: The document was discussed in the meeting, in conferences calls and on the mailing list. The open issues were addressed and there are no open issues, there was consensus on the content of the document. Document Quality: There is an existing implementation of the data model. Personnel: Roni Even is the Document Shepherd. The responsible AD is Alissa Cooper. From nobody Fri Aug 19 11:54:05 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 722A212D8D4 for ; Fri, 19 Aug 2016 11:53:59 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 6wCWRVi0fEBk for ; Fri, 19 Aug 2016 11:53:58 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D481B12D978 for ; Fri, 19 Aug 2016 11:53:57 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-03v.sys.comcast.net with SMTP id aov4bdwZE8GkCaovVbXVEs; Fri, 19 Aug 2016 18:53:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-11v.sys.comcast.net with SMTP id aovTbvMEPm7dBaovUbU3EL; Fri, 19 Aug 2016 18:53:57 +0000 References: <147109006060.15052.2923637511144053272.idtracker@ietfa.amsl.com> To: Simon Pietro Romano , Roberta Presta From: Paul Kyzivat Message-ID: Date: Fri, 19 Aug 2016 14:53:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <147109006060.15052.2923637511144053272.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfHn3oCK4wlI+MBgFHU4pzZNwze7/H9TahnuMIV1mhVuaCYmiQ7tHtuwFx17iR6hLUOTD4VGCJxl9NFSwAxknEPERJWHL0YRQPPqSvqz66vtbjBTIWNBY jOl6C1P4rzO3OycYgBAlpXM7FmdwxDlyKR4xJl1hbItv1NlbU2GcCEDuVMey5hhoejxZjsFt3/wglsY95I56MWT1iTiqbAsUW30U7VB6ep3ra+gFskZblaN+ Mj/0xX/KQ52F5ZMl7jhm6w== Archived-At: Cc: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-09.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, 19 Aug 2016 18:54:00 -0000 I'm just doing a final check as part of my shepherd writeup. I have a couple of loose ends to clear up: In section 5 there is a mention of response code 401. But because of renumbering of response codes that should now be 402. In section 9 (Schema) the version is set to 0.7. Is it intended that it be published with that value? Or is the intent to set the version to 1.0 for publication? If so, it needs to happen soon, and AUTH48 is probably too late. Thanks, Paul On 8/13/16 8:07 AM, 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 : CLUE protocol > Authors : Roberta Presta > Simon Pietro Romano > Filename : draft-ietf-clue-protocol-09.txt > Pages : 56 > Date : 2016-08-13 > > Abstract: > The CLUE protocol is an application protocol conceived for the > description and negotiation of a telepresence session. The design of > the CLUE protocol takes into account the requirements and the > framework defined within the IETF CLUE working group. A companion > document delves into CLUE signaling details, as well as on the SIP/ > SDP session establishment phase. CLUE messages flow upon the CLUE > data channel, based on reliable and ordered SCTP over DTLS transport. > Message details, together with the behavior of CLUE Participants > acting as Media Providers and/or Media Consumers, are herein > discussed. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-clue-protocol-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Fri Aug 19 13:12: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 3500F12DB7A for ; Fri, 19 Aug 2016 13:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.914 X-Spam-Level: X-Spam-Status: No, score=-0.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 W2OC2qrpRDTi for ; Fri, 19 Aug 2016 13:12:26 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2812A12DCB7 for ; Fri, 19 Aug 2016 13:04:54 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-12v.sys.comcast.net with SMTP id aq1abcR6NxBKTaq29b6D1I; Fri, 19 Aug 2016 20:04:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-11v.sys.comcast.net with SMTP id aq28bvdVrm7dBaq29bUCEe; Fri, 19 Aug 2016 20:04:53 +0000 References: <147127728544.31551.11750651334993223688.idtracker@ietfa.amsl.com> Cc: CLUE From: Paul Kyzivat Message-ID: <351b1a4a-d0dc-fd1a-e90b-d68b9f7e0efb@alum.mit.edu> Date: Fri, 19 Aug 2016 16:04:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNfFvetb6CrD4KE2ecJRUbNhXVZ/UAmAhqfu4YeCX3j8FM+PBcwHVvuILJmzxPRhTsYNbwaEUFByGDC+ENMS6Hce9Yk1kAHSFCyGa9wBhuEDY6YxkHH/ ckW7LTqRuxTQwk51uo+NlhetjTNt8rLV2CgGb9QjD3TwIA/69MW50xQ419dEHiaaRL+tRNsFl6tWOw== Archived-At: Subject: [clue] where to put clue iana registries? 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, 19 Aug 2016 20:12:27 -0000 Re the request below: ISTM that we ought to have a new url for clue registries. I don't think they fit well with anything else. For consistency, it probably ought to be called: "ControLling mUltiple streams for tElepresence (CLUE) Parameters" Any other thoughts? Thanks, Paul On 8/19/16 3:40 PM, Amanda Baber via RT wrote: > Dear Authors/Chairs/AD, > > Since IANA last reviewed this document, it has been updated to ask us to create four registries. > > Where should these registries be created? Should they be created at an existing URL, or a new one? You can find a list of existing registries at > > http://www.iana.org/protocols > > If we should create these registries at a new URL, what should be the name of the registry grouping? For example, at http://www.iana.org/assignments/dns-parameters, that name is "Domain Name System (DNS) Parameters." > > A quick note: there are references in the IANA Considerations section to IANA updating the document, but IANA only edits registries. In the future, notes about editing the document should be addressed to the RFC Editor. > > Thanks, > > Amanda Baber > IANA Lead Specialist > ICANN > From nobody Fri Aug 19 13:18: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 8273A12D5AF for ; Fri, 19 Aug 2016 13:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247, 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 pD7HY73nQ0TM for ; Fri, 19 Aug 2016 13:18:04 -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 55D23127058 for ; Fri, 19 Aug 2016 13:17:49 -0700 (PDT) X-ASG-Debug-ID: 1471637866-05ce377868d49cc0001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id pUiSlMFGyPnphXen (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Fri, 19 Aug 2016 22:17:46 +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.53.112.232]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id u7JKHjA8001026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Aug 2016 22:17:45 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <351b1a4a-d0dc-fd1a-e90b-d68b9f7e0efb@alum.mit.edu> References: <147127728544.31551.11750651334993223688.idtracker@ietfa.amsl.com> <351b1a4a-d0dc-fd1a-e90b-d68b9f7e0efb@alum.mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----YSIKUJ5E32YSVALL2ITRF8XI2JQ3OA" Content-Transfer-Encoding: 8bit From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] where to put clue iana registries? Date: Fri, 19 Aug 2016 22:17:53 +0200 To: Paul Kyzivat Message-ID: <4FBD667E-1D35-40B8-AE53-E0CDF6C29B28@unina.it> X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1471637866 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.53.112.232 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.32157 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] where to put clue iana registries? 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, 19 Aug 2016 20:18:06 -0000 ------YSIKUJ5E32YSVALL2ITRF8XI2JQ3OA Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hello Paul, I agree on the new URL, as well as on the name of the registry. Simon Il 19 Agosto 2016 22:04:51 CEST, Paul Kyzivat ha scritto: >Re the request below: > >ISTM that we ought to have a new url for clue registries. I don't think > >they fit well with anything else. For consistency, it probably ought to > >be called: > >"ControLling mUltiple streams for tElepresence (CLUE) Parameters" > >Any other thoughts? > > Thanks, > Paul > >On 8/19/16 3:40 PM, Amanda Baber via RT wrote: >> Dear Authors/Chairs/AD, >> >> Since IANA last reviewed this document, it has been updated to ask us >to create four registries. >> >> Where should these registries be created? Should they be created at >an existing URL, or a new one? You can find a list of existing >registries at >> >> http://www.iana.org/protocols >> >> If we should create these registries at a new URL, what should be the >name of the registry grouping? For example, at >http://www.iana.org/assignments/dns-parameters, that name is "Domain >Name System (DNS) Parameters." >> >> A quick note: there are references in the IANA Considerations section >to IANA updating the document, but IANA only edits registries. In the >future, notes about editing the document should be addressed to the RFC >Editor. >> >> Thanks, >> >> Amanda Baber >> IANA Lead Specialist >> ICANN >> > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue ------YSIKUJ5E32YSVALL2ITRF8XI2JQ3OA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello Paul,

I agree on the new URL, as well as on the name of the registry.

Simon

Il 19 Agosto 2016 22:04:51 CEST, Paul Kyzivat <pkyzivat@alum.mit.edu> ha scritto:
Re the request below:

ISTM that we ought to have a new url for clue registries. I don't think 
they fit well with anything else. For consistency, it probably ought to 
be called:

"ControLling mUltiple streams for tElepresence (CLUE) Parameters"

Any other thoughts?

	Thanks,
	Paul

On 8/19/16 3:40 PM, Amanda Baber via RT wrote:
 Dear Authors/Chairs/AD,

 Since IANA last reviewed this document, it has been updated to ask us to create four registries.

 Where should these registries be created? Should they be created at an existing URL, or a new one? You can find a list of existing registries at

 http://www.iana.org/protocols

 If we should create these registries at a new URL, what shoul
 d be
the name of the registry grouping? For example, at http://www.iana.org/assignments/dns-parameters, that name is "Domain Name System (DNS) Parameters."

 A quick note: there are references in the IANA Considerations section to IANA updating the document, but IANA only edits registries. In the future, notes about editing the document should be addressed to the RFC Editor.

 Thanks,

 Amanda Baber
 IANA Lead Specialist
 ICANN



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

------YSIKUJ5E32YSVALL2ITRF8XI2JQ3OA-- From nobody Mon Aug 22 08:33:41 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA11E12D0C0 for ; Mon, 22 Aug 2016 08:33:39 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 XUv8H9hrHUMh for ; Mon, 22 Aug 2016 08:33:38 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 F3F9212B037 for ; Mon, 22 Aug 2016 08:33:37 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-11v.sys.comcast.net with SMTP id brDybwwHMlSxsbrEHbEtEY; Mon, 22 Aug 2016 15:33:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with SMTP id brEFbiWhTvsB5brEGbsqlj; Mon, 22 Aug 2016 15:33:37 +0000 To: Simon Pietro Romano References: <147127728544.31551.11750651334993223688.idtracker@ietfa.amsl.com> <351b1a4a-d0dc-fd1a-e90b-d68b9f7e0efb@alum.mit.edu> <4FBD667E-1D35-40B8-AE53-E0CDF6C29B28@unina.it> From: Paul Kyzivat Message-ID: Date: Mon, 22 Aug 2016 11:33:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <4FBD667E-1D35-40B8-AE53-E0CDF6C29B28@unina.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKh6+JSRMyqOVG/jVNc5HHoY3tZQS5j7z5t9ufMEhE65Z8agGrZ7nhSGI4kFOiSaBK/xEQnOrcBtieYfRGG4bezajTlHESB/posQ7LFvRBvwfJaCLPI9 gmN7vRbmgLu401V1lCwMlg2Yrpwp7QLUkf6Sz8Ald/iyjMXD8Kz626pfmUDiDQbh6bN27vXUKfpqNM3tH7mCDZBTUJ8ICSC63hI= Archived-At: Cc: CLUE Subject: Re: [clue] where to put clue iana registries? 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, 22 Aug 2016 15:33:40 -0000 Simon, On 8/19/16 4:17 PM, Simon Pietro Romano wrote: > Hello Paul, > > I agree on the new URL, as well as on the name of the registry. Note that I omitted IANA from this exchange because I didn't want to preempt you authors on this. Will you please inform IANA? Thanks, Paul > Simon > > Il 19 Agosto 2016 22:04:51 CEST, Paul Kyzivat ha > scritto: > > Re the request below: > > ISTM that we ought to have a new url for clue registries. I don't think > they fit well with anything else. For consistency, it probably ought to > be called: > > "ControLling mUltiple streams for tElepresence (CLUE) Parameters" > > Any other thoughts? > > Thanks, > Paul > > On 8/19/16 3:40 PM, Amanda Baber via RT wrote: > > Dear Authors/Chairs/AD, > > Since IANA last reviewed this document, it has been updated to > ask us to create four registries. > > Where should these registries be created? Should they be created > at an existing URL, or a new one? You can find a list of > existing registries at > > http://www.iana.org/protocols > > If we should create these registries at a new URL, what shoul d > be the name of the registry grouping? For example, at > http://www.iana.org/assignments/dns-parameters, that name is > "Domain Name System (DNS) Parameters." > > A quick note: there are references in the IANA Considerations > section to IANA updating the document, but IANA only edits > registries. In the future, notes about editing the document > should be addressed to the RFC Editor. > > Thanks, > > Amanda Baber > IANA Lead Specialist > ICANN > > > > ------------------------------------------------------------------------ > > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sat Aug 27 05:58: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 F0D2812B004; Sat, 27 Aug 2016 05:58: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.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147230268098.2155.6202995334293084354.idtracker@ietfa.amsl.com> Date: Sat, 27 Aug 2016 05:58:00 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-08.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 12:58:01 -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 : Mapping RTP streams to CLUE Media Captures Authors : Roni Even Jonathan Lennox Filename : draft-ietf-clue-rtp-mapping-08.txt Pages : 13 Date : 2016-08-27 Abstract: This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE Media Captures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Aug 27 07:56: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 9BC5612B01B for ; Sat, 27 Aug 2016 07:56:44 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 U1XHlUfxZvns for ; Sat, 27 Aug 2016 07:56:43 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 70D9012B005 for ; Sat, 27 Aug 2016 07:56:43 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-05v.sys.comcast.net with SMTP id df1MbvtqI2FGMdf2Ibzs12; Sat, 27 Aug 2016 14:56:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-14v.sys.comcast.net with SMTP id df2Hbe1a5WW8pdf2IbmopA; Sat, 27 Aug 2016 14:56:42 +0000 To: clue@ietf.org References: <147230268098.2155.6202995334293084354.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <9af2a971-4679-e6ba-935b-a4cb43aaa9b6@alum.mit.edu> Date: Sat, 27 Aug 2016 10:56:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <147230268098.2155.6202995334293084354.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfJy61AJiTX1y9T/TJ2/mSAjnh9CppjfLGf99EUvCC66AZywDb1gbvQLe8eSy8vtMlUoNz+lPZpP45d7yVKuasURwkemdZrAfVF4s36qpWbR9DeIxV3SF rt0WcaGnTdPC6rbgaql9pKF+5ILEMb4CLVpPEi4Cj7J4ToFFjEtfY1v+6lykvVdpKtK2GP+Gg6wDwA== Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-08.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: Sat, 27 Aug 2016 14:56:45 -0000 I'd appreciate an explanation for the changes in the new version. Looking at the diff, it appears that the draft has been gutted. I am guessing this reflects discussions held in Berlin. Thanks, Paul On 8/27/16 8:58 AM, 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 : Mapping RTP streams to CLUE Media Captures > Authors : Roni Even > Jonathan Lennox > Filename : draft-ietf-clue-rtp-mapping-08.txt > Pages : 13 > Date : 2016-08-27 > > Abstract: > This document describes how the Real Time transport Protocol (RTP) is > used in the context of the CLUE protocol. It also describes the > mechanisms and recommended practice for mapping RTP media streams > defined in SDP to CLUE Media Captures. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Aug 29 10:14: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 D889412D7A2 for ; Mon, 29 Aug 2016 10:14:44 -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=ptUgLOOu; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=c+Q2Angw 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 ttrztSNlGqa8 for ; Mon, 29 Aug 2016 10:14:43 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12AF12D79E for ; Mon, 29 Aug 2016 10:14:42 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8667120538; Mon, 29 Aug 2016 13:14:39 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 29 Aug 2016 13:14:39 -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=OIX8ODETUUlwhI5VD+g5dHbxL80=; b=ptUgLO Ouo38Op0L24AnZ2Rn6hJafGnKG/b9Zi2ypvPjpZnyVYoPohyU8xQF2hvWwHetni9 p9LyOZM/ox2gCF8W7yNnEj/M8GwzUjHNg/UB+Dywv1cEUtXJNF3uyFMXqYrWDAzr q7ThXTBONmGnWwDCtm+fEtDSfPgd3gwZlFG/g= 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=OIX8ODETUUlwhI5 VD+g5dHbxL80=; b=c+Q2AngwPq0U0mKdAXQzNkZZ2LzaDcx38H27WBZp2w9XcEm 12QYFiShPvPeHaYIrnMVUYnN4l/G0XDCGTfJeL9qjRBvqlhOcoE6X07YJ0fjn5sh wY9Gz7L1rMxaxFuqQT57Gio7XalRdKRE57Nc4u4ByhmBJwIrMJQYDYdMA7As= X-Sasl-enc: WN9aGMcw4xO1nxSBjc9sfGmOGrM6zYeWplejZGreeOHp 1472490879 Received: from sjc-alcoop-8816.cisco.com (unknown [128.107.241.174]) by mail.messagingengine.com (Postfix) with ESMTPA id D8BFBCCE83; Mon, 29 Aug 2016 13:14:38 -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: <9af2a971-4679-e6ba-935b-a4cb43aaa9b6@alum.mit.edu> Date: Mon, 29 Aug 2016 13:14:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147230268098.2155.6202995334293084354.idtracker@ietfa.amsl.com> <9af2a971-4679-e6ba-935b-a4cb43aaa9b6@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3124) Archived-At: Cc: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-08.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 17:14:45 -0000 > On Aug 27, 2016, at 10:56 AM, Paul Kyzivat = wrote: >=20 > I'd appreciate an explanation for the changes in the new version. = Looking at the diff, it appears that the draft has been gutted. I am = guessing this reflects discussions held in Berlin. I was not aware of any such discussions so would appreciate an = explanation as well. The pub req was based on the -07 and I had started = my AD review on the -07. Alissa >=20 > Thanks, > Paul >=20 > On 8/27/16 8:58 AM, internet-drafts@ietf.org wrote: >>=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 : Mapping RTP streams to CLUE Media Captures >> Authors : Roni Even >> Jonathan Lennox >> Filename : draft-ietf-clue-rtp-mapping-08.txt >> Pages : 13 >> Date : 2016-08-27 >>=20 >> Abstract: >> This document describes how the Real Time transport Protocol (RTP) = is >> used in the context of the CLUE protocol. It also describes the >> mechanisms and recommended practice for mapping RTP media streams >> defined in SDP to CLUE Media Captures. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-08 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-rtp-mapping-08 >>=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 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue