Subject: Re: [Netconf] NMDA comments

From: Vladimir Vassilev <[email-masked]>
Date: Thu, 3 Aug 2017 22:53:01 +0200

Hello,

On 07/17/2017 12:38 PM, Balazs Lengyel wrote:

> draft-nmdsdt-netconf-rfc7895bis-01
> -------------------------------------------
> A lot of things should be mandatory and are not including module-name, 
> revision. They are needed by the user. It is even stranger that 
> deviations refer t modules by name, but the name is optional in the 
> list of modules.
>
> Is it an error if a module containing only config=false data is listed 
> for the running datastore? IMHO not, it should just be ignored in the 
> running datastore?
Right. IMO 'mandatory true;' for both name and revision leafs after 
removing them as list keys was the intention (right?).

I would like to use the occasion to propose the removal of the 
'revision' key from the 'deviation' list making the revision leaf 
mandatory true instead. IMO it is a logical contradiction that exists in 
the original rfc7895 module allowing multiple instances of the same 
module name with different revisions to be listed while the description 
statements state that only a single revision of a module (the one that 
has conformance-type=implement) can be listed as deviation.

/Vladimir
>
> The module-set-id only reference to the legacy part both in 
> /yanglib:yang-library-change/yanglib:module-set-id and 
> /yanglib:modules-state/yanglib:module-set-id. I assume this will 
> change also if something changes in the /yanglib:yang-library and the 
> notification will also be sent.
>
> regards Balazs
>
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 4 Aug 2017 16:24:13 +0000

Hi Balazs,

> General: It should be more clearly describe how legacy devices that do 
> not wish to support NMDA should behave. They still need part of the 
> operational datastore, but might not (will probably not) have a separate 
> operational state for configuration from running/intended. Shall they 
> just present the running configuration as part of operational?

The restconf-nmda draft states what a server must do in order to indicate
it supports NMDA.  Similar statements could be put into the nmda-netconf
draft.  But I think your question is more about how a server can implement
the new yang library module while having the same operational behavior as
before - right?  Perhaps rfc7895bis could have an Appendix section that 
maps various scenarios (e.g., NETCONF with :candidate + :writable-running,
RESTCONF as it is) to yang-library 'datastores' with 'properties'.  Would
this work?

> draft-ietf-netmod-revised-datastores-03
> 4.1, 4.3)  "If a device does not have a distinct <startup> and 
>            non-volatile is available, the device will typically
>            use that non-volatile storage to allow <running> to
>            persist across reboots."
>
> It has been a long standing problem for us that we don't prescribe
> how and when the device persists configuration. "Typically" is a
> very week word I would like to see a SHOULD or better a MUST.

I'm unsure if the architecture document should be overly 
proscriptive on this.  Currently we define mechanisms enabling
the server to accurately describe what it does, with the new
datastore properties (e.g., auto-persist), which then lets the
market decide what's best.

> draft-dsdt-nmda-netconf-00
> For us the most important part of the whole datastore restructuring is 
> the clean association of config and system-state data. We must be able 
> to issue a get-xxx operation to get ONLY the system-state data for a 
> particular branch. I don't see any way to filter a get-data on 
> config=false. Problem.
>
> I think we should have a get-data filter based on origin
>
> Yang model, get-data) IMHO 2 leafs are missing from get-data: 
> with-defaults and origin

I'd like to think that we could extend subtree filtering to include
metadata, but so far the config true/false attribute is not considered
metadata.  In lieu of that, perhaps <get-data> could take a 'content'
parameter like https://tools.ietf.org/html/rfc8040#section-4.8.1.

> draft-dsdt-nmda-guidelines-01
> I would love to see a plan for updating existing models. 

Please see Rob's 7/20 email on the netmod list.

> Our priorities being ietf-system, ietf-interfaces

ietf-interface is being worked on.  Regarding ietf-system, Rob wrote:

  RFC 7317: A YANG Data Model for System Management
  [email-masked] defines system-state
  => Model update looks to be trivial.  Martin Bjorklund
  is one of the authors, so hopefully he can help issue
  a updated version.

That said, with all that's going on, I don't imagine this module's
update will be prioritized.  If important, maybe you can submit
an rfc7317bis I-D?

> Page 8) "(c) For published models, the model should be republished with an
>    NMDA-compatible structure, deprecating non-NMDA constructs."
>
> RFC7950 is very vague about what deprecated means (IMHO this is a 
> problem in the RFC).  "deprecated" indicates an obsolete definition,
> but it permits new/continued implementation".   This does mean the fully
> functional implementation MUST still be in place, it allows a node to
> remove it.  If we allow a node to remove e.g. /interfaces-state that
> is a problem.
>
> What do we really mean in this case? We better state it explicitly.

I personally think the definitions are okay.  What's missing is knowledge
of if the server implements the deprecated nodes or not.  Note that even
the 'obsolete' definition allows for continued use.   One way a client
can determine it a server implements deprecated/obsolete nodes is by
trying to get the node(s) with-defaults.  But my guess is that a client
that has the wherewithal to do that can just as easily move to support
the module's new nodes.   What are you asking for, errata on RFC 7950?

> deviations refer t modules by name, but the name is optional in the list 
> of modules.

Fixed in my local copy.

> for the running datastore? IMHO not, it should just be ignored in the 

I'm okay with this, but I'd hope that validating software would flag it
with a warning.

> change also if something changes in the /yanglib:yang-library
> and the notification will also be sent.

Good catch, the yang-library-change notification definition wasn't
updated before.  Regardless which node the leafref points to,
/modules-state/module-set-id or /yang-library/module-sets/module-set/id,
the node s of type 'string'.  This notification enables clients to
maintain a cached listing of the modules a server supports.  To be
backwards compatible, a server should only send this notification for
when the module-set used by the conventional datastores is modified.
However, just doing this doesn't support the new datastores.  It seems
like what is needed is a listing of datastores that use the module-set.
What do you think?

Kent // contributor