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

From: Balazs Lengyel <[email-masked]>
Date: Wed, 05 Jul 2006 15:37:20 +0200

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Jul 2006 07:08:03 -0700

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.

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 05 Jul 2006 16:14:11 +0200

> to write an XML configuration data model though.
This would indicate we've come full circle.  We're here in part because
MIBs failed miserably at configuration.  And if we spin in circles, that
would indicate that we are better buying rather than building.

Eliot

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 05 Jul 2006 16:18:25 +0200

I think there is a misconception here: Even if we use specialized RPCs for configuring 
notification handling we still have a hidden data model in them. You still need to define 
what data can be sent in the RPCs, what they mean and how to specify them. It is just that 
you do your data modeling in an RPC instead of NV stored data.
Mapping between device specific and standard features is the same for data models or "data 
models inside RPCs".

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Jul 2006 07:24:25 -0700

> would indicate that we are better buying rather than building.

Not really.
What (I think) Dave meant is that if the constructs are not very complex,
then SMIv2 can describe the data model in a way the IETF already
understands.  This is better than standing around wondering
how in the world can we define a data model.

I agree with you from the POV that I want to break out from the
"N-ary table of simple types" as the only tool in the box.
However, I don't want to stop everything and reinvent the
SMI and XSD. (We are already reinventing notifications -- that should
be enough for now. ;-)

I think we will figure something out at the interim.
Nested XML isn't that hard, and neither is a data model
for notification delivery.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Jul 2006 08:13:10 -0700

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.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Jul 2006 07:34:48 -0700

Balazs Lengyel wrote:
> I think there is a misconception here: Even if we use specialized RPCs 
> for configuring notification handling we still have a hidden data model 
> in them. You still need to define what data can be sent in the RPCs, 
> what they mean and how to specify them. It is just that you do your data 
> modeling in an RPC instead of NV stored data.
> Mapping between device specific and standard features is the same for 
> data models or "data models inside RPCs".

I pointed this out a few times already.  I suggested:

1) Move the NV-stored parameters to a data model,
    and leave the session parameters in the RPC.

2) Define the absolute path (from the conceptual <config> & <data> root)
    to the data model root.

3) There is no need for special <get> functions to retrieve state
    info for notification delivery activity and statistics.  They are
    just part of the data model.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 05 Jul 2006 16:33:23 +0200

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

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 Jul 2006 09:19:25 +0200 (CEST)

> this to be optional anyway.

Of course this could be an optional capability.  If you don't have a
XSD describing the data, don't use this capability.  On the other
hand, *if* the box has the XSD, it would be nice with a standard way
of getting these XSDs, either inline or through an URL.  (would it be
a misuse of the <get> operation to retreive the inline XSDs using
<get>?)

I don't agree with the statement that "it forces everybody to use XSD
for all their data models".  We use a much simpler language for the
data modelling part, where we also specify e.g constraints that cannot
be expressed in XSD.  From these data model we generate XSDs which
describe the instance documents that are sent on the wire.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 Jul 2006 09:00:15 +0200 (CEST)

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

This can of course be done as a vendor-specific rpc.

> - A statement that the device should advertise his data models in

There's already this sentence from the draft, section 5.2:

   The device uses capabilities to announce the set of data models
   which the device implements.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 Jul 2006 06:50:54 -0700

> describe the instance documents that are sent on the wire.

Traditionally, SNMP agents do not contain all the ASCII MIB modules
they support.  Nor do CLI agents contain all the ASCII or HTML documentation
that they support.

A URL of the general schema (not XSD) is DM language independent.
It can point to a RelaxNG, XSD, or even custom DM file.
The bytes on the wire are XML -- that is the only thing
that is standardized here.

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 6 Jul 2006 11:00:18 -0400

<Balazs>
Then some questions:
configuration data 
complete data 

</Balazs>

For the first, there is a proposed solution in 
	
http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-05.txt

Another approach that is interesting is to instead of specifying
minAccess/maxAccess to actually call data
	- statistics
	- configuration
	- administrative state
	- operational state
	- etc.

and hard code minAccess and maxAccess against each of those. This isn't
what we've been doing in product though. It does have a certain appeal
though. In particular, it works well with the get and get-config
commands.

Sharon