IETF Logo Mail Archive

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

Alexander Clemm <alexander.clemm@huawei.com> Tue, 25 September 2018 20:48 UTC

Return-Path: <alexander.clemm@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD61130DC8 for <netconf@ietfa.amsl.com>; Tue, 25 Sep 2018 13:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REDPBn_vPN1i for <netconf@ietfa.amsl.com>; Tue, 25 Sep 2018 13:48:04 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CA5124C04 for <netconf@ietf.org>; Tue, 25 Sep 2018 13:48:04 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id AA7293A270011 for <netconf@ietf.org>; Tue, 25 Sep 2018 21:47:57 +0100 (IST)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 25 Sep 2018 21:47:59 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.47]) by SJCEML702-CHM.china.huawei.com ([169.254.4.89]) with mapi id 14.03.0415.000; Tue, 25 Sep 2018 13:47:53 -0700
From: Alexander Clemm <alexander.clemm@huawei.com>
To: Kent Watsen <kwatsen@juniper.net>, Andy Bierman <andy@yumaworks.com>, "t.petch" <ietfc@btconnect.com>
CC: Martin Bjorklund <mbj@tail-f.com>, Netconf <netconf@ietf.org>
Thread-Topic: [Netconf] mbj's WGLC review of yang-push-17
Thread-Index: AQHUNImzU9I4weZMB0iH1L0LVTTudKUB7cYAgAAPiID//7pOoA==
Date: Tue, 25 Sep 2018 20:47:52 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6A205@sjceml521-mbx.china.huawei.com>
References: <3B841FC9-63F4-41DD-BCE2-AA543FDADA5C@juniper.net> <20180920.094520.798604819426315275.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB691A5@sjceml521-mbx.china.huawei.com> <20180924.093612.1791958587714330227.mbj@tail-f.com> <A1DF23A4-3D00-43D7-B121-D9F567B2A43F@juniper.net> <020f01d454ae$2e41e4a0$4001a8c0@gateway.2wire.net> <CABCOCHSATfi4Nq3XLGL65Kj4R_gWTFSf6H0v8qD8DE4aYOpDiQ@mail.gmail.com> <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net>
In-Reply-To: <674F5961-D956-4BD1-8AD0-44FE68150070@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.193.35.95]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB6A205sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/lkpTHuOk8LV2FDhS0-dx6OUAWD4>
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Sep 2018 20:48:07 -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:kwatsen@juniper.net]
Sent: Tuesday, September 25, 2018 10:52 AM
To: Andy Bierman <andy@yumaworks.com>; t.petch <ietfc@btconnect.com>
Cc: Martin Bjorklund <mbj@tail-f.com>; Alexander Clemm <alexander.clemm@huawei.com>; Netconf <netconf@ietf.org>
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17


> I do not understand the motivation for using uint16.
> 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

v2.23.0 | Report a Bug | By Email