(Luis) Issue #2 for draft-ma-opsawg-schedule-yang – SEDATE

[luismcontreras]

Draft draft-ietf-sedate-datetime-extended from SEDATE WG defines extensions to the timestamp format defined in RFC3339 for representing additional information including a time zone. It also proposes some further keys (identified as experimental) associated to the time information that can be interpreted by consumers of such time information. This can be a powerful artifact when associated to the time scheduler. Moreover, it adds the possibility of declaring the time (and the applicable calendar) in a human friendly manner. Finally. it addresses the problem of inconsistency on the time zone expression.

So I think it would be good to leverage on those capabilities for creating a more powerful scheduling mechanism. This would imply to associate the timing attributes in draft-ma-opsawg-schedule-yang (i.e., “period-start”, “time-zone-identifier”, “period-end”, etc) to the ones in draft-ietf-sedate-datetime-extended.

[boucadair]

I thought that the key clarification in sedate spec is covered in draft-ietf-netmod-rfc6991-bis (see for example time-with-zone-offset). If not, I think it is better to fix this in rfc6991-bis so that this can be leveraged by all modules, including the schedule model. No?

[luismcontreras]

But the extensions defined in draft-ietf-sedate-datetime-extended are not (and will not) in RFC 6991. If those extensions are valuable maybe should be considered here.

[QiufangMa]

After reading draft-ietf-sedate-datetime-extended,
a couple of thoughts on how the extended data-and-time type might be support:

• define typedef date-and-time-ext and write expression pattern (similar to typedef date-and-time definition according to RFC3339) according to https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-11.html#section-4.1, I am afrid that it is going to be a complex expression
• define time-zone (already have now), critical-flag, suffix-key and values as parameters inside scheduling groupings, not desirable due to interoperability
• what else?