I support the adoption of this draft. There is a great need for a standards
based mechanism for secure enrollment of constrained endpoints, which this
draft provides.
Thanks
Rupak
-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Jim Schaad
Sent: Tuesday, January
On Feb 2, 2018, at 23:24, Benjamin Kaduk wrote:
>
> Finally, in the acknowledgments, we can ask the RFC Editor to use
> the non-ASCII "Gőran" if he so desires. (Last I heard the tooling
> isn't there to use non-ASCII for internet drafts yet, though.)
We have the same issue in
»
Depending upon the values being requested, registration requests are
evaluated on a Standards Track Required, Specification Required,
Expert Review, or Private Use basis [RFC8126]
«
This might give the impression that IANA registrations can be made on a
“Private Use” basis.
RFC
The CBOR Web Token (CWT) specification has been updated to address the shepherd
comments by Benjamin Kaduk. Changes were:
* Updated the RFC 5226 reference to RFC 8126.
* Made the IANA registration criteria consistent across sections.
* Stated that registrations for the limited set
I support the adoption of this draft. The industrial IoT sector is
establishing certificate based secure communications and will need a secure
means to manage these certificates. With the use of CoAp in that space, this
draft can be the what/how to achieve just that.
Warm regards, Nancy
On
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for
Constrained Environments WG of the IETF.
Title : CBOR Web Token (CWT)
Authors : Michael B. Jones
Thanks for your useful review, Ben. I believe that
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-12 addresses all your
comments and is ready to send to Kathleen.
Best wishes,
-- Mike
-Original Message-
From:
Good point. I'll make a note to update the description the next time we
publish a draft to not imply that values in the Private Use range are
registered. I don't think it's worth publishing another draft for just this
until we receive Kathleen's AD review, at which point I'll address it.
Hi all,
We're getting ready to send this to Kathleen for processing
(hopefully to finish before her term as AD does!), but there are a
few nits that should be fixed with a new rev before we actually push
the button.
We currently have an informational reference to RFC 5226, which has
since been
Thanks for the detailed read, Ben. Will do.
-- Mike
-Original Message-
From: Benjamin Kaduk [mailto:ka...@mit.edu]
Sent: Friday, February 2, 2018 2:25 PM
To: ace@ietf.org; draft-ietf-ace-cbor-web-to...@ietf.org
Subject: shepherd review of
Hi Stefan,
Thanks for the support.
I see your point of view; We will look at the text to avoid suggesting
that EST/https and EST/coaps cannot exist together.
Peter
Beck, Stefan schreef op 2018-02-01 12:51:
+1
I support adoption, as it perfectly complements the existing EST work.
So far,
11 matches
Mail list logo