Re: Explicit and unique naming of configuration target

[Phil Shafer <phil@juniper.net>]

Larry Menten writes:
><target>
>  <protocols/>
></target>
<config>
>  <ospf name="1">
>    <area name="0">
>       <interface name="135.104.57.3">
>          <md5 name="3">
>              ...
>          </md5>
>       </interface>
>    </area>
>  </ospf>
></config>

Pros:
- "you have a safety net in case you made a mistake" for a certain
  class of errors

Cons:
- The contents of <config> no longer match a simple schema, since
  they are now an element subhierarchy.
- The target and contents are two distinct elements, so if the client
  were generating them from one source, I'd need buffer output or
  two passes. Consider the pain of doing this is xslt.
- The server needs to remember the target while processing the content.
- Multiple operations (targets) are no longer possible.
- If you are talking about returning config in this form, then
  the configuration losses its lineage. If not, then the results
  of get-config cannot be feed directly back to set-config.

None of these are really insurmountable (except the lack of schemas),
but I just don't see this as a win. As I said before, if you want
to merely test for must-exist, you could do this with attribute-based
operations with less trouble.

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/>