Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

yang-cbor is silent about how to encode yang date-and-time #144

Open
mcr opened this issue Jun 27, 2022 · 3 comments
Open

yang-cbor is silent about how to encode yang date-and-time #144

mcr opened this issue Jun 27, 2022 · 3 comments

Comments

@mcr
Copy link
Collaborator

mcr commented Jun 27, 2022

The other thing we ran into was that the CBOR implementation I'm using, when given a
DateTime object naturally produces a RFC 8949 Section 3.4.2 compliant "tag 1" marked Epoch-Based
Date/Time. And demarshalls this. So I don't really notice.

But, draft-ietf-core-yang-cbor doesn't say much about "yang:date-and-time".
The only reference seems to be at:
https://www.ietf.org/archive/id/draft-ietf-core-yang-cbor-20.html#name-the-container-and-other-nod

where date-and-time is shown as part of a container object.
The Content is defined to be string date pattern.

Section 6, where I might expect to see info about encoding dates:
https://www.ietf.org/archive/id/draft-ietf-core-yang-cbor-20.html#name-representing-yang-data-type

is silent about date and time formats.

So if the string pattern is the correct and only format, then section 6 needs to say this.
If tag 1 is actually what should be used (it's much smaller, and far less surprising), then we need to say that.

@abierman
Copy link
Contributor

The current draft is already approved, but I support a (new RFC) robust general approach to
data type optimizations -- with a proper registry and protocol discovery mechanisms.
My implementation experience (so far) has shown that the values are mostly the same size and
most improvements come from the delta-SID encoding.

Specific tags for problem data types (like ip-address variants) are needed to improve the optimizations at this point

@lemikev
Copy link
Contributor

lemikev commented Jun 27, 2022

I'm just not sure this issue is in scope for this draft.

"draft-ietf-core-yang-cbor" define the encoding of the built-In types listed in https://datatracker.ietf.org/doc/html/rfc7950#section-4.2.4, not every typedef.

[RFC 6021] defines date-and-time as a string with a specific pattern, this is the way these data nodes should be encoded.

typedef date-and-time {
   type string {
     pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
           + '(Z|[\+\-]\d{2}:\d{2})';
   }
}

A clean way to support Epoch-Based Date/Time is to update the ietf-yang-types YANG module to add this option.

 typedef date-and-time {
   union {
     type string {
       pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
             + '(Z|[\+\-]\d{2}:\d{2})';
     }
     type unit64;
}

An alternate option is to use a different typedef in new IoT specific YANG modules.

@cabo
Copy link
Member

cabo commented Aug 28, 2023

I was waiting for 6991bis to be completed to write a draft on one way of doing this. This would be an extension to yang-cbor, so maybe not to be treated too lightly, but it could help with the general problem.
I don't know when 6991bis will get unstuck, but maybe I could simply write the draft based on some assumptions what that will be.
The solution would be a special case for time/date and IP addresses.
Adding an evolution mechanism (e.g., registry) would be the next step if we believe the point solution is fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants