Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03

From: Randy Presuhn <[email-masked]>
Date: Fri, 22 Jan 2016 10:18:18 -0800 (GMT-08:00)

Hi -

The point is that the consequence of that decision is to impose
a requirement on any future protocol making use of this model.
Since this model's applicability is stated as essentially anything
using YANG-based data models, that seems like a rather large swath
of collateral damage.

Randy

-----Original Message-----

From: Andy Bierman 

Sent: Jan 22, 2016 4:13 AM

To: Martin Bjorklund 

Cc: Randy Presuhn , Netconf 

Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03

Hi,
The WG discussed this issue at length and decided notto send 2 notifications for the same thing.  That is why theexisting event is being used.  I don't think anything changedsince this decision was made.

Andy

On Fri, Jan 22, 2016 at 12:38 AM, Martin Bjorklund <[email-masked]> wrote:
Randy Presuhn <[email-masked]> wrote:

> Hi -

> >From: Martin Bjorklund <[email-masked]>

> >Sent: Jan 21, 2016 1:53 PM

> >To: [email-masked]

> >Cc: [email-masked]

> >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03

> >Hi,

> >Randy Presuhn <[email-masked]> wrote:

> >> Hi -

> >> >From: Martin Bjorklund <[email-masked]>

> >> >Sent: Jan 21, 2016 3:15 AM

> >> >To: [email-masked]

> >> >Cc: [email-masked]

> >> >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03

> >> >Randy Presuhn <[email-masked]> wrote:

> >> >> Hi -

> >> >> >From: Martin Bjorklund <[email-masked]>

> >> >> >Sent: Jan 20, 2016 7:00 AM

> >> >> >To: [email-masked]

> >> >> >Cc: [email-masked]

> >> >> >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03

> >> >> >Hi Randy,

> >> >> >Thank you for your review!  Comments inline.

> >> >> >Randy Presuhn <[email-masked]> wrote:

> >[...]

> >> >> >> 2.1.1 module-set-id

[...]

> >> Getting a bit beyond the scope of this draft, this leaf presumes

> >> a polling-based monitoring strategy.  Forgive me for thinking

> >> like an SNMP guy, but wouldn't it scale much better for the

> >> system to be able to generate a notification whenever this

> >> piece of information changes?

> >For YANG 1.1, the module-set-id is actually presented in the

> >capability in the <hello> message.

> >Since the module-set-id is part of a capability, the server will

> >generate a netconf-capability-change notification (defined in RFC

> >6470) if the module set changes.

> This is helpful, but now I'm going to ask a particularly

> ignorant question: does this explanation necessarily hold true

> for all protocols used to shovel around information defined

> using YANG models?

No.  I guess we could specify a notification "yang-library-change":

  notification yang-library-change {

    description

      "Generated when the set of modules and submodules supported

       by the server has changed.";

    leaf module-set-id {

      type leafref {

        path "/yanglib:module/yanglib:module-set-id";

      }

      mandatory true;

      description

        "Contains the module-set-id value representing the

         set of modules and submodules supported at the server at the

         time the notification is generated.";

    }

  }

but it is not obvious to me that such a notification would be the

correct solution.  If a new protocol gets defined that supports some

kind of capability discovery, shouldn't that protocol define how

capability changes are communicated in that particular protocol?

> That is, do all protocols based on YANG

> *necessarily* have a "<hello>" message and netconf-capability-change

> notifications?  It could be a mistake to treat quirks of the current

> implementation environments for this model as though they would

> hold true all future environments in which this model might be

> employed.  On the other hand, if this model is only intended to

> be used in netconf protocol environments, case closed.  :-)

One of the main ideas with this module is to have a generic mechanism

to discovery YANG modules regardless of protocol.  Hmm, this statement

clearly speaks for a generic notification...

/martin

_______________________________________________

Netconf mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/netconf

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 25 Jan 2016 13:38:58 -0800 (GMT-08:00)

Hi -

>Sent: Jan 25, 2016 7:34 AM
>To: [email-masked]
>Cc: [email-masked], [email-masked], [email-masked]
...
>Something like this:
>
>   Note that for a NETCONF server that implements YANG 1.1
>   [I-D.ietf-netmod-rfc6020bis], a change of the "module-set-id" value
>   results in a new value for the :yang-library capability defined in
>   [I-D.ietf-netmod-rfc6020bis].  Thus, if such a server implements
>   NETCONF notifications [RFC5277], and the notification
>   "netconf-capability-change" [RFC6470], a "netconf-capability-change"
>   notification MUST be generated whenever the "module-set-id" changes.
>
>or should it be s/MUST be/is/ ?

I prefer "is" or "would be".

Randy