Subject: Re: [Netconf] mbj's WGLC review of yang-push-17

From: Alexander Clemm <[email-masked]>
Date: Wed, 5 Sep 2018 22:55:01 +0000

Hi Martin,

please see my responses inline, <ALEX>, trimming the closed stuff ("Ok.")

Thanks
--- Alex
...
> 
> > > > > > > o  3.11.1
> > > > > > >
> > > > > > >   The text says:
> > > > > > >
> > > > > > >    It is not
> > > > > > >    required to merge pending update messages.
> > > > > > >
> > > > > > >   This can be read as indicating that a server MAY merge pending
> > > > > > >   update messages.  I assume that it should say that pending update
> > > > > > >   messages MUST NOT be merged.
> > > > > >
> > > > > > <ALEX> Hmm.  I am not sure I agree.  The server is not
> > > > > > required to merge pending update messages - i.e. can send
> > > > > > multiple messages each with a separate update record.
> > > > > > However, there is no reason to preclude that they could be
> > > > > > combined.  So, I don't think an update is needed here.
> > > > > > </ALEX>
> > > > >
> > > > > So you say that the text means that the server MAY merge pending
> > > > > update messages in this case?  If so, I think you should update
> > > > > the text so that this is clear.
> > > > >
> >
> > <ALEX3> OK, how about saying "The server MAY (but does not have to)
> > merge pending update messages". </ALEX3>
> 
> Well, the term "update message" is not defined, so it shouldn't be used.
> Presumably you mean "update record".

<ALEX> sure </ALEX>

> 
> But I still don't really understand how this is supposed to work.  The push-code in
> the publisher creates an update record A and hands it over to the transport
> layer, where it is queued:
> 
>    It is perfectly acceptable to have a series of "push-change-
>    update" notifications (and even "push update" notifications) serially
>    queued at the transport layer awaiting transmission.
> 
> Then the push-code in the publisher creates another update record B and hands
> it over to the transport layer.
> 
> Are you saying that the transport layer code now can merge these two update
> records into a single record?  So if record A had "create foo, delete bar" and
> record B had "delete foo", there would be a single record with "delete bar,
> delete foo"?
> 
> If two records are merged, what happens to the idea of using the 'patch-id' as
> an indication of lost records?
> 
> 

<ALEX> All this is saying is that it is up to the publisher to decide how to "group" the updates: whether to send a single update record (in a single notification), or whether to create multiple records (sent with multiple notifications).  
To make this clear, slight updates as follows:
" It is perfectly acceptable to have a series of "push-change-update" notifications (and even "push update" notifications) serially queued at the transport layer awaiting transmission.  It is not required for the publisher to merge pending update records sent at the the same time."
</ALEX>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 10 Sep 2018 11:33:06 +0200 (CEST)

Hi,

Alexander Clemm <[email-masked]> wrote:
> > records into a single record?

You didn't answer this question.

> > So if record A had "create foo, delete
> > bar" and

You didn't answer this question.

> > an indication of lost records?

You didn't answer this question.

> <ALEX> All this is saying is that it is up to the publisher to decide
> how to "group" the updates: whether to send a single update record (in
> a single notification), or whether to create multiple records (sent
> with multiple notifications).
> " It is perfectly acceptable to have a series of "push-change-update"
> notifications (and even "push update" notifications) serially queued
> at the transport layer awaiting transmission.  It is not required for
> the publisher to merge pending update records sent at the the same
> time."
> </ALEX>

I think that if you really want to allow such merging, it needs to be
described how it is supposed to be done, e.g. wrt. the patch-id.  But
I would rather see that this "merging" feature is removed.

(In one sense, it doesn't matter much; it is an optional behaviour so
since I don't understand it, I can simply just not implement it.)

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Sep 2018 23:06:21 +0000

Hi Martin,

I'm surprised to see that your review doesn't suggest changing "yp:period" from yang:timeticks to seconds.

You had previously made this suggestion in another thread, but it's still timeticks in -18.

Kent // all hat

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 20 Sep 2018 09:45:20 +0200 (CEST)

Hi,

Thanks Kent, I missed this one.

Authors, I suggest we change the type for "yp:period" from
"yang:timeticks" to "uint32" with units "seconds".

See the thread starting at
https://mailarchive.ietf.org/arch/msg/netconf/SU1VnBV1Ea5Ae3QzPn_joyyRnZo

/martin

Kent Watsen <[email-masked]> wrote:
> Hi Martin,
> 
> I'm surprised to see that your review doesn't suggest changing
> "yp:period" from yang:timeticks to seconds.
>

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 20 Sep 2018 18:51:42 +0000

I am about to post -19 but I do not like the suggested change to go from timeticks to seconds.

Seconds is a fairly coarse unit.  I would not be surprised to see requirements for finer granularity in the future, even more so in virtualization and controller scenarios in which we start to see YANG being used.  There are applications that use single second periods today so I think it is entirely conceivable to see need for subsecond support down the line.  To allow periods only in units of seconds would seem to unnecessarily hobble ourselves.  Keeping things to timeticks is more futureproof IMHO.  

--- Alex

> -----Original Message-----
> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Thursday, September 20, 2018 12:45 AM
> To: [email-masked]
> Cc: Alexander Clemm <[email-masked]>; [email-masked]
> Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
> 
> Hi,
> 
> Authors, I suggest we change the type for "yp:period" from "yang:timeticks" to
> "uint32" with units "seconds".
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Sep 2018 09:36:12 +0200 (CEST)

Alexander Clemm <[email-masked]> wrote:
> Seconds is a fairly coarse unit.  I would not be surprised to see
> requirements for finer granularity in the future, even more so in
> virtualization and controller scenarios in which we start to see YANG
> being used.  There are applications that use single second periods
> today so I think it is entirely conceivable to see need for subsecond
> support down the line.  To allow periods only in units of seconds
> would seem to unnecessarily hobble ourselves.  Keeping things to
> timeticks is more futureproof IMHO.

Ok.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Mon, 24 Sep 2018 18:15:56 +0000

>> timeticks is more futureproof IMHO.

I agree that seconds is too course. Hundredths of a second is maybe too
fine, but I won't complain.  That said, I think that it might be an
uncommon scenario and that having hundredths of a second will likely
result in very large numbers.

FWIW, yang:timeticks doesn't seem as intuitive as "units" - for example:

          leaf period {
-           type yang:timeticks;
+           type uint16;
+           units "Hundredths of a second";
            mandatory true;
            description
              "Duration of time which should occur between periodic
               push updates.";
          }

At least I know what this means right away.  I was hoping to find an example
in -19 illustrating its use, but it's none is present.  

BTW, I note that RFC 6991 says:

         When a schema
         node is defined that uses this type, the description of
         the schema node identifies both of the reference epochs.

Which I don't see in -19.

Would it make sense to use a 2-tuple?  Something like:

          leaf period {
            type uint16;
            mandatory true;
            description
              "Duration of time which should occur between periodic
               push updates.";
          }
          leaf period-units {
            type enumeration {
              enum hundredths;
              enum tenths;
              enum seconds;
              enum minutes;
              enum hours;
            }
            mandatory true;
          }

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Sep 2018 11:44:33 -0700

> result in very large numbers.
IMO the current definition is sufficient and further delays in this work
are not justified.

Andy

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

---

From: "Yutianpeng (Tim)" <[email-masked]>
Date: Mon, 24 Sep 2018 19:00:56 +0000

Personally I don't think we need to introduce complexity on this. I prefer use standard timeticks which also keep flexibility.
For the functionality mentioned with seconds, hours, etc, it is very simple with any of the program language nowadays.

Assume we use java and the value we get from yang-push is (yang_timestamp)
Then we can have a code sample as below:
//
long yang_timestamp = 100000000;
Timestamp time = new Timestamp(yang_timestamp);
System.out.println( (time.getHours()) );
System.out.println( (time.getMinutes()) );
//

These logic should be implemented by the program language itself,  not using none-standard yang data types.
And it is not difficult at all as there are implementations for all data types supported.
Hope it helps.

Thanks,
Tim

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: 24 September 2018 19:16
To: Martin Bjorklund <[email-masked]>; Alexander Clemm <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17

>> timeticks is more futureproof IMHO.

I agree that seconds is too course. Hundredths of a second is maybe too fine, but I won't complain.  That said, I think that it might be an uncommon scenario and that having hundredths of a second will likely result in very large numbers.

          leaf period {
-           type yang:timeticks;
+           type uint16;

At least I know what this means right away.  I was hoping to find an example in -19 illustrating its use, but it's none is present.  

         When a schema

          leaf period {
            type uint16;
            mandatory true;
            description

Kent // contributor

---

From: tom petch <[email-masked]>
Date: Tue, 25 Sep 2018 09:00:48 +0000

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
Sent: Monday, September 24, 2018 7:15 PM

> FWIW, yang:timeticks doesn't seem as intuitive as "units" - for
example:

Kent

It may depend where you come from.  As RFC6991 points out, timeticks is
designed to be compatible with SMI TimeTicks and so will likely to be
familiar,  expected even, for those who have been at this for, say, 10
years or more.

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Sep 2018 09:56:50 -0700

> familiar,  expected even, for those who have been at this for, say, 10

Or even 30 years!
https://tools.ietf.org/html/rfc1065

I do not understand the motivation for using uint16.
This would limit the maximum period to 655.35 seconds.

Andy

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 25 Sep 2018 17:44:52 +0000

We should stay with uint32.
uint16 would mean just under 11 minutes – too short imho.
--- Alex

From: Andy Bierman [mailto:[email-masked]]
Sent: Tuesday, September 25, 2018 9:57 AM
To: t.petch <[email-masked]>
Cc: Kent Watsen <[email-masked]>; Martin Bjorklund <[email-masked]>; Alexander Clemm <[email-masked]>; Netconf <[email-masked]>
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17

On Tue, Sep 25, 2018 at 2:01 AM tom petch <[email-masked]<mailto:[email-masked]>> wrote:
----- Original Message -----
From: "Kent Watsen" <[email-masked]<mailto:[email-masked]>>
Sent: Monday, September 24, 2018 7:15 PM

> >Alexander Clemm <[email-masked]<mailto:[email-masked]>> wrote:

Kent

Or even 30 years!

Tom Petch

Andy

> [email-masked]<mailto:[email-masked]>

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 25 Sep 2018 17:51:32 +0000

From: Andy Bierman, September 25, 2018 12:57 PM

----- Original Message -----
From: "Kent Watsen" <[email-masked]<mailto:[email-masked]>>
Sent: Monday, September 24, 2018 7:15 PM

Kent

Or even 30 years!

<eric> Current definition supports up to 248 days.  Which looks sufficient at this point to me.

Eric

Tom Petch

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Sep 2018 17:52:25 +0000

> This would limit the maximum period to 655.35 seconds.

That was a typo - it should've been uint32.  FWIW, when I added the
"anchor-time" to the [netcont/restconf]-client-server drafts, I used "period"
with "type uint16" and "units minutes", which is where uint16 came from.

I still think replacing "type yang:timeticks" with "type unit32" and "units
hundredths of a sec" is more intuitive, as:
  - no need to look up what a timetick is.
  - no need to understand why the two "epoch" times aren't documented
    in YP, as required(?) by RFC 6991.
  - more closely aligns with the [netcont/restconf]-client-server drafts

But it was just a suggestion.

I agree with the comment that software can easily convert hundredths of a
second values to things like "minutes" or "hours", but how would it know
when to do so?   Even if the UI was clever enough to enable an admin to
enter the value using two fields (value + units) and the software internally
converted to hundredths of a second, it doesn't help later when another UI
wants to looks at the value, unless we expect it to step through a bunch of
commonly-used units until finding one that fits nicely.

FWIW, we had a similar discussion a long time back with the netconf-server
draft but, at that time, the minimum designed granularity was "seconds",
which seemed okay since most people are pretty familiar with how seconds
convert to minutes or hours or days.

Kent // contributor

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 25 Sep 2018 20:47:52 +0000

I think timeticks are fairly familar to most people.  Also, I think a UI used by humans to manually configure subscriptions will be only a corner case; in the vast majority of cases I would expect this to be consumed by applications and flow-through interfaces.
---Alex

From: Kent Watsen [mailto:[email-masked]]
Sent: Tuesday, September 25, 2018 10:52 AM
To: Andy Bierman <[email-masked]>; t.petch <[email-masked]>
Cc: Martin Bjorklund <[email-masked]>; Alexander Clemm <[email-masked]>; Netconf <[email-masked]>
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Sep 2018 21:19:26 +0000

that's a good point, a UI wouldn't be used for more than a handful of subscriptions.

/kw

On 9/25/18, 4:47 PM, "Alexander Clemm" <[email-masked]<mailto:[email-masked]>> wrote:

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Sep 2018 23:31:45 +0200

>   - more closely aligns with the [netcont/restconf]-client-server drafts

It seems the type you want for the 'period' leafs in your ID is not
timeticks but an equivalent of RFC 2579's TimeInterval:

TimeInterval ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "A period of time, measured in units of 0.01 seconds."
    SYNTAX       INTEGER (0..2147483647)

I am somewhat surprised we do not have something matching the
TimeInterval TC in RFC 6991, I do not recall why.

The TimeTicks TC (and hence the timeticks YANG type) represents time
that ticks. The classic example is sysUpTime - sysUpTime has a new
value whenever you read it since it constantly ticks. Hence, the
timeticks type is pretty useless for configuration objects.

If you roll your own type, perhaps you want a type like this:

  type centiseconds {
    type uint32;
    description
      "A period of time, measured in units of 0.01 seconds.";
  }

With this, you would get something more descriptive:

          leaf period {
            type centiseconds;
            mandatory true;
            description

/js

-- 
Juergen Schoenwaelder           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: Andy Bierman <[email-masked]>
Date: Tue, 25 Sep 2018 15:11:24 -0700

>       "A period of time, measured in units of 0.01 seconds.";

I like this approach, but maybe it would be better to follow the timeticks
example

   typedef time-interval {
      type uint32;
      units "hundredths of a second";  // ?
      description
          "A period of time, measured in units of 0.01 seconds.";
       reference
            "RFC 2579: Textual Conventions for SMIv2";
   }

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Sep 2018 22:18:50 +0000

> TimeInterval TC in RFC 6991, I do not recall why.

I also thought that maybe there should be something better.  I had 
searched RFC 6991 for "duration" thinking about xsd:duration.

>      "A period of time, measured in units of 0.01 seconds.";

But then by that token, should we have types for seconds, minutes,
hours, etc. too?  This might actually be nice to have, but perhaps
part of a rfc6991bis instead?  

This is why I was thinking to use the "units" statement:

         leaf period {
            type unit32;
            units "Hundredths of a second.";
            mandatory true;
            description
              "Duration of time which should occur between periodic
               push updates.";
          }

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Sep 2018 00:37:03 +0200

> part of a rfc6991bis instead?

Likely.
 
>               "Duration of time which should occur between periodic

Well, the whole point of a type definition is that you do not have
to repeat things multiple times and you can be sure you always have
exactly the same.

By giving a type a good name (but good may be subjective), you also
get information into derived artefacts such as tree diagrams. Compare
these three versions:

  +---w yp:periodic!
     +---w yp:period         yang:timeticks
     +---w yp:anchor-time?   yang:date-and-time

vs

  +---w yp:periodic!
     +---w yp:period         uint32
     +---w yp:anchor-time?   yang:date-and-time

vs

  +---w yp:periodic!
     +---w yp:period         centiseconds
     +---w yp:anchor-time?   yang:date-and-time

A centiseconds type could (of course) still have a suitable units
statement. Anyway, timeticks seems to be semantically wrong.

/js

---

From: Qin Wu <[email-masked]>
Date: Wed, 26 Sep 2018 01:25:54 +0000

-----邮件原件-----
发件人: Netconf [mailto:[email-masked]] 代表 Kent Watsen
发送时间: 2018年9月26日 6:19
收件人: Juergen Schoenwaelder
抄送: Netconf
主题: Re: [Netconf] mbj's WGLC review of yang-push-17

>I also thought that maybe there should be something better.  I had searched RFC 6991 for "duration" thinking about xsd:duration.

>>part of a rfc6991bis instead?  

[Qin]: To address this, one solution we proposed in draft-ietf-lime-yang-connectionless-oam-18:
Is to define ietf-lime-time-types which can be reused in other modules. In ietf-lime-time-types, we define
define time-unit-type as identity. 
But maybe typedef is even better since both time-unit and value are defined in one.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Sep 2018 08:32:05 +0200

On Wed, Sep 26, 2018 at 01:25:54AM +0000, Qin Wu wrote:
> 
> To address this, one solution we proposed in draft-ietf-lime-yang-connectionless-oam-18:

The good old practice was to think about the number range that makes
sense and then to use a numeric type with a suitable unit that covers
the number range.

I wonder whether you really need a uint32 range of hours in the OAM
models. Note that a single uint64 of nanoseconds would give you up to
584 years. If oam models do indeed need delay values that range from
nanoseconds to hundreds of years, I would rather go with a single
uint64 instead of a combination of an uint32 and a unit identifier.

/js

---

From: Qin Wu <[email-masked]>
Date: Wed, 26 Sep 2018 08:00:26 +0000

-----邮件原件-----
发件人: Juergen Schoenwaelder [mailto:[email-masked]] 
发送时间: 2018年9月26日 14:32
收件人: Qin Wu
抄送: Kent Watsen; Netconf
主题: Re: [Netconf] mbj's WGLC review of yang-push-17

On Wed, Sep 26, 2018 at 01:25:54AM +0000, Qin Wu wrote:
> Is to define ietf-lime-time-types which can be reused in other 
> modules. In ietf-lime-time-types, we define define time-unit-type as identity.

The good old practice was to think about the number range that makes sense and then to use a numeric type with a suitable unit that covers the number range.

I wonder whether you really need a uint32 range of hours in the OAM models. 
	
[Qin]: not necessary for OAM model, but It may be used in some other models that require unint32 range of hours.

Note that a single uint64 of nanoseconds would give you up to
584 years. If oam models do indeed need delay values that range from nanoseconds to hundreds of years, I would rather go with a single
uint64 instead of a combination of an uint32 and a unit identifier.

[Qin]: Not advocating using such combination, just point out such common type are also needed in some other models, that's why a separate ietf-lime-time-types was defined.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Sep 2018 11:28:43 +0200

> [Qin]: not necessary for OAM model, but It may be used in some other models that require unint32 range of hours.

Authors may not want to depend on ietf-lime-time-types for generic
types for time periods, nor am I sure the solution there is a simple
solution.

Perhaps its time to see whether it makes sense to spin an update of
RFC 6991 to add definitions that are apparently missing. Aftert 5
years this may be a reasonable thing to do. We should not hold off
work because of this but we may allow authors to transition to common
definitions if what they do now is compatible with a common solution
underway. I would be willing to allocate some of my time to an update
of RFC 6991 if the WG believes this is useful.

/js

---

From: Qin Wu <[email-masked]>
Date: Wed, 26 Sep 2018 09:57:57 +0000

-----邮件原件-----
发件人: Juergen Schoenwaelder [mailto:[email-masked]] 
发送时间: 2018年9月26日 17:29
收件人: Qin Wu
抄送: Kent Watsen; Netconf
主题: Re: [Netconf] mbj's WGLC review of yang-push-17

> [Qin]: not necessary for OAM model, but It may be used in some other models that require unint32 range of hours.

Authors may not want to depend on ietf-lime-time-types for generic types for time periods, nor am I sure the solution there is a simple solution.

[Qin]: works for me.

Perhaps its time to see whether it makes sense to spin an update of RFC 6991 to add definitions that are apparently missing. Aftert 5 years this may be a reasonable thing to do. We should not hold off work because of this but we may allow authors to transition to common definitions if what they do now is compatible with a common solution underway. I would be willing to allocate some of my time to an update of RFC 6991 if the WG believes this is useful.

[Qin]: I think it is useful.

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 26 Sep 2018 11:06:19 +0100

Hi Juergen,

Yes, I think that updating RFC 6991 would be useful, if there are types 
missing.

Thanks,
Rob

---

From: tom petch <[email-masked]>
Date: Wed, 26 Sep 2018 11:39:54 +0000

----- Original Message -----
From: "Robert Wilton" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Kent Watsen" <[email-masked]>;
"Netconf" <[email-masked]>
Sent: Wednesday, September 26, 2018 11:06 AM

> Yes, I think that updating RFC 6991 would be useful, if there are
types

Give us a clue!

And isn't this one one for the netmod WG (a list that is pleasantly
quiet currently) ?

Tom Petch

> >> I wonder whether you really need a uint32 range of hours in the OAM
models.
> >>
> >> [Qin]: not necessary for OAM model, but It may be used in some
other models that require unint32 range of hours.

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 26 Sep 2018 14:56:02 +0000

Hi,

On 2018-09-26, 5:29 AM, "Netconf on behalf of Juergen Schoenwaelder" <[email-masked] on behalf of [email-masked]> wrote:

    

<RR> I believe this is useful. One definition which is missing is date (we discussed this on YD alias in March).

Regards,
Reshad.
    
    /js