[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Do we need data modeling rules like an SMI

Balazs Lengyel wrote:

So we agree that we need standard data types and textual conventions.



Keep in mind that I intend to finish this work on time.
We aren't going to expand the "to-do" list if it means
blowing off the schedule.




Some other topics I would like to see stated:
- A method to extract the data model from the device in an XSD format (Individual devices might decide that they don't want to expose this even with the strictest access control, but generally I think this would be good.) 


IMO this is way out of bounds. It forces
everybody to use XSD for all their data models,
and the agent memory/storage requirements would force
this to be optional anyway.

Instead, a simple URL defining each schema location should be sufficient.
- A statement that the device should advertise his data models in the capability exchange 

This is a good idea.
The details were already worked out on the mailing list awhile back.



- max-access: I feel we do need it


We need normative text explaining the mapping to the protocol.
IMO, an <appinfo> construct in addition would be harmless enough,
but not worth a lot of time.
- a statement that notification definitions should be part of a data model like in SNMP 

We will have an XSD for the format of NETCONF notification PDUs.
We don't have time to define machine readable constructs for
notification content abstractions.  If we define any standard notification
content, it will be included in the XSD.




Then some questions:
- how do you indicate in a data model that a bit of data is read-only configuration data or state data? 

IMO -- SMIv2 MAX-ACCESS clause (mapped to NETCONF protocol of course)
- one namespace is always one data model or is it allowed to define the complete data model in one namespace in multiple modules? 

There are no rules here.  I want to keep it that way.
For now, we just need a 'data' URI to go along with our 'base' URI.



Balazs



Andy




Andy Bierman wrote:

Balazs Lengyel wrote:
I think before the data models themselves we will have to tackle something like the SMI first, that is rules for building data models. 
e.g. standard datatypes, documentation rules, etc.


Not really.  We have an SMI of sorts.
The IETF uses XSD to describe XML data models.

Standard data types: We have the XSD types.
   I think we need some XML TCs, such as the SMIv2 data types
   and the RFC 4001 TCs.  But this is an IETF-wide requirement,
   not a NETCONF requirement.

Documentation rules: We have the <documentation> annotation,
   and we use it.  We may need some documentation rules beyond
   what we already know from RFC 4181, but we don't have enough
   experience with NETCONF to know what they are yet.

Etc.: This is the part that scares me.  IMO, the best way to figure
   out if we have a good data model is to write one and see what
   happens.  If we aren't competent enough to figure out how to
   write an XML data model for notification delivery parameters,
   then it would be good to know that now.

I am strongly opposed to the specification of rules for NETCONF data
models at this time.  NETCONF is content-independent and requires
only well-formed XML payload (+ the 'operation' attribute).
Also, we do not have enough experience with NETCONF data models to
define any significant rules (beyond XSD and some TCs).

Dave H. had a good suggestion, which I will paraphrase:
If we can't figure out how to write an XML data model module,
then write a MIB module first, and then figure out how to to
convert it to XML.  I'm hoping this WG will figure out how
to write an XML configuration data model though.


Andy





Balazs

Phil Shafer wrote:

Andy Bierman writes:

There are many people (including myself) who believe that
standard configuration data models are a critical component
to a complete standards based solution for network configuration.


I completely agree that standard configuration data models are
critical, but I do not agree that they are trivial.  I think this
is the next big hurdle for this working group.  The question on the
floor is whether we should stop other work until we have a real
meta-model for configuration and a way of specifying standard data
models that will work in the real world.  If so, let's stop talking
about notifications and get our butts in gear on modeling.


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