Re: [netmod] AD review of draft-ietf-netmod-rfc6991-bis-15

[[e-mail]]

Hi Jürgen, all,

With regards to draft-ietf-sedate-datetime-extended, we do have a related open issue about this at: https://github.com/boucadair/policy-based-network-acl/issues/74 for draft-ietf-netmod-schedule.

I think that it is better to handle this as part of the 6991-bis (rather than in a separate module). I would update the definition to align with the sedate ABNF.

Cheers,
Med

> -----Message d'origine-----
> De : netmod <[e-mail]> De la part de Jürgen Schönwälder
> Envoyé : jeudi 18 avril 2024 15:06
> À : Mahesh Jethanandani <[e-mail]>
> Cc : NETMOD Working Group <[e-mail]>
> Objet : Re: [netmod] AD review of draft-ietf-netmod-rfc6991-bis-15
> 
> 
> On Tue, Apr 16, 2024 at 10:08:09AM -0700, Mahesh Jethanandani wrote:
> > Hi Jürgen,
> >
> > It appears that Brian and you had made progress on the other thread
> related to IPv6 zone definition. Are there any outstanding issues that
> need to be resolved?
> >
> > What is the plan to submit an updated version of the document?
> >
> 
> I had to take a fresh look at things and I think the discussion around
> zones of IP addresses is moving to a conclusion. That said, I believe
> we are not done with the work related to dates, times, and durations.
> What we have is not really good and also in conflict with newer work
> that came out of the sedate WG and has passed IESG approval (I think).
> Here is a not so short summary (I have even more details since I did
> take a look into what standard libraries of various system programming
> languages offer).
> 
> * date-and-time, date, time
> 
>   For time zones, we used to have the canonical format +00:00 for
>   systems in UTC located and a known timezone offset of 00:00. For
>   systems in UTC with an unknown timezone offset, the canonical format
>   has been -00:00. This was based on RFC 3339 which introduced the
>   -00:00 which is not strictly allowed by the ISO 8601 format.
> 
>   The sedate work is updating RFC 3339 recommending against the use of
>   the -00:00 notation (since it is not conforming to ISO 8601) and
>   instead suggests that Z is used for systems in UTC with an unknown
>   timezone offset.
> 
>   The question is now how we deal with this non-backwards compatible
>   change of RFC 3339 that apparently got approved by the IESG and
>   hence there is believe that the Internet won't break based on the
>   argument that using Z instead of -00:00 is already common practice.
>   If so, do we simply align our definition with the updated version of
>   RFC 3339?  Or do we go an deprecate date-and-time and create a new
>   definition (and then we deal with the updates of all affected
>   modules over time)?
> 
>   Note that this also affects the newly defined zoned types date and
>   time.
> 
>   Looking forward, we may even want to consider supporting formats
>   that allow for timezone names instead of only static numeric
>   offsets. So another option might be to leave date-and-time as is
>   (potentially deprecating it once there is a better replacement) and
>   to start a new module, say ietf-chrono, that defines new date and
>   time related types that are aligned with the updated RFC 3339 and
>   the work done by the sedate working group to enable the use of time
>   zone names.
> 
> * nanoseconds, microseconds, milliseconds, seconds, minutes, hours
> 
>   There was some discussion around the choice of signed vs unsigned
>   base types and the choice between 32 and 64 bits. I have
>   investigated a bit what standard libraries of system programming
>   languages do and I concluded that using signed integer types
>   dominates and that we should use 64-bit types for everything up
>   to and including seconds (and not offer 32-bit alternatives).
> 
>   It is easy to range restrict to just positive numbers and it is
>   also easy to range restrict to use less than 64 bits.
> 
>   If we would start a new module for date and time types, then these
>   definitions should likely be moved there as well.
> 
> I believe to have proper types for data and time and durations, it is
> best to factor this work out into a separate effort. This gives us
> more freedom to do things right without any harm on backwards
> compatibility (we would not change date-and-time, except perhaps
> adding a warning note that use of -00:00 is getting discouraged).
> 
> /js
> 
> --
> Jürgen Schönwälder              Constructor University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C02%7Cmohamed.boucadai
> r%40orange.com%7Cf6a1137e0ba34522105f08dc5fa85411%7C90c7a20af34b40bfbc
> 48b9253b6f5d20%7C0%7C0%7C638490423774715463%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7C&sdata=HBu%2Bm9zCbDl%2Bo%2Fy%2B%2Bno7nhVn%2FcTMofvz%2B2b%2FHyEm
> E1s%3D&reserved=0
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.