Semantic Definition Format (SDF) for Data and Interactions of Things
draft-ietf-asdf-sdf-18

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-asdf-sdf-18. If any part of this review is inaccurate, please let us know.

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

First, in the application namespace of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a single new registration will be made as follows:

Name: sdf+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

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

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

a single new registration is to be made from the IETF Review range of Ids (256-999) as follows:

Content Type: application/sdf+json
Content Coding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Third, in the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers registry in the Uniform Resource Name (URN) Namespace for IETF Use registry group located at:

https://www.iana.org/assignments/params/

Registered Parameter Identifier: unit
Reference: [ RFC-to-be ]
IANA Registry Reference: [ TBD-at-Registration ]

Fourth, a new registry group will be created with [ TBD-at-Registration ] as the reference. The name of the new registry group will be SDF Parameters.

Fifth, in the newly created SDF Parameters registry group, a new registry will be created called the Quality Name Prefixes registry. The new registry will be managed via Expert Review as defined in RFC8126.

There are no initial registrations in the new Quality Name Prefixes registry.

Sixth, also in the newly created SDF Parameters registry group, a new registry will be created called the sdfType Values registry. The new registry will be managed via Specification Required as defined in RFC8126.

There are two initial registrations in the new sdfType Values registry as follows:

Name: byte-string
Description: A sequence of zero or more bytes
type: string
JSON Representation: base64url without padding
Reference: [ RFC8949; Section 3.4.5.2 ]

Name: unix-time
Description: A point in civil time
type: number
JSON Representation: POSIX time
Reference: [ RFC8949; Section 3.4.2 ]

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 2024-05-22):

From: The IESG
To: IETF-Announce
CC: asdf-chairs@ietf.org, asdf@ietf.org, draft-ietf-asdf-sdf@ietf.org, francesca.palombini@ericsson.com, mcr+ietf@sandelman.ca
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Semantic Definition Format (SDF) for Data and Interactions of Things) to Proposed Standard


The IESG has received a request from the A Semantic Definition Format for
Data and Interactions of Things WG (asdf) to consider the following document:
- 'Semantic Definition Format (SDF) for Data and Interactions of Things'
  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 2024-05-22. 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 Semantic Definition Format (SDF) is a format for domain experts
  to use in the creation and maintenance of data and interaction models
  that describe Things, i.e., physical objects that are available for
  interaction over a network.  An SDF specification describes
  definitions of SDF Objects/SDF Things and their associated
  interactions (Events, Actions, Properties), as well as the Data types
  for the information exchanged in those interactions.  Tools convert
  this format to database formats and other serializations as needed.


  // The present revision (-18) adds security considerations, a few
  // editorial cleanups, discusses JSON pointer encodings, and adds
  // sockets to the CDDL for easier future extension.




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



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

Document Shepherd Write-Up for Group Documents: draft-ietf-asdf-sdf-18
(This draft template is dated 4 July 2022.)

Review updated 2024-03-13.

Document History
> Does the working group (WG) consensus represent the strong concurrence of a
> few individuals, with others being silent, or did it reach broad agreement?

The group is very small, but the document represents the consensus of the WG.

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

No controversy.

> Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> 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 recommends) or elsewhere
> (where)?

Yes, there are existing implementations.

>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.

There is some overlap with SENML in the CORE WG, and those people are in
common.  The rest of the overlap is with entities outside of the IETF, and
some of those interactions are well underway (and complete), and others
likely will not occur until after the RFC is published.

> Describe how the document meets any required formal expert review criteria,
> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Media type reviews for application/sdf+json and related Content-Format have
been requested.

>Document Shepherd Checks
>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?

The security considerations section has been completed since the first
shepherd review.

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

Standards Track is appropriate.

> Have reasonable efforts been made to remind all authors of the intellectual
> property rights (IPR) disclosure obligations described in BCP 79? 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.

Yes.

> 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.

Yes.

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

No important nits.

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

A review has been done, and it seems correct.

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

None.

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

no.

> 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.

> Will publication of this document change the status of any existing RFCs?
> If

No.

> Describe the document shepherd's review of the IANA considerations section,
> especially with regard to its consistency with the body of the document.

reviewed, seemed to be complete and included useful advice to Experts.

> 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.

Yes.
Experts TBD.

Document Shepherd Write-Up for Group Documents: draft-ietf-asdf-sdf-18
(This draft template is dated 4 July 2022.)

Review updated 2024-03-13.

Document History
> Does the working group (WG) consensus represent the strong concurrence of a
> few individuals, with others being silent, or did it reach broad agreement?

The group is very small, but the document represents the consensus of the WG.

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

No controversy.

> Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> 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 recommends) or elsewhere
> (where)?

Yes, there are existing implementations.

>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.

There is some overlap with SENML in the CORE WG, and those people are in
common.  The rest of the overlap is with entities outside of the IETF, and
some of those interactions are well underway (and complete), and others
likely will not occur until after the RFC is published.

> Describe how the document meets any required formal expert review criteria,
> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Media type reviews for application/sdf+json and related Content-Format have
been requested.

>Document Shepherd Checks
>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?

The security considerations section has been completed since the first
shepherd review.

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

Standards Track is appropriate.

> Have reasonable efforts been made to remind all authors of the intellectual
> property rights (IPR) disclosure obligations described in BCP 79? 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.

Yes.

> 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.

Yes.

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

No important nits.

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

A review has been done, and it seems correct.

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

None.

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

no.

> 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.

> Will publication of this document change the status of any existing RFCs?
> If

No.

> Describe the document shepherd's review of the IANA considerations section,
> especially with regard to its consistency with the body of the document.

reviewed, seemed to be complete and included useful advice to Experts.

> 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.

Yes.
Experts TBD.

Document Shepherd Write-Up for Group Documents: draft-ietf-asdf-sdf-18
This version is dated 4 July 2022.

Document History
> Does the working group (WG) consensus represent the strong concurrence of a
> few individuals, with others being silent, or did it reach broad agreement?

The group is very small, but the document represents the consensus of the WG.

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

No controversy.

> Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> 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 recommends) or elsewhere
> (where)?

Yes, there are existing implementations.

>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.

There is some overlap with SENML in the CORE WG, and those people are in
common.  The rest of the overlap is with entities outside of the IETF, and
some of those interactions are well underway (and complete), and others
likely will not occur until after the RFC is published.

> Describe how the document meets any required formal expert review criteria,
> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None required.

>Document Shepherd Checks
>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?

The security considerations section has been completed since the first
shepherd review.

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

Standards Track is appropriate.

> Have reasonable efforts been made to remind all authors of the intellectual
> property rights (IPR) disclosure obligations described in BCP 79? 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.

Yes.

> 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.

Yes.

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

No important nits.

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

Yes.

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

None.

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

no.

> 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.

> Will publication of this document change the status of any existing RFCs?
> If

No.

> Describe the document shepherd's review of the IANA considerations section,
> especially with regard to its consistency with the body of the document.

reviewed, seemed to be complete and included useful advice to Experts.

> 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.

Yes.
Experts TBD.

Document Shepherd Write-Up for Group Documents: draft-ietf-asdf-sdf-16
This version is dated 4 July 2022.

Document History
> Does the working group (WG) consensus represent the strong concurrence of a
> few individuals, with others being silent, or did it reach broad agreement?

The group is very small, but the document represents the consensus of the WG.

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

No controversy.

> Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> 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 recommends) or elsewhere
> (where)?

Yes, there are existing implementations.

>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.

There is some overlap with SENML in the CORE WG, and those people are in
common.  The rest of the overlap is with entities outside of the IETF, and
some of those interactions are well underway (and complete), and others
likely will not occur until after the RFC is published.

> Describe how the document meets any required formal expert review criteria,
> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None required.

>Document Shepherd Checks
>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?

At the time (2023-10-12), tHe document still needs a better Security Considerations.

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

Standards Track is appropriate.

> Have reasonable efforts been made to remind all authors of the intellectual
> property rights (IPR) disclosure obligations described in BCP 79? 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.

Yes.

> 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.

Yes.

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

No important nits.

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

Maybe some things to fix.

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

None.

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

no.

> 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.

> Will publication of this document change the status of any existing RFCs?
> If

No.

> Describe the document shepherd's review of the IANA considerations section,
> especially with regard to its consistency with the body of the document.

reviewed, seemed to be complete and included useful advice to Experts.

> 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.

Yes.
Experts TBD.