Re: [Ace] WGLC for draft-ietf-ace-coap-est

Klaus Hartke <> Wed, 27 February 2019 16:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0862130EE5 for <>; Wed, 27 Feb 2019 08:40:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g4f1Fmg04Awo for <>; Wed, 27 Feb 2019 08:39:58 -0800 (PST)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25F1913101B for <>; Wed, 27 Feb 2019 08:39:57 -0800 (PST)
Received: from ([]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gz2FP-0006NA-Em; Wed, 27 Feb 2019 17:39:55 +0100
Received: by with SMTP id j36so19913395qta.7 for <>; Wed, 27 Feb 2019 08:39:55 -0800 (PST)
X-Gm-Message-State: APjAAAWXoXbbmGUwGiR11o4NV7dWmZVvNqsfdObqob77ExLud5LjVqRU KskiEEDvHDUt3oioufRi8zlzA3Yw3pOLDWYUkGw=
X-Google-Smtp-Source: APXvYqydlm3xtpes5+Wo6x/alI6ohFpKUZyjQ+bSbXlMugjwNZWZweGPcI2ygQYv32JYxic+D0lhPDJ7IbZiurYRVHo=
X-Received: by 2002:a0c:99e2:: with SMTP id y34mr2697215qve.18.1551285594218; Wed, 27 Feb 2019 08:39:54 -0800 (PST)
MIME-Version: 1.0
References: <003701d4abbe$0cfab580$26f02080$> <> <>
In-Reply-To: <>
From: Klaus Hartke <>
Date: Wed, 27 Feb 2019 17:39:17 +0100
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: "Panos Kampanakis (pkampana)" <>
Cc: "" <>, Jim Schaad <>
Content-Type: text/plain; charset="UTF-8"
X-bounce-key:;; 1551285598; 23e4f963;
X-HE-SMSGID: 1gz2FP-0006NA-Em
Archived-At: <>
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Feb 2019 16:40:01 -0000

Hi Panos,

thanks for addressing all issues so thoroughly. I've performed another
quick review of draft-ietf-ace-coap-est-09.

5.1. The discovery looks much better now! I think you had 5 or 6 ways
for a client to construct or discover the URIs of an EST deployment.
Now it seems there are only two:

Either (A) the client is configured out-of-band with host name/IP
address, port, and optionally an ArbitraryLabel and constructs a URI
of the form coaps://{hostname]:{port}/.well-known/est/{optionally an
ArbitraryLabel}/{one of the suffixes}.

Or (B) the client is configured out-of-band with host name/IP address
and port, constructs a URI of the form
coaps://{hostname}:{port}/.well-known/core, performs a look up on that
URI, and looks for a link in the response with a resource type of the
form "ace.est.{one of the suffixes}".

But can't the client just be configured out-of-band with the URIs directly?

5.1 "The ArbitraryLabel path-segment, if used, SHOULD be of the
shortest length possible" -- So if someone decides to use an
ArbitraryLabel path-segment consisting of more than 0 characters
(which is the shortest length possible), then it's a protocol
violation? This seems to be a matter of implementation quality to me,
not a requirement for interoperability.

5.1 "(Sections 3.1 and 3.2.2 of [RFC7030]." -- Missing )

5.1 "The EST-coaps server URIs, obtained through discovery of the
EST-coaps root resource(s) as shown below, are of the form:" -- There
is no longer a 'root resource' if a client discovers the full paths.
For example, implementers are free to send the following
/.well-known/core if they want:


5.1 "The first three lines of the discovery response above MUST be
returned if the server supports resource discovery." -- ...if it
supports EST? I mean, if a server has a /.well-known/core resource and
implements a draft, is there a reason why it wouldn't include the EST
resources in the /.well-known/core representation? If it doesn't want
to offer two sets of paths, it can simply return this:


5.1 "The Content-Formats in the response allow the client to request
one that is supported by the server." -- Maybe state explicitly that
these are the values accepted by the server in the Accept option?

5.1 "Discoverable port numbers can be returned in the response
payload." -- Now I'm wondering if that's actually permitted by RFC

5.1 " The client SHOULD use resource discovery when /.well-known/est
fails" -- But if /.well-known/est fails, then the server clearly
doesn't support EST because of "The server MUST support the default
/.well-known/est root resource.", right?

5.1 "It is up to the implementation to choose its root resource;" --
As above, there is no root resource.

5.4 "All EST-coaps request messages expect an acknowledgement (with a
response payload); EST-coaps requests are confirmable CON CoAP
messages." -- This seems to be a matter of implementation quality and
should not be a requirement for interoperability. I suggest to remove

7. "Parameters" -- This section should be a non-normative
implementation note or removed altogether.

A. "These examples assume a short root resource path of "/est"." -- As
above, there is no root resource. Maybe the very first example in this
section should be a look up of /.well-known/core for the URIs used in
the following subsections?

A.1 "Option Length = 0x9 Option Value =" -- The
value of 0x9 does not match the length of "".
Also in other examples and for other options.

A.1. "The Uri-Host and Uri-Port Options can be omitted" -- But they
aren't in this example. Since it's not important for the example,
maybe just remove Uri-Host and Uri-Port from the example and also this

A.2 "POST [2001:db8::2:1]:61616/est/sen" -- We don't have a standard
format for CoAP examples, but this line uses a different format than
section A.1. It might be good to make this consistent.