[core] Re: Coreconf Notifications

[Carsten Bormann <[e-mail]>]

> 
> “Implementations must support time zones” comes from RFC5277 [https://datatracker.ietf.org/doc/html/rfc5277#section-2.2.1]

Yes, but what does that *mean*?
How do you “support” timezones?
Maybe you decode time zone offsets?
But what do you use that useless information for then?

> What draft-ahuang-netconf-notif-yang is trying to solve is defining the structure of the notification in a YANG model so that YANG tooling can use the YANG module to validate Notifications rather than relying on just text.
> And the reason draft-ahuang-netconf-notif-yang goes up to RFC5277 is because YANG has until now relied on this RFC5277 to define how such notifications are encoded.

This might be the right time to clean that up.
Are emitters actually putting in their timezones there and expecting an effect from that?
Do consumers decode the timezone (beyond just applying the time zone offset, which is useless complication) and then do something useful with it?

> Note also that in RFC6991, the date-and-time type, the timezone is included.

Yes, and that is usually wrong, so it is not quite clear why this is reinforced.

> Our comments to draft-ietf-core-comi are because in section 3.4 (https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-18#name-event-stream) the authors reference 5277 even though the model is defined in XML only.
> So, we suggest to the authors to change that reference to draft-ahuang-netconf-notif-yang to have a common model also in CORECONF.

That would be a normative reference to an individual draft.
That might slow us down, so I would prefer not to do that.

Grüße, Carsten