[core] AD review of draft-ietf-core-resource-directory-23
Alexey Melnikov <alexey.melnikov@isode.com> Mon, 04 November 2019 17:07 UTC
Return-Path: <alexey.melnikov@isode.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 5BD7B120AF1 for <core@ietfa.amsl.com>; Mon, 4 Nov 2019 09:07:54 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 M_1N7doq_OO0 for <core@ietfa.amsl.com>; Mon, 4 Nov 2019 09:07:52 -0800 (PST)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 25C0A120AEA for <core@ietf.org>; Mon, 4 Nov 2019 09:07:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1572887271; d=isode.com; s=june2016; i=@isode.com; bh=sjT6wsKRd8FVHmkiWFwZdAR2DJ1UItEv3iJBuj32veA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=O0rpy6PN6Q2qiUzJh/KDrz5A+tU9tFCJWr4OmcZJdQM65zCJdAZFemFw5pZBqly6dnaRat wHo739cr9zyGHbnE5rLB8lhZUemn/aCkugBRnA7Ir22SEFp/mmYX5lWI+gYM90+vP7YokW c/i2//yKuyYuOMRou3WTc8MYw1Bd4B8=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <XcBa5wB8pzbk@statler.isode.com>; Mon, 4 Nov 2019 17:07:51 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: "core@ietf.org" <core@ietf.org>
Message-ID: <481f9820-bcea-af6a-d5c4-d713be24d43d@isode.com>
Date: Mon, 04 Nov 2019 17:06:45 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/QRSNN9ZhsB5PXcMyPFn226DSgpM>
Subject: [core] AD review of draft-ietf-core-resource-directory-23
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: Mon, 04 Nov 2019 17:07:54 -0000
Hi, My apologies for the delay in reviewing this document: Everywhere: header ==> header field (at least one instance in Section 5, there might be more) In Section 3.7: the first mention of URN needs a reference. In 4.1.1: RDAO type of 38 - IANA typically should be allowed to pick the next available value unless there was an early allocation. You should be prepared for this value to change. In 4.3: The well-known entry points SHOULD be provided to enable unicast discovery. I don't see a new .well-known value being registered in the IANA Considerations section. Have I misintepreted what this mean? In 4.3, 6th para: Clients of the RD SHOULD therefore accept URIs of all schemes they support, both as URIs and relative references, Did you mean to say "absolute URIs"? Relative URIs are still URIs and not limit the set of discovered URIs to those hosted at the address used for URI discovery. In Section 5: ep := Endpoint name (mostly mandatory). The endpoint name is an identifier that MUST be unique within a sector. As the endpoint name is a Unicode string, it is encoded in UTF-8 (and possibly pct-encoding) pct-encoding ==> pct-encoded during variable expansion (see [RFC6570] Section 3.2.1). At the end of section 5: Req: POST /rd?ep=node1&base=http://[2001:db8:1::1] HTTP/1.1 Host: example.com Content-Type: application/link-format Payload: </sensors/temp>;ct=41;rt="temperature-c";if="sensor", <http://www.example.com/sensors/temp>; anchor="/sensors/temp";rel="describedby" This is not valid HTTP, I would rather you used a proper HTTP example. If you do, the line "Payload:" should be replaced with an empty line to separate payload from the header section. In 5.3, 1st para: This section describes how the registering endpoint can maintain the registrations that it created. The registering endpoint can be the registrant-ep or the CT. An endpoint SHOULD NOT use this interface Why SHOULD NOT (instead of MUST NOT) and how is this enforced? for registrations that it did not create. The registrations are resources of the RD. In 5.3.1 on page 31: typo: Service Unabailable ==> Service Unavailable In 6.2, 5th para: Note that "href" is a valid search criterion and matches target references. Like all search criteria, on a resource lookup it can match the target reference of the resource link itself, but also the registration resource of the endpoint that registered it. Queries for resource link targets MUST be in URI form (i.e. not relative I think you means "absolute URI form" (relative reference is still a URI form) references) and are matched against a resolved link target. Queries for endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; "relative URI form" here? the RD SHOULD recognize either. In 6.2: search := Search criteria for limiting the number of results (optional). I think this is undespecified. Can you give me an example? In 6.4, 3rd para: in path-absolute form or, if required, as absolute references. What is the difference between these two? In 7.3: Assuming that the client is provided by a certificate at manufacturing time, the certificate is uniquely identified by the CN field and the serial number. This probably needs a reference for CN/serial number. In 9.3: o validity requirements if any, and Does this include syntax? Also, should the list of fields include "reference to the document with more information"? (can be optional) At the end of section 9.3: It is expected that the registry will receive between 5 and 50 registrations in total over the next years. This will not age well! Maybe remove this text from the document and add it to the spherding write-up? I think the following reference is Normative the way it is used in the document: [I-D.ietf-core-rd-dns-sd] Stok, P., Koster, M., and C. Amsuess, "CoRE Resource Directory: DNS-SD mapping", draft-ietf-core-rd-dns-sd-05 (work in progress), July 2019. Best Regards, Alexey
- [core] AD review of draft-ietf-core-resource-dire… Alexey Melnikov
- Re: [core] AD review of draft-ietf-core-resource-… Klaus Hartke
- Re: [core] AD review of draft-ietf-core-resource-… Christian Amsüss
- Re: [core] AD review of draft-ietf-core-resource-… Carsten Bormann
- Re: [core] AD review of draft-ietf-core-resource-… Jaime Jiménez
- Re: [core] AD review of draft-ietf-core-resource-… Alexey Melnikov
- [core] DNS-SD service types for CoRE-RD (Re: AD r… Carsten Bormann
- Re: [core] DNS-SD service types for CoRE-RD (Re: … Christian Amsüss
- Re: [core] DNS-SD service types for CoRE-RD (Re: … Ted Lemon
- Re: [core] DNS-SD service types for CoRE-RD (Re: … Carsten Bormann
- Re: [core] DNS-SD service types for CoRE-RD (Re: … Ted Lemon
- Re: [core] DNS-SD service types for CoRE-RD (Re: … Christian Amsüss
- Re: [core] AD review of draft-ietf-core-resource-… Alexey Melnikov
- Re: [core] AD review of draft-ietf-core-resource-… Jaime Jiménez
- Re: [core] AD review of draft-ietf-core-resource-… Alexey Melnikov
- Re: [core] AD review of draft-ietf-core-resource-… Christian Amsüss
- Re: [core] AD review of draft-ietf-core-resource-… Alexey Melnikov