[core] Comments on draft-ietf-core-resource-directory-11

Jim Schaad <ietf@augustcellars.com> Thu, 10 August 2017 17:57 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 153631323BC; Thu, 10 Aug 2017 10:57:29 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=augustcellars.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 i0-qt10Bd5wu; Thu, 10 Aug 2017 10:57:25 -0700 (PDT)
Received: from mail4.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 A4C0D131D1A; Thu, 10 Aug 2017 10:57:25 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1502387818; h=from:subject:to:date:message-id; bh=6Qd06VIi2BaUnu+jv6chfuKbnREUZQFKf4vfTSPdRFo=; b=IAKCfav7NhlHVB1CZ0m5n3K/L4yRumEomw4MAoEugfpTBfGuogrtKOg+GZXu3aA9JwUZqmQ6N3E e4ymY6rnqpCtTPpt/hh8GGXPlH5HqRM7hyK+RohLjRBc+wS7U2d2BX6OO6zdnPQEsqfBAEaKqikXE k5fruAKqzLBRWXRTHkWJYGycQV6NCaWFuYfALA9uSmd71bpuuvCARs2P8nQEbOVaLhF/NVa6b+BkM xXYdC8axBRDISfNFVb60ZwPjPdswDPUlmFM8R5PbVMbFk3lQj7MrldZaiwt4yl/zeAT30sXEA2Z3o 9ocoga2Mrn1LIB3XVV8/0uSbHYuGMFkvyqRA==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 10 Aug 2017 10:56:56 -0700
Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 10 Aug 2017 10:56:32 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: draft-ietf-core-resource-directory@ietf.org
CC: core@ietf.org
Date: Thu, 10 Aug 2017 10:56:54 -0700
Message-ID: <008e01d31202$0eea5870$2cbf0950$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdMRci0Luk2lCuSlSeikhZNrR/U7SQ==
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Vn-D4DeDLBEkpjzagsM_-2D3giA>
Subject: [core] Comments on draft-ietf-core-resource-directory-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 10 Aug 2017 17:57:29 -0000

1.  In section 5.2 para 2 - Not sure if this is wrong or not.  However I
would think that rt=core.rd-group is used to discover the URI path for RD
group operations not rt=core.gp.  I note that core.gp is not listed in the
set of valid rt values in the template.

2.  I am unclear of the proper interactions of the following items:
  * The anchor attribute - does it override the context query parameter
  * What happens if  a full URI is given as the target?  How does this
interact w/ the context query parameter?

3.  For simple registration.  If the client has needed to find the RD so it
knows where to do the post, why is the post not done to the RD rather than
to the /.well-know/core point?

4.  It is not clear to me what if the patch payload of  {data} should be
accepted.  Looking at the document as JSON, there is always an array wrapper
around it so that this template never matches the resulting document.  It
seems as if this should always be [{data}] instead.  Is there an implicit
add of the array if absent?  If you have a pattern of {data} and you match
multiple items, is that an error?

5.  Is there an implication that if the resources associated with an
endpoint expire, that the endpoint expires from all of its groups as well?
Is there a different way that endpoints are registered with the RD?

6.  Can an endpoint register zero items with an RD?

7.  should there be some text on interactions between ETag and page/count
query parameters?  What happens if there is a an update of the registry in
the middle of doing a sequence of queries about the links using these
options?


Jim


Typo
s/ecample.com/example.com/