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
--
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/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
