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:
</the/quick/>;rt="ace.est.crts",
</brown>;rt="ace.est.sen",
</fox/jumps/over>;rt="ace.est.sren",
</the/>;rt="ace.est.att",
</lazy/dog?281>;rt="ace.est.skg",
</lazy/dog?287>;rt="ace.est.skc"
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:
</.well-known/est/crts>;rt="ace.est.crts",
</.well-known/est/sen>;rt="ace.est.sen",
</.well-known/est/sren>;rt="ace.est.sren",
</.well-known/est/att>;rt="ace.est.att",
</.well-known/est/skg>;rt="ace.est.skg",
</.well-known/est/skc>;rt="ace.est.skc"
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
6690...
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
this.
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 = est-coaps.example.org" -- The
value of 0x9 does not match the length of "est-coaps.example.org".
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
paragraph?
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.
Klaus
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
