Hi Juergen,
Thanks for the review and comments.
Yes, when I originally thought of this idea I intended using XML
attributes, but after discussion with a couple of colleagues, we saw a
couple of issue with using them:
1) One of the desired requirements in draft-openconfig-netmod-opstate-01
(section 4.5 last paragraph) is to have a unique path to identify the
intended cfg node vs the applied cfg node. I couldn't see how this
could be solved with attributes. I'm also not sure whether the separate
applied config data store solves this problem, although presumably a NMS
could store all paths as a (datastore, path) pairing.
2) I wanted to be able to represent config nodes for configuration that
are in the process of being deleted (i.e. applied but not intended), and
wasn't convinced that this could be achieved cleanly using attributes.
3) There doesn't seem to be any standard encoding for attributes in JSON
... although of course this doesn't prevent attributes from being used
in XML based encodings.
Thanks,
Rob
On 04/09/2015 08:38, Juergen Schoenwaelder wrote:
Hm. Adding a parameter to get-config() that changes the encoding of
data very fundamentally is somehow difficult to fall in love with.
If you would have used meta-data, things would likely easier to like,
e.g., instead of
<mtu>
<cfg-intended>9000</cfg-intended>
<cfg-status>waiting</cfg-status>
<cfg-status-reason>Linecard 1 is not available</cfg-status-reason>
</mtu>
using something like this
<mtu status="waiting" status-reason="Linecard 1 is not available">
9000
</mtu>
would have made more sense to me from an encoding point of view. There
might be issues with carrying actual config values in metadata in XML,
I guess I like the actual datastore approach still a bit more (but
perhaps having standard meta-data annotations providing additional
information might actually be useful.
/js
On Thu, Sep 03, 2015 at 09:40:58PM +0100, Robert Wilton wrote:
Hi,
I've posted a new experimental draft, that proposes a potential
different solution for handling applied configuration, for possible
discussion at next week's interim meeting on opstate.
Comments before hand are welcome.
Thanks,
Rob
-------- Forwarded Message --------
Subject: New Version Notification for
draft-wilton-netmod-opstate-yang-00.txt
Date: Thu, 3 Sep 2015 13:31:00 -0700
From: [email protected]
To: Robert Wilton <[email protected]>, Robert Wilton <[email protected]>
A new version of I-D, draft-wilton-netmod-opstate-yang-00.txt
has been successfully submitted by Robert Wilton and posted to the
IETF repository.
Name: draft-wilton-netmod-opstate-yang
Revision: 00
Title: "With-config-state" Capability for NETCONF/RESTCONF
Document date: 2015-09-03
Group: Individual Submission
Pages: 22
URL:
https://www.ietf.org/internet-drafts/draft-wilton-netmod-opstate-yang-00.txt
Status:
https://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/
Htmlized:
https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-00
Abstract:
This document proposes a possible alternative solution for handling
applied configuration state in YANG as described in draft-openconfig-
netmod-opstate-01. The proposed solution, roughly modelled on the
with-defaults NETCONF/RESTCONF capability, aims to meet the key
requirements set out in draft-openconfig-netmod-opstate-01 without
the need for YANG module authors to explicitly duplicate
configuration nodes in both configuration and operational containers.
This draft does not address the issue of co-location of configuration
and operational state for interfaces, nor does it provide a NETCONF
mechanism to retrieve operational data separately from configuration
data.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
