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

Jim Schaad <ietf@augustcellars.com> Tue, 05 March 2019 20:09 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0BC12DF71 for <ace@ietfa.amsl.com>; Tue, 5 Mar 2019 12:09:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 lHVzjmSkmCVM for <ace@ietfa.amsl.com>; Tue, 5 Mar 2019 12:09:36 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18E0130EDE for <ace@ietf.org>; Tue, 5 Mar 2019 12:09:33 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Mar 2019 12:09:07 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: "'Panos Kampanakis (pkampana)'" <pkampana@cisco.com>, 'Klaus Hartke' <hartke@projectcool.de>
CC: <ace@ietf.org>
References: <003701d4abbe$0cfab580$26f02080$@augustcellars.com> <CAAzbHvYwEY8TGgNbVPpwo03gQ-j6M4xkVLTZJaSYiLYhZhKMaQ@mail.gmail.com> <9c257f8ffa27435fbe8a24a8c7c25c31@XCH-ALN-010.cisco.com> <CAAzbHvZHfgRTpNWNjg98HXokXCeLECLA13O-RG49woZ1u8QPiQ@mail.gmail.com> <bffe2da1b435462d9acc2b03b969714e@XCH-ALN-010.cisco.com> <CAAzbHvaKS9XDmqmQ789CCS2WikNfAcPC=9sm+-_b0byebdVUHg@mail.gmail.com> <b16aac8eafe4452aa20a7aa4ef6895ea@XCH-ALN-010.cisco.com>
In-Reply-To: <b16aac8eafe4452aa20a7aa4ef6895ea@XCH-ALN-010.cisco.com>
Date: Tue, 5 Mar 2019 12:09:04 -0800
Message-ID: <018501d4d38f$49ed2790$ddc776b0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEe4BfBS1If46evJWTJJBMjZisWiwKDUd/uAmd8YCICEf4ppgHWc7TeAkqsal0B7+S7NacA7zpA
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/CsqNQ64zFL7inqJ8LttY95dpfUI>
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2019 20:09:40 -0000


> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Panos Kampanakis
> (pkampana)
> Sent: Tuesday, March 5, 2019 8:34 AM
> To: Klaus Hartke <hartke@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 <hartke@projectcool.de>
> Sent: Tuesday, March 05, 2019 8:45 AM
> To: Panos Kampanakis (pkampana) <pkampana@cisco.com>
> Cc: ace@ietf.org; Jim Schaad <ietf@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