Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt
Andy Bierman <andy@yumaworks.com> Fri, 10 January 2020 15:47 UTC
Return-Path: <andy@yumaworks.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 2CF6712006B for <netconf@ietfa.amsl.com>; Fri, 10 Jan 2020 07:47:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 kEEI6yi8gyMK for <netconf@ietfa.amsl.com>; Fri, 10 Jan 2020 07:47:53 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489B6120048 for <netconf@ietf.org>; Fri, 10 Jan 2020 07:47:53 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id y6so2643132lji.0 for <netconf@ietf.org>; Fri, 10 Jan 2020 07:47:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kxa0+24gsQA4/PXBxyQg22Zvs5B4x9D7sQ8ALN3CQTc=; b=nvh/kteNydPpABamGD3WY0E00GLreiLMN47DxpM0mlhB0cioAndDkHP6jZqlGT4GD/ z8WHN39SROk9EXhw2VVSKa2D9H1bJM1QkZJa2ffrZRc30E2cFCftJciAtYAY78MqS3SX I1N3TTXsxfqToti8RT1QlA49lWmaQuQMs2jxXR01B1p2lTtl5Z0Y59cL6oBWQHtv0yhZ DTm9q85wvuZ0JEfAchz34wWEZQXGTqZrAOjNcoX8bFQpO7PHNOKwya2yGYlZ5XkBdDPM +bDgh755iguJqvWazwFPQYJ6XDX4hfB0quuzGHj+LKhJgTrGh9+B+52p2yAfJj/Q2yXL k2JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kxa0+24gsQA4/PXBxyQg22Zvs5B4x9D7sQ8ALN3CQTc=; b=GQzZxdc7oK5X8NQXewrTqh6EQyGEYIy9jTM3VJz1AplJEHZ9C/SeBnh5OgyDivrWQ0 gMwacGJeQ70LYdZv2fqO+OLj+I5jJ/RhQKN9fJg5VQOvIzq73RYvgweY+FzpUFFXLDK+ JRiE6qxRs2R6BSgRPSLt1DIUEcNXO8Ls2EVi0p6CijoWaKiGoA0flyMJ4pdVs3VDFoGt E2V89A3WK2ROFomCcsfX1GyCaTw1D2HwSCr9QyoqdqJB1OiOqn7moxRJyBSJ0GqDz+4X xCMhBSvteWkBjznA1lDlE4vkSjjHWJUjgiRv+rfCijJpvNJqbNwLGj9qWGZPYc/PDsSq N5xw==
X-Gm-Message-State: APjAAAXE6fJsGZu9PbnnFjdfxAuvM7uFwCcgZNdhfU/54CU55Fe8Qoea 992kX62VrKAs3mHQflZxU4K6gn8GeWqnSbfoe1hTKA==
X-Google-Smtp-Source: APXvYqytxDSuwDpEI25O55yO5n7FXmmvrSjz8YKOqCh+/Y7uHbwQcDAsuTYS+SF9OmWEr+/HhA0qKZ+wI63EVQBo1Fw=
X-Received: by 2002:a2e:9596:: with SMTP id w22mr2981341ljh.21.1578671271392; Fri, 10 Jan 2020 07:47:51 -0800 (PST)
MIME-Version: 1.0
References: <157838571918.20942.9897465405126184637.idtracker@ietfa.amsl.com> <0100016f801b8360-00636b39-8317-4e78-a233-dba17073fc39-000000@email.amazonses.com> <CABCOCHRn_sXEh_G4TKk3stZjWW0RFOroYtocFDKc2pntza_pVw@mail.gmail.com> <20200109.125407.1696793655072242187.mbjorklu@cisco.com> <CABCOCHSUfEAoQ27pgJYmmPnrQyE-rM8ur=BNF0nVD8sfuvZCmQ@mail.gmail.com> <VI1PR07MB404757A9D5638B70D8B91D62F0380@VI1PR07MB4047.eurprd07.prod.outlook.com>
In-Reply-To: <VI1PR07MB404757A9D5638B70D8B91D62F0380@VI1PR07MB4047.eurprd07.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 10 Jan 2020 07:47:40 -0800
Message-ID: <CABCOCHSdv9i=OR142t_eMYJ5aNA2+5mQa0P2ZzEr_YzYmjO+KA@mail.gmail.com>
To: Balázs Lengyel <balazs.lengyel@ericsson.com>
Cc: Martin Bjorklund <mbjorklu@cisco.com>, Netconf <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005949fb059bcb0c05"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/u69VlXbA2ASkV3X1nF9q77O7iF4>
Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt
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: Fri, 10 Jan 2020 15:47:58 -0000
On Fri, Jan 10, 2020 at 4:16 AM Balázs Lengyel <balazs.lengyel@ericsson.com> wrote: > *See BALAZS2 below.* > > > > *From:* netconf <netconf-bounces@ietf.org> *On Behalf Of *Andy Bierman > *Sent:* 2020. január 9., csütörtök 18:15 > *To:* Martin Bjorklund <mbjorklu@cisco.com> > *Cc:* Netconf <netconf@ietf.org> > *Subject:* Re: [netconf] New Version Notification - > draft-ietf-netconf-notification-capabilities-09.txt > > > > > > > > On Thu, Jan 9, 2020 at 3:54 AM Martin Bjorklund <mbjorklu@cisco.com> > wrote: > > Andy Bierman <andy@yumaworks.com> wrote: > > Hi, > > > > I think the new system capabilities module is good enough. > > The node-instance-identifier type allows a key to be missing, which > > provides some entry reuse. > > > > My concerns are with the notification capabilities module. > > > > - notification-support: why is this an enumeration instead of bits? > > > > suggest: > > > > typedef notification-support { > > type bits { > > bit notifications-for-config-changes-supported { > > description "The publisher is capable of sending > > notifications for config=true nodes, but not > > for config=false nodes for the relevant scope > > and subscription type." ; > > } > > bit notifications-for-state-changes-supported { > > description "The publisher is capable of sending > > notifications for config=false nodes, but not > > for config=true nodes for the relevant scope > > and subscription type." ; > > } > > } > > > > - can the names be shorter (config-changes, state-changes)? > > these names seem redundant and verbose > > +1 for bits and the suggested shorter names > > > > > - update-period > > this object seems implementation-specific. > > The description should be less normative and use 2119 language > > > > A periodic subscription to the selected data nodes must > > specify a value that is at least as large or greater than > > this > > > > Suggest: s/must/SHOULD/ > > I don't think either is correct. This leaf informs the client what an > acceptable 'period' value is. A client that sends a shorter period > will get a 'period-unsupported' error back, as defined in RFC 8641. > Perhaps rephrase the sentence to: > > A request for a periodic subscription to the selected data nodes > with a smaller period than what this leaf specifies will result in > a 'period-unsupported' error. > > > > I agree this is better. > > BALAZS2: OK > > > > > > > - supported-update-period > > - this is very implementation-specific, especially as a leaf-list > > instead of a > > leaf with a range > > - also has 'must' language that is inappropriate; s/must/SHOULD/ > > See above. > > > - max-objects-per-update > > - extremely implementation-specific; Does this assume a server > generates > > updates > > by counting objects and stopping when this value is reached? > > - the text is not clear if it means objects or object instances? Do > > child nodes count > > as instances? IMO this object should be removed or changes to max. > > bytes per update > > (also implementation-specific) > > I agree that this is implementation-specific, and a byte-count as > well. It assumes that the implementation uses very static > datastructures. But I think it can be ok - an implementation that > doesn't have such static limits will not instantiate this leaf. > > > > Then there should be text in the description-stmt that this leaf will not > > be instantiated if the server implementation does not restrict an update > > to a specific number of objects. > > BALAZS2: We have the following text in the sys-cap module description. I > hope that is OK: > > “If no entries are found in the previous steps the > > publisher is not capable of providing a value because > > it is unknown, the capability is changing for some reason, > > there is no specified limit etc. In this case the > > system's behavior is unspecified. “ > > This is actually a general issue, that sometimes it is not possible to > provide a meaningful value for a capability. > > > > What about the supported-update-period leaf-list? > > If a server allows any centi-second value from 1 sec to 1 hour then this > will > > be a leaf-list with 5900 instances in it.. Since there is no reason to > limit the upper-bound > > (e.g., client wants 1 statistics update per day) this leaf-list will > likely have millions > > of instances in it. > > > > IMO this leaf-list should be removed. The minimum-update-period is > sufficient. > > > > BALAZS2: There are implementations and standards that use specific values > not ranges. > > > The YANG-Push standard simply specifies "centiseconds" as the type. There is no mention in RFC 8641 of anything related to supporting a subset of this data type. The YANG syntax for "centiseconds" allows for 4 billion distinct values: typedef centiseconds { type uint32; description "A period of time, measured in units of 0.01 seconds."; } IMO this object could be added via augment by a vendor or other SDO. It has no relevance to the YANG-Push standard. > > > /martin > > Andy > > > > > Andy > > > > > > > > - supported-excluded-change-type > > - this union has overlapping enumeration implied values > > suggest assigning value -2; and value -1; to none and all enums > > > > > > Andy > > > > > > > > On Tue, Jan 7, 2020 at 5:04 AM Kent Watsen <kent+ietf@watsen.net> wrote: > > > > > > > > Dear WG, > > > > > > This is a fairly substantial update that defines a generic > > > "ietf-system-capabilities’ > > > module and a separate "ietf-notification-capabilities” module that > > > augments into it. > > > > > > We could start WGLC #2 now, but it would be good to get a few > high-level > > > reactions > > > from the WG before doing so. > > > > > > Please provide comments as to if you believe the draft is ready for > WGLC > > > #2. > > > > > > Thanks, > > > Kent // as shepherd > > > > > > > > > > On Jan 7, 2020, at 3:28 AM, internet-drafts@ietf.org wrote: > > > > > > > > > > > > A new version (-09) has been submitted for > > > draft-ietf-netconf-notification-capabilities: > > > > > > > > https://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-capabilities-09.txt > > > > > > > > > > > > The IETF datatracker page for this Internet-Draft is: > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/ > > > > > > > > Diff from previous version: > > > > > > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-09 > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission > > > > until the diff is available at tools.ietf.org. > > > > > > > > IETF Secretariat. > > > > > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > >
- Re: [netconf] New Version Notification - draft-ie… Kent Watsen
- Re: [netconf] New Version Notification - draft-ie… Rob Wilton (rwilton)
- Re: [netconf] New Version Notification - draft-ie… Kent Watsen
- Re: [netconf] New Version Notification - draft-ie… Andy Bierman
- Re: [netconf] New Version Notification - draft-ie… Balázs Lengyel
- Re: [netconf] New Version Notification - draft-ie… Martin Bjorklund
- Re: [netconf] New Version Notification - draft-ie… Balázs Lengyel
- Re: [netconf] New Version Notification - draft-ie… Andy Bierman
- Re: [netconf] New Version Notification - draft-ie… Martin Bjorklund
- Re: [netconf] New Version Notification - draft-ie… Balázs Lengyel
- Re: [netconf] New Version Notification - draft-ie… Balázs Lengyel
- Re: [netconf] New Version Notification - draft-ie… Kent Watsen
- Re: [netconf] New Version Notification - draft-ie… Andy Bierman
- Re: [netconf] New Version Notification - draft-ie… Balázs Lengyel
- Re: [netconf] New Version Notification - draft-ie… Rob Wilton (rwilton)
- Re: [netconf] New Version Notification - draft-ie… Andy Bierman
- Re: [netconf] New Version Notification - draft-ie… Balázs Lengyel
- Re: [netconf] New Version Notification - draft-ie… Reshad Rahman (rrahman)
- Re: [netconf] New Version Notification - draft-ie… Rob Wilton (rwilton)
- Re: [netconf] New Version Notification - draft-ie… Reshad Rahman (rrahman)