Subject: Re: [netmod] IETF WG state changed for draft-ietf-netmod-rfc6991-bis

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 7 Apr 2022 09:13:35 +0200

On Wed, Apr 06, 2022 at 05:49:26PM -0700, IETF Secretariat wrote:
> 
> The IETF WG state of draft-ietf-netmod-rfc6991-bis has been changed to "WG
> Consensus: Waiting for Write-Up" from "Waiting for WG Chair Go-Ahead" by Kent
> Watsen:
> 
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/
>

Dear chairs,

given recent discussions around ip addresses, I am not sure about the
consensus and perhaps we should consider to name the new date and time
types differently, e.g.

  date -> date-with-zone
  date-no-zone -> date
  time -> time-with-zone
  time-no-zone -> time

to avoid similar discussions in the future and to adopt a naming style
where optional elements are reflected in the name instead of using a
naming style where the absence of optional parts is reflected in the
name.

/js

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 7 Apr 2022 15:30:32 +0000

Hi Juergen,

> On Apr 7, 2022, at 3:13 AM, Jürgen Schönwälder <[email-masked]> wrote:
> 
> consensus

I just moved the state back so it doesn't suggest consensus.

>  and perhaps we should consider to name the new date and time
> types differently, e.g.
> 
>  date -> date-with-zone
>  date-no-zone -> date
>  time -> time-with-zone
>  time-no-zone -> time
> 

Here's what is intuitive to me:

	- date		YYYY-MM-DD
	- time		hh:mm:ss

Effectively your proposal.  I question if "date-with-zone" or "time-with-zone" are ever needed.    Certainly not "date-with-zone", as there is no way to reason about it.  As for "time-with-zone", I'm suspicious, as I've never seen it disconnected from a "date" before.

Kent // contributor

---

From: tom petch <[email-masked]>
Date: Thu, 7 Apr 2022 15:52:22 +0000

From: netmod <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Sent: 07 April 2022 16:30

Hi Juergen,

On Apr 7, 2022, at 3:13 AM, Jürgen Schönwälder <[email-masked]<mailto:[email-masked]>> wrote:

Dear chairs,

 date -> date-with-zone
 date-no-zone -> date
 time -> time-with-zone
 time-no-zone -> time

- date YYYY-MM-DD
- time hh:mm:ss

<tp>
I see time with zone and no date.  It is needed whenever monitoring or some other operational requirement is being set up to occur at the same time every day (which I see as a very common requirement).

You can find it in e.g. I2NSF-consumer-facing (which I keep being told has been around  for years before being brought to the IETF).
 
Tom Petch

Kent // contributor

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Apr 2022 08:56:15 -0700

On Thu, Apr 7, 2022 at 8:31 AM Kent Watsen <[email-masked]> wrote:

>
> Hi Juergen,
>
> On Apr 7, 2022, at 3:13 AM, Jürgen Schönwälder <
> [email-masked]> wrote:
>
+1

> Effectively your proposal.  I question if "date-with-zone" or
> "time-with-zone" are ever needed.    Certainly not "date-with-zone", as
> there is no way to reason about it.  As for "time-with-zone", I'm
> suspicious, as I've never seen it disconnected from a "date" before.
>
>
Perhaps the clue as to why these problems were not discovered until now.

> Kent // contributor

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 7 Apr 2022 17:56:44 +0200

> Effectively your proposal.  I question if "date-with-zone" or "time-with-zone" are ever needed.    Certainly not "date-with-zone", as there is no way to reason about it.  As for "time-with-zone", I…

This is what xsd:date and xsd:time do, see section 3.2.8 and 2.3.9 of
<https://www.w3.org/TR/xmlschema-2/> and the intention was to provide
a type that is compatible with the XSD definitions. I guess W3C also
surprises their users. ;-)

I will change the names and we need to answer the question whether we
want to provide in addition types that are compatible with the XSD
types or not.

/js

PS: The reason for date-with-zone is that it specifies an unambiguous
    24 hour interval. If you state the deadline is 2022-04-08, then
    this means different things in different time zones. If you write
    2022-04-08Z, then this ambiguity goes away. Perhaps nobody does
    this in the real world because people are prepared to deal with
    the ambiguity somehow but I can see reasons why XSD people went
    this way.

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 7 Apr 2022 11:19:03 -0700

Hi -

On 2022-04-07 12:13 AM, Jürgen Schönwälder wrote:
...
> naming style where the absence of optional parts is reflected in the

That's a reasonable rationale, and might even make a good CLR if
adopted from the very beginning, but given the ability of model
designers to read too much (or too little) into names,
perhaps one might consider the possibility of eliminating this
particular source of confusion altogether?

     date -> date-with-zone
     date-no-zone -> date-no-zone
     time -> time-with-zone
     time-no-zone -> time-no-zone

Randy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 7 Apr 2022 18:31:56 +0000

Hi Randy,

>    time-no-zone -> time-no-zone

This looks like my option 'e' in the other thread.  It's good because it makes it a conscious decision either way.

> Randy

K.

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 7 Apr 2022 11:48:12 -0700

Hi -

> This looks like my option 'e' in the other thread.  It's good because it makes it a conscious decision either way.

Sorry to have duplicated your idea without credit.

One concern, both here and with respect to the LSR discussion -
Though there is clearly *mnemonic* value to descriptive labels,
I hate to see an institutionalization of the questionable
practice of inferring *semantics* from the construction of labels.
Hungarian notation has its limits.

Randy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 8 Apr 2022 10:45:24 +0000

Randy!

> Sorry to have duplicated your idea without credit.

Think nothing of it.  My only interest is ensuring others make the connection as well.  Just trying to me helpful. 

K.