Re: Explicit and unique naming of configuration target

[Phil Shafer <phil@juniper.net>]

Larry Menten writes:
>A transaction that is intended to create an ospf instance, an ospf area instance
>within that ospf instance, an ospf interface instance within that area, and an
>MD5 key instance within that interface is the same as one that would be formulated
>just to create the MD5 key instance.  The behavior is determined by the current
>state of the configuration.

A transaction that adds a md5 key to a given interface within a given
ospf area carries an implicit knowledge of that configuration. Turning
this into an error means forcing an explicit creation of every element
of an incoming configuration, which will be a pain.

Sort of like asking your wife to give your son the car keys, if you don't
have a wife or a son or a car. Or maybe mailing her a letter asking that
and expecting the post office to give you an error. Sort of. In a way.....

One could add this sort of must-exist assertion as an attribute,
but I'd be against seeing it as the default. And I'm not sure that
I'd ever need or use it myself. It could be a capability, of course.

Then again, I alias -p onto mkdir.

>This could be done with an XPath expression or by replacing the
>contents of the <target> element with a tree that provides the tag hierarchy
>with unique keys.

I would not look forward to introducing xpath into my code.

Thanks,
 Phil

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>