Subject: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 17 Aug 2012 00:12:34 +0200

Based on the comments and feedback and the positions
expressed on the mailing list, it is clear that after all
we did NOT have consensus on the new WG charter.

Without further ado, this is another proposed WG charter.
It focuses on the things that we do seme to have agreement on.

Pls comment and/or express your support or objections
no later than August 31, 2012.

OK, new chapter text (omitting the description of what we have
achieved sofar):

   In the current phase of the incremental development of NETCONF the
   workgroup will focus on following items:

   1. Advance NETCONF over TLS to be in-line with NETCONF 1:1.
      This means that RFC5593 needs to be updated.

   2. Based on the implementation, deployment experience and interoperability
      testing, the WG will document the status of NETCONF in a report.
      Based on this, the WG may decide to make some clarifications to
      RFC6241 and RFC6242 (then also fixing any reported errata).

   3. Since Netconf over BEEP and over SOAP seem not being deployed
      the WG will write a document that makes those 2 protocols
      (RFC4743 and RFC4744) HISTORIC.

Goals and Milestones:
   done     - Send with-defaults to IESG for consideration as Proposed Standard
   done     - WG Last Call on rfc4741bis
   done     - rfc4741bis to IESG for consideration as Proposed Standard
   done     - Send rfc4742bis to IESG for consideration as proposed Standard.
   done     - first WG draft (rev 00) on NACM posted
   done     - first WG draft (rev 00) on NETCONF specific YANG modules posted
   done     - WGLC for NACM document
   done     - WGLC for NETCONF specific notifications document
   done     - submit NACM document to IESG for consideration as Proposed Standard
   done     - submit NETCONF specific notifications  document to IESG for
              consideration as Proposed Standard
   Aug 2012 - submit initial WG draft for rfc5539bis
   Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic.
   Sep 2012 - WGLC for rfc5539bis
   Sep 2012 - WGLC for RFC4743 and 4743 to historic
   Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard
   Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic
   Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242
   Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience
   Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience
   Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc
              to IESG for publication as Informational RFC.
   Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close WG

Bert and Mehmet

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 17 Aug 2012 10:35:50 +0200

It is not necessary to mention in the charter that interested parties
can bring I-Ds into discussion following the usual WG process.

Mehmet 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext
> Bert Wijnen (IETF)
> Sent: Friday, August 17, 2012 12:13 AM
> To: netconf
> Subject: [Netconf] New WGLC for a proposed new WG Charter - respond
BEFORESept
> 1st
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 17 Aug 2012 11:04:18 +0200

Hi,

I had the impression that there was a reasonable agreement that work on operational state data is needed. Although this problem lies somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in a better position to start this work because apparently NETMOD WG will have to continue the work on the core data models for some time.

So I propose the following fourth item for the charter:

4. The WG will investigate the relationship and interactions between configurations and
   operational state data, propose their appropriate representation and semantics, and 
   devise methods for effective data modeling of both configurations and operational state data.
   It is expected that this work will be carried out in a close sooperation with the NETMOD WG.

Lada     

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 17 Aug 2012 11:09:15 +0200

We had agreed in our last f2f meeting that people would submit
individual I-Ds, and based on that we would potentially
consider work in this space. So by all means do submit
such individual drafts and discuss them on the mailing list.

But we do not have a good problem statement or starting I-D
to base this work on, so cannot put it on the current charter.

Bert Wijnen

---

From: t.petch <[email-masked]>
Date: Mon, 20 Aug 2012 10:26:13 +0100

---- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "Bert Wijnen (IETF)" <[email-masked]>; "netconf"
<[email-masked]>
Sent: Friday, August 17, 2012 10:04 AM
>
> I had the impression that there was a reasonable agreement that work
on operational state data is needed. Although this problem lies
somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in a
better position to start this work because apparently NETMOD WG will
have to continue the work on the core data models for some time.
>    It is expected that this work will be carried out in a close
sooperation with the NETMOD WG.

Trouble is, I think that the distinction between operational state and
configuration data is an artificial one, that is that the Netconf/MOD
WGs have adopted a definition that allows an object to be classified as
one or the other but that the distinction is not then a helpful one when
it comes to operating networks.

Whilst focussing on core data models, then this issue hardly arises, the
objects of interest are mostly configuration; get more sophisticated and
I think that we open up a can of worms that we are unlikely to resolve
any better than we have to date.

Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 20 Aug 2012 12:14:02 +0200 (CEST)

Hi,

> it comes to operating networks.

Actually, we have no definition of "operational state" in 6241 or
6020.  6241 mentions the term, but 6020 does not.  And this is the
problem - how to identify what is the operational state (the schema),
how to view the current operational state ("<get-operational>") and
how to edit the (writable subset of the) operational state.

> any better than we have to date.

Maybe, but I hope not :)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Aug 2012 12:15:03 +0200

> it comes to operating networks.

I agree, therefore the definitions of operational state and configuration data should be clarified.

> any better than we have to date.

It is clear that even the existing core modules need some more state data to be really useful. For example, the "ietf-ip" module doesn't offer any means for obtaining auto-configured adresses that are in operational use on an interface.

Yes, it can (and will) get tricky, but I think we should at least try to address this issue.

Lada

---

From: Kent Watsen <[email-masked]>
Date: Mon, 20 Aug 2012 08:40:10 -0700

On 8/20/12 6:14 AM, "Martin Bjorklund" <[email-masked]> wrote:

>And how to edit the (writable subset of the) operational state.
>

Is any operational-state writable?  How would it be different than
ephemeral configuration, such as what the SDN folks want?

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Aug 2012 09:17:47 -0700

> ephemeral configuration, such as what the SDN folks want?

I brought this issue during RFC 4741 discussions.
I wanted a 3rd classification for this 'middle ground', I called 'tconfig'.
But we ended up with a boolean <get-config> + <get>.

I brought it up again in 2009:
http://www.ietf.org/mail-archive/web/netmod/current/msg03812.html

The SDN discussions seem to include access-control, rollback and
roll-forward, and other CM-like tasks for which NETCONF already
has standard solutions. I don't know if "SDN content" should be
defined in YANG -- that is a different part of the problem space.

> Kent

Andy

---

From: t.petch <[email-masked]>
Date: Mon, 20 Aug 2012 17:18:12 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, August 20, 2012 11:14 AM
> how to edit the (writable subset of the) operational state.

That surprises me.  RFC6020 has a lot to say about configuration and
state data, implying that they are the two alternatives, the former
writable, that latter mostly not. Unless, of course, you are
differentiating
state and operational state, in which case I do not know what the
latter is.

Lada's item 4 also suggests to me that there are just two already
defined
alternatives.  If not, then item 4 does not seem to make sense to me.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Mon, 20 Aug 2012 17:29:23 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 20, 2012 4:40 PM

>And how to edit the (writable subset of the) operational state.
Is any operational-state writable?

<tp>
Previous list discussions suggested not, to me, but RFC6020 says

" state data: The additional data on a system that is not
      configuration data such as read-only status information and
      collected statistics [RFC4741]."
which could be parsed as
"read-only status information" "collected statistics" ...
or
"read-only status information" " read-only collected statistics"
"read-only ...".
I assumed the latter, as I did that state and operational state
are equivalent.

The routing(forwarding) table is an interesting case to model, with
entries put in explicitly, statically;
entries put in implicitly from the configuration of an ip address on an
interface;
entries learnt from a routing protocol;
entries calculated as a result of link state information from a
protocol;
and all that then subjected to a configurable filtering algorithm which
may or may not yield one or more best routes.
Operationally, I would hope to see the combined routing(forwarding)
table that the box is using, regardless of its classification by
configuration, state or whatever.

Tom Petch
</tp>

How would it be different than
ephemeral configuration, such as what the SDN folks want?

Thanks,
Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Aug 2012 18:45:15 +0200

> alternatives.  If not, then item 4 does not seem to make sense to me.

My take is that what really matters is the full set of operational state data because it is what governs the device behaviour. NETCONF then provides an interface for changing (parts of) this operational state.

As I understand it, "writable operational state", "ephemeral config" etc. just mean other similar (and usually simpler) interfaces.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 20 Aug 2012 21:37:02 +0200 (CEST)

> ephemeral configuration, such as what the SDN folks want?

I think it's the same thing.

/martin

---

From: Tina TSOU <[email-masked]>
Date: Mon, 20 Aug 2012 19:48:10 +0000

Tina

> defined in YANG -- that is a different part of the problem space.
[Tina] 
I think it should go to netmod WG. It is about data model.

---

From: Phil Shafer <[email-masked]>
Date: Mon, 20 Aug 2012 18:21:50 -0400

"operational state" is what the current operational state is, not
what you asked it to be.  The real state will be an outcome driven
by configuration data (the existing NETCONF datastores), external
sources (BGP peers, link state databases, RADIUS servers, DHCP
replies, etc), and some local logic (protocol engines, dhclient.conf,
etc).  You should always be able to ask "what did I tell you to set it
to" distinctly from "what is the current operational value".

Thanks,
 Phil

---

From: Kent Watsen <[email-masked]>
Date: Mon, 20 Aug 2012 16:18:37 -0700

>to" distinctly from "what is the current operational value".

This matches my view as well.

To me, ephemeral configuration is *config* that either goes to a special
datastore or to the "running" datastore with an XML-attribute indicating
that it's ephemeral.  Likewise, we either <get-config> on a special
datastore or with a flag to the running datastore indicating that
ephemeral config should also be returned, with the nodes annotated with a
XML-attribute to distinguish them from standard config.

Comparing this to Andy's 3rd-state (tconfig), I guess this puts me in the
"boolean boat"  ;)

Regarding moving this discussion to the NETMOD list so that the data
modeling aspects can be sorted, I think that it's the *conceptual* model
that needs to be worked out first and thus suggest keeping the discussion
here, if we choose to discuss it all, since it didn't come up as a charter
item before.  Of course, all this assumes that a XML-based protocol is
performant enough for the use-cases that we'd be trying to enable...

Thanks,
Kent

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 21 Aug 2012 00:43:02 +0000

I tend to agree as well.

I do think there are additional distinctions.  E.g. physical immutable properties associated with a device, such as its equipment type or serial number - clearly not config, but the term "operational data" does not capture it quite either.  Likewise, historical records (e.g. of events).  

At the end of the day, what is important is who "owns" the data, i.e. where it originates from - an external app or the managed system - this is what I think the operational / config data distinction ultimately refers to (making "operational" somewhat of a misnomer) - and whether the data is "transient" or "persistent", which could be covered by the notion of different data stores. 

One aspect or distinction that could perhaps be made clearer concerns the notion of data stores _complementing_ each other, versus providing _alternatives_ to one another.  The aspect of ephemeral data points to the need to perhaps distinguish multiple data stores, which collectively provide the "overall" view of the managed system, as opposed to e.g. the notion of running and startup and candidate which provides more alternative views of the same information.  The ability to make such a distinction of complementing vs "competing" data stores is something that appears to be missing.  

--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Monday, August 20, 2012 4:19 PM
To: Phil Shafer
Cc: [email-masked]
Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st

Thanks,
Kent

---

From: Xiang Li <[email-masked]>
Date: Mon, 20 Aug 2012 19:47:25 -0500

>     It is expected that this work will be carried out in a close sooperation with the NETMOD WG.

I can easily understand "ephemeral config" or Andy's "transient config", 
but the concept of " operational state data" and "the writable subset of 
the operational state" are rather  hard for me to grasp.

--Xiang

-- 
--Xiang Li
Web: www.seguesoft.com
Voice: 1 (872) 216-2610
Mobile: 1 (217) 472-4108

---

From: Xiang Li <[email-masked]>
Date: Mon, 20 Aug 2012 20:11:07 -0500

On 8/20/2012 6:18 PM, Kent Watsen wrote:
>> ....
>> To me, ephemeral configuration is *config* that either goes to a special datastore

I think Kent explained this very well.  I think "ephemeral config" (or 
Andy's "transient config") can still be considered as 'config data'. It 
would be nice we can keep things simple and conceptually only maintain 
two set of data: (readonly) state data and (readwrte) config data.

I am not sure the "ephemeral config" should go to a special datastore 
because doing that means the device needs to look at the "config 
datastore" and "transient config datastore" to get to its operational 
state.  Is that a bad or good thing, I don't know... guess further 
discussion is needed.
> or to the "running" datastore with an XML-attribute indicating
> that it's ephemeral.
That could work. But if a device does not support <:writable-running> 
then we have a problem.

--Xiang

-- 
--Xiang Li

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Aug 2012 18:40:44 -0700

On Mon, Aug 20, 2012 at 5:47 PM, Xiang Li <[email-masked]> wrote:
>> I had the impression that there was a reasonable agreement that work on
>> operational state data is needed. Although this problem lies somewhere
>> between NETCONF and NETMOD, I think the NETCONF WG is now in a better
>> position to start this work because apparently NETMOD WG will have to
>> continue the work on the core data models for some time.
>>
> I can easily understand "ephemeral config" or Andy's "transient config", but
> the concept of " operational state data" and "the writable subset of the
> operational state" are rather  hard for me to grasp.
>

I think <get-config> would not return 'tconfig' like I said in 2009.
That was wrong.  Martin's <get-operational> would return tconfig
and <edit-operational> would allow it to be changed.

It is a fuzzy boundary.
A config=true table to pre-load an ARP cache with static entries
seems clearly to be config.  But what if the entries are not stored
across a reboot but rather generated on the fly (e.g., launch VM)?
This is the middle ground -- client injecting stuff into the control plane.
This seems to be what SDN needs, and <edit-operational> would
address that.  It is not intended to write server state or statistics.

Andy

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 21 Aug 2012 09:46:30 +0200

PLEASE.... pay attention to the SUBJECT line.

We (WG chairs) are trying to get AGREEMENT of a pretty
simple, short, straight forward WG Charter to let us
finalize some work in the coming 3-6 months.

It was clear from earlier charter discussion (WGLC etc) that
the WG does NOT AGREE on what exactly to do for
- REST API or YANG API
- operational (or other) non-config data.

We (WG Chairs) are FINE if you discuss these matters (with
appropriate SUBJECT lines PLEASE) on teh WG list.
It may result in good individual I-Ds (for next ietf
or the one after that) so that we can THEN consider to
take any of these work items as WG work items.

For NOW, PLEASE do let us know if you support (or object to)
the simple short/concise proposed new WG charter.
If so, we can quickly get it approved by the IESG, and I
think we can then also quickly (i.e. within 3-6 months)
complete that work.

In parallel, we/you can discuss these other matters, but PLEASE
PLEASE use appropriate SUBJECT lines, so that it is easier to wade
thought the relevant postings for a specific subject issue.

Bert

---

From: t.petch <[email-masked]>
Date: Tue, 21 Aug 2012 09:51:10 +0100

Going back to the original question, I cannot see how we can
meaningfully work on item 2) without first resolving this issue of a
third type of data.  Most of the views expressed in the past day or so
seem to support the existence of a third type, which is something I
cannot reconcile with RFC6241 as currently worded.  In which case, item
2) does not make sense to me.  As Lada says, 'there was a reasonable
agreement that work on xxx' is needed for some choice of the phrase xxx.

Tom Petch

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "Bert Wijnen (IETF)" <[email-masked]>; "netconf"
<[email-masked]>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 21 Aug 2012 11:06:14 +0200 (CEST)

> agreement that work on xxx' is needed for some choice of the phrase xxx.

The way I see this is that NETCONF currently does not support
read/write of operational state.  This would be an additional feature
that we might add in the future.  But this should not preclude us from
verifying the existing protocol with its current features (which I
beleive what item 2 is about).

/martin

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 21 Aug 2012 11:33:19 +0200

> beleive what item 2 is about).
EXACTLY. It has been a long while (I believe) that we last did any
interoperability testing. Would be very good to know what the
state of the art is and if the RFCs are clear for implementers.

Bert

---

From: t.petch <[email-masked]>
Date: Tue, 21 Aug 2012 11:17:32 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 21, 2012 10:06 AM
> beleive what item 2 is about).

Yes, but should we be approving the definitions in NETCONF base of there
only being two kinds of data when we seem to have established that there
are
more? I think not.

I was not suggesting we go as far as Lada, in developing schema and
protocol,
but that we should update the definitions to accept that there is at
least
one more type of data - such as ephemeral configuration - which is a
subject
for future work.

I prefer 'ephemeral configuration' to operational state, since we have
resolutely
stated for 10 years than state is read only whereas configuration is
written, so
now to have writable state seems a bigger somersault than to have
ephemeral
configuration.

Tom Petch
> > > 4. The WG will investigate the relationship and interactions
between
> > configurations and
> > >    operational state data, propose their appropriate
representation
> > and semantics, and
> > >    devise methods for effective data modeling of both
configurations
> > and operational state data.
> > > >    In the current phase of the incremental development of
NETCONF
> > the
> > > >       Based on this, the WG may decide to make some
clarifications
> > to
> > > >    done     - Send rfc4742bis to IESG for consideration as
proposed
> > Standard.
> > > >    Aug 2012 - submit initial WG draft for making RFC4743 and
RFC4744
> > historic.
> > > >    Nov 2012 - Collect Implementation/Deployment reports for
RFC6241
> > and 6242
> > > >    Dec 2012 - Initial I-D for RFC6241/6242
implementation/deployment
> > experience
> > > >    Mar 2013 - Evaluate if more work needs to be done by NETCONF
WG
> > or close WG

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 21 Aug 2012 12:30:45 +0200 (CEST)

> only being two kinds of data when we seem to have established that there

Item 2) was:

  2. Based on the implementation, deployment experience and
     interoperability
     testing, the WG will document the status of NETCONF in a report.
     Based on this, the WG may decide to make some clarifications to
     RFC6241 and RFC6242 (then also fixing any reported errata).

I think both these activities can be done w/o introducing "operational
state" (or whatever the term will be).

However, if (as a result of the report) we open 6241, there is of
course an opportunity to define more terms etc...

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 21 Aug 2012 12:56:25 +0200 (CEST)

> now to have writable state seems a bigger somersault than to have

To me, "ephemeral configuration" seems to indicate that it is a
separate datastore, probably merged with the running datastore to
produce the initial operational state (what the device is *really*
using).

The IRS people had a use case where they wanted to inject routes into
the routing table.  If the routing table is operation state, they need
to modify the operational state through a protocol.

I think a solution that directly modifies the operational state is
easy to understand and use, but a solution that merges different
datastores will be very complex.  But I guess we need to work out the
details and describe the solutions we believe work in individual
drafts.

/martin

---

From: t.petch <[email-masked]>
Date: Tue, 21 Aug 2012 14:02:51 +0100

---- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 21, 2012 11:30 AM
> > > > third type of data.  Most of the views expressed in the past day
or
> > so
> > > > cannot reconcile with RFC6241 as currently worded.  In which
case,
> > item
> > > > agreement that work on xxx' is needed for some choice of the
phrase
> > xxx.

Yes, it can be done:-)

I think though, that given the current debate about how many states
there are, it would be wrong not to tackle the issue as part of 2)
i.e 2) should call out this issue as a possible clarification, that
we agree that this must be looked at even if we do not go as far
as new protocols or schema.

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 Aug 2012 15:19:04 +0200

> to base this work on, so cannot put it on the current charter.

OK, after this clarification I support the charter with your three items.

I am sorry for leading this thread a little astray, it was not my intention.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 Aug 2012 15:52:37 +0200

> produce the initial operational state (what the device is *really*

Why is it then called ephemeral? To me, this adjective indicates that this configuration will disappear after a while.

> to modify the operational state through a protocol.

But is this really different from NETCONF? The NETCONF client provides a list of static routes and these routes eventually appear in the routing table. Writing directly to the routing table just bypasses - for better or worse - all bells and whistles of the NETCONF stack (and maybe other software).

It's like with the speed of a car - a normal driver's interface are only the pedals while a serviceman may be able to connect a special-purpose computer to achieve the same effect more directly.

The statement that operational state is not writeble means (to me at least) that the NETCONF client can achieve modifications in the state only through writing something to the running datastore.
However, the state as such must be modifiable, otherwise the device wouldn't be very interesting.

> details and describe the solutions we believe work in individual

+1

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 21 Aug 2012 08:49:30 -0700

>> details and describe the solutions we believe work in individual

I agree with Martin that operational state can be added as a new capability.
There is no impact on interoperability of existing operations that I can see.

Here is a list of operational state examples that Lada raised 3 years ago:

   The recent examples demonstrate various interactions between config and
    operational parameters, e.g.

     - IP address configured either manually (from a config item) or via DHCP
     - use global value if local is not set (hold-time example)
     - operational routing table is a union of static routes (config item)
       and routes obtained from routing protocols

I think the each NETMOD YANG module addresses these operational state
issues in an ad-hoc manner.  The new feature we are calling "operational state"
is to be able to handle this class of data in a generic manner.

Currently we can use the description-stmt to say that
operStatus is related to the adminStatus leaf.  We can write
a custom RPC called <inject-route> if we want to modify
specific operational routing data.

I am not seen any generic solution proposals and I am not
convinced that a generic approach will be worth the cost,
and be that much better than the ad-hoc approach we
already have.

I certainly do not agree that base:1.1 is broken because we
have an ad-hoc solution instead of a generic solution for this corner-case.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 21 Aug 2012 10:42:02 -0400

>datastore or to the "running" datastore with an XML-attribute indicating

I have a hard time using the term "config" for a route learned via
BGP or an address learned via DHCP.  This will be hopelessly
confusing to modelers and reviewers.

Thanks,
 Phil

---

From: Kent Watsen <[email-masked]>
Date: Tue, 21 Aug 2012 10:26:16 -0700

>confusing to modelers and reviewers.

Agreed.  My use of ephemeral config wasn't intended to cover what's
learned from within protocols, which seems more like "operational state"
as far as NETCONF is concerned.

I liked very much what Alex wrote yesterday:

	At the end of the day, what is important is who "owns" the data, i.e.
Where
	it originates from - an external app or the managed system - this is what
I
	think the operational / config data distinction ultimately refers to
(making
	"operational" somewhat of a misnomer) - and whether the data is
"transient"
	or "persistent", which could be covered by the notion of different data
stores.

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Tue, 21 Aug 2012 11:04:39 -0700

>         or "persistent", which could be covered by the notion of different data

This sounds like model-specific meta-data to me.
Is also seems model-specific whether the internal
protocol behavior needs to be modeled at all.
(e.g., routing cfg vs. forwarding table).

I am a bit concerned about boiling a lake if the charter
is to identify every possible situation where a data modeler
might want to allow the client to alter service behavior.
Designing the solution for 1 popular use-case
doesn't make it a generic solution.

I like <get-operational>. That is long overdue.
I am not convinced at all that <edit-operational>
is going to be better than model-specific operations
like <inject-route>.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 21 Aug 2012 16:40:07 -0400

>is going to be better than model-specific operations

<edit-operational> means the model has to indicate if/how/when
the operational data can be munged.  I'd prefer is the operational
data be the _real_ operational data and if the model wants to allow
external interjection of data, they model that data and describe
how it interacts with config data, operational data, learned data, etc.

For example, if you expose your OSPF link state database as operational
data, allowing clients to edit it would be pointless.  The OSPF checksum
would fail, and you would get a new copy of the database.  But if you
want to alter how that routes in the LSDB are imported into other RIBs,
then that would need to be expressed in the model, and the router would
need to understand how to integrate data from protocols, configuration,
IRS, etc.

So I think we need to look at a new sort of NETCONF datastore that
I'll call "dynamic", in that data is put there dynamically during
the normal operation of the router and it's neither configuration
data nor operational data.  We used the term "control data" at the
last IETF, and either works, though "control" makes one think
"control plane", which is not completely accurate.  "Dynamic" is
pretty fuzzy, but, well, that's completely appropriate.

Many questions remain re: the interaction of config and dynamic data.
But my guess is that the model will have to describe this in words.

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 21 Aug 2012 16:46:16 -0700

Hi -

(new subject line, heeding Bert's plea)

> To: "Phil Shafer" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, August 21, 2012 10:26 AM

While that distinction is useful, more is needed, and it goes beyond
ownership.  It goes beyond whether a particular bit of data is
writeable or even persistent.  I think the first question is:

   (1) is it something that would make sense in *versioned*
         configuration data?  That is, if the value is changed, it's
         really a different configuration, from a configuration
         management perspective.

This begs a second question:

   (2) The flip side of this is that there may be knobs that can be
         twiddled, but which in a sense don't constitute a change to
         a system's configuration.

While (1) is likely to be persistent, it doesn't have to be.  Consider
portions of a system's configuration delivered by other protocols -
the mechanism for the persistence may lie outside the box.  Likewise,
(2) may include persistent post-it notes whose semantics put them
outside the scope of (1).  For example, a "Joe is monitoring this
interface" post-it should probably be persistent across re-boots,
but probably should not be considered as part of versioned
configuration data.

There are also the knobs that *do* things, but that we probably don't
want to make persistent.  For example, consider knobs on ephemeral
objects like connections, or the route ontogenesis.

Where does this all lead?  It leads me to the conclusion that
the persistence and +/- config of a piece of "configuration"
are distinct aspects, and that the current approach which
tends to mingle these will become increasingly problematic.
With the historic management protocols, this would be purely
a modeling issue, but the design of netconf makes it a
protocol issue as well.  Good luck.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Aug 2012 08:09:05 -0700

> protocol issue as well.  Good luck.

I like the 'config comment' tagging example.
Not only is config=false fuzzy, but so it config=true.
We have work to do. ;-)

Back in 2007, I thought the 3rd state (tconfig) was just like
config except save-to-nvstore skipped this data.  Transient
config can be added or deleted by the client or server, but
it was only part of the running config, never the startup config.

Now I think this implementation was too simplistic,
at least from a modeling perspective. It would be nice to get
both the model and the implementation correct.
The former is a much more subjective decision.

Andy

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 22 Aug 2012 20:55:32 +0200

Let's organize the observations mentioned earlier in this thread into perspective:

40 years ago, all routing information was config. Now it is mostly operational data exchanged over routing protocols.
15 years ago we configured our host addresses. Now that us usually taken care of by dhcp.
3 years ago base station frequencies and signal strengths were planned and configured, today that is often operational data exchanged over SON protocols.
Today network topology is configuration, in a couple of years it might be operational data exchanged over SDN protocols.

When I define "configuration" in our NETCONF+Yang trainings, it usually boils down to "the set of orders coming from the owner/commander of the system". Alex and Kent said something similar "At the end of the day, what is important is who "owns" the data, i.e. Where it originates from."

The truth is that with this definition, the set of objects that constitute the configuration evolves over time, and it varies with the use case. I think this is shown by the list of examples above. This makes me wonder if this is (only) a modeling issue. A single model declaring an element to be config or not, can't cover all use cases, current and future. Even adding some middle state(s) to the single model won't help really. Whatever you do here will only reflect the truth for a specific set of use cases. Whether an element is treated as config or not by a manager varies with the use case, and they vary over time.

In many use cases (at least the ones I selected above) I think the behavioral evolution can be summarized with: delegation.

A manager delegates certain aspects (elements) of the configuration to a sub-manager (protocol, mechanism). When that happens, the manager is no longer interested in viewing the sub-managed aspects as part of the (main) configuration. Those elements should no longer be visible in <get-config>, but in <get>. They should no longer be included in backup or rollback files visible to the manager. They should no longer be affected by a <lock> operation performed by the main manager. From the manager's perspective, this is now operational data. 

For the sub-manager, these elements should be treated as configuration. They should be visible in <get-config>, modified by <edit-config>, affected by a <lock> performed by the sub-manager. The sub-manager should not see the main part of the configuration, at least not be able to modify it.

From the network element's perspective, lowest of them all, the set of configurable elements is fixed. It is whatever the device offers to its managers, delegated or not. It is still called running.

So is the way to tackle the evolution of config true/false adding some <delegate> operation(s) to NETCONF?

Maybe not. 

Looking at the delegation concept more closely, I notice that this resembles the semantics of a role based access control system, implemented to its fullest. Could the main manager define access control rules that limits its own view of the configuration, turning some areas into (read-only) operational data? Could these rules limit the power of <lock> to not include items that the main manager cannot touch? Could the main manager configure a role for a sub-manager, such that the sub-manager can view and modify the parts the main manager delegates?

/Jan
--
Jan Lindblad, [email-masked], +46 702855728
Principal Solutions Architect, Tail-f Systems, www.tail-f.com

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 26 Aug 2012 23:23:04 +0200

On Tue, Aug 21, 2012 at 11:17:32AM +0100, t.petch wrote:
 
> I prefer 'ephemeral configuration' to operational state, since we
> have resolutely stated for 10 years than state is read only whereas
> configuration is written, so now to have writable state seems a
> bigger somersault than to have ephemeral configuration.

I do not know why you believe that state is necessarily read only. RFC
6244 has some material in sections 4.3 and 4.4. The recommendation
given in section 4.4. is not really workable, as we find out working
on real data models in NETMOD.

The first issue is that there is no standard way to retrieve
operational state other than duplicating large parts of the data
models, which seems costly and counter intuitive to modelers (who tend
to put config false objects next to config true objects). The get()
operation gives you a blend of operational state and configuration
state with the result that the data is useless when it overlaps.  I
personally consider the get() operation somewhat broken and useless
because of this. Sure, we can test that we got interoperable
implementations of get() and make NETCONF a standard, the practical
value of this however remains small. For me, something like
get-operational is really a needed bug fix.

The second issues is support for writable non-config / ephemeral /
control / ... layers or datastores or whatever. This is about adding a
new feature NETCONF currently does not have. This is harder to get
right and after the side discussions in Vancouver I am also not sure
we understand yet how this would work.

/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: "Patrick Gili (pgili)" <[email-masked]>
Date: Sun, 26 Aug 2012 21:47:21 +0000

I think some of the confusion we are experiencing has a lot to do with terminology.

In the past, we have traditionally only concerned ourselves with two types of data:

1) Configuration data, which when modified transforms the operational state of the device. It is worth noting that we have always limited to the scope of what can modify this data to management interfaces, such as CLI, SNMP, and NETCONF.

2) Operation data, which is strictly limited to read-only state, such as routes learned by protocols (e.g., BGP) and statistics (to name of few types of operational data).

YANG adequately models these types of data.

However, the evolution of feature sets over the last decade have blurred the lines between configuration and operational data. For example, during authentication of a subscriber session, a device may receive a policy that it needs to apply to the subscriber session. Typically, a policy consists of configuration data; however, we do not consider the policy pushed by the RADIUS server, because a management interface cannot change the policy and the device will not persist the policy when an actor saves the running datastore to the startup datastore. On the other hand, if I invoke a command from the device's console to list all the policies configured on the device, it is desirable to see the policy pushed by the RADIUS server in the same list as any other policy configured through a management interface. While some vendors provide separate commands for this purpose, it has been determined through experience that this is a pain point for operators and technicians.

Drive this evolution one step further and we are at the brink of SDN. One applicable example that comes to mind is a particular service provider (that I won't name) that wants to eliminate RADIUS and push policy (and other configuration) using NETCONF. In this example, they want to configure the policy and apply it to the subscriber session in a manner no different than if I was sitting at a console doing it manually. However, there are slight differences:

1)  This configuration can never persist.

2) This configuration ideally should revert when the subscriber session terminates. The reversion criteria I have spelled out here are particular to the example, but in general, the client that created the configuration should be able to specify reversion criteria, when met causes the device to revert the configuration.

3) There should exist a layered model of configuration that supports the override of lower priority configuration. At the bottom of this layer, we have what we all know today as the running datastore. The layers above this represent transient configuration applied according to the priority of the layer.

We are referring to this as transient configuration and keep it separate from the notion of "ephemeral configuration", which traditionally includes configuration inside the notion of the set of operational data created and maintained by mechanisms other than management interfaces, such as routing protocols, DHCP, AAA, etc.

-Patrick Gili

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Sunday, August 26, 2012 5:23 PM
To: t.petch
Cc: [email-masked]
Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st

On Tue, Aug 21, 2012 at 11:17:32AM +0100, t.petch wrote:
 
> resolutely stated for 10 years than state is read only whereas 
> configuration is written, so now to have writable state seems a bigger 
> somersault than to have ephemeral configuration.

I do not know why you believe that state is necessarily read only. RFC
6244 has some material in sections 4.3 and 4.4. The recommendation given in section 4.4. is not really workable, as we find out working on real data models in NETMOD.

The first issue is that there is no standard way to retrieve operational state other than duplicating large parts of the data models, which seems costly and counter intuitive to modelers (who tend to put config false objects next to config true objects). The get() operation gives you a blend of operational state and configuration state with the result that the data is useless when it overlaps.  I personally consider the get() operation somewhat broken and useless because of this. Sure, we can test that we got interoperable implementations of get() and make NETCONF a standard, the practical value of this however remains small. For me, something like get-operational is really a needed bug fix.

The second issues is support for writable non-config / ephemeral / control / ... layers or datastores or whatever. This is about adding a new feature NETCONF currently does not have. This is harder to get right and after the side discussions in Vancouver I am also not sure we understand yet how this would work.

/js

---

From: t.petch <[email-masked]>
Date: Tue, 28 Aug 2012 16:44:44 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Martin Bjorklund" <[email-masked]>; <[email-masked]>
Sent: Sunday, August 26, 2012 10:23 PM
> I do not know why you believe that state is necessarily read only.

Because most of what we have produced says so:-( and what we have
produced reflects the discussions on the list).

I remain unconvinced about the concept of operational state, that it
is a meaningful concept.  Reading what the operators asked for in
RFC3535,
"Some devices make it very hard to determine
        which parameters were administratively configured and which
        were obtained via other mechanisms such as routing
        protocols."
I always think of the routing table and think that that is by-and-large
a unique, if very common, problem and that trying to extrapolate from
the routing table to all the other data in a box is not helpful - there
is
nothing else like a routing table.  The ARP cache has some similarities
but is much simpler; MPLS FECs may be the other example.

A separate problem is the interface up/down.  An operator has configured
an interface as up and the box says down, because it knows best - the
line
card just blew a fuse.  This does have parallels elsewhere, with DHCP,
and may be worth generalising but has little conceptually in common
with routing tables IMO.

Statistics are different in other ways.  Read only, but only sort of; it
is
valuable to have a reset, so that counters may go to zero at midnight
or some such.  SMI recognised statistics as different with Counters
and that was good to have.  It struggled with the sheer volume of data -
I once set a MIB walk going on the RMONMIB and if I had not shut
the box down after several days, it would probably still be going some
years later.  But I see nothing in common with the routing table problem
and the interface status problem, just how to get meaningful information
from masses of raw data, ie do the maths in the box and ship out the
summary - and SMI did look at that but it did not seem
to catch on.

Tom Petch

RFC

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 29 Aug 2012 11:13:08 +0200

> is a meaningful concept.  Reading what the operators asked for in

It is difficult to argue about these concepts without having their definintion. These premises make sense to me though:

1. Each device has a set of system parameters/structures that *directly* influence the device   
behaviour, no matter how they were set (operator action, factory default, protocol, ...). I'd 
suggest to define this set as the "operational state" of the device. Operators need to be able to 
have one or more interfaces for viewing (a subset of) this set.

2. In order to be able to control the device, operators need an interface for specifying their instructions for intended changes to the operational state and, consequently, device behaviour. I'd suggest to call these instructions a configuration. The device takes a submitted configuration and applies it according to a certain algorithm depending on the configuration, active network protocols, built-in policies etc.

Examples of configuration interfaces are:

- NETCONF (or CLI), where the operator's instructions have to be installed as the "running configuration".
- Unix init scripts, where the instructions are essentially shell scripts.
- RESTful interface, where the operational state is exposed as a set of resources and some of them may be modified via HTTP methods.

Of course, the hard part is to define the relationship and interactions between a configuration and operational state. In the simplest case, a configuration parameter directly maps to an operational state parameter - the device may accept the configured value or not.

But there are also more complicated mappings, e.g.:

- One configuration parameter may disable a subsystem, i.e. a subtree in operational state.
- A list of configured entries get merged to a larger list which is a part of the operational state. An example is the routing table that contains static routes (= configuration) as well as routes learnt from routing protocols.
   
> and may be worth generalising but has little conceptually in common

Right, so the operator gave an instruction/request but the device knows better and doesn't accept it: the up/down parameter in operational state remains down.
 
> Statistics are different in other ways.  Read only, but only sort of; it

I think that statistics should be put aside and not considered a part of operational state - at least for the purpose of this discussion.

Lada 

>> operation gives you a blend of operational state and configurat

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 29 Aug 2012 12:08:00 +0200

Mmm... as far as I can determine, only ONE person has expressed
a clear YES I SUPPORT statement.
Others have diverged again into discussing "operational-state".
Good discussion, but not what we were trying to get consensus on.

Please express your SUPPORT or OBJECTION to the simple and
easy charter below. It is a short-term charter with work items
that we (seem) to have agreed on.

Additional/other work (on which we have no consensus for the
exact direction yet) can be brought to the WG in a normal manner
via submitting individual I-Ds and getting the WG to discuss it.
We can then  later add that to the charter of we find that the
WG is indeed interested in working on such things.

For NOW, PLEASE stick to YES I SUPPORT or NO I OBJECT

Bert

-------- Original Message --------
Subject: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st
Date: Fri, 17 Aug 2012 00:12:34 +0200
From: Bert Wijnen (IETF) <[email-masked]>
To: netconf <[email-masked]>

Goals and Milestones:

Bert and Mehmet

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 29 Aug 2012 12:09:09 +0200

YES I SUPPORT

Dan

> Behalf Of Bert Wijnen (IETF)
> Sent: Wednesday, August 29, 2012 1:08 PM
> To: Netconf
> Subject: [Netconf] REminder: deadline Aug 31st: New WGLC for a
proposed
> new WG Charter - respond BEFORE Sept 1st
> 
> Mmm... as far as I can determine, only ONE person has expressed a
clear
> YES I SUPPORT statement.
> Please express your SUPPORT or OBJECTION to the simple and easy
charter
> below. It is a short-term charter with work items that we (seem) to
have
> agreed on.
> 
> Additional/other work (on which we have no consensus for the exact
> direction yet) can be brought to the WG in a normal manner via
> submitting individual I-Ds and getting the WG to discuss it.
> We can then  later add that to the charter of we find that the WG is
> indeed interested in working on such things.
> 
> BEFORE Sept 1st
> Based on the comments and feedback and the positions expressed on the
> mailing list, it is clear that after all we did NOT have consensus on
> the new WG charter.
> 
> Pls comment and/or express your support or objections no later than
> August 31, 2012.
> 
achieved
> sofar):
>    done     - submit NACM document to IESG for consideration as
Proposed
> Standard
>    Oct 2012 - submit rfc5539bis to AD/IESG for consideration as
Proposed
> Standard
>    Nov 2012 - Collect Implementation/Deployment reports for RFC6241
and
> 6242

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Aug 2012 12:24:54 +0200

Hi,

I am kind of OK with this although I am not sure we really need to
have RFC6241/6242 implementation/deployment experience published as an
informational RFC. Even if we decide in Nov/Dec to advance, this does
not seem to be required (when we moved some of the ISMS documents to
Draft Standard, having an I-D was good enough).

But charters can be changed and I hope that we get to a clearer
consensus what to do and what not to do in Nov/Dec.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 29 Aug 2012 12:32:24 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> informational RFC.

+1

/martin

 Even if we decide in Nov/Dec to advance, this does

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 29 Aug 2012 12:33:27 +0200

+1

Dan

> Behalf Of Martin Bjorklund
> Sent: Wednesday, August 29, 2012 1:32 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Netconf] REminder: deadline Aug 31st: New WGLC for a
> proposed new WG Charter - respond BEFORE Sept 1st
> 
> > > clear YES I SUPPORT statement.
> > > charter below. It is a short-term charter with work items that we
> > > (seem) to have agreed on.
> > >
> > > Based on the comments and feedback and the positions expressed on
> > > the mailing list, it is clear that after all we did NOT have
> > > consensus on the new WG charter.
> > >
> Proposed Standard
> > >   done     - submit NETCONF specific notifications  document to
IESG
> for
RFC4744
> Proposed Standard
> > >   Mar 2013 - Evaluate if more work needs to be done by NETCONF WG
or
> > > close WG

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Aug 2012 06:49:20 -0700

+0

I am neutral on this charter.

When you say "support", does that mean the person is volunteering
to review drafts, write drafts, participate in email discussions?

Or does it mean you support the concept of the work item
as long as somebody else does all the work?

Please make sure you have the resources to do whatever work
gets chartered.

Andy

---

From: Xiang Li <[email-masked]>
Date: Wed, 29 Aug 2012 09:15:37 -0500

I support.

-- 
--
Xiang Li
Web: www.seguesoft.com
Voice: 1 (872) 216-2610

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 29 Aug 2012 16:16:57 +0200

inline

> I am neutral on this charter.

Thanks, that is fine

> to review drafts, write drafts, participate in email discussions?

in principle, yes, that is what it means

> as long as somebody else does all the work?

that too. We have however defined volunteers for the work items
(or so I believe). Yes, we do expect WG participants to review any
WG docs that get to WG LC.

> Please make sure you have the resources to do whatever work

I believe we do.
You agreed to an interop event. Maybe not to the writeup?
At the other hand, you earlier on agreed to advance 6241/42, which
would mean documenting th eresults (maybe not as RFC).

Bert

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Aug 2012 07:22:01 -0700

> would mean documenting th eresults (maybe not as RFC).

Yes -- I am willing to work on an interop report draft/RFC.
It would be very terse.  Each feature/capability would be
identified and documented wrt/ # of inter-operating implementations.

Andy

>>> BEFORE
>>> Sept 1st
>>>    Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or
>>> close
>>> WG
>>>
>>> Bert and Mehmet

---

From: t.petch <[email-masked]>
Date: Fri, 31 Aug 2012 12:08:57 +0100

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "t.petch" <[email-masked]>; "Juergen Schoenwaelder"
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 29, 2012 10:13 AM
> It is difficult to argue about these concepts without having their
> have one or more interfaces for viewing (a subset of) this set.

Right, I have no problem with this, only that it is new and different to
what we have previously discussed and is, for me, a fundamental change
of view.  I always have had a problem with the Netconf/netmod split of
configuration and state, seeing it as artificial.  Rather, what you
define above, is what I would have called, pre-netmod/conf,
configuration, by and large, with or without the epithet 'ephemeral', as
I think that many others would do.  It does not matter how the routing
(/forwarding) table entry got there, the routing table is part of the
configuration.

I have always read RFC3535 as wanting
- how to get a new box from the manufacturer operational
- how to get a failing box working again by a variety of means
and the netmod/conf view of configuration has focussed on the first
which, while
important, is not the whole story; and now we are starting to look at
the whole story.
Well, except that we are not, because it has been ruled out of scope pro
tem:-(

Tom Petch

> 2. In order to be able to control the device, operators need an
interface for specifying their instructions for intended changes to the
operational state and, consequently, device behaviour. I'd suggest to
call these instructions a configuration. The device takes a submitted
configuration and applies it according to a certain algorithm depending
on the configuration, active network protocols, built-in policies etc.
> - NETCONF (or CLI), where the operator's instructions have to be
installed as the "running configuration".
> - RESTful interface, where the operational state is exposed as a set
of resources and some of them may be modified via HTTP methods.
>
> Of course, the hard part is to define the relationship and
interactions between a configuration and operational state. In the
simplest case, a configuration parameter directly maps to an operational
state parameter - the device may accept the configured value or not.
> - A list of configured entries get merged to a larger list which is a
part of the operational state. An example is the routing table that
contains static routes (= configuration) as well as routes learnt from
routing protocols.
> Right, so the operator gave an instruction/request but the device
knows better and doesn't accept it: the up/down parameter in operational
state remains down.
> I think that statistics should be put aside and not considered a part
of operational state - at least for the purpose of this discussion.

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 31 Aug 2012 16:13:40 +0200

> (/forwarding) table entry got there, the routing table is part of the

Hmm, according to my definition, a routing table is a part of operational state. The term "configuration" is limited to the stuff explicitly written by the client/manager.

> Well, except that we are not, because it has been ruled out of scope pro

Do you mean it has been ruled out of scope because Bert didn't accept my fourth charter item? It is not how I see it - in fact, I believe there is now a general consensus that the "whole story" has to be addressed. The only problem is that nobody has proposed anything concrete so far, and Bert rightly demanded that such proposal(s) be first submitted as individual drafts.

Lada

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 31 Aug 2012 16:30:18 +0200

Exactly

On 8/31/12 4:13 PM, Ladislav Lhotka wrote:
> Do you mean it has been ruled out of scope because Bert didn't accept my
> fourth charter item? It is not how I see it - in fact, I believe there
> is now a general consensus that the "whole story" has to be addressed.
> The only problem is that nobody has proposed anything concrete so far,
> and Bert rightly demanded that such proposal(s) be first submitted as
> individual drafts.
>
> Lada
>

Exactly!

Bert