Subject: [netmod] NMDA comments

From: Balazs Lengyel <[email-masked]>
Date: Mon, 17 Jul 2017 12:38:27 +0200

Hello,

Some comments to the NMDA drafts:

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?

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.

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

draft-dsdt-nmda-guidelines-01
-------------------------------------------
I would love to see a plan for updating existing models. Our priorities 
being ietf-system, ietf-interfaces

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.

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?

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Jul 2017 13:23:23 +0200

I am only responding to the NETMOD specific comments.

On Mon, Jul 17, 2017 at 12:38:27PM +0200, Balazs Lengyel wrote:
> 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?

If the <applied> of a device _always_ equals <intended>, then
reporting <intended> as <applied> is obviously correct. If <applied>
and <intended> are only _mostly_ the same, well then customers will
tell you at the end whether they want the differences to be visible.

Note that a single say IP address list in <operational> may have
entries from <intended> but also from other sources (e.g., IP addresses
learned from DHCP or IP addresses generated by the system in addition
to configured IP addresses).

Focus on what is operationally used by a device when implementing
<operational> and the question where this data is originating from
should be a second thought.

> 4.1, 4.3)  "If a device does not have a distinct <startup> and non-volatile
> is
> 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.

Our protocols are not very clear about this and we decided to live
with this vagueness since we felt it is outside of the scope of our
task to change/update protocols semantics.
 
> 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.

The plan I think is to revise the core modules as soon as we get to it.

Not sure what you mean with 'node' above. Deprecated means that there
is a new definition that should be implemented/used but the old
definition has been kept to allow for a smooth transition.

/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: Balazs Lengyel <[email-masked]>
Date: Mon, 17 Jul 2017 15:36:26 +0200

My problem is that https://tools.ietf.org/html/rfc7950#section-7.21.2 does not say for a deprecated schema part "the old
definition has been kept" as you say. It only says for deprecated "it permits new/continued
implementation". The word "permit" only allows keeping the deprecated schema parts, it does not mandate, does not even encourage the implementer to keep the deprecated part.
regards Balazs
(BY node I meant network node a.k.a. netconf sever. Sorry my sloppy wording.)

On 2017-07-17 13:23, Juergen
Schoenwaelder wrote:

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Jul 2017 16:21:32 +0200

Balazs,

the wording originates from SMIv2, more specifically [RFC 2578]
section 6.1:

   While the value "deprecated" also indicates an obsolete definition,
   it permits new/continued implementation in order to foster
   interoperability with older/existing implementations.

Yes, deprecated does not imply that these definitions must be
implemented, and this may seem bad since this means you can't rely on
them being present.

The IETF is not republishing modules to 'just' change the status of
definitions and hence in reality something marked deprecated may stay
deprecated forever but new implementations may at some point in time
not implement deprecated definitions anymore. In an ideal world, the
IETF would have more agile processes for maintaining and updating
artefacts such data models but also this a 20 year old discussion
(back then in the context of MIB modules).

/js

On Mon, Jul 17, 2017 at 03:36:26PM +0200, Balazs Lengyel wrote:
>  My problem is that [1]https://tools.ietf.org/html/rfc7950#section-7.21.2 does not say for a deprecated schema part "the old
>    On 2017-07-17 13:23, Juergen Schoenwaelder wrote:
> 
>  Mobile: +36-70-330-7909              email: [2][email-masked]
> 
> References
> 
>    Visible links
>    1. https://tools.ietf.org/html/rfc7950#section-7.21.2
>    2. mailto:[email-masked]

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