Re: [clue] Publishing CLUE protocol as Experimental?

"Roni Even (A)" <> Thu, 07 February 2019 05:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4301A130FD1 for <>; Wed, 6 Feb 2019 21:58:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iSHveAVtQtgC for <>; Wed, 6 Feb 2019 21:58:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C562F1288BD for <>; Wed, 6 Feb 2019 21:58:23 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTP id E8424FFFBCEF3F59FAB4 for <>; Thu, 7 Feb 2019 05:58:20 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 7 Feb 2019 05:58:20 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 7 Feb 2019 05:58:20 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Thu, 7 Feb 2019 05:58:20 +0000
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Thu, 7 Feb 2019 13:58:16 +0800
From: "Roni Even (A)" <>
To: Stephen Botzko <>, Simon Pietro Romano <>
CC: "" <>, "" <>, Adam Roach <>, Benjamin Kaduk <>
Thread-Topic: [clue] Publishing CLUE protocol as Experimental?
Thread-Index: AQHUmYJgBSIgPZbHfEWPW6VL16e0bKWKAvqAgAAvs4CASe5BsA==
Date: Thu, 7 Feb 2019 05:58:16 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD18CB305Bdggemm526mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [clue] Publishing CLUE protocol as Experimental?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Feb 2019 05:58:26 -0000

Hi Steve,
Is this a problem, I assume that the documents will be an appendix in the ITU-T document.
Roni Even

From: clue [] On Behalf Of Stephen Botzko
Sent: Saturday, December 22, 2018 2:58 PM
To: Simon Pietro Romano
Cc:;; Adam Roach; Benjamin Kaduk
Subject: Re: [clue] Publishing CLUE protocol as Experimental?

This will have an impact on on-going work in the ITU-T.  The ITU-T telepresence group chose to use CLUE directly instead of developing a competing protocol, and they have several drafts which have been waiting for the IETF publication for some years now.

They cannot make normative references to an experimental RFC.  They'd either need to abandon their work, or directly incorporate CLUE into their recommendations.


On Sat, Dec 22, 2018 at 5:07 AM Simon Pietro Romano <<>> wrote:
Hello everybody,

I’m perfectly fine with Benjamin’s and Ben’s proposal.



                               ( O-O )
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                      Computer Engineering Department
             Phone: +39 081 7683823 -- Fax: +39 081 7683816

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

Il giorno 22 dic 2018, alle ore 00:10, Adam Roach <<>> ha scritto:

CLUE working group and document authors:

During IESG evaluation, Benjamin and Ben raised some issues around the state machine design, timeouts, and interaction with the various SIP state machines. While these could probably be addressed by adding substantial new text and a handful of new states and supervisory timers to the CLUE state machines, as well as including additional detail about the interaction between such state machines and the SIP state machines, it's not clear to me that the CLUE working group has the kind of energy necessary for that kind of refinement at this point in its lifecycle.

An alternate path that both Ben and Benjamin would be okay with is publication of the protocol mechanism as Experimental rather than Standards Track, in order to allow the collection of operational experience around implementing and deploying the protocol with the state machines as specified. This would be sufficient to satisfy their concerns around the currently-defined state machine and would allow publication of the CLUE documents. (Note that, due to the relationship between clue-protocol, clue-signaling, and clue-datachannel, this would also result in the publication of clue-signaling and clue-datachannel as experimental.)

Recognizing that many people are out of the office during this time of year, I'd like to ask that anyone who has comments regarding the proposal to move the core CLUE documents to Experimental status respond before Friday, January 18th. Thanks.


clue mailing list<>