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.
»
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
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:
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
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
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
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 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
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
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
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