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

From: Randy Presuhn <[email-masked]>
Date: Thu, 21 Jan 2016 13:45:03 -0800 (GMT-08:00)

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:
>> >> Hi -
>> >> 
>> >> I was asked to take a look at draft-ietf-netconf-yang-library-03,
>> >> so here are a few of my comments.
>> >> 
>> >> Comments on draft-ietf-netconf-yang-library-03.txt
>> >> 
>> >> Abstract:
>> >>   First sentence includes the phrase "YANG modules
>> >>   used by a device to represent management and protocol
>> >>   information."  It's unclear what is meant by "protocol
>> >>   information", particularly since the following sentence
>> >>   uses "protocols" to mean (AFAICT) seomthing else.
>> >> 
>> >>   Second sentence gives a requirement for cache management,
>> >>   but the document doesn't address it in any meaningful way.
>> >>   This sentence should either be deleted or amended to declare
>> >>   that the requirement is recognized but solutions to the
>> >>   problem are outside the scope of this document.
>> >
>> >How about this NEW Abstract:
>> >
>> >  This document describes a YANG library, which provides information
>> >  about all the YANG modules used by a server.  Simple caching
>> >  mechanisms are provided to allow clients to minimize retrieval of
>> >  this information.
>> 
>> This addresses the thrust of my comment.
>> 
>> But....
>> I wonder whether it might be better (in this instance, since
>> abstracts are read with relatively little context) to replace
>> "server" with something that would make it clear that NETCONF
>> (and other management protocol) servers were intended, and not
>> servers in some more general sense.  "Device" was problematic
>> because a device might host multiple (NETCONF) servers; I realize
>> this is intended to work with more than just NETCONF, but the naked
>> term "server" in this particular case (without benefit of the
>> definitions section) leaves me uncomfortable.
>
>How about:
>
>  This document describes a YANG library, which provides information
>  about all the YANG modules used by a network management server
>  (e.g., a Network Configuration Protocol (NETCONF) server).

Sounds good to me.  Thanks!

>> >> Introduction:
>> >>   First paragraph states "This information changes very
>> >>   infrequently, so it is important that clients be able
>> >>   to cache the YANG library and easily identify if their
>> >>   cache is out-of-date."  The assertion "changes very
>> >>   infrequently" may characterize some existing implementations
>> >>   today, but is this a necessary, *architectural* implication
>> >>   for all systems using YANG to model information?   I'd like
>> >>   to see either documention of this alleged archictectual
>> >>   limitation, revision of this sentence to identify this
>> >>   limiting assumption of this particular model, or if there
>> >>   is no *architectural* limitation and this model could
>> >>   in fact be useful in dynamic environments, re-working
>> >>   this sentence to justify cacheing without presuming
>> >>   a nearly-static environment.
>> >
>> >I think this text simply means that the module set "normally" changes
>> >less often than a client access the server, and thus that caching can
>> >be useful.
>> >
>> >Maybe we can simply say:
>> >
>> >OLD:
>> >
>> >  If a large number of YANG modules are utilized by the server, then
>> >  the YANG library information needed can be relatively large.  This
>> >  information changes very infrequently, so it is important that
>> >  clients be able to cache the YANG library and easily identify if
>> >  their cache is out-of-date.
>> >
>> >NEW:
>> >
>> >  If a large number of YANG modules are utilized by the server, then
>> >  the YANG library information needed can be relatively large.  Thus
>> >  it is important that clients be able to cache the YANG library and
>> >  easily identify if their cache is out-of-date.
>> 
>> Works for me.  I'd replace the last "if" with "whether" as a courtesy
>> to non-native speakers.
>
>Ok.
>
>> Does the second occurrance of "YANG library" refer to the same thing
>> as the previous occurance of "YANG library information"?
>
>Yes.  Should we use "YANG library contents" in both places instead?

If that's what's intended, I think that would be fine.

>> In my mind
>> the summary represented by this "library" module and the actual
>> definitions thus summarized are two distinct things, and a client,
>> depending on what that client needs to do, might need to only cache
>> one or the other.
>
>[...]
>
>> >> 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".

>  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."

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?

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Jan 2016 22:53:06 +0100 (CET)

Hi,

[...]

Ok.

> when the library changes; it has to be a "sure thing."

Maybe we should simply remove this "for example" sentence?

> 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.

/martin