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

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Sun, 3 Mar 2019 23:31:32 +0000

Thanks again Klaus. 

We addressed your 2nd WGLC review comments in https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=%22Klaus+WGLC+review+2%2F27%2F2019%22   I think that is all of them. The latest version of the text is https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt 

We are planning to reupload this week, please let us know if there is more feedback. 

Below I am addressing the rest of your questions or things I didn't think needed an update in the draft. 

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

That is right. We could mandate only .well-known URIs. But I think we ought to let a deployment use non-default URIs. For example some usecase might not want to send the .well-known in the URI to save transmission bytes and thus use a custom short URI. If the URI change takes place after deployment client will find that out with a discovery. Similarly, a usecase might initially not support one of the optional requests like server-side keygen. If the server adds support sometime in the future, the client could find out using discovery. And we ought to let the client be able to recover in case the well-known request URI fails for some reason and he wants to see what is supported by the server.That is why we thought it is still worth to keep the .well-known URIs along with the discovery.  

> 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"

Yes. The point of the "MUST" is that since crts, sen and sren are mandatory you are supposed to give them out when you support resource discovery for EST-coaps. If you are asking why don't we just support discovery and not the default ./well-known path, the reason that there might be cases where discovery is wasteful in terms of transmission and client code to parse the responses. These cases will never discover anything, they will just use the well-known path. 

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

I saw <http://www.example.com/sensors/t123>;anchor="/sensors/temp";rel="describedby in a couple of examples in RFC6690. I also saw it in https://tools.ietf.org/html/draft-ietf-core-resource-directory that shows 
"Res: 2.05 Content
   <coap://[2001:db8:3::123]:61616/temp>;rt="temperature";
              anchor="coap://[2001:db8:3::123]:61616"
Jim suggested the anchor is not needed, but I think the example is OK to include the port. 

> 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.

We want to make use of Delayed responses. There are cases where the CA takes time to generate the cert/keypair, and in that case it needs to signal the delay with a Max-Age or Empty ACK. That is why we use CON. The text justification does not explain explicitly, but we didn't want to clutter the wording, so we kept it simple. 

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

Yes, we removed all normative language from this section. 

> 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? 

I wanted to keep it in there. We explain that it can be assumed from DTLS if omitted, but I think it is worth to show how the option would be included. I had trouble finding a COAP Uri-Host and port example online when I was searching and thus this is useful as a reference as well. 

Rgs,
Panos 

-----Original Message-----
From: Klaus Hartke <[email-masked]> 
Sent: Wednesday, February 27, 2019 11:39 AM
To: Panos Kampanakis (pkampana) <[email-masked]>
Cc: [email-masked]; Jim Schaad <[email-masked]>
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Mar 2019 16:55:16 -0500

> That is right. We could mandate only .well-known URIs. But I think we
    > ought to let a deployment use non-default URIs. For example some
    > usecase might not want to send the .well-known in the URI to save
    > transmission bytes and thus use a custom short URI. If the URI change
    > takes place after deployment client will find that out with a
    > discovery. Similarly, a usecase might initially not support one of the
    > optional requests like server-side keygen. If the server adds support
    > sometime in the future, the client could find out using discovery. And
    > we ought to let the client be able to recover in case the well-known
    > request URI fails for some reason and he wants to see what is supported
    > by the server.That is why we thought it is still worth to keep the
    > .well-known URIs along with the discovery.

also, EST-COAP is a building block for draft-ietf-anima-constrained-voucher
(containing constrained BRSKI) so preconfiguration won't work.   While
constrained BRSKI can operate on .well-known the LDevID renewal might occur
with a different server, and so discovery might be worthwhile.

There are two reasons for doing the resource discovery:

1) to get a multicast response when looking for a registrar.
2) to get a shorter name to save some bytes.

I think that (2) contributes negatively to code-complexity, and so if not
for (1), I'd prefer to live on /.well-known only.  But, I don't object
to having shorter URLs available for those that want to spend the code.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 5 Mar 2019 14:44:47 +0100

Panos Kampanakis wrote:
> That is right. We could mandate only .well-known URIs. But I think we ought to let a deployment use non-default URIs. [...]

I was aiming at something different, but, re-reading my question, my
question wasn't very clear. Let me try again.

In draft-ietf-ace-coap-est-09, a client can do discovery. For that, it
needs to know the host name (or IP address) and port number of a CoAP
server. It then constructs the URI
<coaps://{host}:{port}/.well-known/core> and then gets a list of links
to the EST resources. The host name and port number must come from
somewhere -- e.g., from configuration or from some other discovery
process. I'm quite happy with this.

Then you were saying that, in some cases, this discovery step is
unnecessary/wasteful. A client would instead need to know the host
name (or IP address) and port number of a CoAP server as well as an
ArbitraryLabel. It would then construct the URI
<coaps://{host}:{port}/.well-known/est/{ArbitraryLabel}/sen> and could
immediately start interacting with that resource. Again, the host
name, port number and ArbitraryLabel must come from somewhere. You
were saying that they come from configuration.

My question is: If host name, port number and ArbitraryLabel can come
from configuration, from which the client constructs
<coaps://{host}:{port}/.well-known/est/{ArbitraryLabel}/sen>, wouldn't
it also be possible to configure the client with the whole URI
containing the three parts directly?

> [...] but I think the example is OK to include the port.

I'm not sure. RFC 6690 is really weird. Let me get back to you on this.

> We want to make use of Delayed responses. There are cases where the CA takes time to generate the cert/keypair, and in that case it needs to signal the delay with a Max-Age or Empty ACK. That is wh…

You're mixing up protocol specification and implementation guidance.
On the protocol specification side, both clients and servers are free
to choose if they want to use confirmable or non-confirmable messages.
And an application should not make any restrictions on that. On the
implementation guidance side, I think it makes a lot of sense to
choose delayed responses here. But implementation guidance should be
clearly marked as such, as not to create the impression that
implementations can only use certain messages types or can rely on
only certain messages types being used.

> I wanted to keep it in there. We explain that it can be assumed from DTLS if omitted, but I think it is worth to show how the option would be included. I had trouble finding a COAP Uri-Host and por…

Yes, having more examples for reference is really nice. And I really
like that you, the authors, spent quite obviously a lot of time making
sure that EST-coaps is actually implementable and figuring out the
best ways to implement it. But, as I said above, you're mixing up
protocol specification and implementation guidance too much for my
taste. I really don't see why the EST-coaps specification needs to
provide examples for basic CoAP features that don't play a crucial
role in the application.

Specifically on Uri-Host and Uri-Port: RFC 7252 notes that "If the
value of an option is intended to be this default value, the option
SHOULD NOT be included in the message." [1] So your example actually
violates this 'SHOULD NOT'...

Klaus

[1] https://tools.ietf.org/html/rfc7252#section-5.4.4

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 5 Mar 2019 16:34:07 +0000

Thanks Klaus. 

OK about waiting for confirmation on ports returned in discovery and RFC6690.

> wouldn't it also be possible to configure the client with the whole URI containing the three parts directly?

Yes, that is perfectly possible. I don't think the draft is forbidding the whole URL being configured instead of a host:port:ArbitraryLabel tuple. 

> I really don't see why the EST-coaps specification needs to provide examples for basic CoAP features that don't play a crucial role in the application.

Understood what you meant. I removed the normative "MUST" and replaced the language to more explicitly state the "RECOMMENDED" for implementers. 

> Specifically on Uri-Host and Uri-Port: RFC 7252 notes that "If the value of an option is intended to be this default value, the option SHOULD NOT be included in the message." [1] So your example actually violates this 'SHOULD NOT'...

For consistency we now use FQDNs in all our /crt examples, so I think the A.1 is more justified. 

If you want to check the updated draft use https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt 

Rgs,
Panos

-----Original Message-----
From: Klaus Hartke <[email-masked]> 
Sent: Tuesday, March 05, 2019 8:45 AM
To: Panos Kampanakis (pkampana) <[email-masked]>
Cc: [email-masked]; Jim Schaad <[email-masked]>
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est

Panos Kampanakis wrote:
> ought to let a deployment use non-default URIs. [...]

I was aiming at something different, but, re-reading my question, my question wasn't very clear. Let me try again.

In draft-ietf-ace-coap-est-09, a client can do discovery. For that, it needs to know the host name (or IP address) and port number of a CoAP server. It then constructs the URI <coaps://{host}:{port}/.well-known/core> and then gets a list of links to the EST resources. The host name and port number must come from somewhere -- e.g., from configuration or from some other discovery process. I'm quite happy with this.

Then you were saying that, in some cases, this discovery step is unnecessary/wasteful. A client would instead need to know the host name (or IP address) and port number of a CoAP server as well as an ArbitraryLabel. It would then construct the URI <coaps://{host}:{port}/.well-known/est/{ArbitraryLabel}/sen> and could immediately start interacting with that resource. Again, the host name, port number and ArbitraryLabel must come from somewhere. You were saying that they come from configuration.

My question is: If host name, port number and ArbitraryLabel can come from configuration, from which the client constructs <coaps://{host}:{port}/.well-known/est/{ArbitraryLabel}/sen>, wouldn't it also be possible to configure the client with the whole URI containing the three parts directly?

You're mixing up protocol specification and implementation guidance.
On the protocol specification side, both clients and servers are free to choose if they want to use confirmable or non-confirmable messages.
And an application should not make any restrictions on that. On the implementation guidance side, I think it makes a lot of sense to choose delayed responses here. But implementation guidance should be clearly marked as such, as not to create the impression that implementations can only use certain messages types or can rely on only certain messages types being used.

> I wanted to keep it in there. We explain that it can be assumed from DTLS if omitted, but I think it is worth to show how the option would be included. I had trouble finding a COAP Uri-Host and por…

Yes, having more examples for reference is really nice. And I really like that you, the authors, spent quite obviously a lot of time making sure that EST-coaps is actually implementable and figuring out the best ways to implement it. But, as I said above, you're mixing up protocol specification and implementation guidance too much for my taste. I really don't see why the EST-coaps specification needs to provide examples for basic CoAP features that don't play a crucial role in the application.

Specifically on Uri-Host and Uri-Port: RFC 7252 notes that "If the value of an option is intended to be this default value, the option SHOULD NOT be included in the message." [1] So your example actually violates this 'SHOULD NOT'...

Klaus

---

From: Jim Schaad <[email-masked]>
Date: Tue, 5 Mar 2019 12:09:04 -0800

> From: Ace <[email-masked]> On Behalf Of Panos Kampanakis
> (pkampana)
> Sent: Tuesday, March 5, 2019 8:34 AM
> To: Klaus Hartke <[email-masked]>
> Cc: [email-masked]

RFC 6690 references to 3986 for  URI-reference

RFC 3986 defines the following ABNF

   URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

   hier-part     = "//" authority path-abempty
                 / path-absolute
                 / path-rootless
                 / path-empty

   URI-reference = URI / relative-ref

   authority     = [ userinfo "@" ] host [ ":" port ]

Thus yes port is just fine to include

Jim

> Yes, that is perfectly possible. I don't think the draft is forbidding the
whole
> URL being configured instead of a host:port:ArbitraryLabel tuple.
> 
> > I really don't see why the EST-coaps specification needs to provide
> examples for basic CoAP features that don't play a crucial role in the
> application.
> 
> Understood what you meant. I removed the normative "MUST" and
> replaced the language to more explicitly state the "RECOMMENDED" for
> implementers.
> 
> > Specifically on Uri-Host and Uri-Port: RFC 7252 notes that "If the value
of an
> option is intended to be this default value, the option SHOULD NOT be
> included in the message." [1] So your example actually violates this
'SHOULD
> NOT'...
> 
> For consistency we now use FQDNs in all our /crt examples, so I think the
A.1
> is more justified.
> 
> If you want to check the updated draft use
> https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-
> coap-est.txt
> 
> Rgs,
> Panos
> 
> 
needs to
> know the host name (or IP address) and port number of a CoAP server. It
> then constructs the URI <coaps://{host}:{port}/.well-known/core> and then
> gets a list of links to the EST resources. The host name and port number
must
> come from somewhere -- e.g., from configuration or from some other
> discovery process. I'm quite happy with this.
> 
> unnecessary/wasteful. A client would instead need to know the host name
> (or IP address) and port number of a CoAP server as well as an
<coaps://{host}:{port}/.well-
> known/est/{ArbitraryLabel}/sen> and could immediately start interacting
> with that resource. Again, the host name, port number and ArbitraryLabel
> must come from somewhere. You were saying that they come from
> configuration.
> 
> My question is: If host name, port number and ArbitraryLabel can come from
> configuration, from which the client constructs
<coaps://{host}:{port}/.well-
> known/est/{ArbitraryLabel}/sen>, wouldn't it also be possible to configure
> the client with the whole URI containing the three parts directly?
> 
> > > 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.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.
> >
> > We want to make use of Delayed responses. There are cases where the CA
> takes time to generate the cert/keypair, and in that case it needs to
signal
> the delay with a Max-Age or Empty ACK. That is why we use CON. The text
> justification does not explain explicitly, but we didn't want to clutter
the
> wording, so we kept it simple.
> 
> On the protocol specification side, both clients and servers are free to
choose
> if they want to use confirmable or non-confirmable messages.
> implementation guidance side, I think it makes a lot of sense to choose
> delayed responses here. But implementation guidance should be clearly
> marked as such, as not to create the impression that implementations can
> only use certain messages types or can rely on only certain messages types
> being used.
> 
> > > 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?
> >
> > I wanted to keep it in there. We explain that it can be assumed from
DTLS if
> omitted, but I think it is worth to show how the option would be included.
I
> had trouble finding a COAP Uri-Host and port example online when I was
> searching and thus this is useful as a reference as well.
> 
> Yes, having more examples for reference is really nice. And I really like
that
> you, the authors, spent quite obviously a lot of time making sure that
EST-
> coaps is actually implementable and figuring out the best ways to
implement
> it. But, as I said above, you're mixing up protocol specification and
> implementation guidance too much for my taste. I really don't see why the
> EST-coaps specification needs to provide examples for basic CoAP features
> that don't play a crucial role in the application.
> 
> Specifically on Uri-Host and Uri-Port: RFC 7252 notes that "If the value
of an
> option is intended to be this default value, the option SHOULD NOT be
> included in the message." [1] So your example actually violates this
'SHOULD
> NOT'...
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace