core-wg / yang-cbor

Internet-Draft for CBOR representation of YANG data
5 stars 10 forks source link

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

Open mcr opened 2 years ago

mcr commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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.