[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