I encounter a number of problems with this I-D. Much of it is about IANA
Considerations and I note the absence of a reference to RFC8126 which
provides the basis for much of my comments.
RFC8126 specifies a two-tier structure for IANA, of Group name an
Registry name, which makes it easier to find data, now and in future.
This I-D makes no mention of the Group name; perhaps easy enough to
guess in this instance, but better specified.
The I-D contains references to some of TBD1 to TBD11, with no indication
of what to do with them. Looking at the current registry it is apparent
that Early Allocation took place in 2018 and 2019. The I-D makes no
reference to this. Are all these values to be made permanent? Some of
them? I expect the I-D to say.
The I-D adds the value 'filter only' to one of the columns. The
registry was set up by RFC8152 which lists permitted values of which
this is not one. This then constitutes an update to RFC8152 which the
I-D does not mention.
The registry has five columns; this I-D adds a new one, Capabilities,
another update to RFC8152. What then happens to this column for
existing entries in the registry? The I-D is silent.
RFC8152 is Standards Track; this I-D which IMHO updates it is
Informational.
The IANA registry entry gives a reference of 'RFC8152'; this I-D, which
changes the specification of the registry, needs adding to that
reference.
RFC8126 recommends that IANA Considerations be for IANA, that IANA does
not have to search the rest of the document for the data it needs.
Here, the relevant data appears in three other sections as well (and
there is much in the I-D that is not relevant to IANA, it is not one of
those I-D that is only about IANA).
Abstract should be plain text -
[I-D.ietf-cose-rfc8152bis-struct]
does not look like plain text.
I have great faith in the ability of IANA to make sense of what they are
asked to do but do think that the more straightforward that is the
better. And then there are those that come after, who want the RFC to
say what happened and why without digging into the e-mail archives (as I
see happening now and again:-)
Tom Petch
----- Original Message -----
From: "IETF-Announce on behalf of The IESG"
<ietf-announce-bounces@ietf.orgiesg-secretary@xxxxxxxx>
To: <IETF-Announce>
Cc: <draft-ietf-cose-hash-algs@xxxxxxxx>; <cose-chairs@xxxxxxxx>;
<cose@xxxxxxxx>; <ivaylo@xxxxxxx>
Sent: Tuesday, May 12, 2020 4:26 PM
The IESG has received a request from the CBOR Object Signing and
Encryption
WG (cose) to consider the following document: - 'CBOR Object Signing
and
Encryption (COSE): Hash Algorithms'
<draft-ietf-cose-hash-algs-03.txt> as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2020-05-26. Exceptionally,
comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning
of the Subject line to allow automated sorting.
Abstract
The CBOR Object Signing and Encryption (COSE) syntax
[I-D.ietf-cose-rfc8152bis-struct] does not define any direct
methods
for using hash algorithms. There are however circumstances where
hash algorithms are used: Indirect signatures where the hash of one
or more contents are signed. X.509 certificate or other object
identification by the use of a fingerprint. This document defines
a
set of hash algorithms that are identified by COSE Algorithm
Identifiers.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
=
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
