Thanks, this is approved. We can allocate an available number, suggesting the
261-270 range.
Regards
Esko
-Original Message-
From: David Dong via RT
Sent: Friday, March 15, 2024 20:23
Cc: Esko Dijk ; alexan...@ackl.io; c...@tzi.org;
ja...@iki.fi; jaime.jime...@ericsson.com; har
Dijk
Cc: garcia...@uniovi.es; ace@ietf.org
Subject: Re: [Ace] [IANA #1303039] expert review for draft-ietf-ace-wg-coap-eap
(core-parameters, CoAP Content-Formats)
Dear Esko,
Thank you for your comments.
Please, see responses inline.
El 12/1/24 a las 10:55, Esko Dijk escribió:
> Hello,
&g
reason/rationale needs to be provided.
Regards
Esko
-Original Message-
From: David Dong via RT
Sent: Friday, January 12, 2024 02:10
Cc: Esko Dijk ; har...@projectcool.de;
c...@tzi.org; ja...@iki.fi; jaime.jime...@ericsson.com; alexan...@ackl.io;
ace@ietf.org
Subject: [IANA #1303039] exper
/ace-groupcomm+cbor
Content Coding: -
regards
Esko
-Original Message-
From: David Dong via RT
Sent: Friday, October 20, 2023 00:23
Cc: Esko Dijk ; ace@ietf.org;
har...@projectcool.de; c...@tzi.org; ja...@iki.fi; jaime.jime...@ericsson.com;
alexan...@ackl.io
Subject: [IANA #1284518] expert re
Thanks, the proposed text is fine! Agree it is a minor item.
Esko
-Original Message-
From: Panos Kampanakis (pkampana)
Sent: Monday, February 17, 2020 17:47
To: Esko Dijk ; ace@ietf.org
Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt
Thank you for this Esko. Hmm, point
Hello Jim,
Thanks for your comments - the authors are now looking into these and we'll
reply again as soon as we have answers. I also copy this to the CoRE WG list;
as the draft targets the CoRE WG.
Esko
-Original Message-
From: Jim Schaad
Sent: Wednesday, May 29, 2019 00:45
To:
s."
-> should be "an EST-coaps server is expected to" ? Because this
specification and 10.1 describes the EST-coaps server, not a CA.
* Sections 5.1, 5.7, 10.2 : word "he" is used to refer to client or server.
Maybe this should become "it" (not a person).
-
y this works.
Hope these comments can still be used for improvement of the spec. I will send
further review comments in a next email: still need to write these down.
Best regards
Esko
-Original Message-
From: Panos Kampanakis (pkampana)
Sent: Monday, May 20, 2019 17:31
To: Esko Dijk
Thanks,
A few comments I had still on the discovery section - sorry to be late
post-WGLC with this:
- page 10 bottom mentions "management data" - should say "management
resources", or "EST resources" perhaps?
- page 10 bottom: " Upon success, the return payload will contain the root
resource
Dear authors,
In the draft both the paths /crt and /crts are used – this appears to be
incorrect. Should it /crts always ?
Best regards
Esko
Esko Dijk IoT Consultancy | Email/Skype:
esko.d...@iotconsultancy.nl<mailto:esko.d...@iotconsultancy
” is then maybe a more
psychological requirement rather than technical. A powerful server with RTC
just sounds more capable to do private key generation than an IoT device, which
is why server-side keygen may be preferred ;)
Esko
From: Hannes Tschofenig
Sent: Tuesday, May 14, 2019 18:46
To: Esko
Hi Panos, Hannes,
Another reason for server-side keygen can be that an IT department/manager
wants it that way. There could be a policy that the keypairs for all domain
certificates must be created by the systems under direct control of the IT
department. (E.g. to comply with other policies or
ople think about this issue.
Esko
-Original Message-
From: Michael Richardson
Sent: Thursday, February 14, 2019 15:38
To: Panos Kampanakis (pkampana)
Cc: Klaus Hartke ; Esko Dijk
; ace@ietf.org
Subject: Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287
Panos Kamp
uot;ace.est.skg";ct="62 280 284 281 TBD287"
NEW:
;rt="ace.est.skg";ct=62
Note that this format is now CoAP-correct but has the drawback that the client
can't see whether the optional TBD287 is supported or not in the /skg function.
Best regards,
Esko
Esko Dij
ion, that would contradict its purpose.
Best regards
Esko Dijk
-Original Message-
From: Ace On Behalf Of Michael Richardson
Sent: Thursday, January 24, 2019 16:59
To: Panos Kampanakis (pkampana) ; ace@ietf.org
Cc: Jim Schaad ; consulta...@vanderstok.org
Subject: Re: [Ace] FW: WGLC comm
, a 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 text is not so clear on what will happen.
Best regards
Esko Dijk
-Original Message-
From: Ace On Behalf Of Panos Kampanakis (pkampana)
Sent: Monday, September 17, 2018 18:56
To: Jim Schaad ; draft-ietf-ace-coap-...@ietf.org
Cc: 'ace'
Subject: Re: [Ace] Review draft-ietf-ace-coap-est
> I've asked if discovery is always required, permitted, or encouraged.
Normally it is always encouraged to use discovery in favour of fixed URIs at
the server, to avoid specs squatting the URI namespace. But in our case the
/.well-known/est space is already assigned (RFC 7030) so we have to
Esko
From: Peter van der Stok
Sent: Thursday, September 20, 2018 16:56
To: Michael Richardson
Cc: Esko Dijk ; Panos Kampanakis (pkampana)
; ace@ietf.org
Subject: Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Michael Richardson schreef op 2018-09-20 16:51:
I didn't thin
: Panos Kampanakis (pkampana)
Sent: Monday, September 17, 2018 19:12
To: Esko Dijk ; ace@ietf.org
Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI
Hi Esko,
Good point. We made this change to ensure the text is clearer. You will see it
in the next iteration.
Thank you,
Panos
/
coaps://www.example.com//ArbitraryLabel/
--
The suggestion by Peter to add references to the corresponding EST RFC 7030
sections is also good.
Regards
Esko
From: Panos Kampanakis (pkampana)
Sent: Wednesday, September 12, 2018 17:31
To: Esko Dijk ; ace@ietf.org
Subject: RE: ace-coap-es
I support the WG adoption of this document. It will be a useful component to
create a security solution for IoT devices. On the current or a future version
of this draft I can do a review, also.
Best regards
Esko Dijk
-Original Message-
From: Ace [mailto:ace-boun...@ietf.org
it.
Esko
-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Carsten Bormann
Sent: Monday, December 11, 2017 22:59
To: Esko Dijk <esko.d...@philips.com>
Cc: Samuel Erdtman <sam...@erdtman.se>; Mike Jones
<michael.jo...@microsoft.com>; Benjamin Kaduk <ka...
velopers. They might think
they need to implement something while the requirement actually asks them *not*
to implement something. Most developers would not bother to implement such
extra checks anyhow.
thanks
Esko
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Friday, December 8,
and a receiver MUST ignore the value of this field”.
Both are needed.
Best Regards
Esko
From: Samuel Erdtman [mailto:sam...@erdtman.se]
Sent: Wednesday, December 6, 2017 13:48
To: Esko Dijk <esko.d...@philips.com>
Cc: Benjamin Kaduk <ka...@mit.edu>; ace@ietf.org
Subject: Re: [Ace] WGLC
COSE CBOR tag"?
9.2.1
"Applications that use this media type: IoT applications sending security
tokens over HTTP(S) and other transports"
-> can already mention CoAP/CoAPs here ?
Best regards
Esko Dijk
-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Be
26 matches
Mail list logo
