Subject: [NGO] DM alignment

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Nov 2006 14:26:34 -0800

Hi,

Although it is not clear what objectives actually will
be worked on, one of my objectives is to find the right
balance of SMI reuse, CLI friendliness, and OOA/SOA usability.

For example, the SMIv2 range clause cannot be represented in RelaxNG or XSD.
IMPORTS and tables are much simpler in SMIv2.
Augmentation, lifecycle, access control, conformance, and
documentation mechanisms are much better in SMIv2 than anything else. 

There are obviously many more things that RelaxNG and XSD can do
that SMIv2 cannot, like attributes (metadata) attached to data,
arbitrarily complex nested data, comprehensive extension and restriction
mechanisms, appinfo, etc.

I think the point of the "DIFFSERV Info Model Challenge" is to compare
how we would model something complicated in RelaxNG (and XSD?),
using NETCONF verbs, to compare it to the DIFFSERV MIB and source info 
model.
IMO, this will require more DIFFSERV domain knowledge
than NETMOD domain knowledge to execute, but we'll see.

The reason the SMIv2 standard MIB modules cannot be ignored
is a matter of domain WG priority -- if a WG has spent a lot of time
already to agree on the MIB to manage their protocol, that WG
will not be highly motivated to start over and agree on the
standard knobs all over again to create a NETCONF
data model, regardless of the DM language we use.

IMO, a phased approach (independent of the DM language we use) is needed:

 0) Create a standard XSD for SMIv2 data types and core TCs

 1) Automatic translation at the PDU layer
    Special RPC (e.g., snmp-getnext) provides peek/poke varbind-based API

 2) Direct, automatic data model translation
    Algorithmically convert SMIv2 to XSD and access the converted MIB
    with any NETCONF RPC method.  Access SMIv2 XML separately from 'new'
    and 'vendor' XML (e.g., separate namespace or separate branch
    in data org tree).  Not clear if full edit-config is possible or 
even needed.

 3) Creation of new modules, or manual conversion of existing SMIv2 modules,
    into 'deep models' (i.e., uses the full DM feature set)
    These models may include new RPC methods, config data, monitoring data,
    notifications, etc.

Step (1) and (2) can be done at the same time as (3), or skipped entirely.
It's not clear to me what the IETF wants to do here.

Andy

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo