Re: [netconf] mbj review of draft-ietf-netconf-notification-capabilities-01

Martin Bjorklund <mbj@tail-f.com> Tue, 26 March 2019 11:12 UTC

Return-Path: <mbj@tail-f.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 092421202DB for <netconf@ietfa.amsl.com>; Tue, 26 Mar 2019 04:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qs__hi402mkd for <netconf@ietfa.amsl.com>; Tue, 26 Mar 2019 04:12:34 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 216281202D1 for <netconf@ietf.org>; Tue, 26 Mar 2019 04:12:34 -0700 (PDT)
Received: from localhost (dhcp-97ad.meeting.ietf.org [31.133.151.173]) by mail.tail-f.com (Postfix) with ESMTPSA id BA23D1AE02BD; Tue, 26 Mar 2019 12:12:31 +0100 (CET)
Date: Tue, 26 Mar 2019 12:12:31 +0100 (CET)
Message-Id: <20190326.121231.1546381642017000114.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <e333e4e3-2c40-2f19-5035-d6d24a0adcab@ericsson.com>
References: <20190325.215637.1342845104682793774.mbj@tail-f.com> <e333e4e3-2c40-2f19-5035-d6d24a0adcab@ericsson.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/41-5enJAz67_R7REjuLfj_0ZhnU>
Subject: Re: [netconf] mbj review of draft-ietf-netconf-notification-capabilities-01
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG 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, 26 Mar 2019 11:12:36 -0000

Hi,

Pruning...


Balázs Lengyel <balazs.lengyel@ericsson.com>; wrote:
> Thanks for the comments, See below. Balazs
> 
> On 2019. 03. 25. 21:56, Martin Bjorklund wrote:
> 
>     Hi,
> 
> Here are my (mostly minor) comments on
> draft-ietf-netconf-notification-capabilities-01

[...]

>     o  General
> 
>   In YP, support for on-change is optional.   There is a feature
>   called "on-change".  I think this document should state explicitly
>   that this module is intended for servers that implement that
>   feature.
> 
> BALAZS: OK, but some other capacity related proerties are still valid.

What other capacity related properties do you mean?

>     o  Section 3.2
> 
>   You have:
> 
>          units msec;
> 
>          units centiseconds;
> 
>   I think you probably should do s/msec/milliseconds/
> 
> BALAZS: OK, probably change all to centiseconds. Is there a general
> rule not to use the official abbreviations?

What is the official abbrevation?  According to wikipedia, the SI name
is "millisecond" and "centisecond", and the corresponding symbols are
"ms" and "cs".  I briefly scanned the SI spec, but didn't really come
to any conclusion...

My point was just that it is probably best to be consistent and not
use an abbreviation in one place and the full word in the other.

>     o  Section 3.2
> 
>   minimum-dampening-period is optional.  It should be stated what it
>   means if this leaf is not present.   (or should the default be 0?)
> 
> BALAZS: If not present it means that the system does not tell you what
> it is. No special meaning. I do not see a reasonable minimum value
> (eventhough 0 would look strange). IMHO it is the responsibility of
> the server to provide a meaningful value. If it says zero, that's
> obviously crazy, just ignore it. I don't thing we need to have rules,
> like: do not provide stupid state data.

Note that 0 is the default in YP, so I don't know why you think it is
crazy.

I suggest you add default "0" to this.

>     o  Section 3.2
> 
>   The choice update-period is not mandatory, and doesn't have a
>   default.  What does it mean if this is not reported?
> 
> BALAZS: If not present it means that the system does not tell you what
> it is. No special meaning.

I think this should be clarified in the description.

>     o  Section 3.2
> 
>   The leaf max-objects-per-update is not mandatory.  What does it mean
>   if this is not reported?  It can have the value 0.  What does that
>   mean?
> 
> BALAZS: If not present it means that the system does not tell you what
> it is. No special meaning.
>
> I do not see a reasonable minimum value
> (eventhough 0 would look strange). IMHO it is the responsibility of
> the server to provide a meaningful value. If it says zero, that's
> obviously crazy, just ignore it.

I suggest you add a range "1..max" to the type.

>       Perhaps make a union of uint32 0..max and the enum "infinite" and
>   make that the default?  (of course "infinite" is not really
>   correct...)
> 
> BALAZS: IMHO infinite is unreasonable. If the server doesn't know the
> real limit, it should just not provide a value.

Ok, makes sense.  I think this should be clarified in the description.


/martin