Constrained Resource Identifiers
draft-ietf-core-href-30

# Andy Newton, ART AD, comments for draft-ietf-core-href-25
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-core-href-25.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

Many thanks to Arnt Gulbrandsen for his ARTART review.

## Comments

### Instructions to DEs

This would be a DISCUSS, except I don't have any good answers or suggestions myself.
Given the text below, I have concerns that the DEs are being given too much
subjective guidance. Is there no way to place some sort of measurements on these
criteria to make them more objective?

1586       The expert is instructed to be frugal in the allocation of CRI scheme
1587       number values whose scheme-id values (Section 5.1.1) have short
1588       representations (1+0 and 1+1 encoding), keeping them in reserve for
1589       applications that are likely to enjoy wide use and can make good use
1590       of their shortness.

and

1599       The expert exceptionally also may make such a registration for text
1600       strings that have not been registered in the Uniform Resource
1601       Identifier (URI) Schemes registry if and only if the expert considers
1602       them to be in wide use in place of URI scheme names in constrained
1603       applications. ...

Thanks for addressing all my previous points (DISCUSS & COMMENT) at:
https://mailarchive.ietf.org/arch/msg/core/4f1WO_gQMqs6yTnm2gw_HcXRvmw/

Thankyou for this document. I do not see any issues from the perspective of the design of the transport protocol, and have no comments.

I note that Figure 1 in the PDF renders very small.

Thanks to the authors and the WG for their work on this document.

I am moving on previous point from the DISCUSS to COMMENT section based on the discussion on the telechat. This point is about the classification of URL references to the IANA registry-groups/registries being placed in normative references when they seem just informative to me.

[IANA.cbor-tags]
IANA, "Concise Binary Object Representation (CBOR) Tags", <https://www.iana.org/assignments/cbor-tags>.
[IANA.core-parameters]
IANA, "Constrained RESTful Environments (CoRE) Parameters", <https://www.iana.org/assignments/core-parameters>.
[IANA.media-type-sub-parameters]
IANA, "Media Type Sub-Parameter Registries", <https://www.iana.org/assignments/media-type-sub-parameters>.
[IANA.uri-schemes]
IANA, "Uniform Resource Identifier (URI) Schemes", <https://www.iana.org/assignments/uri-schemes>.

I support the DISCUSS position from Orie. It seems like this document is introducing a parallel registry when it could perhaps be folded into the existing one.

I also have a few comments and suggestions:

1) The URL reference to [IANA.cbor-diagnostic-notation] is missing

2) The use of BCPs instead of the specific RFCs in this document is different from what I've seen normally. I think the reference to specific RFCs directly is more helpful.

3) The BCP14 boilerplate is not accurate - there is the use of () instead of []

I support Orie's DISCUSS. Although perhaps the two registries can be lazily linked? Only allow entries that already have a name in the URI registry, but only register them on request in the CRI registry?

Thank you to Joel Halpern for the GENART review.