Hi Gunter, even though this document has left the WG, let me quickly add a couple of observations to yours.
> My observation is that while the shepherd writeup claims nothing noteworthy > when running idnits, but when i run idnits > (https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-17.txt) > i end up with a long laundry list of observations. ...Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). > Maybe worthwhile to run > through the list and explain why they are deemed not meaningful/relevant and > add this context in the write-up? We could do that in the future. idnits has so many false positives that it is a chore to process its output. E.g., these “errors” (“**”) point to PKCS 9 and PKCS 10: ** Downref: Normative reference to an Informational RFC: RFC 2985 ** Downref: Normative reference to an Informational RFC: RFC 2986 These are frequent downrefs [1], with 13 [2] resp. 33 [3] normative references from other documents at this point: [1]: https://datatracker.ietf.org/doc/downref [2]: https://datatracker.ietf.org/doc/rfc2985/referencedby/ [3]: https://datatracker.ietf.org/doc/rfc2986/referencedby/ idnits could know that. I’ll leave ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) ** Obsolete normative reference: RFC 8398 (Obsoleted by RFC 9598) …to the authors; while the first one just points to the RFC with the original definition, it seems the other two could make use of the new specification. ** There are 43 instances of too long lines in the document, the longest one being 25 characters in excess of 72. …could also be addressed by the authors, either via RFC 8792 or by editing the unruly sourcecode, e.g., by adding a newline after a rule start that has an excessively long identifier. Most of the instances come from the formatter malfunction in Table 20. This may need to be addressed by the tools team/RPC. > One of those idnits observations is that there may only be v4 examples and no > v6 examples? This is actually a correct observation: There is one IPv4 example in Section 3.3 that is not accompanied by a IPv6 example. Looking at this document as a potential user, I consider this fine, as the principle explained here becomes quite clear from the IPv4 example. There are tons of constructs in the draft that may look like dotted-quads (IPv4 addresses) to a tool such as idnits but that are really ASN.1 Object Identifiers. I think this is where "42 instances of lines with non-RFC6890-compliant IPv4 addresses” comes from. Many programming languages have pragmas to suppress misleading warnings; it doesn’t seem easy to add such a feature to idnits but it will need to be done if idnits is to be taken more seriously by authors. Grüße, Carsten _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
