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

RE: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)



 
in-line
Hector


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

HT: I think there needs to be the equivalent of an SMI. If this is not
in place then
there is a really good possibility that models will be different (e.g.
style, use of constructs, etc.)
Saying that NETCONF data models are written using XSD is not sufficient.


> 
> 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).

HT: When is a good time to define rules (SMI equivalent)?

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

HT: Writing an XML data model is not a problem but w/o the rules it is
going to be a mess. If some people decide
to write SNMP MIBs and then translate them and others write the XML data
models by hand they are going to look
completely different. 

I guess a data model could be written for event notifications w/o having
the SMI equivalent/rules to move things forward but I don't think that's
a good idea in general.   

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

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