Re: [NGO] NETCONF Data Modeling BoF (NDM) proposal

Juergen Schoenwaelder wrote:
> On Thu, Sep 06, 2007 at 12:13:36PM -0700, Andy Bierman wrote:
>> Juergen Schoenwaelder wrote:
>>> On Thu, Sep 06, 2007 at 10:41:37AM -0700, Andy Bierman wrote:
>>>> SMIv2 (for SNMP) provides many features that the IETF relies
>>>> on to maintain an integrated and ever-changing mix of vendor
>>>> and standard MIB modules.  There are many features
>>>> unrelated to the SYNTAX or DESCRIPTION clauses, such as
>>>> object and instance naming, module headers, definition importing,
>>>> INDEX and MAX-ACCESS clauses, version control, and flexible agent
>>>> conformance, which NETCONF does not currently address.  A NETCONF
>>>> compatible data modeling framework is needed, which provides these
>>>> important features.
>>> [...]
>>>> The NDM WG will not produce any new data modeling language.
>>>> Instead, existing mechanisms such as Xpath will be used instead.
>>> How is a "NETCONF compatible data modeling framework [...] which
>>> provides [...] object and instance naming, module headers, definition
>>> importing, INDEX and MAX-ACCESS clauses, version control, and flexible
>>> agent conformance" different from a data modeling language?
>> Some features, such as object and instance naming, rely on Xpath.
>> Others, such as MAX-ACCESS or INDEX, are properties that can be defined
>> independently of a specific DML.  Mappings to a specific DML are needed,
>> such as <appinfo> extensions for XSD.  Other DMLs could support
>> these standard properties as well, in their own way.
> 
> You mentioned more: "module headers". "definition importing", "version
> control", "flexible agent conformance".
> 

All of these things can be defined independently of a DML.
For example, info models, not data models could be defined
for module header contents.

Definition importing is more complicated.
I would like a framework not so tightly coupled to namespace URIs,
but that may not be possible.  Making people memorize long complicated
strings instead of module names and 'descriptor' names seems
like a step backwards.

Version control -- change control rules and version identifiers,
can be defined.  Mappings to DMLs, such as the 'version' attribute
in the XSD <schema> element, are also needed.

Agent conformance is complicated.
IMO, the SNMP agent conformance mechanisms should be examined
to determine what works and what doesn't.
The same sort of mechanisms (e.g., conformance groups, MIN-ACCESS)
apply to NETCONF configuration data.

<soapbox>
I am not against a new DML for NETCONF.
I just want to get started on standard data models,
and use XSD while a new DML matures enough to co-exist
and perhaps eventually replace XSD.

I used to think the 'XSD appinfo' approach would be a total hack,
and 'brand new everything' would do the job better.  Now I think
of XSD as the underlying assembly language of XML tools.
It is now common practice to use an 'in-house' DML that make
XML data modeling possible for humans, and generates write-only XSDs
for tools.  (Got one myself ;-)

So instead of getting rid of XSD, we should use it as the low-level
machine readable common language, and some <appinfo> extensions
in the ASM code may look ugly, but they will get the job done.
</soapbox>

> /js
> 

Andy

_______________________________________________
NGO mailing list
NGO@ietf.org
https://www1.ietf.org/mailman/listinfo/ngo