partial locks

[Andy Bierman <andy@andybierman.com>]

Hi,

[This will move to the NGO mailing list when it gets created.]

This issue came up again, and I was wondering
if there is any progress in this area in implementations.

IMO, XML-focused solutions like Xpath do not allow
for other protocol access methods to easily participate in partial locking.
This is sub-optimal, because NETCONF will have zero access if
any other protocol has any access at all.

IMO, a better approach would be a simple classification
scheme, something like Perl uses: <Application>::<Module>.
This is very coarse granularity, but it is possible for all
protocol APIs to make this sort of simple classification.

It means that all NETCONF data models would need to identify
this meta-data somehow in the schema.  This isn't that hard
so far:


  netconf::base
  netconf::notifications


Agents supporting the :partial-lock capability MUST support
partial locking across all access methods of an
individual application, and SHOULD provide locking of an
individual module within an application. Each owner (ietf, vendor, etc.)
can define applications, which are identified in XML by a namespace.

An application could be 'routing', and module could be 'bgp',
or an application could be 'remops', and a module could be 'ping'.
It's all up to the data model designer as usual.

XML hierarchy for <edit-config>, <get> and <get-config> falls out for free:
(Note that <data> is the conceptual <top>.
There is no need to actually include that in the data model.)

[Namespace prefixes not shown:]

  <data>
    <netconf>
      <notifications>
        <streams>
          <stream>
            ...
          </stream>
         </stream>
      </notifications>
    </netconf>
  </data>


Comments?


Andy





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