Re: Reload

[Andy Bierman <ietf@andybierman.com>]

Balazs Lengyel wrote:
> For us the main point is to allow the definition of new <exec>s with 
> minimum modification to the management SW.
>
> Yes the full value of <exec> relies on data modeling. You really gain a 
> lot only if you have something like this in place (an excerpt from our 
> DTD that defines our modeling language like SMI)
>
> <!ELEMENT action (description, returnType, parameter*, raisesException*)>
> <!ATTLIST action name CDATA #REQUIRED>
>
> <!ELEMENT exception description,name, exceptionParameter*)>
>
> You have to define the number of parameters and for each parameter you 
> have to define the exact type. This allows our management system to 
> handle new actions (<exec>s) based on the data model without modification.


IMO, this belongs in the schema, not the agent.
There is already a mechanism to advertise data model capabilities.

There is a plan in the WG to specify what a "module capability"
looks like.  The only place the schema should show up (wrt/
mandatory support) is in the capabilities exchange, in the <hello>
PDU.


<capability>some-uri-to-identify-the-data-model-namespace</capability>

There is an assumption (by many people) that the DM language
is XSD, and therefore a module is a <schema> element, which
refers to a single target namespace.

I don't like this assumption, but as long as a <capability>
identifies a data model namespace, and not a module, then
it doesn't matter.

But the WG's plan to use capabilities for this purpose is still
somewhat broken because we're not really supposed to parse
URIs to get the capability name and version fields.

<capability type="data-model" name="foo" version="1.0">
    http://example.com/schemas/foo/1.0
</capability>

I don't think the NETCONF schema allows this extension, so
we need to leave the ad-hoc parsing out-of-scope.

I am not in favor of standardizing additional data model
discovery mechanisms, especially before all the current
chartered work is completed.





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