Re: [core] Review draft-tiloca-core-oscore-discovery-04
Jim Schaad <ietf@augustcellars.com> Wed, 20 November 2019 20:19 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E83120100 for <core@ietfa.amsl.com>; Wed, 20 Nov 2019 12:19:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wZsyKhBC7Bsy for <core@ietfa.amsl.com>; Wed, 20 Nov 2019 12:19:13 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 089671200D7 for <core@ietf.org>; Wed, 20 Nov 2019 12:19:13 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 20 Nov 2019 12:19:07 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: "'Christian M. Amsüss'" <christian@amsuess.com>, core@ietf.org
References: <022101d59f70$9a9cf9b0$cfd6ed10$@augustcellars.com> <20191120100734.GA717484@hephaistos.amsuess.com>
In-Reply-To: <20191120100734.GA717484@hephaistos.amsuess.com>
Date: Thu, 21 Nov 2019 04:19:05 +0800
Message-ID: <02aa01d59fdf$c37cff50$4a76fdf0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFmF6eGOqiGspPa3Xs9ezEjvRHCKqhzj8AA
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/4wd7sb1adqtuuHSIjjSlwWN-KDk>
Subject: Re: [core] Review draft-tiloca-core-oscore-discovery-04
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Nov 2019 20:19:15 -0000
-----Original Message----- From: core <core-bounces@ietf.org> On Behalf Of Christian M. Amsüss Sent: Wednesday, November 20, 2019 6:08 PM To: core@ietf.org Subject: Re: [core] Review draft-tiloca-core-oscore-discovery-04 Hello Jim, > Need to go here as well. This too. just picking the points I feel I have something to say about: > * Should this document be re-written to only use CoRAL-reef? I don't think so in general for time line reasons. (There's no concrete pressure on this as far as I know of, but CoRAL still has no forseeable timeline). [JLS] It is not clear to me that there is a timeline for this document as well. What I could see us do is having both in examples, and possibly even accept that some features are not as optimized or usable in link-format but can be in CoRAL. (The link from the join resource to the authorization server, on which there was the comment today from proxy-Klaus, comes to mind.) [JLS] That would be helpful > * Section 5 - I don't care if you specify the same application group > multiple times. I don't want to have to figure out how to check this one > thing and error. Plus the end result will always be the same anyway Considering the paragraph below that, the app-gp paragraph can be vastly simplified anyway, and I think we already have an item about making this less normative. (The link's content is normative; how it's looked up in an RD is just a description of the combined steps). > * Section 5.1 - I think the anchor in the response is supposed to be absent. The anchor needs to be there because it's an RD lookup result, and the RD needs to fill in the anchor because it could be relevant for interpreting the implied "hosts" relation or any non-target link attributes (which I usually claim should not be registered, but that's what we arrived at RD for 6690 compatibility). [JLS] Rats - I guess I need to go back and read the RD draft again. The last thing that I remember was that everything came back as fully resolved and thus anchor did not mean anything. Jim Thanks for your input c -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
- [core] FW: Review draft-tiloca-core-oscore-discov… Jim Schaad
- Re: [core] Review draft-tiloca-core-oscore-discov… Christian M. Amsüss
- Re: [core] Review draft-tiloca-core-oscore-discov… Jim Schaad
- Re: [core] FW: Review draft-tiloca-core-oscore-di… Marco Tiloca