On 04/09/2015 23:35, Andy Bierman wrote:
On Fri, Sep 4, 2015 at 11:20 AM, Juergen Schoenwaelder
<[email protected]
<mailto:[email protected]>> wrote:
On Fri, Sep 04, 2015 at 11:33:27AM +0100, Robert Wilton wrote:
> 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.
Yep, I do not agree with this requirement. Datastores are an
architectural concept in both NETCONF and YANG and hence an NMS needs
to understand what a datastore is.
+1
IMO is is extremely important that the instance-identifier for a data
node be
exactly the same in each datastore. This is much easier to manage
If datastores are the right solution for intended vs actual, then I
completely agree that they should have the same path in both.
than if the data is named differently, depending whether it is
intended or actual.
> 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.
Yep. This may require some careful design.
The same careful design is needed for pub/sub to identify deleted nodes
in the delta.
OOI, has any one proposed how this should be done yet, or is pub/sub not
at that stage yet?
> 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.
See draft-ietf-netmod-yang-metadata-01 section 4.2 for the proposed
JSON encoding.
We have already implemented this draft, so if there are any problems
that require changes, it would be good to know about it ASAP
I just wasn't aware of this draft. I'll give it a read.
In particular, I was reading ietf-netconf-restconf-06, section 4.8.9 on
with-defaults, particularly the report-all-tagged option. I think that
it might be helpful if the description of the "report-all-tagged"
description also had a reference to draft-ietf-netmod-yang-metadata (or
alternatively section 5.4) for the JSON encoding of the "default" attribute.
Thanks,
Rob
/js
Andy
--
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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
