[core] Ketan Talaulikar's Discuss on draft-ietf-core-href-25: (with DISCUSS and COMMENT)

[Ketan Talaulikar via Datatracker <[e-mail]>]

Ketan Talaulikar has entered the following ballot position for
draft-ietf-core-href-25: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-href/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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

I have just one point to discuss which is 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>.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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 []