Subject: [Netconf] Fwd: New Version Notification for draft-lengyel-netconf-notification-capabilities-01.txt

From: Balazs Lengyel <[email-masked]>
Date: Wed, 13 Jun 2018 16:19:16 +0200

Hello,

I submitted a new version of the
draft-lengyel-netconf-notification-capabilities updated with
comments from the last IETF and others. I would like to get this
adopted as a workgroup item. Please review it and if you like it,
please indicate that you support it as a workgroup item.

Changes:

o  Augment only the new yanglib branch

o  Correct the conditions for notifying about state data

o  Corrections, clarifications

regards Balazs

-------- Forwarded Message --------

Subject:

New Version Notification for
draft-lengyel-netconf-notification-capabilities-01.txt

Date:

Wed, 13 Jun 2018 01:57:58 -0700

From:

[email-masked]

To:

Alexander Clemm <[email-masked]>, Balazs Lengyel
<[email-masked]>

A new version of I-D, draft-lengyel-netconf-notification-capabilities-01.txt
has been successfully submitted by Balazs Lengyel and posted to the
IETF repository.

Name: draft-lengyel-netconf-notification-capabilities
Revision: 01
Title: YangPush Notification Capabilities
Document date: 2018-06-13
Group: Individual Submission
Pages: 10
URL: https://www.ietf.org/internet-drafts/draft-lengyel-netconf-notification-capabilities-01.txt
Status: https://datatracker.ietf.org/doc/draft-lengyel-netconf-notification-capabilities/
Htmlized: https://tools.ietf.org/html/draft-lengyel-netconf-notification-capabilities-01
Htmlized: https://datatracker.ietf.org/doc/html/draft-lengyel-netconf-notification-capabilities
Diff: https://www.ietf.org/rfcdiff?url2=draft-lengyel-netconf-notification-capabilities-01

Abstract:
This document proposes a YANG module that allows a YANG server to
specify for which data nodes it will send "YANG Datastore
Subscription" on-change notifications. It also proposes to use YANG
Instance Data to document this information in implementation time.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 13 Jun 2018 20:11:43 +0000

Hi Balazs,

This is good stuff.   I certainly would vote for adoption.

Some other thoughts:

Section 2
//which ones they are not/which ones are not/

Not sure what “purely model driven” means.   Is this getting to the point that sometimes for a single schema, some instance data might be subscribable, and some might not?

For implementation time information, it might be good to describe the interaction of this information with run-time on-change support markings.  E.g., is it possible for implementation time to be “Yes” and run-time to be “No”?  Should we care about this?

Section 3.1
Instead of boolean for notification-sent-for-config-default and notification-sent-for-state-default, should there be a boolean for each datastore?

Thanks,
Eric

From: Netconf <[email-masked]> On Behalf Of Balazs Lengyel
Sent: Wednesday, June 13, 2018 10:19 AM
To: [email-masked]
Subject: [Netconf] Fwd: New Version Notification for draft-lengyel-netconf-notification-capabilities-01.txt

Hello,

I submitted a new version of the draft-lengyel-netconf-notification-capabilities updated with comments from the last IETF and others. I would like to get this adopted as a workgroup item. Please review it and if you like it, please indicate that you support it as a workgroup item.

Changes:

-------- Forwarded Message --------
Subject:

New Version Notification for draft-lengyel-netconf-notification-capabilities-01.txt

Date:

From:

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

To:

Alexander Clemm <[email-masked]><mailto:[email-masked]>, Balazs Lengyel <[email-masked]><mailto:[email-masked]>

IETF repository.

Revision:     01

Pages:        10

Abstract:

The IETF Secretariat

--

Senior Specialist

Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 14 Jun 2018 13:00:40 +0200

On 6/13/2018 10:11 PM, Eric Voit
(evoit) wrote:

Hi
Balazs,

This
is good stuff.   I certainly would vote for adoption.

Some
other thoughts:

Section
2

//which
ones they are not/which ones are not/

BALAZS: OK

Not
sure what “purely model driven” means.   Is this getting to
the point that sometimes for a single schema, some instance
data might be subscribable, and some might not?

BALAZS: Purely model driven OAM application would be something that
e.g. mirrors the datastore in the NMS, but does not really care what
the data means. It job is just to get the data into the NMS. As long
as it has a valid model, it does not care how that has changed over
time.

Yes Martin and some others wanted to handle the use-case where the
capability of sending on-change notifications depends on things like
1) HW availability, HW version running the SW or 2) even the CPU
load. Things that change, but not too rapidly, otherwise it becomes
meaningless.

For
implementation time information, it might be good to
describe the interaction of this information with run-time
on-change support markings.  E.g., is it possible for
implementation time to be “Yes” and run-time to be “No”?
Should we care about this?

BALAZS: This is mentioned in the instance data draft, but also at
the end of section 3.

If the information retrieved via Netconf/Restconf and the YANG

Instance Data File conflict, the former MUST be considered

authoritative.

Section
3.1

Instead
of boolean for notification-sent-for-config-default and
notification-sent-for-state-default, should there be a
boolean for each datastore?

BALAZS: For config=false the answer is easy, only valid for
operational.

For config=true your question is valid. However you could ask the
same for the full YAM including the
on-change-notification-capability list. IMO that would be an
overkill.

Thanks,

Eric

From:
Netconf <[email-masked]>
On Behalf Of Balazs Lengyel

To: [email-masked]

Subject: [Netconf] Fwd: New Version
Notification for
draft-lengyel-netconf-notification-capabilities-01.txt

Hello,

I submitted a new version of the
draft-lengyel-netconf-notification-capabilities updated with
comments from the last IETF and others. I would like to get
this adopted as a workgroup item. Please review it and if
you like it, please indicate that you support it as a
workgroup item.

Changes:

regards Balazs

-------- Forwarded Message --------

Subject:

Date:

From:

[email-masked]

To:

Alexander Clemm <[email-masked]>,
Balazs Lengyel
<[email-masked]>

IETF repository.

Revision:     01

Pages:        10

Abstract:

The IETF Secretariat

--

Senior Specialist

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 19 Jun 2018 10:26:48 +0200 (CEST)

Hi,

Balazs Lengyel <[email-masked]> wrote:
> draft-lengyel-netconf-notification-capabilities updated with comments
> from the last IETF and others. I would like to get this adopted as a
> workgroup item. Please review it and if you like it, please indicate
> that you support it as a workgroup item.
> 
> Changes:

The model you propose has the structure:

     augment /yanglib:yang-library/yanglib:module-set/yanglib:module:
       +--ro notification-sent-for-config-default?   boolean
       +--ro notification-sent-for-state-default?    boolean
       +--ro on-change-notification-capability* [data-node-selector]
          +--ro data-node-selector    nacm:node-instance-identifier
          +--ro on-change-notification-sent?            boolean

(NOTE: the tree diagram in the draft doesn't match the data model.)

So there is one "on-change-notification-capability" list per *module*
in a module-set.

This seems quite complex for a client to digest.  It is not clear how
the "data-node-selector" relates to the "module".  It probably works
fine when a module is completely self-contained with no augments, and
no other module that augements it, but it gets complicated with
augemnts.

Wouldn't it be better to have a single structure per datastore?

/martin

>  Subject:  New Version Notification for
>  Date:     Wed, 13 Jun 2018 01:57:58 -0700
>  From:     [email-masked]
>  To:       Alexander Clemm <[email-masked]>, Balazs Lengyel