Open mcr opened 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
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.
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.
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.