From nobody Tue Jan 8 10:11:28 2019 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5055130F53 for ; Tue, 8 Jan 2019 10:11:26 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ntlworld.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 nXejllf1Fu68 for ; Tue, 8 Jan 2019 10:11:22 -0800 (PST) Received: from know-smtprelay-omc-11.server.virginmedia.net (know-smtprelay-omc-11.server.virginmedia.net [80.0.253.75]) (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 F403A130F4C for ; Tue, 8 Jan 2019 10:11:21 -0800 (PST) Received: from [172.17.162.16] ([88.211.126.138]) by cmsmtp with ESMTPA id gvqQgq6TXhtC0gvqQgm3rT; Tue, 08 Jan 2019 18:11:19 +0000 X-Originating-IP: [88.211.126.138] X-Authenticated-User: drageke@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=KJXu82No c=1 sm=1 tr=0 a=A23Of5e5ItRGPqVSphLRgg==:117 a=A23Of5e5ItRGPqVSphLRgg==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=Z80JlwQ0AAAA:8 a=RE0BCZwv57cF0JTyLqQA:9 a=2L4LXxOSTqbRSQQ-:21 a=ReRbAGhEXVRunnHA:21 a=pILNOxqGKmIA:10 a=_ByUwbrgkbwA:10 a=UqCG9HQmAAAA:8 a=8A3WR-1y-Z9cxjvMvgUA:9 a=KY9mJnK47geuRd6T:21 a=AIrS2uBmSN2ipSZ9:21 a=jjFimIRGldHz89gg:21 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Zz-tw7mMPhxMdvFcggwQ:22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1546971079; bh=pPfx1hQlnyUpeDp2Yoow8hld8379qLT4gNLUOHI6ZA8=; h=Subject:To:References:From:Date:In-Reply-To; b=OufSzFimtj2So4cw6adYNmRnCR7N1miXogH3bAbLb/UdHbyrpv+lQ4Lp5vcIdwP3p 49Tlwz7ypBKbDPbQl8Eo7G5FiJ8gBNi1vQvfcM+AQZjsait01MdM7X2KxeHFNnLCKY YuVpiiRwTuUlAaoMpYn2DEczyZMiXySd534VH32Sz4vwZ7wE5PsrfWWoKhjDqculYd fXURBAdSVtMAyoZ9ZgDIWZGIWs7/wugdmgBELSyM11OdZcMr3b4jKWwbQNGeRVE3/x S6QJUL881CdEEwEzc2ZxZ4dXhIprEPmUYgsT27Vt1uzvqauyvHOqWuF5a3s5zphJip 95w8PjAReZbmg== To: clue@ietf.org References: <371a0f51-3919-8ae2-c782-e51ce4fc6e2f@nostrum.com> <62794BF0-F1A8-4F18-BCB4-110CCF2E9D57@unina.it> From: Keith Drage Message-ID: Date: Tue, 8 Jan 2019 18:11:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D09FFB5DA04227CADEC39338" Content-Language: en-US X-CMAE-Envelope: MS4wfBk/cRxWysd9OQgNQmmb3ZerM5mfKj3Y3UAFHGz73fAch7SuUUX6EmMl/hueIHySpcPgdafFD6N0vUXrbAQYx8zUkO7l+BCFYYH8/N2hu7BrrOBS0KA1 0Vf+1zKPAlwAyea00ThNslYVj88rSp0gZyYN0YGmP3f2yJF3Myamxjy9 Archived-At: Subject: Re: [clue] Publishing CLUE protocol as Experimental? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 18:11:27 -0000 This is a multi-part message in MIME format. --------------D09FFB5DA04227CADEC39338 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Unless the policy has changed recently, the only constraint on 3GPP is that the material that it references normatively has to be written in a fashion that can be understood with such intent, i.e. one can assess conformity, etc. In general, one would expect experimental document to be written in a fashion. To 3GPP therefore, it is irrelevant whether the IETF define the document as standards track or experimental; the 3GPP reference from a standard effectively makes it equivalent to standards track for those who use the 3GPP standard. Keith On 22-Dec-18 11:23 PM, Christer Holmberg wrote: > > > Hi, > > > I think the issue raised by Stephen also apply to 3GPP, but I will > double check that. > > > Regards, > > > Christer > > > > ------------------------------------------------------------------------ > *From:* clue on behalf of Stephen Botzko > > *Sent:* Saturday, December 22, 2018 2:57 PM > *To:* Simon Pietro Romano > *Cc:* draft-ietf-clue-protocol.all@tools.ietf.org; clue@ietf.org; 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. > > Stephen > > 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. > > 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 > >   <   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >                      oooO >        ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ 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. >> >> /a >> >> > > _______________________________________________ > 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 --------------D09FFB5DA04227CADEC39338 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Unless the policy has changed recently, the only constraint on 3GPP is that the material that it references normatively has to be written in a fashion that can be understood with such intent, i.e. one can assess conformity, etc. In general, one would expect experimental document to be written in a fashion.

To 3GPP therefore, it is irrelevant whether the IETF define the document as standards track or experimental; the 3GPP reference from a standard effectively makes it equivalent to standards track for those who use the 3GPP standard.

Keith

On 22-Dec-18 11:23 PM, Christer Holmberg wrote:


Hi,


I think the issue raised by Stephen also apply to 3GPP, but I will double check that.


Regards,


Christer



From: clue <clue-bounces@ietf.org> on behalf of Stephen Botzko <stephen.botzko@gmail.com>
Sent: Saturday, December 22, 2018 2:57 PM
To: Simon Pietro Romano
Cc: draft-ietf-clue-protocol.all@tools.ietf.org; clue@ietf.org; 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.

Stephen

On Sat, Dec 22, 2018 at 5:07 AM Simon Pietro Romano <spromano@unina.it> wrote:
Hello everybody,

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

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 è l'alibi degli 
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                                     oooO
       ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                 \ (            (   )
                                  \_)          ) /
                                                                       (_/



Il giorno 22 dic 2018, alle ore 00:10, Adam Roach <adam@nostrum.com> 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.

/a



_______________________________________________
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


--------------D09FFB5DA04227CADEC39338-- From nobody Tue Jan 8 12:40:08 2019 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEF113113C for ; Tue, 8 Jan 2019 12:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.364 X-Spam-Level: X-Spam-Status: No, score=-4.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=bAEpN4IP; dkim=pass (1024-bit key) header.d=ericsson.com header.b=gKkbUqYq 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 g5v0r5H4PV6Q for ; Tue, 8 Jan 2019 12:40:03 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 0505B1310E6 for ; Tue, 8 Jan 2019 12:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1546980001; x=1549572001; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9NGK9tDd4Ian+dQSl5Tq3O3pJvLxvfUtoNXBQcJxmB8=; b=bAEpN4IP+0wgA965sUkuohTwkrjVBI7o212u+1nLv/R+r1CiLmaUzgc9rkPFRfSa mfZLM5qTsWkSrI5Ao2YwlAxv1pIwlpy+uSdiXw7elCbiEpA7oANGCggmO4t3ZkV/ K4qCelKe9ZlIbfuvXmZ9VG+F6PjOhWBdcve6pEBt00o=; X-AuditID: c1b4fb2d-2198b9e00000062f-3f-5c350aa06de2 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 48.41.01583.0AA053C5; Tue, 8 Jan 2019 21:40:00 +0100 (CET) Received: from ESESSMR506.ericsson.se (153.88.183.128) by ESESSMB504.ericsson.se (153.88.183.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 8 Jan 2019 21:39:53 +0100 Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMR506.ericsson.se (153.88.183.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 8 Jan 2019 21:39:53 +0100 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 8 Jan 2019 21:39:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9NGK9tDd4Ian+dQSl5Tq3O3pJvLxvfUtoNXBQcJxmB8=; b=gKkbUqYq6U4PBTwCn6Yba8hoJzAkbNreOH4nXk4rswdwsPPbuiLvfunmcWhZJJ1VwNX2uYGCnuMSbS8GrdEKvVcwFfMf5M4xo9TG1wUIT/Lc3YqD2Gbrot7tEx5NUJ4dOGRXHSSqf8dy4KncXLYAHShkow9jzbUA7xLYJwSzCjw= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3451.eurprd07.prod.outlook.com (10.170.247.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.7; Tue, 8 Jan 2019 20:39:52 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::852a:3f04:e342:cf55]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::852a:3f04:e342:cf55%3]) with mapi id 15.20.1516.010; Tue, 8 Jan 2019 20:39:52 +0000 From: Christer Holmberg To: Keith Drage , "clue@ietf.org" Thread-Topic: [clue] Publishing CLUE protocol as Experimental? Thread-Index: AQHUmYJwgWvvRTsAfE+GXqp5IciF/qWKiRaAgAAvtICAAK6MMYAaYMYAgAApaTY= Date: Tue, 8 Jan 2019 20:39:51 +0000 Message-ID: References: <371a0f51-3919-8ae2-c782-e51ce4fc6e2f@nostrum.com> <62794BF0-F1A8-4F18-BCB4-110CCF2E9D57@unina.it> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [37.33.31.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3451; 6:YOTSPAouEOSLbceKFopRB4VwY64xyEM7y4TY2ZuOXfyoCcUeAa5fAjLKi8uxYQvzERs5AB/c6IKP2TuHaEVo0c7Lo+m/pdg4+tDemtCXB/CCDDCTu8dpGGZU79FTFf43N7tooPlI2VYFnhUh5dnX9drR+D0pAhmBADlOSnvxe8ozUwuPEjgW1SfI4btxe8YU+XaRQq6elft2EERs7cR+S2ZkZDae72lXRr+5YS/JM7ZlhckgVKTO1lyb+Hxo3wd0Mm8+w89V98Rxeiii1wxk0k63KOxjEghddoG0RClL4MCEhXp+lDkBrl32qWub5xyKK6IxeM1Qmj9Ou0rgY5pb/uQXRh+EfWsI48JMXshrriqEnAJSXFfKI4NXY2tsXK9vSEXztRMvCDpZj/tnlHPl01BYV2E/JMXVylktjpSEZNhAEbKEK+6YXvMrpc2cP34gx7I6ruJxPMNzKJke67mXzQ==; 5:SEnB+YP3pMgG32V/YHtTXQH9+uWXnUgQ0xWml5pYnXzR9nLwwsTndNp9Ky5qlIJUripLVdRv7eGSDtlesoPpoAw8UHz/0zGIN5n85FmGMMa9MpdPNUZOZE8xbwggSckeDfdw7a0JpCWvV/+kDbE6Yh/W7zjIaWe0z9AA31xoIxgELRa0TvBQ+cX4+dh97rpXhX9S8wWYgNEX/HaAmXAeeQ==; 7:GB4Jltcl8B30aMGzttYlZnn9gsSXe1A6E0f2EqCggyzSIfjmiZc8mPzqZWnXV1TbMwJKu7Dlz8p9BNnQUObq37YZcJvsE+e9f+E7Ra5AM4wulGDxje6uXdfIce6K3LmkE6SRqOVdXDd7C2dvq1efHQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fabf0ce5-91d6-4aef-fedd-08d675a970dc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3451; x-ms-traffictypediagnostic: HE1PR07MB3451: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(3002001)(93006095)(93001095)(3231475)(944501520)(52105112)(10201501046)(6041310)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB3451; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3451; x-forefront-prvs: 0911D5CE78 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(136003)(366004)(376002)(396003)(53754006)(199004)(189003)(74316002)(44832011)(2906002)(7696005)(14454004)(6606003)(486006)(446003)(97736004)(11346002)(561944003)(6116002)(8676002)(229853002)(81166006)(81156014)(8936002)(86362001)(110136005)(476003)(3846002)(53936002)(6246003)(71190400001)(71200400001)(5070765005)(66066001)(106356001)(99286004)(33656002)(14444005)(256004)(6306002)(1015004)(25786009)(7736002)(102836004)(54896002)(55016002)(68736007)(236005)(9686003)(606006)(53546011)(6506007)(186003)(26005)(105586002)(478600001)(316002)(76176011)(6436002)(2501003)(93886005)(19627405001)(5660300001)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3451; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: klXzrrO5DwW5mtS6b9Uiw60wnctwBRL33m0r9kt3mKVbSsn1BrMN4dfvhcNQ9GswP9MwRWfNgxBagt0grxYaF5UdytSYQlQEWBEq9CqHWuCuJ549WHIY157qW7KbrYFYea8b91rtIo6l3ecsK3Y3eFwdAVcpIbC0J6/QTYVYMlP2rZsK5d7K3WZ1afiWCRlSKGFfwKd6dq3hvbVZStyfA0cG2FQepXjFw4uMHjH9dc5+jwmBGeEeQkpXD0rXV5RJOHmjogxFXAoTwl/ZtV/2ZFj1QHfeh1vEQ4KeQvpa3iP0NO/HUoN+erJ1JBuh5niQ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB31613453A5F73FB1F07B8C7A938A0HE1PR07MB3161eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fabf0ce5-91d6-4aef-fedd-08d675a970dc X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2019 20:39:52.0996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3451 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUyM2J7le5CLtMYgzOiFvtPXWa2eNh/ncWB yePEsiusHkuW/GQKYIrisklJzcksSy3St0vgyvj++CFzwYEexornHRuYGhhPlHcxcnJICJhI tH1cydzFyMUhJHCEUWLq4n4o5yujxKLJt1ngnD8bnrNDOIuZJH6+PwuWYRGYwCxxfMlTqJ5J TBJTl21ihXAeMkp82PeQsYuRg4NNwEKi+582iCkiECWxo5cFZLmwgK3Ez5mnmEBsEQE7iRv3 HkPZfhIPjrWwgtgsAioSa6dMYQSxeQViJE6t3g1mCwnsY5L48CYRxOYUcJC4/v4M2ExGATGJ 76fWgM1hFhCXuPVkPhPEowISS/acZ4awRSVePv7HClGfKLF/1QOouILElIaTbBC2rMSl+d2M IK9ICDSxS0zefZoRIqEr8WHqVKgGX4mpc3eyQRRdYJSYfWUC2L8SAloSx7dmQdRkS9zceocd ouYis8TGlQehBslIXHp0gXECo/4sJMdC2PkSx7+cZZkF9rSgxMmZT1gg4gYS78/NZ4awtSWW LXwNZetLbPxylhFZfAEj+ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwBR0cMtv3R2Mq187 HmIU4GBU4uHN/2cSI8SaWFZcmXuIUYKDWUmEV/0OUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjv HyHBGCGB9MSS1OzU1ILUIpgsEwenVAOjdqmxpW+EW+d7znDvdQW+3IaCTvf2uOxSTOB9sn5z 42yPtcuMt/1OVu1+7LaH8foB6WnhV7wlpzpNcd0d+H/lN0H/DUIROrkquVU712e6lKWe7/7W mu92LI/XZnpjaJOnc1Wn5Y84m40aDmrenbtVqx/MPCbHUKTl+ay4un3JWr7uxtarL5RYijMS DbWYi4oTAQ5otqE9AwAA Archived-At: Subject: Re: [clue] Publishing CLUE protocol as Experimental? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 20:40:06 -0000 --_000_HE1PR07MB31613453A5F73FB1F07B8C7A938A0HE1PR07MB3161eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Gotha. Thanks, Keith! Regards, Christer ________________________________ From: clue on behalf of Keith Drage Sent: Tuesday, January 8, 2019 8:11 PM To: clue@ietf.org Subject: Re: [clue] Publishing CLUE protocol as Experimental? Unless the policy has changed recently, the only constraint on 3GPP is that= the material that it references normatively has to be written in a fashion= that can be understood with such intent, i.e. one can assess conformity, e= tc. In general, one would expect experimental document to be written in a f= ashion. To 3GPP therefore, it is irrelevant whether the IETF define the document as= standards track or experimental; the 3GPP reference from a standard effect= ively makes it equivalent to standards track for those who use the 3GPP sta= ndard. Keith On 22-Dec-18 11:23 PM, Christer Holmberg wrote: Hi, I think the issue raised by Stephen also apply to 3GPP, but I will double c= heck that. Regards, Christer ________________________________ From: clue on behalf = of Stephen Botzko Sent: Saturday, December 22, 2018 2:57 PM To: Simon Pietro Romano Cc: draft-ietf-clue-protocol.all@tools.ietf.org; clue@ietf.org; 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 telepres= ence group chose to use CLUE directly instead of developing a competing pro= tocol, and they have several drafts which have been waiting for the IETF pu= blication for some years now. They cannot make normative references to an experimental RFC. They'd eithe= r need to abandon their work, or directly incorporate CLUE into their recom= mendations. Stephen On Sat, Dec 22, 2018 at 5:07 AM Simon Pietro Romano > wrote: Hello everybody, I=92m perfectly fine with Benjamin=92s and Ben=92s proposal. 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 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ 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 stat= e machine design, timeouts, and interaction with the various SIP state mach= ines. While these could probably be addressed by adding substantial new tex= t and a handful of new states and supervisory timers to the CLUE state mach= ines, 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 t= he CLUE working group has the kind of energy necessary for that kind of ref= inement at this point in its lifecycle. An alternate path that both Ben and Benjamin would be okay with is publicat= ion of the protocol mechanism as Experimental rather than Standards Track, = in order to allow the collection of operational experience around implement= ing and deploying the protocol with the state machines as specified. This w= ould be sufficient to satisfy their concerns around the currently-defined s= tate machine and would allow publication of the CLUE documents. (Note that,= due to the relationship between clue-protocol, clue-signaling, and clue-da= tachannel, 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 mo= ve the core CLUE documents to Experimental status respond before Friday, Ja= nuary 18th. Thanks. /a _______________________________________________ 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 --_000_HE1PR07MB31613453A5F73FB1F07B8C7A938A0HE1PR07MB3161eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Gotha. Thanks, Keith!


Regards,


Christer



From: clue <clue-bounces= @ietf.org> on behalf of Keith Drage <drageke=3D40ntlworld.com@dmarc.i= etf.org>
Sent: Tuesday, January 8, 2019 8:11 PM
To: clue@ietf.org
Subject: Re: [clue] Publishing CLUE protocol as Experimental?
 
Unless the policy has changed recently, th= e only constraint on 3GPP is that the material that it references normative= ly has to be written in a fashion that can be understood with such intent, = i.e. one can assess conformity, etc. In general, one would expect experimental document to be written in a fash= ion.

To 3GPP therefore, it is irrelevant whethe= r the IETF define the document as standards track or experimental; the 3GPP= reference from a standard effectively makes it equivalent to standards tra= ck for those who use the 3GPP standard.

Keith

On 22-Dec-18 11:23 PM, Christer Holmberg w= rote:


Hi,


I think the issue raised by Step= hen also apply to 3GPP, but I will double check that.


Regards,


Christer



From: clue <clue-bounces@ietf.org> on behalf of Stephen Botzko <stephen.botzko@gmail.com>
Sent: Saturday, December 22, 2018 2:57 PM
To: Simon Pietro Romano
Cc: draft-ietf-clue-protocol.all@tools.ietf.org; clue@ietf.org; 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.&nb= sp; The ITU-T telepresence group chose to use CLUE directly instead of deve= loping a competing protocol, and they have several drafts which have been w= aiting for the IETF publication for some years now.

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

Stephen

On Sat, Dec 22, 2018 at 5:07 AM Simon Pietro Romano <spromano@unina.it> wrote:
Hello everybody,

I=92m perfectly fine with Benjamin=92s and Ben=92s proposal.

Cheers,

Simon

                     = ;             _\\|//_
                     = ;          ( O-O )
      ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~= ~~~~~
                    = Simon Pietro Romano
               Universita' di Napoli Federico II
                      Computer Engineering Department 
             P= hone: +39 081 7683823 -- Fax: +39 081 7683816
                     = ;                     &nb= sp;e-mail: spromano@uni= na..it

    <<Molti mi dicono che lo = ;scoraggiamento =E8 l'alibi degli 
    idioti. Ci rifletto un istante; e m= i scoraggio>>. Magritte.
                                   = ;  oooO
       ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~= ~~~~~~~~~~~~~~~~~~~~~~~
              =    \ (            (   )
              =                     \_) &= nbsp;        ) /
                     = ;                     &nb= sp;                     &= nbsp;      (_/



Il giorno 22 dic 2018, alle ore 00:10, Adam Roach <adam@nostrum.com> ha scritto:

CLUE working group and document authors:

During IESG evaluation, Benjamin and Ben raised some issues around the stat= e machine design, timeouts, and interaction with the various SIP state mach= ines. While these could probably be addressed by adding substantial new tex= t and a handful of new states and supervisory timers to the CLUE state machines, as well as including additi= onal detail about the interaction between such state machines and the SIP s= tate machines, it's not clear to me that the CLUE working group has the kin= d 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 publicat= ion of the protocol mechanism as Experimental rather than Standards Track, = in order to allow the collection of operational experience around implement= ing 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 public= ation of the CLUE documents. (Note that, due to the relationship between cl= ue-protocol, clue-signaling, and clue-datachannel, this would also result in the publication of clue-signal= ing 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 mo= ve the core CLUE documents to Experimental status respond before Friday, Ja= nuary 18th. Thanks.

/a



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

____________________________________________=
___=0A=
clue mailing list=0A=
clue@ietf.org=0A=
https:=
//www.ietf.org/mailman/listinfo/clue=0A=


--_000_HE1PR07MB31613453A5F73FB1F07B8C7A938A0HE1PR07MB3161eurp_--