> -----Original Message-----
> From: Ace <ace-boun...@ietf.org> On Behalf Of Panos Kampanakis
> (pkampana)
> Sent: Tuesday, March 5, 2019 8:34 AM
> To: Klaus Hartke <har...@projectcool.de>
> Cc: ace@ietf.org
> Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est
>
> Thanks Klaus.
>
> OK about waiting for confirmation on ports returned in discovery and
> RFC6690.
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
>
> > 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 <har...@projectcool.de>
> Sent: Tuesday, March 05, 2019 8:45 AM
> To: Panos Kampanakis (pkampana) <pkamp...@cisco.com>
> Cc: ace@ietf.org; Jim Schaad <i...@augustcellars.com>
> Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est
>
> Panos Kampanakis wrote:
> > > 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. [...]
>
> 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?
>
> > > 5.1 "Discoverable port numbers can be returned in the response
> payload." -- Now I'm wondering if that's actually permitted by RFC 6690...
> >
> > [...] 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.
>
> > > 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.
>
> 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.
>
> > > 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'...
>
> Klaus
>
> [1] https://tools.ietf.org/html/rfc7252#section-5.4.4
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
