Subject: RE: Do we need data modeling rules like an SMI

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 5 Jul 2006 12:52:39 -0700

Hi,

+1 to all the suggestions below.

I also think making the XSD available is important.

And a data model and single namespace should be able to 
span a tree of XSD files, not just a single file.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Balazs Lengyel
> Sent: Wednesday, July 05, 2006 10:33 AM
> To: Andy Bierman
> Cc: Phil Shafer; Sharon Chisholm; [email-masked]
> Subject: Do we need data modeling rules like an SMI 
> 
> 
> So we agree that we need standard data types and textual conventions.
> 
> 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.)
> - A statement that the device should advertise his data 
> models in the capability exchange
> - max-access: I feel we do need it
> - a statement that notification definitions should be part of 
> a data model like in SNMP
> 
> Then some questions:
> - how do you indicate in a data model that a bit of data is 
> read-only configuration data 
> or state data?
> - one namespace is always one data model or is it allowed to 
> define the complete data 
> model in one namespace in multiple modules?
> Balazs
> 
> 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
> >>
> >>
> > 
> 
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> TSP System Manager
> ECN: 831 7320                        Fax: +36 1 4377792
> Tel: +36-1-437-7320     email: [email-masked]
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 06 Jul 2006 10:09:10 +0200

> span a tree of XSD files, not just a single file.

Could you explain this a bit more.

Yes in design and during model specification it is really important to be able to use 
multiple files. But is it needed when the device presents it's data model on the wire ?
Balazs

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 Jul 2006 08:31:38 -0700

> Could you explain this a bit more.

I was going to comment on this, but Joel did first.
You cannot assume a 1:1 mapping between modules and
namespaces.  Just like the SMI, the module is just
a container of definitions that has absolutely no
hard-wired relationship to the nature or location of
the conceptual data model instances described in each module.

> 
> Yes in design and during model specification it is really important to 
> be able to use multiple files. But is it needed when the device presents 
> it's data model on the wire ?

No.
It is not needed at all, but NMS developers want it anyway.
The XML on the wire is identified with namespaces.

The solution is to simply add an optional 'schemaLocation'
attribute to the <capability> element, so module capabilities
(which identify a conformance level to a particular module)
can also indicate the URL for the actual module schema.

Andy