> -Original Message-
> From: Ace On Behalf Of Panos Kampanakis
> (pkampana)
> Sent: Tuesday, March 5, 2019 8:34 AM
> To: Klaus Hartke
> Cc: ace@ietf.org
> Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est
>
> Thanks Klaus.
>
> OK about waiting for
r/draft-ietf-ace-coap-est.txt
Rgs,
Panos
-Original Message-
From: Klaus Hartke
Sent: Tuesday, March 05, 2019 8:45 AM
To: Panos Kampanakis (pkampana)
Cc: ace@ietf.org; Jim Schaad
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est
Panos Kampanakis wrote:
> > But can't the cl
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 questio
Panos Kampanakis (pkampana) 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. For example some
> usecase might not want t
e 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 po
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:
D.
Panos
-Original Message-
From: Benjamin Kaduk
Sent: Sunday, February 24, 2019 7:08 PM
To: Panos Kampanakis (pkampana)
Cc: Klaus Hartke ; Jim Schaad ;
ace@ietf.org
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est
On Fri, Feb 22, 2019 at 09:00:05PM +, Panos Kampanakis (pkampa
27;t always afford to
> > establish a DTLS connection for every EST transaction." -- I'm not aware of
> > any requirement that says CoAP clients must establish a new DTLS connection
> > for every request...
>
> EST mandates using a new truststore after a cac
uot; -- I'm not aware of
> any requirement that says CoAP clients must establish a new DTLS connection
> for every request...
EST mandates using a new truststore after a cacerts request which most usually
means a new TLS connection. We can't always require the client to do that i
Jim Schaad wrote:
> The chairs believe that the EST over CoAP draft is nearing the point it
> should be sent to the IESG for publication. We are therefore going to have
> a Working Group Last Call on this document. WGLC will until 29th of this
> month. Please review the document and send comment
more feedback.
Rgs,
Panos
-Original Message-
From: Ace On Behalf Of Jim Schaad
Sent: Tuesday, January 29, 2019 12:59 AM
To: ace@ietf.org
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est
This message concludes the last call for this document. The authors are
requested to create and
I believe that I already said yes.
Jim
> -Original Message-
> From: Michael Richardson
> Sent: Saturday, February 2, 2019 12:27 PM
> To: Jim Schaad
> Cc: 'Esko Dijk' ; ace@ietf.org
> Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for
&g
Jim Schaad wrote:
> Of anybody on the mailing list believes that the document should not
> add a new CoAP content type for "application/pkix-cert" please speak up
> before next Monday.
Can we go ahead with this request now? :-)
--
Michael Richardson , Sandelman Software Works
-= IP
rg
> Subject: [Ace] WGLC for draft-ietf-ace-coap-est
>
> The chairs believe that the EST over CoAP draft is nearing the point it
should
> be sent to the IESG for publication. We are therefore going to have a
> Working Group Last Call on this document. WGLC will until 29th of this
January 24, 2019 8:01 AM
> To: Esko Dijk
> Cc: ace@ietf.org
> Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for
> embedded devices
>
>
> Esko Dijk wrote:
> > So to reduce code size for embedded implementations it would be very
>
Esko Dijk wrote:
> So to reduce code size for embedded implementations it would be very
> beneficial if the EST Server would support an additional content
> format:
> application/pkix-cert (see RFC 5280)
So, to implement this in the specification, we need an additional
Content-T
Sent: Thursday, January 24, 2019 06:05
To: 'Michael Richardson' ; Esko Dijk
Cc: ace@ietf.org
Subject: RE: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded
devices
> -Original Message-
> From: Ace On Behalf Of Michael Richardson
> Sent: Wednesday,
> -Original Message-
> From: Ace On Behalf Of Michael Richardson
> Sent: Wednesday, January 23, 2019 6:27 PM
> To: Esko Dijk
> Cc: ace@ietf.org
> Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for
> embedded devices
>
>
> Esko Dijk
Esko Dijk wrote:
> My main comment on this draft is based on recent experience with an
> embedded implementation. In the draft, the content format
> "application/pkcs7-mime;smime-type=certs-only" is used to transport a
> single certificate back to the client. However, in the embed
slow server can
acknowledge the request with a 2.31 code" -> 2.31 is not specified in RFC 7252.
Best regards
Esko Dijk
-Original Message-
From: Ace On Behalf Of Jim Schaad
Sent: Monday, January 14, 2019 05:03
To: ace@ietf.org
Subject: [Ace] WGLC for draft-ietf-ace-coap-est
The cha
The chairs believe that the EST over CoAP draft is nearing the point it
should be sent to the IESG for publication. We are therefore going to have
a Working Group Last Call on this document. WGLC will until 29th of this
month. Please review the document and send comments both positive and
negati
21 matches
Mail list logo
