Subject: [NGO] NETCONF Data Modeling BoF (NDM) proposal

From: Andy Bierman <[email-masked]>
Date: Thu, 06 Sep 2007 10:41:37 -0700

Hi,

I am proposing a BoF (will find BoF co-chair TBD)
to do work on NETCONF Data Modeling (NDM WG).

DOCUMENTS:

   http://www.ietf.org/internet-drafts/draft-bierman-ncx-smi-00.txt

MAILING LIST:

Send comments on this BoF proposal to the NETCONF GOES ON (NGO) list:

    mailto:[email-masked]

PURPOSE:

The NETCONF protocol needs a standard content layer.
A data modeling framework is needed which supports
ongoing development of WG and vendor defined modules,
within an integrated and seamless conceptual configuration database.

It is important to determine if and how standard NETCONF data model
modules with writable configuration data, compatible with the
<edit-config> operation, can be developed in the IETF in a manner
similar to MIB module development.

There are many different viewpoints on NETCONF and its non-existent
data model.  Hopefully, consensus could be reached anyway,
based on real use cases and running code.  In the area of
network device configuration, the IETF has rarely been able to achieve
any deployment success.  So far, NETCONF is no exception.

SMIv2 (for SNMP) provides many features that the IETF relies
on to maintain an integrated and ever-changing mix of vendor
and standard MIB modules.  There are many features
unrelated to the SYNTAX or DESCRIPTION clauses, such as
object and instance naming, module headers, definition importing,
INDEX and MAX-ACCESS clauses, version control, and flexible agent
conformance, which NETCONF does not currently address.  A NETCONF
compatible data modeling framework is needed, which provides these
important features.

It is important to distinguish between XML usage conventions
for better interoperability and NM usability, and data modeling languages.
By focusing on the XML instance documents themselves (i.e., NETCONF PDUs),
an SMI can be developed which can be supported by many languages.
However, for better interoperability, a canonical mapping for all
NDM constructs to the XML Schema Definition (XSD) data modeling language
is needed.

NDM WG OUTPUT:

The output of the NDM WG would be 1 or more documents
defining the structure of NETCONF data models, focusing on
the common mechanisms needed to develop standard and vendor defined
data model modules.

This work can (and should) be done concurrently with actual
configuration data model development, such as the data model
to configure partial locking.

It would be useful for a separate WG to focus on the larger issues
for an entire management system, and develop the conventions and
mechanisms needed for standard data models to follow.

NDM NON-GOALS:

The NDM WG will not produce any new data modeling language.
Instead, existing mechanisms such as Xpath will be used instead.

The NDM WG will not integrate multiple data modeling architectures
into some sort of unified XML melting pot.  Future work on specific
protocol integration support, such as SNMP/SMIv2, would be possible,
once the output of the NDM WG was published.

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Sep 2007 20:44:30 +0200

> compatible data modeling framework is needed, which provides these

[...]

> Instead, existing mechanisms such as Xpath will be used instead.

How is a "NETCONF compatible data modeling framework [...] which
provides [...] object and instance naming, module headers, definition
importing, INDEX and MAX-ACCESS clauses, version control, and flexible
agent conformance" different from a data modeling language?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 Sep 2007 12:13:36 -0700

> agent conformance" different from a data modeling language?

Some features, such as object and instance naming, rely on Xpath.
Others, such as MAX-ACCESS or INDEX, are properties that can be defined
independently of a specific DML.  Mappings to a specific DML are needed,
such as <appinfo> extensions for XSD.  Other DMLs could support
these standard properties as well, in their own way.

> /js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Sep 2007 21:55:55 +0200

> these standard properties as well, in their own way.

You mentioned more: "module headers". "definition importing", "version
control", "flexible agent conformance".

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 Sep 2007 13:28:59 -0700

> control", "flexible agent conformance".

All of these things can be defined independently of a DML.
For example, info models, not data models could be defined
for module header contents.

Definition importing is more complicated.
I would like a framework not so tightly coupled to namespace URIs,
but that may not be possible.  Making people memorize long complicated
strings instead of module names and 'descriptor' names seems
like a step backwards.

Version control -- change control rules and version identifiers,
can be defined.  Mappings to DMLs, such as the 'version' attribute
in the XSD <schema> element, are also needed.

Agent conformance is complicated.
IMO, the SNMP agent conformance mechanisms should be examined
to determine what works and what doesn't.
The same sort of mechanisms (e.g., conformance groups, MIN-ACCESS)
apply to NETCONF configuration data.

<soapbox>
I am not against a new DML for NETCONF.
I just want to get started on standard data models,
and use XSD while a new DML matures enough to co-exist
and perhaps eventually replace XSD.

I used to think the 'XSD appinfo' approach would be a total hack,
and 'brand new everything' would do the job better.  Now I think
of XSD as the underlying assembly language of XML tools.
It is now common practice to use an 'in-house' DML that make
XML data modeling possible for humans, and generates write-only XSDs
for tools.  (Got one myself ;-)

So instead of getting rid of XSD, we should use it as the low-level
machine readable common language, and some <appinfo> extensions
in the ASM code may look ugly, but they will get the job done.
</soapbox>

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Sep 2007 23:16:58 +0200

> in the ASM code may look ugly, but they will get the job done.

So you suggest to standardize data models in assembler code?

Or do you suggest to standardize informal englisch prose information
models that everybody can turn into their favourite NETCONF data
modeling language to produce some assembler that hopefully is
interoperable?

Something else?

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 Sep 2007 15:02:49 -0700

> So you suggest to standardize data models in assembler code?

I am suggesting that XSD continue to be used for the foreseeable future.

> modeling language to produce some assembler that hopefully is

I am suggesting that data models be clearly documented, instead
of just putting an XSD into an xml2rfc template and publishing it.
I think an SMI document is needed that addresses many details
that need to be supported for long-term module management,
and interoperability between modules, which I address in the ncx-smi-00 draft.

> Something else?

I think new DMLs should be considered experiments,
and experiments are good for achieving the long term goals.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 07 Sep 2007 08:11:27 +0200

> of just putting an XSD into an xml2rfc template and publishing it.

Perhaps XSD folks could come up with something similar to
http://www.ietf.org/internet-drafts/draft-lhotka-relaxng-to-rfc-00.txt

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Sep 2007 08:32:32 +0200

> I am suggesting that XSD continue to be used for the foreseeable future.

It is hard for me to understand you. You sometimes argue that XSD is
human unreadable and you point to the NETCONF experience with bugs in
the XSD not being detected and a moment later you argue that XSD is
kind of assembler code but then you also seem to tell me that XSD is
the way to publish standard data models.

> and experiments are good for achieving the long term goals.

I guess I do not really understand the difference between "an SMI
document is needed that addresses many details that need to be
supported for long-term module management, and interoperability
between modules" and a new DML which would be an experiment.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Sep 2007 06:20:52 -0700

> the way to publish standard data models.

XSD is problematic, but it is the only robust DML that
has decent tools support.

The IETF is way too clueless to develop a suitable XSD replacement
from scratch.  Even if there were enough cluefull people to
do the work, it would take 5+ years to finish.

IMO, this is just a less-than-clever way to put off creating
any standard data models for configuration.  Just publish cryptic
XSDs with no documentation, and claim that XSD is too hard to read.
Just claim that no data models can possibly be standardized until
a brand new DML is 'done', and since the SMIng WG showed how well
the IETF can agree on a new DML, that could be never.

> between modules" and a new DML which would be an experiment.

How is a module allowed to change over time?
What does the use of the same namespace URI over time mean?
How does the manager discover modules and versions?
How does a manager compare versions?
How does a manager know the difference between
a read-create row and a read-only row (or column)?
How does a manager know what an agent is supposed to
implement to claim a certain level of conformance?

These are some of the open issues that NETCONF needs to
address, just as SMIv2 addresses these issues for the SNMP protocol.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Sep 2007 17:01:33 +0200

> address, just as SMIv2 addresses these issues for the SNMP protocol.

It remains to a large extend unclear to me how one can work out all
these things without having defined what a module is, what a module
contains, what a notion of a row is (do we still have the notion of
rows in NETCONF?), what the versioning aspects of making changes to
things are, and what conformance actually means. But if I am the only
one who is puzzled, just ignore me.

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 07 Sep 2007 17:20:17 +0200

Hello Andy,
You yourself sad that XSD is
- write-only
- prone to errors
- you yourself choose not to use it
- is like programming in assembler

(Which I fully agree with.)

I am surprised that you still want it as the main modeling language for Netconf.

The fact that IETF could not agree on SMIng should not just mean that we avoid modeling in the 
future, but also that we accept, that there is a stronger need for compromise.

As I see it, a  good part of SMIng's problem were due to compatibility constraints with SNMP, 
which is less of a problem for a Netconf modeling language.

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Sep 2007 08:29:58 -0700

> one who is puzzled, just ignore me.

I guess my draft is unclear then.
These things need to be defined for NETCONF, just as they have
been defined for SNMP.  I think many protocol interoperability details,
such as the <rpc-error> contents, <edit-config> behavior,
should be defined in better detail as well.

A table row in XML is just a complex element with multiple instances,
and there is a key defined for identifying entries.  It is a conceptual row.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Sep 2007 08:50:37 -0700

> I am surprised that you still want it as the main modeling language for 

I don't really see any better alternatives.
One can simplify the problem by drastically limiting
what one can do within XML, within NETCONF, as a way
to address the problem.  But the NETCONF WG has already
used many complex features of XSD, such as substitutionGroups
and choices, because they were needed to express the data model complexity.

I think a new DML is fine for a background experiment,
not as something in the critical path for producing
any standard data models.

The advancement of protocol interoperability can only helped
by standardizing Xpath object/instance identifiers for better
<error-path> usability, or defining how the continue-on-error
option actually works, or defining which top level element is used
for the target of a <copy-config> operation, or dozens of other
details that implementers are aware of...

> 
> The fact that IETF could not agree on SMIng should not just mean that we 
> avoid modeling in the future, but also that we accept, that there is a 
> stronger need for compromise.
> 
> As I see it, a  good part of SMIng's problem were due to compatibility 
> constraints with SNMP, which is less of a problem for a Netconf modeling 
> language.

SMIng had many problems, including COPS-PR integration as part of the charter.
There is not going to be consensus on another SMIng without producing
a requirements document, conducting a candidate evaluation phase, and
then a standard definition phase.  That takes 5 years in the IETF, if you are lucky.

What about the tools problem?
The whole point of using XML was to take advantage of mainstream/free tools
and not repeat the SMIv2 mistake (adapted subset of obsolete version of ASN.1)
of being the only ones using the DML.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 07 Sep 2007 18:16:56 +0200

Hello,
You seem to want to describe everything around a data model just not the data model itself.

See also below!

regards Balazs

>>>> So you suggest to standardize data models in assembler code?
[BALAZS]: Kill me, but I have 23 years of programming behind me, and I never really knew 
assembler. I don't want to start now. Give me something better then XSD. I will never be able 
to convince Ericsson to start working in XSD.
> do the work, it would take 5+ years to finish.
[BALAZS]: I think we should NOT speak of an XSD replacement. A NETCONF data modeling language 
must be much more simple then XSD. That would be the main reason to have a new language, to 
make it smaller, more understandable. I agree that if we would want the full power of XSD, then 
we would have a difficult job, but we don't.
>>> and interoperability between modules, which I address in the 
[BALAZS]: Your draft was very interesting for me with a number of good proposals, but you will 
need a way  to formally describe some of the topics, like max-access. In which modeling language?
> How does a manager know the difference between
[BALAZS]: As an example when you start to define which parts can be changed in a 
compatible/incompatible way you will need to go into data modeling details. You will use the 
XSD terminology or something new. Now you can say that you are happy with XSD, but a number of 
people are not.
Either way if we delay defining the Netconf DML for another 5 years two things can happen:
1) People will not use Netconf because they don't know how to describe their data models
2) People will hate XSD so they avoid Netconf or use a proprietary DML
3) People start to learn XSD, but as some people have indicated they didn't learn XSD until 
now, so a sudden change is not certain.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Sep 2007 11:01:26 -0700

Balazs Lengyel wrote:
> [BALAZS]: Kill me, but I have 23 years of programming behind me, and I 
> never really knew assembler. I don't want to start now. Give me 
> something better then XSD. I will never be able to convince Ericsson to 
> start working in XSD.

There are tools that help do it for you, just
like there are C compilers that do the ASM for you.
BTW, I have 24 years, and a few of them writing
device drivers in x86 ASM.

What about writing MIBs and translating them to XSD?
Your engineers can handle that right?

Well, this certainly is a problem, that's for sure.
If people are not willing or able to learn XSD,
then no WGs can ever really effectively standardize
data models that use XSD to define the XML syntax.

> [BALAZS]: I think we should NOT speak of an XSD replacement. A NETCONF 
> data modeling language must be much more simple then XSD. That would be 
> the main reason to have a new language, to make it smaller, more 
> understandable. I agree that if we would want the full power of XSD, 
> then we would have a difficult job, but we don't.

Who is 'we'?
We (the NETCONF WG) has already used complex XSD features
for the protocol spec and for the notification data model,
which are the only 2 data models we have done so far.
There is no agreement across all vendors on how much "power of XSD"
is actually needed.  (That's the Requirements Phase -- the
first 18 months of the 5 year plan.)

> [BALAZS]: Your draft was very interesting for me with a number of good 
> proposals, but you will need a way  to formally describe some of the 
> topics, like max-access. In which modeling language?

Why can't max-access be a property of the data, which is realized
in different ways.  In XSD, it would be an <appinfo> extension.
In SMIv2, it is MAX-ACCESS. In NCX, it is max-access.
I think many SMI features can be defined in two parts,
the conceptual definition, and the DML-specific definition.

> [BALAZS]: As an example when you start to define which parts can be 
> changed in a compatible/incompatible way you will need to go into data 
> modeling details. You will use the XSD terminology or something new. Now 
> you can say that you are happy with XSD, but a number of people are not.
> 3) People start to learn XSD, but as some people have indicated they 
> didn't learn XSD until now, so a sudden change is not certain.

Sigh...

People not only refuse to learn XSD,
there is no agreement at all on what should be
used instead.  RelaxNG with description clauses
didn't look much better than XSD, and doesn't address
any NETCONF-specific issues either.

You're right that I don't use XSD to write data models.
I am trying to refine my DML to optimize tool automation.
I think it's way easier to use than XSD, but my language
preference is for a C-like syntax (like SMIng).  Other people
like XML, others SMIv2, and so on.

Can agreement on a new DML really be reached in the IETF?
A giant, complicated, "let's do everybody's idea" approach (ala DIFFSERV)
is not going to work.  I am skeptical the WG result will be
better and simpler than XSD.

I completely agree that XSD is not the long term solution.
I am quite frustrated with the progress that we have had using XSD.
At a previous WG meeting, Simon asked people who did not understand XSD
to abstain from a straw poll.  The count was 3 for, 3 against, 40+ abstain.

On the other hand, I really don't want to wait 5+ years
for a new DML.  New work like the partial locking and ACM
are using XSD, and so will all other new DM work.
I don't see how one can avoid learning XSD, even if a new DML
is on the horizon.  And what about the free tools for the DML?
How long will those take to get established?  Will there be any?

Andy

---

From: Tomoyuki Iijima <[email-masked]>
Date: Mon, 10 Sep 2007 14:13:19 +0900

Hello,

> How long will those take to get established?  Will there be any?

I totally agrew with Andy's comments. We talked about XSD's superiority
at the 68th IETF meeting in Prague. The slide related to this issue is
found below.
http://www3.ietf.org/proceedings/07mar/slides/opsarea-6/sld15.htm

In addition, I mentioned following things.
http://www3.ietf.org/proceedings/07mar/slides/opsarea-6/sld5.htm
IMO, since data models written by XML is transformable into another one
thanks to the XML technology including WSDL, rough data modeling is
enough as long as meaning of each parameter inside data model is well
defined.

Andy Bierman wrote:
>> something better then XSD. I will never be able to convince Ericsson 
>> to start working in XSD.
> 
>> data modeling language must be much more simple then XSD. That would 
>> be the main reason to have a new language, to make it smaller, more 
>> modeling details. You will use the XSD terminology or something new. 
>> Now you can say that you are happy with XSD, but a number of people 
>> are not.
> .

-- 
Tomoyuki Iijima
Hitachi, Ltd. Central Research Laboratory
TEL:+81-42-323-1111 ext.3579
FAX:+81-42-327-7868
E-mail:[email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 10 Sep 2007 09:07:13 +0200

> http://www3.ietf.org/proceedings/07mar/slides/opsarea-6/sld15.htm

Your account is biased towards XSD:
1. Support for RELAX NG in .NET does exist, it is included in the Mono
implementation.
2. Python has very good support for RELAX NG (as well as for XSD) via
libxml2.
3. For me the best schema editor is Emacs with nxml-mode.
4. RELAX NG has the compact syntax.

> enough as long as meaning of each parameter inside data model is well

I think we have so far too little real-life experience and so this
discussion is rather moot. Let's go ahead and implement some data models
in our devices (we are working on one) using whatever formalism and then
compare the results to see the relative benefits and drawbacks.

Lada
 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Mon, 10 Sep 2007 09:41:52 -0400

>like there are C compilers that do the ASM for you.

Which is why we standardize C, not ASM.

>device drivers in x86 ASM.

So you grok why only device drivers are written in ASM ;^)
(And gcc asm hooks mean you don't even need to do that)

>data models that use XSD to define the XML syntax.

Given the number of errors and surprises in the netconf
xsd (where people _were_ willing or able to learn XSD),
how can we inflict this on the rest of the ietf?

>(That's the Requirements Phase -- the

Are you just trying to make me cry?

>in different ways.  In XSD, it would be an <appinfo> extension.

So you need extensions to your lower-level language to handle
high-level concepts?

>preference is for a C-like syntax (like SMIng).

Amen.

>better and simpler than XSD.

The all-singing-all-dancing approach won't fly, but that doesn't
mean we're stuck w/ XSD.  I favor an incremental approach, starting
with a small number of important things, getting something working,
building trust, and then moving on to other issues.  This approach
works well, if future work builds on the initial work, rather than
recreating it.

>I completely agree that XSD is not the long term solution.

My opinion is that the IETF isn't a good place for short term solutions.

>to abstain from a straw poll.  The count was 3 for, 3 against, 40+ abstain.

But _all_ the votes where single digit for/against.  My worry is
that this is a sign that folks have completely lost interest.  Which
would be very bad news.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Sep 2007 07:49:30 -0700

> Which is why we standardize C, not ASM.

C is even more powerful than ASM, not less.
My goal is to have a single language to
specify everything we do with NETCONF data,
which provides all the features from XSD that
we rely on, but in a manner usable by mere mortals.

Unless the new DML covers everything we currently do with XSD,
then part of the XSD is never going away.  This is a worst-case
scenario, where we need to learn XSD for part of the NETCONF PDU,
and another DML for the rest of the PDU, since the 'MIB document'
will need to contain an XSD for the parts not covered by the new DML.

> (And gcc asm hooks mean you don't even need to do that)

Of course -- total control over the runtime and optimized performance

But my analogy is intended to point out that CPUs still
need the ASM to work.  They don't run C directly.
We trust the C compiler to deal with it, but it didn't go away.

> how can we inflict this on the rest of the ietf?

You can still introduce bugs into the 'C' version of the data model.
(Or at least I can, and anybody else who doesn't write perfect code
all the time  ;-)

> Are you just trying to make me cry?

Look how long it takes to do anything significant in the IETF and do the math.
I don't want to put all data modeling on hold until a new DML is
done, which means limping along with XSD for 5 more years at least.

I would prefer that people learn XSD or invest in tools that
help them understand XSD files.  However, this does not
seem to be happening in large enough numbers to reach critical mass.

> So you need extensions to your lower-level language to handle

You need to convey high-level info to other applications,
through the low-level language.  <appInfo> is outside XSD,
meaning XSD ignores it and just makes it available to higher layers.

XSD-based tools are able to use the <appInfo>, if they are
extended by programmers to do so.  This is going to be easier
than rewriting all the XSD tools to use a new DML instead.

IMO, XSD does not go away.  I am trying to generate WSDL and XSD
so it is 100% write-only.  Human groking of XSD will hopefully go
away, just like with C and ASM.

> My opinion is that the IETF isn't a good place for short term solutions.

A long term solution takes a long time to standardize.
Something better than XSD, that is as widely supported
as XSD, would deserve to be the long term solution.
Just declaring many XSD features "too hard" or "not important"
is not going to be a long term solution either.

> that this is a sign that folks have completely lost interest.  Which

The patient is not dead yet.
The Notification work has been a detour that many WG members
have largely ignored, for various reasons.  I think there
is interest in standard data models for NETCONF.  BTW, the
latest Notification draft is pretty good, and I think we will
be glad we have the ability to define NETCONF notifications
along with configuration data, as feature-specific data models
are standardized in the future.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Sep 2007 12:44:57 -0700

Phil Shafer wrote:
>....

You mean, like RFC 2856, published over 7 years ago
as a short-term hack until 64-bit numbers were added to SMIv2,
which is of course, never happened.

One reason I nitpick the NETCONF drafts to death is because
the normal case in the IETF is for the Proposed Standard RFC
to stick around several years before it is updated.

Andy

---

From: "tom.petch" <[email-masked]>
Date: Wed, 12 Sep 2007 10:17:43 +0200

Uh huh.

Andy,

I agree with you that XML/XSD is the only realistic alternative.  I have
immersed myself in it over the life of NETCONF and the more I learn the less I
like; the fundamentals are plain wrong (IMnotsoHO).

But, like other not quite perfect pieces of technology in the past, it has swept
most before it so I think it the only choice.

That said, I hope that XPath (even more fundamentally unsound I...) might get
improved so I would make XML a must but try to leave wiggle room for a better
select/filter operation.

Also, I think your initial proposal too all embracing and would rather see it
nailed down more precisely - even at this stage - eg flexible conformance is a
right can of worms whereas the more limited base and towers of SMIv2 should be
enough; while I see nothing that relates to tables and think that while SMIv2
gets tables wrong, it is right to nail the topic down.  I would like a closed
list of bullet items, a sentence each, of what will be covered.  We have
lightyears of experience with MIB modules of what it takes to operate and manage
everything under the sun and so should be capable of reverse engineering that
experience into the topic/concept/... list that this new effort needs to
embrace.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Wed, 12 Sep 2007 11:49:19 +0200

----- Original Message -----
From: "Phil Shafer" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: "NETCONF Goes On" <[email-masked]>
Sent: Monday, September 10, 2007 3:41 PM
Subject: Re: [NGO] NETCONF Data Modeling BoF (NDM) proposal

<snip>

Phil

No, not lack of interest.  A year ago, I would have abstained but in the
interim, I decided I needed to master XSD and so have.  Ditto XPath, so earlier
this year, I could see, from my general language knowledge, that an XPath
expression was malformed - now I could put it right.  So were I at the meeting,
I would not have abstained.

It takes time for skills to be seen to be needed and then time for them to be
acquired; what prompted me was partly the work in the IETF but as much the
number of courses being offered by commercial trainers.  If others are acquiring
the skills, I need to too.  (Of course, there is always the time I spent on OSI
in 1986-1988 for which I still look forward to the payback).

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 12 Sep 2007 14:24:09 +0200

> most before it so I think it the only choice.

I really don't understand this. Virtually everyone is complaining about
XSD being broken and I've never heard similar objections being raised
against RELAX NG, but apparently nobody seems to give it a slightest
consideration(?). As a data model specification language, RELAX NG is
IMO much more readable than XSD and I wrote a XSLT stylesheet allowing
annotated RELAX NG schemas to be incorporated in xml2rfc sources in a
way that resembles Knuth's literate programming. So what's wrong with
it?

Of course, specific NETCONF software could use XSD or whatever schemas
automatically translated from RELAX NG, if necessary, so this discussion
is really about data model specifications intended to be read by humans.

Lada
 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "tom.petch" <[email-masked]>
Date: Wed, 12 Sep 2007 14:10:28 +0200

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 12, 2007 2:24 PM
Subject: Re: [NGO] NETCONF Data Modeling BoF (NDM) proposal

<tp>
Not powerful enough
Tom Petch
</tp>

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 12 Sep 2007 16:46:02 +0200

> Not powerful enough

Can you be more specific? What do you miss? RELAX NG is now used for the
most complex beasts such as DocBook or Open Document Format.

Lada
 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 Sep 2007 12:17:53 -0700

> way that resembles Knuth's literate programming. So what's wrong with

I don't think that many people know RelaxNG.
When <appinfo> and <documentation> type of clauses are included,
it isn't so clean anymore.  It may be just as hard to learn for
people as XSD.  It doesn't really deal with any NETCONF-specific
issues (like max-access and conceptual tables) any more than XSD.

Picking a DML is very subjective.  I doubt there are that many
objective metrics you could apply.  Metrics like quantity of
deployed tools can only go so far.  Human usability is very hard
to quantify.  Varying additional factors, like SMIv2 reuse,
CLI integration, application complexity, and internal SW-dev
environment make objective evaluation even harder.

The only important factor (applying Occam's razor here) is that
WG members who are trying to standardize a NETCONF data model have a
common understanding of the entire document, which is high enough
to maintain a reasonable standards process.   Everything else is secondary
to that goal.  This is a standards body.  We make standards.
That is our product.  If we cannot understand the documents we
are trying to standardize, then we have no product.

I do not really care that much which DML is chosen for NETCONF,
as long as this primary goal can be achieved.  It is clearly
not be achieved with XSD.  That is why (IMO) the long term
solution is a new DML that can be translated to XSD without
information loss (<appinfo> not considered info loss).

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 12 Sep 2007 23:50:58 +0200

> it isn't so clean anymore.  It may be just as hard to learn for

RELAX NG allows application-specific info and documentation (in foreign
namespaces) to be directly included in the schema, without any (clumsy)
encapsulating elements. Here is an example:
http://www.flowmon.org/flowmon-probe/devel/config/flowmon-rng/
(this HTML was compiled directly from a valid RELAX NG schema via XSLT)
   
> issues (like max-access and conceptual tables) any more than XSD.

Maybe not, but at least it is relatively simple, extensible and based on
a sound mathematical basis (labelled tree automata). See also
http://www.imc.org/ietf-xml-use/mail-archive/msg00217.html

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 Sep 2007 17:35:27 -0700

> (this HTML was compiled directly from a valid RELAX NG schema via XSLT)

Although a very nice example,
I actually prefer XSD to RelaxNG (XML syntax).
That's probably because I spent the time to study XSD
in detail, but not RelaxNG.  I think somebody new to both
would not think either one was easy.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Sep 2007 08:18:20 +0200

On Wed, Sep 12, 2007 at 05:35:27PM -0700, Andy Bierman wrote:

> Although a very nice example, I actually prefer XSD to RelaxNG (XML
> syntax).  That's probably because I spent the time to study XSD in
> detail, but not RelaxNG.

There seems to be some evidence of some bigger projects switching from
XSD to RelaxNG - is anybody aware of any bigger projects doing the
opposite, namely switching from RelaxNG to XSD?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Sep 2007 09:12:06 +0200

> would not think either one was easy. 

Try it and you will see that RELAX NG is way easier and more
predictable. James Clark claims the RNG Tutorial can get you going in 30
minutes, which is probably an exaggeration, but perhaps two hours could
be enough?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Sep 2007 12:40:23 -0700

> minutes, which is probably an exaggeration, but perhaps two hours could

I did try RelaxNG.
I didn't say I don't understand the RNG you wrote,
I'm saying I like the consistency and symmetry of XSD
better than the less predictable syntax of RNG.

I like abstract elements and substitutionGroup replacement of those elements.
I like the way XSD complex types are extended, and think that is going to be
important for vendor augmentation of standard data models.  I like the ability
to create complex choices (via group definitions and unions).

We have used all of these features extensively already in NETCONF data models.
(Both of them ;-)  XSD and XML allow us to create syntax which exact mirrors
the 'native' format of complex procedural interfaces.

This is the main reason I think NETCONF has a some chance to succeed as
a configuration protocol. When new data models are designed by a WG,
semi-object-oriented APIs can be created, not just data structures.
A WG has much more control than ever before over the partition of
public and private data.

Domain-specific RPC methods may be easier to reach consensus on than
pure data driven APIs, because the RPC method can place many more
constraints on the parameters, and these parameters cannot be changed
later on with <edit-config>.

Eventually there will be data modeling languages available which
exploit the full power of the protocol, and understand the difference
between procedural operations on configuration databases, and descriptions
of valid XML instance documents (which is all XSD and RNG provide).

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 14 Sep 2007 08:24:38 +0200

> the 'native' format of complex procedural interfaces.

Are any of these data models available for inspection? I'd like to see
what this really means.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Fri, 14 Sep 2007 13:21:29 +0200

> From: Ladislav Lhotka [mailto:[email-masked]] 
> Sent: Thursday, September 13, 2007 9:12 AM
> To: Andy Bierman
> Cc: [email-masked]
> predictable. James Clark claims the RNG Tutorial can get you 
> going in 30 minutes, which is probably an exaggeration, but 
> perhaps two hours could be enough?
> 

Candidate tutorial for Vancouver?

Can we also have one on XSD?

Bert

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 14 Sep 2007 13:35:27 +0200

> Candidate tutorial for Vancouver?

OK, if there is interest, I am volunteering to prepare it.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 14 Sep 2007 06:42:48 -0700

> Are any of these data models available for inspection? I'd like to see

Yes -- look at the XSD in RFC 4741 for starters.
Reproduce it in RNG, with all the appropriate extensible
complex types, choices, and parameters to RPC methods.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 14 Sep 2007 15:54:43 +0200

> complex types, choices, and parameters to RPC methods.
OK, thanks, I'll try it.

Lada
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 14 Sep 2007 07:09:49 -0700

>> complex types, choices, and parameters to RPC methods.

Another one for comparison would be the XSD in romascanu-datatypes:

http://www.ietf.org/internet-drafts/draft-romascanu-netconf-datatypes-02.txt

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 20 Sep 2007 18:03:51 +0200

Hello Ladislav,
Why did you choose to use the XML format of RelaxNG? I was always told that the compact format 
is much nicer.
Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 23 Sep 2007 13:01:31 +0200

Hi Balasz,

the main reason is the stunning nxml mode for emacs that does
autocompletion, on-the-fly validation etc.

I tend to agree though that the best way of presenting schemas in RFCs
would be the compact format as it would be accessible to a broader
community almost without any a priori explanation.

A useful extension of the method I described in
draft-lhotka-relaxng-to-rfc-00 could thus be to transform the annotated
input schema (in XML syntax, exactly as described in the draft) into
xml2rfc XML but present the RELAX NG blobs in the compact syntax.

Cheers, Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C