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

From: Randy Presuhn <[email-masked]>
Date: Thu, 21 Jan 2016 14:09:51 -0800 (GMT-08:00)

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
>> >> >> 
>> >> >>   There's an ambiguity surrounding the word "unique" here.  If the
>> >> >>   set of modules and submodules reverts to some previous set, is the
>> >> >>   module-set-id *required* to revert to the corresponding prior value,
>> >> >>   or is it sufficient for the value to take on a new value every time
>> >> >>   the set of modules and submodules changes?
>> >> >
>> >> >Since it is only used to help caching on the client, it is ok if the
>> >> >value changes every time the set changes.  Do you think this needs to
>> >> >be clarified?
>> >> 
>> >> Yes.  It's easy to read the existing language as mandating some
>> >> kind of implementation-specific guaranteed-collision-free hashing.
>> >> It sounds like some much easier to implement and verify would meet
>> >> the requirement.
>> >
>> >Would this be better?
>> >
>> >OLD:
>> >
>> >  This mandatory leaf contains a unique implementation-specific
>> >  identifier representing the current set of modules and submodules.
>> >  This can for example be a checksum of all modules and submodules.
>> >
>> >NEW:
>> >
>> >  This mandatory leaf contains a unique implementation-specific
>> >  identifier representing the current set of modules and submodules.
>> >
>> >  The value of this leaf MUST change if the set of modules and
>> >  submodules in the YANG library changes.  There is no requirement
>> >  that the same set always results in the same  module-set-id value.
>> 
>> So far, so good, though I'd prefer "whenever" to "if".
>
>Ok.
>
>> >  The value can for example be a timestamp or a checksum of all
>> >  modules and submodules.
>> 
>> This still makes me a bit queasy - checksums are not
>> *guaranteed* to change, and it omits the simplest,
>> cheapest, and most robust example that comes to mind:
>> an integer (with a large potential range) incremented
>> with each change.  For this to work, it's not sufficient
>> that it be merely *highly probable* that the value changes
>> when the library changes; it has to be a "sure thing."
>
>Maybe we should simply remove this "for example" sentence?

That would be ok with me.

>> 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?  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.  :-)

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 Jan 2016 09:38:55 +0100 (CET)

[...]

> 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

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Jan 2016 04:13:39 -0800

Hi,

The WG discussed this issue at length and decided not
to send 2 notifications for the same thing.  That is why the
existing event is being used.  I don't think anything changed
since this decision was made.

Andy

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

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 24 Jan 2016 11:39:20 +0100

Andy,

can you provide a pointer to backup your claim?

Thanks,

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 24 Jan 2016 06:52:00 -0800

> can you provide a pointer to backup your claim?

I was wrong.
We discussed adding the module-set-id leaf to the netconf-capability-change
event.
But there is no augment-stmt in the YANG module for this detail.  Looks
like when we decided
to claim there is no relationship between ietf-netconf-monitoring and
RESTCONF,
that this got dropped or taken out.

So I don't care if a notification is added.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Jan 2016 08:34:35 +0100 (CET)

> So I don't care if a notification is added.

I think shuch a notification makes sense, in order to make
yang-library complete and self-contained, even though it means
duplicate notifications for NETCONF.  I believe this is the last issue
for yang library, so it would be very useful to hear people's opinion
before we publish an updated draft.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Jan 2016 09:46:50 +0100

> before we publish an updated draft.

Some observations:

- If the change of the module set should be considered a capability
  change by implementors, then I think we should spell this out
  somewhere so that implementors who also implement
  ietf-netconf-notifications.yang get this right.

- Given that module set changes are assumed to be infrequent, I think
  it is OK to have a more specific notification defined that makes the
  yang-library module self-contained.

- I would not be surprised to see applications that check the
  module-set-id upon 'session' start and then they will silently
  assume that module-set-id does not change for the duration of the
  'session' (and they won't sign up for notifications).  (I put
  session in quotes here since RESTCONF does not have a strict notion
  of a session.) Does it make sense to give guidance here?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Jan 2016 16:34:56 +0100 (CET)

>   ietf-netconf-notifications.yang get this right.

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/ ?

Suggestions for shorter / simpler text are welcome!

Ok.

>   of a session.) Does it make sense to give guidance here?

Do you have any suggestions for specific text?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Jan 2016 16:52:32 +0100

> Suggestions for shorter / simpler text are welcome!

Looks good to me. I think this helps to explain things.

> Do you have any suggestions for specific text?

I fear this might carry us away from this I-D and gets us into new
feature discussion space. But since you ask... I could envision
certain 'session' properties where I can ask the server to end the
'session' if assumptions my code makes about certain session
properties are not true anymore. But yes, something like this sounds
like an item for a wishlist.

/js