Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps?

Phil Hunt <phil.hunt@oracle.com> Thu, 11 September 2014 16:07 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988391A0410 for <oauth@ietfa.amsl.com>; Thu, 11 Sep 2014 09:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.853
X-Spam-Level:
X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
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 ZlUwRlS_vbGD for <oauth@ietfa.amsl.com>; Thu, 11 Sep 2014 09:07:40 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7531A89AE for <oauth@ietf.org>; Thu, 11 Sep 2014 09:07:27 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8BG7QVX019345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Sep 2014 16:07:27 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8BG7OIW017092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Sep 2014 16:07:25 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8BG7OYe022151; Thu, 11 Sep 2014 16:07:24 GMT
Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Sep 2014 09:07:24 -0700
References: <5410E3AF.3030806@gmx.net> <d9523ba290534a9493fc805980f4365d@BLUPR03MB309.namprd03.prod.outlook.com> <9E856DCC-79F4-421B-A6EB-1438115843CB@mitre.org> <AA4C1102-5092-4660-8BF8-51E53B0CD26D@oracle.com> <3AD141D9-5673-4945-9DC9-E95D7D35EF33@ve7jtb.com> <AB44CD57-D088-4FEC-B927-BA9D1D78B52D@mitre.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <AB44CD57-D088-4FEC-B927-BA9D1D78B52D@mitre.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <597105CD-0F67-437B-89E7-EE9BC3DDB910@oracle.com>
X-Mailer: iPhone Mail (11D257)
From: Phil Hunt <phil.hunt@oracle.com>
Date: Thu, 11 Sep 2014 09:07:22 -0700
To: "Richer, Justin P." <jricher@mitre.org>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/aUQTgSesjI2Y-ZiGLHeWQgcFhK0
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 16:07:45 -0000

+1. Experimental seems best here. 

Phil

> On Sep 11, 2014, at 9:03, "Richer, Justin P." <jricher@mitre.org> wrote:
> 
> +1 
> 
> That was the key line that I took from the guidelines as well and this was my understanding of the discussion in Toronto.
> 
> -- Justin
> 
>> On Sep 11, 2014, at 12:02 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>> 
>> I think this fits.
>> 
>>    • If the IETF may publish something based on this on the standards track once we know how well this one works, it's Experimental. This is the typical case of not being able to decide which protocol is "better" before we have experience of dealing with them from a stable specification. Case in point: "PGM Reliable Transport Protocol Specification" (RFC 3208)
>> 
>> If we publish something it may or may not look like the current spec but getting some experience with the current spec will inform that decision. 
>> 
>> John B.
>>> On Sep 11, 2014, at 12:55 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>>> 
>>> Interesting. The definitions in that don't correspond with what ADs and other groups are doing. 
>>> 
>>> I heard httpbis using experimental as a placeholder for a draft that didn't have full consensus to bring back later. 
>>> 
>>> That was the feel I had in Toronto-that we weren't done but it was time to publish something. 
>>> 
>>> Reading the actual definition i would say neither fits. Ugh. 
>>> 
>>> Phil
>>> 
>>>> On Sep 11, 2014, at 8:01, "Richer, Justin P." <jricher@mitre.org> wrote:
>>>> 
>>>> According to the guidelines here:
>>>> 
>>>> https://www.ietf.org/iesg/informational-vs-experimental.html
>>>> 
>>>> And the discussion in Toronto, it's clearly experimental.
>>>> 
>>>> -- Justin
>>>> 
>>>>> On Sep 11, 2014, at 10:36 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:
>>>>> 
>>>>> Is "experimental" the correct classification? Maybe "informational" is more appropriate as both of these were discussed. 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
>>>>> Sent: Wednesday, September 10, 2014 4:50 PM
>>>>> To: oauth@ietf.org
>>>>> Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps?
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> in response to the discussions at the last IETF meeting the authors of the "Dynamic Client Registration Management Protocol"
>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have changed the document type to "Experimental".
>>>>> 
>>>>> We need to make a decision about the next steps for the document and we see the following options:
>>>>> 
>>>>> a) Publish it as an experimental RFC
>>>>> 
>>>>> b) Remove it from the working group and ask an AD to shepherd it
>>>>> 
>>>>> c) Remove it from the working group and let the authors publish it via the independent submission track.
>>>>> 
>>>>> In any case it would be nice to let folks play around with it and then, after some time, come back to determine whether there is enough interest to produce a standard.
>>>>> 
>>>>> Please let us know what you think!
>>>>> 
>>>>> Ciao
>>>>> Hannes & Derek
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>