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

John Bradley <ve7jtb@ve7jtb.com> Thu, 11 September 2014 16:02 UTC

Return-Path: <ve7jtb@ve7jtb.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 3A6831A898F for <oauth@ietfa.amsl.com>; Thu, 11 Sep 2014 09:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 olYJE6Tze7ye for <oauth@ietfa.amsl.com>; Thu, 11 Sep 2014 09:02:18 -0700 (PDT)
Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C322C1A895F for <oauth@ietf.org>; Thu, 11 Sep 2014 09:02:17 -0700 (PDT)
Received: by mail-qg0-f45.google.com with SMTP id j107so7794665qga.32 for <oauth@ietf.org>; Thu, 11 Sep 2014 09:02:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=V+0B6zNKY0etms/qdIIZew53vdEvr8uYeilwsyh7XII=; b=lMRzr+nqlPnUEnkgk6xu5DlwV1PgSxQEmSf/fM/x1oo2Zhq+LNYznN6ce50Owu9m/E KDGOH+gz4lZ/ybrbMX9ikKk+FEyT5GwkKp4Nt8hzddxEJYnUv6IaX7ioQns55MgfqlEt EikUQrLpq4YjhzYxIP5NRbMU3X7vklF/kTDZfC6UIDlMWzuB+izkFCO8IpJpvEpchB05 t8HY+foANW1n1UGiNNBCp+klIrGuZ9F1rJ395J+OAfaypPKPZP9F9Ef19B4IXTK1hTnk 1Ug0kw4gbw4jZknZIrfyCZfaqSvwn4TvBIquTIXtEt7xtqj7nqm+NzKlTaqmaw2mU7hz 11dw==
X-Gm-Message-State: ALoCoQlDWS6zN8OldpT6JCSMk9j0c5WrVuBgSUulUhX7/DA9gHFakuEBfX8g1bBCY8ju3GX1KJVN
X-Received: by 10.229.65.135 with SMTP id j7mr2940497qci.22.1410451336389; Thu, 11 Sep 2014 09:02:16 -0700 (PDT)
Received: from [192.168.1.37] (186-106-172-214.baf.movistar.cl. [186.106.172.214]) by mx.google.com with ESMTPSA id h2sm899354qah.35.2014.09.11.09.02.14 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Sep 2014 09:02:15 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_5D2C334C-B0CB-4D95-B011-12B53C31F1C5"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <AA4C1102-5092-4660-8BF8-51E53B0CD26D@oracle.com>
Date: Thu, 11 Sep 2014 13:02:08 -0300
Message-Id: <3AD141D9-5673-4945-9DC9-E95D7D35EF33@ve7jtb.com>
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>
To: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/SgalUgfthFWZEI1iJ1ZeOr-S3uI
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:02:20 -0000

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