RE: Do we need data modeling rules like an SMI

["McDonald, Ira" <imcdonald@sharplabs.com>]

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: imcdonald@sharplabs.com

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Balazs Lengyel
> Sent: Wednesday, July 05, 2006 10:33 AM
> To: Andy Bierman
> Cc: Phil Shafer; Sharon Chisholm; netconf@ops.ietf.org
> 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: Balazs.Lengyel@ericsson.com
> 
> --
> 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/>
> 

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