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

[Ballot comment]
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", .
[IANA.core-parameters]
IANA, "Constrained RESTful Environments (CoRE) Parameters", .
[IANA.media-type-sub-parameters]
IANA, "Media Type Sub-Parameter Registries", .
[IANA.uri-schemes]
IANA, "Uniform Resource Identifier (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 []

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-core-href-25
CC @evyncke

Thank you for the work put into this document. This is smart and elegant.

Please find below one blocking DISCUSS (trivial to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Thomas Fossati for the shepherd's detailed write-up including the WG consensus *but* the justification of the intended status is rather light.

Please note that Loganaden Velvindron is the IoT directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-core-href/reviewrequest/22815/

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 11.3

As indicated by the idnits tool, the actual reference for [IANA.cbor-diagnostic-notation] is missing.

[Ballot comment]

## COMMENTS (non-blocking)

### Support for Orie Steele DISCUSS

I support Orie's DISCUSS about having 2 registries.

### Section 2.1

In `In a CRI reference, components can additionally be _not set_` 'not set' is in italics but is not a term defined in this document (per section 1.1) as far as I can tell.

`Future versions of IP are not supported` this brings a smile on my face ;-) You made my day !

### Section 2.2

Is there a reason why `.` and `..` are not quoted in this section while there were previously ?

Who is is "we" in `we instead add in a discard component` (and other places) ? The authors ? The CORE WG ? The IETF ? Please avoid using ambiguous terms in a PS.

[Ballot comment]
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?

[Ballot comment]
# 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. ...

[Ballot 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", .
[IANA.core-parameters]
IANA, "Constrained RESTful Environments (CoRE) Parameters", .
[IANA.media-type-sub-parameters]
IANA, "Media Type Sub-Parameter Registries", .
[IANA.uri-schemes]
IANA, "Uniform Resource Identifier (URI) Schemes", .

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

[Ballot comment]
Hi Carsten and Henk,

Thank you for the work put into this specification.

This is a great piece of work. Appreciate in particular the alignment with I-D.ietf-netmod-rfc6991-bis for zone identifiers.

Cheers,
Med

[Ballot discuss]
# Orie Steele, ART AD, comments for draft-ietf-core-href-25
CC @OR13

* 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/

## Discuss

### Designated experts

```
1592   When the expert notices that a registration has been made in the
1593   Uniform Resource Identifier (URI) Schemes registry (see also
1594   Section 11.2), the expert is requested to initiate a parallel
1595   registration in the CRI Scheme Numbers registry.  CRI scheme number
```

It seems likely that this will not happen (eventually).
And further, that there is high probability that one day a URI and CRI will have similar names, while being otherwise unrelated.

Per:

```
1614   A registration in the CRI Scheme Numbers registry does not imply that
1615   a URI scheme under this name exists or has been registered in the
1616   Uniform Resource Identifier (URI) Schemes registry -- it essentially
1617   is only providing an integer identifier for an otherwise
1618   uninterpreted text string.
```

Would it not be better to have a single registry, and just add a column for integer values?

Keeping 2 registries in sync via expert review and a "note" seems doomed to fail.

[Ballot comment]

## Comments

Thanks to Arnt Gulbrandsen for the ARTART review.
And to the authors for addressing his comments.
...and to idnits 2.17.1 for complaining about lines appearing to long due to UTF-8 encoding.

[Ballot comment]
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.

# Document Shepherd Write-Up for CoRE Constrained Resource Identifiers (CRI)

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
This document has quite a long history.
Its incubation began in the Thing-to-Thing RG about eight years ago.
Shortly after, it was adopted by the CoRE WG.
While it was paused for a time, over the past four years it has been developed by a very committed design team that has held fortnightly calls and made regular reports to the CoRE WG at various interims and face-to-face meetings.

The consensus represents the *very* strong agreement among a few individuals (the DT and a small group of dedicated reviewers).

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This specification has been the subject of extensive and detailed discussion over an extended period.
No instances of controversy have been raised that I am aware of.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No. I reviewed the mailing list conversations and meeting minutes, but found no such indication.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, there are three independent open-source implementations (in Rust, Python and Go) listed in the Implementation Status section.
Another (currently PoC) implementation in Ruby exists but is not listed in the document.

The editors and early implementers developed a [test suite][18] based on the specification, which has served (and will serve) as an interop & coordination tool for (future) implementers.
 
## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

It's hard to predict who will consume this specification, beyond the obvious target, the IoT community.
Some inherent constraints (i.e., the C in CRI) may limit widespread adoption, but there is also an extensibility story baked into the data model that may allow it to gain a larger footprint in the future.
At this point, I don’t see a need for a wider review pool than the usual directorates, but more eyes are always better.
Two critical directorates to involve and ask for *robust* reviews are ARTART and Iotdir.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
The data format is expressed using CDDL. This document should be reviewed by an ideal "CDDL Fairies" team, which at present is merely a fantasy. However, Carsten, being at the same time CDDL's Fairy Godmother and editor of this document, gives me confidence that there can't be substantial problems.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

There is no YANG in this document.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks are available. I have manually verified that the [CDDL definition][19] holds tight and that the examples in [§5.1.3][20] validate against it, after applying the "augmented rules for interchange" described in prose in [§5.1][21].

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

ARTART is the obvious candidate for an in-depth review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the correct stream for this document according to the definition in RFC2026.
All the relevant DT attributes are in order.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

No IPR has been disclosed (for now).

An [email][22] has been sent to the authors and the mailing list.

Both authors (Carsten and Henk) confirm they are not personally aware of any patent claims that would read on this specification.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There are two authors and two contributors.

All but one of the contributors, Klaus, who hasn't yet replied to [my email][23], confirm their willingness to be listed as author/editor/contributor.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No meaningful nits remain.

There are two nits worth an explanation:

>  == Missing Reference: 'I-D.bormann-cbor-draft-numbers' is mentioned on line
>    2037, but not defined

This is in a note to IANA.  It's safe to ignore: it'll be deleted before/when the RFC editor sees it.

>  -- Obsolete informational reference (is this intentional?): RFC 3490
>    (Obsoleted by RFC 5890, RFC 5891)

`ToASCII` is defined in RFC3490. Though many documents refer to 5890 for its definition, it’s not there. Hence the pointer to the previous revision.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
All normative references are freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No, there aren't.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
   
No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document creates the new "CRI Scheme Numbers" Registry.
All the registry bootstrapping aspects are correctly covered.
This document updates the "Uniform Resource Identifier (URI) Schemes" Registry by adding a note to link it with the new "CRI Scheme Numbers" Registry.
The rest are "usual" registrations in a few CBOR-, CoRE- and ACE-specific registries.
All look in good shape.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The new "CRI Scheme Numbers" Registry is under Expert Review policy.
The instructions for the Designated Experts look clear and thorough.
I don't have any DE candidates to suggest.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
[18]: https://github.com/core-wg/href/tree/main/tests
[19]: https://raw.githubusercontent.com/core-wg/href/refs/heads/main/cddl/cri.cddl
[20]: https://www.ietf.org/archive/id/draft-ietf-core-href-21.html#section-5.1.3
[21]: https://www.ietf.org/archive/id/draft-ietf-core-href-21.html#section-5.1-7
[22]: https://mailarchive.ietf.org/arch/msg/core/I9nxjvBIBTdaa7m9qOA6hvqvrLo/
[23]: https://mailarchive.ietf.org/arch/msg/core/Gxv-xt-Sk_VOBxq-o9gT2rQRXY4/

# Document Shepherd Write-Up for CoRE Constrained Resource Identifiers (CRI)

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
This document has quite a long history.
Its incubation began in the Thing-to-Thing RG about eight years ago.
Shortly after, it was adopted by the CoRE WG.
While it was paused for a time, over the past four years it has been developed by a very committed design team that has held fortnightly calls and made regular reports to the CoRE WG at various interims and face-to-face meetings.

The consensus represents the *very* strong agreement among a few individuals (the DT and a small group of dedicated reviewers).

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This specification has been the subject of extensive and detailed discussion over an extended period.
No instances of controversy have been raised that I am aware of.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No. I reviewed the mailing list conversations and meeting minutes, but found no such indication.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, there are three independent open-source implementations (in Rust, Python and Go) listed in the Implementation Consideration section.
Another (currently PoC) implementation in Ruby exists but is not listed in the document.

The editors and early implementers developed a [test suite][18] based on the specification, which has served (and will serve) as an interop & coordination tool for (future) implementers.
 
## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

It's hard to predict who will consume this specification, beyond the obvious target, the IoT community.
Some inherent constraints (i.e., the C in CRI) may limit widespread adoption, but there is also an extensibility story baked into the data model which may allow it to gain a larger footprint in the future.
At this point, I don’t see a need for a wider review pool than the usual directorates, but more eyes are always better.
Two critical directorates to involve and ask for *robust* reviews are ARTART and Iotdir.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
The data format is expressed using CDDL. This document should be reviewed by an ideal "CDDL Fairies" team, which at present is merely a fantasy. However, Carsten, being at the same time CDDL's Fairy Godmother and editor of this document, gives me confidence that there can't be substantial problems.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

There is no YANG in this document.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks are available. I have manually verified that the [CDDL definition][19] holds tight and that the examples in [§5.1.3][20] validate against it, after applying the "augmented rules for interchange" described in prose in [§5.1][21].

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

ARTART is the obvious candidate for an in-depth review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the correct stream for this document according to the definition in RFC2026.
All the relevant DT attributes are in order.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

No IPR has been disclosed (for now).

An [email][22] has been sent to the authors and the mailing list.

Both authors (Carsten and Henk) confirm they are not personally aware of any patent claims that would read on this specification.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There are two authors and two contributors.

All but one of the contributors, Klaus, who hasn't yet replied to [my email][23], confirm their willingness to be listed as author/editor/contributor.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No meaningful nits remain.

There are two nits worth an explanation:

>  == Missing Reference: 'I-D.bormann-cbor-draft-numbers' is mentioned on line
>    2037, but not defined

This is in a note to IANA.  It's safe to ignore: it'll be deleted before/when the RFC editor sees it.

>  -- Obsolete informational reference (is this intentional?): RFC 3490
>    (Obsoleted by RFC 5890, RFC 5891)

`ToASCII` is defined in RFC3490. Though many documents refer to 5890 for its definition, it’s not there. Hence the pointer to the previous revision.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
All normative references are freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No, there aren't.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
   
No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document creates the new "CRI Scheme Numbers" Registry.
All the registry bootstrapping aspects are correctly covered.
This document updates the "Uniform Resource Identifier (URI) Schemes" Registry by adding a note to link it with the new "CRI Scheme Numbers" Registry.
The rest are "usual" registrations in a few CBOR-, CoRE- and ACE-specific registries.
All look in good shape.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The new "CRI Scheme Numbers" Registry is under Expert Review policy.
The instructions for the Designated Experts look clear and thorough.
I don't have any DE candidates to suggest.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
[18]: https://github.com/core-wg/href/tree/main/tests
[19]: https://raw.githubusercontent.com/core-wg/href/refs/heads/main/cddl/cri.cddl
[20]: https://www.ietf.org/archive/id/draft-ietf-core-href-21.html#section-5.1.3
[21]: https://www.ietf.org/archive/id/draft-ietf-core-href-21.html#section-5.1-7
[22]: https://mailarchive.ietf.org/arch/msg/core/I9nxjvBIBTdaa7m9qOA6hvqvrLo/
[23]: https://mailarchive.ietf.org/arch/msg/core/Gxv-xt-Sk_VOBxq-o9gT2rQRXY4/

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-core-href-23. If any part of this review is inaccurate, please let us know.

IANA understands that one of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document:

draft-ietf-cbor-edn-literals

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are seven actions which we must complete.

First, a new registry will be created called the CRI Scheme Numbers registry. The new registry will be located in the Constrained RESTful Environments (CoRE) Parameters registry group located at:

https://www.iana.org/assignments/core-parameters/

The new registry will be managed via Expert Review as defined by RFC8126.

There are initial registrations in the new registry as defined in Appendix C of the current draft. All of the initial registrations provided in Appendix C will have a reference of [ RFC-to-be ].

Second, in the Uniform Resource Identifier (URI) Schemes registry located at:

https://www.iana.org/assignments/uri-schemes/

a new note will be added to the registry as follows:

The CRI Scheme Numbers Registry registers numeric identifiers for what essentially are URI Scheme names. Registrants for the Uniform Resource Identifier (URI) Schemes Registry are requested to make a parallel registration in the CRI Scheme Numbers registry. The number for this registration will be assigned by the Designated Expert for that registry.

Third, in the Application-Extension Identifiers registry in the CBOR Diagnostic Notation registry group that is to be created upon approval of another draft:

draft-ietf-cbor-edn-literals

a single new registration will be made as follows:

Application-extension Identifier: cri
Description: Constrained Resource Identifier
Change Controller: IETF
Reference: [ RFC-to-be; Appendix B ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request once draft-ietf-cbor-edn-literals has been approved and the new registry has been created. This review must be completed before the document's IANA state can be changed to "IANA OK."

Fourth, in the CBOR Tags registry located at:

https://www.iana.org/assignments/cbor-tags/

a single new registration will be made as follows:

Tag: [ TBD-at-Registration ]
Data Item: array
Semantics: CRI Reference
Reference: [ RFC-to-be ]
Template:

IANA notes that a value of 99 has been suggested by the authors for this tag.

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

Fifth, in the CoAP Option Numbers registry in the Constrained RESTful Environments (CoRE) Parameters registry group located at:

https://www.iana.org/assignments/core-parameters/

two new registrations will be made as follows:

Number: [ TBD-at-Registration ]
Name: Proxy-Cri
Reference: [ RFC-to-be ]

Number: [ TBD-at-Registration ]
Name: Proxy-Scheme-Number
Reference: [ RFC-to-be ]

IANA notes that values of 235 and 239 have been suggested for these new registrations.

Sixth, in the Sub-Parameter Registry for application/aif+cbor and application/aif+json registry in the Media Type Sub-Parameter Registries registry group located at:

https://www.iana.org/assignments/media-type-sub-parameters/

a single new registration will be made as follows:

Parameter: Toid
Name: CRI-local-part
Description/Specification: local-part of CRI
Reference: [ RFC-to-be; Section 8.3 ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Seventh, in the CoAP Content-Formats registry in the Constrained RESTful Environments (CoRE) Parameters registry located at:

https://www.iana.org/assignments/core-parameters/

a single new registration will be made as follows:

Content Type: application/aif+cbor;Toid=CRI-local-part
Content Coding:
Media Type:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA Question --> What is the Media Type for this new registration? application/aif+cbor?

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-07-29):

From: The IESG
To: IETF-Announce
CC: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-href@ietf.org, mbishop@evequefou.be, thomas.fossati@linaro.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Constrained Resource Identifiers) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'Constrained Resource
Identifiers'
  as Proposed Standard

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@ietf.org mailing lists by 2025-07-29. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Constrained Resource Identifier (CRI) is a complement to the
  Uniform Resource Identifier (URI) that represents the URI components
  in Concise Binary Object Representation (CBOR) rather than as a
  sequence of characters.  This approach simplifies parsing,
  comparison, and reference resolution in environments with severe
  limitations on processing power, code size, and memory size.

  This RFC updates RFC 7595 to add a note on how the "URI Schemes"
  registry of RFC 7595 cooperates with the "CRI Scheme Numbers"
  registry created by the present RFC.


  // (This "cref" paragraph will be removed by the RFC editor:) The
  // present revision –23 attempts to address the AD review comments;
  // it is submitted right before the I-D deadline in order to serve as
  // discussion input to IETF 123 even though not all discussions have
  // completed.  In particular, the updated handling of zone
  // identifiers requires some additional scrutiny.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-href/



No IPR declarations have been submitted directly on this I-D.

Thanks for the careful work on this document so far. I have one high-level issue, several smaller comments, and a few nits.

I can see this has been the work of many years, which probably results directly in my biggest observation.  This document relies on a few now-obsolete documents, which may need simple pointer updates or may need more drastic changes:
RFC6874 is being obsoleted by draft-ietf-6man-zone-ui, including reverting its updates to RFC3986. As 6.1 notes, the doc needs to be updated with the outcome of this "currently in flux" situation before it ships. The existing statement references a document (draft-carpenter-6man-rfc6874bis) which was subsequently adopted by the 6man WG, then submitted to the IESG but not published. The obvious questions are:
Given that this is CBOR, could we use RFC9164 Address tags to handle the IPv4/v6 case?
If not, given that the contents of the CRI are not percent-encoded, the representation from RFC4007 Section 11 is less problematic than in URIs.
Include a reference to draft-ietf-6man-zone-ui and remove the references to RFC6874.
Also consider whether a link to draft-schinazi-httpbis-link-local-uri-bcp would be useful; it's an unadopted I-D, but contains useful context and history around the problem.
Sections 8.1.x may need updates as part of this.
This document references Unicode 13, but Unicode 16 is the most current. Let's update to 16 before shipping unless there's a reason not to.
Given that RFC3490 is deprecated, is this still the best reference for ToASCII in Section 6.1? I would think there would be a newer one in the obsoleting documents, but I didn't find one on cursory inspection.

My remaining observations are much more minor.

In Section 1, I'm not sure the "aperçu" adds much; consider rewording.

In Section 1.1, I believe the term "italics" is generally used for this formatting. (See https://creativemarket.com/blog/difference-cursive-script-italic-oblique) Regardless, consider using the glossary formatting for this instead, which would make instances of the word link to the relevant definition.

In Section 2, C10, consider defining "query parameter", since while it is a commonly used term in the web space, it is not a defined term in RFC3986. It's perhaps worth being more explicit that this spec optimizes for the common convention of key=value pairs joined by ampersands in query parameters, but that's not mandated by either 3986 or this document. (You can just have a single element in your array containing whatever query string you need.)

In Section 3, we have "...it may need to apply the following (and only the following) normalizations to get the CRI more likely to validate:"  Does this need 2119 language? Perhaps implementations MUST NOT apply normalizations other than the following? MAY/SHOULD apply the following but MUST NOT apply any others?

Also in Section 3, the reference to NFC points to C5, but NFC is only referenced by C0. Consider spelling out Normalization Form C here in the second and fourth bullets. Are the links to C9-C11 in the fourth bullet relevant, given that they don't specify NFC form? (Or should they?)

Should Section 4 call out that different orderings of query components may be equivalent to some applications but will be distinct in this algorithm?

In Section 5.1.1, rearrange the first sentence to be clear whether the "or" attaches to "scheme-id" or "scheme-number".

In Section 5.2.1, we have "CRIs that do not use indefinite length encoding, as mandated in Section 5.1." Is "mandated" the correct term? 5.1 says that it is RECOMMENDED not to allow indefinite-length encodings, which means they could potentially exist.

In Section 5.3, how does the fragment from the reference get into the resolved CRI? Step 5 would copy it, but then set it to null if there were any query elements.

Section 6.1 is titled to refer to CRIs and URIs, but the entire text talks about CRI references and URI references. The title suggests this section should be about base CRIs and URIs, with the sentence immediately before the heading making it apply equivalently to references? Or if not, perhaps reverse the equivalence text.

In 8.1.1, will the deep link in Step 4 be usable in the text version? If not, is there a better way to render this? I would have no idea how to identify "Paragraph 2.4.6" if it weren't a hyperlink.

In Sections 8.2.x and 11.5, is IANA being requested to allocate 235/239? If so, perhaps say that; regardless, the RFC Editor should be requested to update the placeholders with the values allocated by IANA. (Similar to the note in 11.4.)

In Section 11.1.1, is there precedent for the DE being the one to initiate registry updates, or directed to watch another registry? Should IANA be directed to notify the DE of new registrations in the URI Scheme registry? Would it make more sense to update the URI Scheme registry to add a CRI Scheme Number column so registrations are automatic?

In Section 11.1.2, since the registrant of the CRI Scheme Number will potentially be the DE, should this be the registrant of the URI Scheme? Is there any interaction with the URI Scheme registrant to confirm that they want this?

Section 11.2's request for the URI registrant to make a parallel request is potentially duplicative with Section 11.1.1's direction for the DE to do the registration. Have we talked with IANA about streamlining this?

Appendix A could perhaps use a clearer title. "Examples" doesn't really fit since it's not intended to show normal cases, though adding a few normal-case examples might be one option.

===NITS FOLLOW===

2, C7: "is defining" => "defines"

5, last paragraph - "respective CRI" => "respective CRIs"

5.2.1 - "in there" => "therein"

6.1 - "the ToASCII procedure Section 4.1 of [RFC3490]" => "the ToASCII procedure from Section 4.1 of [RFC3490]"

# Document Shepherd Write-Up for CoRE Constrained Resource Identifiers (CRI)

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
This document has quite a long history.
Its incubation began in the Thing-to-Thing RG about eight years ago.
Shortly after, it was adopted by the CoRE WG.
While it was paused for a time, over the past four years it has been developed by a very committed design team that has held fortnightly calls and made regular reports to the CoRE WG at various interims and face-to-face meetings.

The consensus represents the *very* strong agreement among a few individuals (the DT and a small group of dedicated reviewers).

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This specification has been the subject of extensive and detailed discussion over an extended period.
No instances of controversy have been raised that I am aware of.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No. I reviewed the mailing list conversations and meeting minutes but found no such indication.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, there are three independent open-source implementations (in Rust, Python and Go) listed in the Implementation Consideration section.
Another (currently PoC) implementation in Ruby exists but is not listed in the document.

The editors and early implementers developed a [test suite][18] based on the specification, which has served (and will serve) as an interop & coordination tool for (future) implementers.
 
## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

It's hard to predict who will consume this specification, beyond the obvious target, the IoT community.
Some inherent constraints (i.e., the C in CRI) may limit widespread adoption, but there is also an extensibility story baked into the data model which may allow it to gain a larger footprint in the future.
At this point, I don’t see a need for a wider review pool than usual directorates, but more eyes are always better.
Two critical directorates to involve and ask for *robust* reviews are ARTART and Iotdir.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
The data format is expressed using CDDL. This document should be reviewed by an ideal "CDDL Fairies" team, which at present is merely a fantasy. However, Carsten being at the same time CDDL's Fairy Godmother and editor of this document gives me confidence that there can't be substantial problems.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

There is no YANG in this document.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks are available. I have manually verified that the [CDDL definition][19] holds tight and that the examples in [§5.1.3][20] validate against it, after applying the "augmented rules for interchange" described in prose in [§5.1][21].

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

ARTART is the obvious candidate for an in-depth review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the correct stream for this document.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

No IPR has been disclosed (for now).

An [email][22] has been sent to the authors and the mailing list.

Both authors (Carsten and Henk) confirm they are not personally aware of any patent claims that would read on this specification.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There are two authors and two contributors.

All but one of the contributors, Klaus, who hasn't yet replied to [my email][23], confirm their willingness to be listed as author/editor/contributor.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No meaningful nits remain.

There are two nits worth an explanation:

>  == Missing Reference: 'I-D.bormann-cbor-draft-numbers' is mentioned on line
>    2037, but not defined

This is in a note to IANA.  It's safe to ignore: it'll be deleted before/when the RFC editor sees it.

>  -- Obsolete informational reference (is this intentional?): RFC 3490
>    (Obsoleted by RFC 5890, RFC 5891)

`ToASCII` is defined in RFC3490. Though many documents refer to 5890 for its definition, it’s not there. Hence the pointer to the previous revision.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
All normative references are freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No, there aren't.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
   
No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document creates the new "CRI Scheme Numbers" Registry.
All the registry bootstrapping aspects are correctly covered.
This document updates the "Uniform Resource Identifier (URI) Schemes" Registry by adding a note to link it with the new "CRI Scheme Numbers" Registry.
The rest are "usual" registrations in a few CBOR-, CoRE- and ACE-specific registries.
All look in good shape.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The new "CRI Scheme Numbers" Registry is under Expert Review policy.
The instructions for the Designated Experts look clear and thorough.
I don't have any DE candidates to suggest.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
[18]: https://github.com/core-wg/href/tree/main/tests
[19]: https://raw.githubusercontent.com/core-wg/href/refs/heads/main/cddl/cri.cddl
[20]: https://www.ietf.org/archive/id/draft-ietf-core-href-21.html#section-5.1.3
[21]: https://www.ietf.org/archive/id/draft-ietf-core-href-21.html#section-5.1-7
[22]: https://mailarchive.ietf.org/arch/msg/core/I9nxjvBIBTdaa7m9qOA6hvqvrLo/
[23]: https://mailarchive.ietf.org/arch/msg/core/Gxv-xt-Sk_VOBxq-o9gT2rQRXY4/

# Document Shepherd Write-Up for CoRE Constrained Resource Identifiers (CRI)

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
This document has quite a long history.
Its incubation began in the Thing-to-Thing RG about eight years ago.
Shortly after, it was adopted by the CoRE WG.
While it was paused for a time, over the past four years it has been developed by a very committed design team that has held fortnightly calls and made regular reports to the CoRE WG at various interims and face-to-face meetings.

The consensus represents the *very* strong agreement among a few individuals (the DT and a small group of dedicated reviewers).

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This specification has been the subject of extensive and detailed discussion over an extended period.
No instances of controversy have been raised that I am aware of.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No. I reviewed the mailing list conversations and meeting minutes but found no such indication.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, there are three independent open-source implementations (in Rust, Python and Go) listed in the Implementation Consideration section.
Another (currently PoC) implementation in Ruby exists but is not listed in the document.

The editors and early implementers developed a [test suite][18] based on the specification, which has served (and will serve) as an interop & coordination tool for (future) implementers.
 
## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

It's hard to predict who will consume this specification, beyond the obvious target, the IoT community.
Some inherent constraints (i.e., the C in CRI) may limit widespread adoption, but there is also an extensibility story baked into the data model which may allow it to gain a larger footprint in the future.
At this point, I don’t see a need for a wider review pool than usual directorates, but more eyes are always better.
Two critical directorates to involve and ask for *robust* reviews are ARTART and Iotdir.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
The data format is expressed using CDDL. This document should be reviewed by an ideal "CDDL Fairies" team, which at present is merely a fantasy. However, Carsten being at the same time CDDL's Fairy Godmother and editor of this document gives me confidence that there can't be substantial problems.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

There is no YANG in this document.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks are available. I have manually verified that the [CDDL definition][19] holds tight and that the examples in [§5.1.3][20] validate against it, after applying the "augmented rules for interchange" described in prose in [§5.1][21].

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

ARTART is the obvious candidate for an in-depth review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the correct stream for this document.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

No IPR has been disclosed (for now).

An [email][22] has been sent to the authors and the mailing list.

Both authors (Carsten and Henk) confirm they are not personally aware of any patent claims that would read on this specification.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There are two authors and two contributors.

All but one of the contributors, Klaus, who hasn't yet replied to [my email][23], confirm their willingness to be listed as author/editor/contributor.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No meaningful nits remain.

There are two nits worth an explanation:

>  == Missing Reference: 'I-D.bormann-cbor-draft-numbers' is mentioned on line
>    2037, but not defined

This is in a note to IANA.  It's safe to ignore: it'll be deleted before/when the RFC editor sees it.

>  -- Obsolete informational reference (is this intentional?): RFC 3490
>    (Obsoleted by RFC 5890, RFC 5891)

`ToASCII` is defined in RFC3490. Though many documents refer to 5890 for its definition, it’s not there. Hence the pointer to the previous revision.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
All normative references are freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No, there aren't.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
   
No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document creates the new "CRI Scheme Numbers" Registry.
All the registry bootstrapping aspects are correctly covered.
This document updates the "Uniform Resource Identifier (URI) Schemes" Registry by adding a note to link it with the new "CRI Scheme Numbers" Registry.
The rest are "usual" registrations in a few CBOR-, CoRE- and ACE-specific registries.
All look in good shape.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The new "CRI Scheme Numbers" Registry is under Expert Review policy.
The instructions for the Designated Experts look clear and thorough.
I don't have any DE candidates to suggest.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
[18]: https://github.com/core-wg/href/tree/main/tests
[19]: https://raw.githubusercontent.com/core-wg/href/refs/heads/main/cddl/cri.cddl
[20]: https://www.ietf.org/archive/id/draft-ietf-core-href-21.html#section-5.1.3
[21]: https://www.ietf.org/archive/id/draft-ietf-core-href-21.html#section-5.1-7
[22]: https://mailarchive.ietf.org/arch/msg/core/I9nxjvBIBTdaa7m9qOA6hvqvrLo/
[23]: https://mailarchive.ietf.org/arch/msg/core/Gxv-xt-Sk_VOBxq-o9gT2rQRXY4/

# Document Shepherd Write-Up for CoRE Constrained Resource Identifiers (CRI)

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
This document has quite a long history.
Its incubation began in the Thing-to-Thing RG about eight years ago.
Shortly after, it was adopted by the CoRE WG.
While it was paused for a time, over the past four years it has been developed by a very committed design team that has held weekly calls and made regular reports to the CoRE WG at various interims and face-to-face meetings.

The consensus represents the *very* strong agreement among a few individuals (the DT and a small group of dedicated reviewers).

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This specification has been the subject of extensive and detailed discussion over an extended period.
No instances of controversy have been raised that I am aware of.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No. I reviewed the mailing list conversations and meeting minutes but found no such indication.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, there are three independent open-source implementations (in Rust, Python and Go) listed in the Implementation Consideration section.
Another (currently PoC) implementation in Ruby exists but is not listed in the document.

The editors and early implementers developed a [test suite][18] based on the specification, which has served (and will serve) as an interop & coordination tool for (future) implementers.
 
## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

It's hard to predict who will consume this specification, beyond the obvious target, the IoT community.
Some inherent constraints (i.e., the C in CRI) may limit widespread adoption, but there is also an extensibility story baked into the data model which may allow it to gain a larger footprint in the future.
At this point, I don’t see a need for a wider review pool than usual directorates, but more eyes are always better.
Two critical directorates to involve and ask for *robust* reviews are ARTART and Iotdir.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
The data format is expressed using CDDL. This document should be reviewed by an ideal "CDDL Fairies" team, which at present is merely a fantasy. However, Carsten being at the same time CDDL's Fairy Godmother and editor of this document gives me confidence that there can't be substantial problems.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

There is no YANG in this document.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks are available. I have manually verified that the [CDDL definition][19] holds tight and that the examples in [§5.1.3][20] validate against it, after applying the "augmented rules for interchange" described in prose in [§5.1][21].

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

ARTART is the obvious candidate for an in-depth review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the correct stream for this document.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

No IPR has been disclosed (for now).

An [email][22] has been sent to the authors and the mailing list.

Both authors (Carsten and Henk) confirm they are not personally aware of any patent claims that would read on this specification.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There are two authors and two contributors.

All but one of the contributors, Klaus, who hasn't yet replied to [my email][23], confirm their willingness to be listed as author/editor/contributor.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No meaningful nits remain.

There are two nits worth an explanation:

>  == Missing Reference: 'I-D.bormann-cbor-draft-numbers' is mentioned on line
>    2037, but not defined

This is in a note to IANA.  It's safe to ignore: it'll be deleted before/when the RFC editor sees it.

>  -- Obsolete informational reference (is this intentional?): RFC 3490
>    (Obsoleted by RFC 5890, RFC 5891)

`ToASCII` is defined in RFC3490. Though many documents refer to 5890 for its definition, it’s not there. Hence the pointer to the previous revision.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
All normative references are freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No, there aren't.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
   
No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document creates the new "CRI Scheme Numbers" Registry.
All the registry bootstrapping aspects are correctly covered.
This document updates the "Uniform Resource Identifier (URI) Schemes" Registry by adding a note to link it with the new "CRI Scheme Numbers" Registry.
The rest are "usual" registrations in a few CBOR-, CoRE- and ACE-specific registries.
All look in good shape.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The new "CRI Scheme Numbers" Registry is under Expert Review policy.
The instructions for the Designated Experts look clear and thorough.
I don't have any DE candidates to suggest.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
[18]: https://github.com/core-wg/href/tree/main/tests
[19]: https://raw.githubusercontent.com/core-wg/href/refs/heads/main/cddl/cri.cddl
[20]: https://www.ietf.org/archive/id/draft-ietf-core-href-21.html#section-5.1.3
[21]: https://www.ietf.org/archive/id/draft-ietf-core-href-21.html#section-5.1-7
[22]: https://mailarchive.ietf.org/arch/msg/core/I9nxjvBIBTdaa7m9qOA6hvqvrLo/
[23]: https://mailarchive.ietf.org/arch/msg/core/Gxv-xt-Sk_VOBxq-o9gT2rQRXY4/

# Document Shepherd Write-Up for CoRE Constrained Resource Identifiers (CRI)

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
This document has quite a long history.
Its incubation began in the Thing-to-Thing RG about eight years ago.
Shortly after, it was adopted by the CoRE WG.
While it was paused for a time, over the past four years it has been developed by a very committed design team that has held weekly calls and made regular reports to the CoRE WG at various interims and face-to-face meetings.

The consensus represents the *very* strong agreement among a few individuals (the DT and a small group of dedicated reviewers).

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This specification has been the subject of extensive and detailed discussion over an extended period.
No instances of controversy have been raised that I am aware of.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No. I reviewed the mailing list conversations and meeting minutes but found no such indication.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, there are three independent open-source implementations (in Rust, Python and Go) listed in the Implementation Consideration section.
Another (currently PoC) implementation in Ruby exists but is not listed in the document.

The editors and early implementers developed a [test suite][20] based on the specification, which has served (and will serve) as an interop & coordination tool for (future) implementers.
 
## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

It's hard to predict who will consume this specification, beyond the obvious target, the IoT community.
Some inherent constraints (i.e., the C in CRI) may limit widespread adoption, but there is also an extensibility story baked into the data model which may allow it to gain a larger footprint in the future.
At this point, I don’t see a need for a wider review pool than usual directorates, but more eyes are always better.
Two critical directorates to involve and ask for *robust* reviews are ARTART and Iotdir.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
The data format is expressed using CDDL. This document should be reviewed by an ideal "CDDL Fairies" team, which at present is merely a fantasy. However, Carsten being at the same time CDDL's Fairy Godmother and editor of this document gives me confidence that there can't be substantial problems.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

There is no YANG in this document.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks are available. I have manually verified that the [CDDL definition][21] holds tight and that the examples in [§5.1.3][22] validate against it, after applying the "augmented rules for interchange" described in prose in [§5.1][23].

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

ARTART is the obvious candidate for an in-depth review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the correct stream for this document.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

No IPR has been disclosed (for now).

An [email][24] has been sent to the authors and the mailing list.

Both authors (Carsten and Henk) confirm they are not personally aware of any patent claims that would read on this specification.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There are two authors and two contributors.

All but one of the contributors, Klaus, who hasn't yet replied to [my email][25], confirm their willingness to be listed as author/editor/contributor.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No meaningful nits remain.

There are two nits worth an explanation:

>  == Missing Reference: 'I-D.bormann-cbor-draft-numbers' is mentioned on line
>    2037, but not defined

This is in a note to IANA.  It's safe to ignore: it'll be deleted before/when the RFC editor sees it.

>  -- Obsolete informational reference (is this intentional?): RFC 3490
>    (Obsoleted by RFC 5890, RFC 5891)

`ToASCII` is defined in RFC3490. Though many documents refer to 5890 for its definition, it’s not there. Hence the pointer to the previous revision.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
All normative references are freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No, there aren't.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
   
No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document creates the new "CRI Scheme Numbers" Registry.
All the registry bootstrapping aspects are correctly covered.
This document updates the "Uniform Resource Identifier (URI) Schemes" Registry by adding a note to link it with the new "CRI Scheme Numbers" Registry.
The rest are "usual" registrations in a few CBOR-, CoRE- and ACE-specific registries.
All look in good shape.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The new "CRI Scheme Numbers" Registry is under Expert Review policy.
The instructions for the Designated Experts look clear and thorough.
I don't have any DE candidates to suggest.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

[20]: https://github.com/core-wg/href/tree/main/tests
[21]: https://raw.githubusercontent.com/core-wg/href/refs/heads/main/cddl/cri.cddl
[22]: https://www.ietf.org/archive/id/draft-ietf-core-href-21.html#section-5.1.3
[23]: https://www.ietf.org/archive/id/draft-ietf-core-href-21.html#section-5.1-7
[24]: https://mailarchive.ietf.org/arch/msg/core/I9nxjvBIBTdaa7m9qOA6hvqvrLo/
[25]: https://mailarchive.ietf.org/arch/msg/core/Gxv-xt-Sk_VOBxq-o9gT2rQRXY4/

# Document Shepherd Write-Up for CoRE Constrained Resource Identifiers (CRI)

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
 
This document has quite a long history.
Its incubation began in the Thing-to-Thing RG about eight years ago.
Shortly after, it was adopted by the CoRE WG.
While it was paused for a time, over the past four years it has been developed by a very committed design team that has held weekly calls and made regular reports to the CoRE WG at various interims and face-to-face meetings.

The consensus represents the *very* strong agreement among a few individuals (the DT and a small group of dedicated reviewers).

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This specification has been the subject of extensive and detailed discussion over an extended period.
No instances of controversy have been raised that I am aware of.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No. I reviewed the mailing list conversations and meeting minutes but found no such indication.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, there are three independent open-source implementations (in Rust, Python and Go) listed in the Implementation Consideration section.
Another (currently PoC) implementation in Ruby exists but is not listed in the document.

The editors and early implementers developed a [test suite](https://github.com/core-wg/href/tree/main/tests) based on the specification, which has served (and will serve) as an interop & coordination tool for (future) implementers.
 
## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

It's hard to predict who will consume this specification, beyond the obvious target, the IoT community.
Some inherent constraints (i.e., the C in CRI) may limit widespread adoption, but there is also an extensibility story baked into the data model which may allow it to gain a larger footprint in the future.
At this point, I don’t see a need for a wider review pool than usual directorates, but more eyes are always better.
Two critical directorates to involve and ask for *robust* reviews are ARTART and Iotdir.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
 
The data format is expressed using CDDL. This document should be reviewed by an ideal "CDDL Fairies" team, which at present is merely a fantasy. However, Carsten being at the same time CDDL's Fairy Godmother and editor of this document gives me confidence that there can't be substantial problems.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

There is no YANG in this document.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks are available. I have manually verified that the [CDDL definition](https://raw.githubusercontent.com/core-wg/href/refs/heads/main/cddl/cri.cddl) holds tight and that the examples in [§5.1.3](https://www.ietf.org/archive/id/draft-ietf-core-href-21.html#section-5.1.3) validate against it, after applying the "augmented rules for interchange" described in prose in [§5.1](https://www.ietf.org/archive/id/draft-ietf-core-href-21.html#section-5.1-7).

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

ARTART is the obvious candidate for an in-depth review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the correct stream for this document.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

No IPR has been disclosed (for now).

An [email](https://mailarchive.ietf.org/arch/msg/core/I9nxjvBIBTdaa7m9qOA6hvqvrLo/) has been sent to the authors and the mailing list.

Both authors (Carsten and Henk) confirm they are not personally aware of any patent claims that would read on this specification.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There are two authors and two contributors.

All but one of the contributors, Klaus, who hasn't yet replied to [my email](https://mailarchive.ietf.org/arch/msg/core/Gxv-xt-Sk_VOBxq-o9gT2rQRXY4/), confirm their willingness to be listed as author/editor/contributor.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No meaningful nits remain.

There are two nits worth an explanation:

>  == Missing Reference: 'I-D.bormann-cbor-draft-numbers' is mentioned on line
>    2037, but not defined

This is in a note to IANA.  It's safe to ignore: it'll be deleted before/when the RFC editor sees it.

>  -- Obsolete informational reference (is this intentional?): RFC 3490
>    (Obsoleted by RFC 5890, RFC 5891)

`ToASCII` is defined in RFC3490. Though many documents refer to 5890 for its definition, it’s not there. Hence the pointer to the previous revision.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
All normative references are freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No, there aren't.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
   
No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document creates the new "CRI Scheme Numbers" Registry.
All the registry bootstrapping aspects are correctly covered.
This document updates the "Uniform Resource Identifier (URI) Schemes" Registry by adding a note to link it with the new "CRI Scheme Numbers" Registry.
The rest are "usual" registrations in a few CBOR-, CoRE- and ACE-specific registries.
All look in good shape.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The new "CRI Scheme Numbers" Registry is under Expert Review policy.
The instructions for the Designated Experts look clear and thorough.
I don't have any DE candidates to suggest.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/