Subject: Re: Last Call: <draft-ietf-netmod-opstate-reqs-04.txt> (Terminology and Requirements for Enhanced Handling of Operational State) to Informational RFC

From: tom p. <[email-masked]>
Date: Wed, 3 Feb 2016 09:29:42 +0000

This I-D worries me.  I see it as very important, but can it be
understood by those who have not read the thousands of e-mails about it
(and its precursors) on the netmod WG list?  I see it as recasting
network management for the next 10 years, in the way that RFC3535 (IAB
Workshop) has for the past 10, a workshop that led to NETCONF, RESTCONF,
YANG and so on.  Yet there are no references back to this work, no
definitions imported from this work, in what
I see as a major change to this work and the RFC that describe it; the
only normative reference is RFC2119!

That IAB workshop stressed configuration at the expense of state, and
gave the former a very narrow role, and this has driven all the work
since.  This I-D makes no reference to those terms, uses configuration
in a different sense and even refers to 'configuration state' which,
hithertoo, would have been the oxymoron to end all oxymorons.  As I say,
read all the posts on the netmod list and you may know what it means,
but I worry.

My own take on this topic is that because of the stress on
configuration, as narrowly defined, YANG and NETCONF have had problems
dealing with some common scenarios where state and configuration
intertwine, such as hot-plugging an interface card, or modelling a
routing table with inputs from various sources.  I see these as solved
problems, albeit not very elegantly, in the current YANG models and see
these new requirements, at least in part, as a request to change YANG or
NETCONF or both to provide a more elegant solution to those problems so
perhaps I am a bit cynical about the benefits that a solution to these
requirements will bring - the problem, at least in part is solved, let's
move on to another one.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, February 02, 2016 2:42 PM

>
> The IESG has received a request from the NETCONF Data Modeling
Language
> WG (netmod) to consider the following document:
> - 'Terminology and Requirements for Enhanced Handling of Operational
>    State'
>   <draft-ietf-netmod-opstate-reqs-04.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2016-02-16. Exceptionally, comments may
be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document primarily regards the difference between the intended
>    configuration and the applied configuration of a device and how
>    intended and applied configuration relate to the operational state
of
>    a device.  This document defines requirements for the applied
>    configuration's data model and its values, as well as for enabling
a
>    client to know when a configuration has been fully applied or not,
>    how to access operational state, and how to relate intended
>    configuration nodes to applied configuration and derived state
nodes.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/
>
> IESG discussion can be tracked via
>
https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 3 Feb 2016 09:20:46 -0800

> requirements will bring - the problem, at least in part is solved, let's
I cannot disagree with anything you wrote.
I suggest people read this draft and decide for themselves.

> Tom Petch

Andy