Subject: [NGO] A bigger picture WAS:Re: completed CANMOD agenda

From: Mehmet Ersue <[email-masked]>
Date: Wed, 27 Feb 2008 14:53:34 +0000 (GMT)

Hi Phil,

On Tuesday, February 26, 2008 5:37 PM Phil Shafer wrote:
.... 
> We have three proposed solution, so let's look at the pros
> and cons:
> 
> XSD:
> - pro:
>   - w3c standard
> - con:
>   - XSD sucks:
>       W3C XML Schemas (XSD) suck. They are hard to read, hard to
>       write, hard to understand, have interoperability problems,
>       and are unable to describe lots of things you want to do all
>       the time in XML.   -- Tim Bray
>   - incomplete solution: requires NETCONF extensions
> 
> DSDL:
> - pro:
>   - people like the condensed syntax (cause it looks like YANG ;^)
>   - ISO standard
> - con:
>   - no one knows it (in the NM world)
>   - incomplete solution: requires NETCONF extensions
> 
> YANG:
> - pro:
>   - simple syntax
>   - tailored to the NETCONF problem space
> - con:
>   - new work: IETF standard

Is this really the complete picture? You forget other available solutions.
Kalua is XML based, supports object-oriented data modeling and saves 
time and resources by using already available classes for modeling. 
There are different features and ways how Kalua can save you time for 
data model design. BTW using XML is more easy then XSD, RelaxNG.

The question about building on top of existing standards vs. building 
from scratch is valid. Both ways are doable, and with different results. 
It is not easy to quantify the benefits of either approach, the practical 
experience is better indicator than theoretical benefits. 

I essentially agree that XSD approach is more complex and a more 
readable modeling language syntax is useful. Kalua and Yin syntaxes 
are readable. In this respect Kalua and Yang are close to each other, 
where Kalua is just using the XML format, which is well known. 

Personally I like YANG pretty much (there is already a transformation 
available to YIN), but I would rather see XML syntax as the core syntax, 
and there can be a standardized ASCII mapping of it.
One could have long discussions on what is more readable and at the 
end what you already use a long time is the best what you have.
 
....
> Is there any way to quantify the two sides of this cost/benefit
> tradeoff?  The "benefit" side is supposed to pay off in an existing
> knowledge base and existing software tools.  IMHO these are both
> mythological.
> 
>  - The audience we are targeting (IETF) knows very little about
>  either XSD or DSDL and are unlikely to learn them until forced
>  at gun point.

This is not fully correct. IETF has already experience with XML and XSD 
usage in many WGs. There are some WGs though who prefer RelaxNG.
 
....
> 
> So the cost is modest and unavoidable.
> 
> So the choice becomes:
> 
> - a custom version of XSD
>   - unreadable
> 
> - a custom version of DSDL
>   - already enough cats in that sack
> 
> - YANG
>   (cue patriotic music, starting slowly, building)

The criteria above is not really comprehensible.

....
> One final point:  consider the current push for "canonical XSD" as
> an indication of what's ahead of us.  XSD has the ability to describe
> the same thing in multiple ways, which is an asset if you see the
> schema information as a bad box against which content is compared
> for validation.
>
> But NETCONF engines require considerable more insight into their
> schemas.  An application has be break open the schema, decide how
> to parse and store the information, as well as divining the best
> way to present this information to the user or outside world.

You can use language specific XML syntax (like Yin or Kalua) for this
without the complexity of defining the models themselves with XSD
or RelaxNG.
 
> This means your engine would need to parse the XSD/DSDL data, turn
> it into some internal form, and use that internal form when handling
> the data.  For example, I need an understanding of keys to find the
> appropriate data inside my config database.  So I need an intimate
> view of my schema data that isn't normally available.  And having
> to deal with discerning this intimate view from the multiple
> ways that XSD/DSDL can represent it is not easy.
>
>
> So an XSD/DSDL approach will be a "+-" approach, adding some NETCONF
> specific information, but also removing abilities and mechanisms
> in order to limit the schema to a solvable problem.  This reduces
> the benefits of the existence of knowledge or software that supports
> the full standard.  "You can't do that in our version of XSD/DSDL"
> is a recipe for trouble.

You can use XML syntax for this.
 
> That's the big picture.  Are we crazier making jury-rigged versions
> of ugly or inbred standards, or are we crazier to think that we can
> do better?

I don't know the answer here. I think the picture is a bit bigger than 
assumed and we have now other solutions to consider which look 
usable and helpful for different reasons.

Cheers,
Mehmet
 
> Thanks,
>  Phil
> _______________________________________________
> NGO mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/ngo
> 

      Lesen Sie Ihre E-Mails auf dem Handy.
www.yahoo.de/go

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Feb 2008 07:32:21 -0800

Mehmet Ersue wrote:
>...

I don't agree with this conclusion.
IMO, ease of use is the most important factor
in mistake-free configuration management, so
it is important to agree on what 'more readable' means.
The DM readers (implementors and operators) need to be
able to easily understand the data model, so they don't
mis-interpret or fail to recognize the important details.

I don't agree with sec. 4.1 of the Kalua draft, the explains
why XML encoding for the DM source document is a good choice.
The source document syntax does not need to be the same as
the wire encoding.  Sure XML is well-known in the industry, but not
as well-known as plain text, without all the verbosity.
Sure XSD is available to specify the syntax of an XML document,
but ABNF has been around longer to specify language syntax than XSD.

Andy

> ------------------------------------------------------------------------
> Beginnen Sie den Tag mit den neuesten Nachrichten. Machen Sie Yahoo! zu 
> Ihrer Startseite! 
> <http://de.rd.yahoo.com/evt=41213/*http://de.yahoo.com/set>
> 
> 
> ------------------------------------------------------------------------
>

---

From: <[email-masked]>
Date: Wed, 27 Feb 2008 18:29:07 +0200

Hi,

hmm, the source configuration could as well exist in other formats,
let's say a graphical presentation of planned configuration, before
transferred over wire to the server. But I'd say in context of Netconf
we should first agree on how the data is encoded between client and the
server, and how model is encoded between the client and the server, not
how different systems may present either to their users.

While there is value in standardizing the user interfaces (e.g.
standardizing a user readable/writeable presentation of the
configuration or model), the standardization of wire syntax is required
for interoperability of the systems, and the user interface
standardization can be done later on top of the modelling language. The
systems can also help user to notice the parts of the model which are
relevant for the part of the configuration that the user is planning.

Netconf is anyway based on XML both for signaling and payload, and thus
implementations need to support XML, so why model layer should be
different?

Regards,

Mikko

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Andy Bierman
>Sent: 27.02.2008 17:32
>To: Mehmet Ersue
>Cc: NGO-list
>Subject: Re: [NGO] A bigger picture WAS:Re: completed CANMOD agenda
>
>Mehmet Ersue wrote:
>> 
>> Hi Phil,
>>...
>>available to YIN), but I would rather see XML syntax as the core 
>>syntax,  and there can be a standardized ASCII mapping of it.
>IMO, ease of use is the most important factor in mistake-free 
>configuration management, so it is important to agree on what 
>'more readable' means.
>The DM readers (implementors and operators) need to be able to 
>easily understand the data model, so they don't mis-interpret 
>or fail to recognize the important details.
>
>The source document syntax does not need to be the same as the 
>wire encoding.  Sure XML is well-known in the industry, but 
>not as well-known as plain text, without all the verbosity.
>Sure XSD is available to specify the syntax of an XML 
>document, but ABNF has been around longer to specify language 
>syntax than XSD.
>
>
>Andy
>
>
>> ....
>>  > Is there any way to quantify the two sides of this 
>cost/benefit  > 
>> tradeoff?  The "benefit" side is supposed to pay off in an 
>existing  > 
>> knowledge base and existing software tools.  IMHO these are both  > 
>> mythological.
>>  >
>>  >  - The audience we are targeting (IETF) knows very little 
>about  >  
>> either XSD or DSDL and are unlikely to learn them until 
>forced  >  at 
>> gun point.
>> 
>> This is not fully correct. IETF has already experience with XML and 
>> XSD usage in many WGs. There are some WGs though who prefer RelaxNG.
>>  
>> ....
>>  >
>> > an indication of what's ahead of us.  XSD has the ability to 
>> describe  > the same thing in multiple ways, which is an 
>asset if you 
>> see the  > schema information as a bad box against which content is 
>> compared  > for validation.
>>  >
>>  > But NETCONF engines require considerable more insight 
>into their  > 
>> schemas.  An application has be break open the schema, decide how  > 
>> to parse and store the information, as well as divining the best  > 
>> without the complexity of defining the models themselves with XSD or 
>> RelaxNG.
>>  
>> > view of my schema data that isn't normally available.  And 
>having  > 
>> to deal with discerning this intimate view from the multiple  > ways 
>> that XSD/DSDL can represent it is not easy.
>>  >
>>  >
>>  > So an XSD/DSDL approach will be a "+-" approach, adding some 
>> NETCONF  > specific information, but also removing abilities and 
>> mechanisms  > in order to limit the schema to a solvable problem.  
>> This reduces  > the benefits of the existence of knowledge 
>or software 
>> that supports  > the full standard.  "You can't do that in 
>our version of XSD/DSDL"
>>  > is a recipe for trouble.
>> 
>> assumed and we have now other solutions to consider which 
>look usable 
>> and helpful for different reasons.
>> 
>> Cheers,
>> Mehmet
>>  
>>  > Thanks,
>>  >  Phil
>----------------------------------------------------------------------
>> -- Beginnen Sie den Tag mit den neuesten Nachrichten. Machen Sie 
>> Yahoo! zu Ihrer Startseite!

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Feb 2008 08:41:34 -0800

> how different systems may present either to their users.

It is an implementation detail as to how you convert your
PowerPoint slides to a compliant NETCONF client application I guess.

> relevant for the part of the configuration that the user is planning.

This is already done.
RFC 4741 says how to encode NETCONF PDUs.

The feature we need to work on now is a data modeling
language that IETF participants and network operators
can understand, so NETCONF content can be defined in a manner
that provides the highest degree of NETCONF protocol interoperability,
extensibility, and operational robustness.

> implementations need to support XML, so why model layer should be

The highest priority are human readers, not implementation readers.
Just because the machine already knows XML does not mean that
all us humans have to spend the next 20 years looking at XML in
NETCONF MIB modules.  These modules are primarily for humans to understand
the conceptual data model definitions.

Andy

>>> --

---

From: Phil Shafer <[email-masked]>
Date: Wed, 27 Feb 2008 12:42:20 -0500

>and there can be a standardized ASCII mapping of it.

I don't want to rathole on this for too long, but I'd like to
point out that XML is a _great_ encoding for machine-to-machine
communication, since it is simple, extensible, and trivial to
parse.  But its readability often suffers grave injury due to
verbosity and the tendency to put first order concepts into
second order encodings.

For example, compare the XSLT and SLAX encoding of a simple if
statement:

XSLT:
    <xsl:if test="$value &lt; 15">
      <error>Too low</error>
    </xsl:if>

SLAX:
    if ($value < 15) {
        <error> "Too low";
    }

The important data ("$value < 15") is encoded in an attribute (second
order) instead of a first class language construct.  Worse, I have to
use "&lt;", reducing the readability.

Adding an "else" makes it worse, since you have to use <xsl:choose>
since an XML encoding needs a parent to organize the alternatives:

    <xsl:choose>
        <xsl:when test=""$value &lt; 15">
            <error>Too low</error>
        </xsl:when>
        <xsl:when test=""$oil &gt; 100">
            <panic>OMG</panic>
        </xsl:when>
        <xsl:otherwise>
            <drive>Like a banshee</drive>
        </xsl:otherwise>
    </xsl:choose>

SLAX:

    if ($value < 15) {
        <error> "Too low";
    } else if ($oil > 100) {
        <panic> "OMG";
    } else {
        <drive> "Like a banshee";
    }

A language designed for human readability (YANG) can't help but
be more readable than an one encoded in XML.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 27 Feb 2008 12:45:24 -0500

[email-masked] writes:
>But I'd say in context of Netconf

UI presentation issues aren't NETCONF's core.  Instead the first
target is to look at how the data is organized, what is means, and
its constraints and internal relationships.  The wire encoding
should fall out of this easily.

Thanks,
 Phil

---

From: <[email-masked]>
Date: Thu, 28 Feb 2008 13:29:47 +0200

>From: ext Phil Shafer [mailto:[email-masked]] 
>Sent: 27.02.2008 19:45
>To: Lahdensivu Mikko (NSN - FI/Tampere)
>Cc: [email-masked]; [email-masked]; [email-masked]
>UI presentation issues aren't NETCONF's core.  Instead the 
>first target is to look at how the data is organized, what is 
>means, and its constraints and internal relationships.  The 
>wire encoding should fall out of this easily.

I agree that the metamodel of the language, the capabilities of the
language, not the syntax, is the most important. But the metamodel can
be realized with different syntaxes. And of the concrete syntaxes I
think the one used between different systems is more important to
standardize within Netconf than how each user sees the model, because
when syntax used between different tools/systems is defined, then UI
presentations (such as the Yang format) fall out easily.

And I specifically agree with "UI presentation issues aren't NETCONF's
core", and how I see it is that Yang syntax is such a UI presentation of
a model. And thus I think that it is sufficient now to define an XML
syntax for the metamodel, and leave UI presentations out of Netconf's
core.

At least I see more value in Netconf modelling language as a way for the
tools/system to exchange exact information of models, users anhyway have
different preferences how to see the data (whether XML, "C style" plain
text, tables, graphics etc.) But the core modelling language syntax
should be such that it is easy to translate that to other presentations,
as all tools should agree on one syntax for interoperability, and I
think for that purpose XML is most suitable. Translations to/from system
specific presentations should not be done by people, but by tools.

Regards,

Mikko

---

From: <[email-masked]>
Date: Thu, 28 Feb 2008 13:54:38 +0200

>From: ext Andy Bierman [mailto:[email-masked]] 
>Sent: 27.02.2008 18:42
>Cc: [email-masked]; [email-masked]
>> we should first agree on how the data is encoded between client and 
>> the server, and how model is encoded between the client and the 
>> server, not how different systems may present either to their users.
>> 
>
>> configuration or model), the standardization of wire syntax is 
>> required for interoperability of the systems, and the user interface 
>> standardization can be done later on top of the modelling language. 
>> The systems can also help user to notice the parts of the 
>model which 
>> are relevant for the part of the configuration that the user 
>is planning.
>> 
>
>This is already done.

No, wire syntax of Netconf RPC is defined, and wire syntax of
configuration data is arbitrary XML data, but the wire syntax of the
model is not defined. A generic Netconf client somehow needs to be
adapted/configured to support a Netconf server, and this
adaptation/configuration should be doable over wire, without an user
interpreting the model on behalf of the client. Of course also user
needs to understand the model, but the client can present the model to
the user as part of the user interfaces.

>
>The feature we need to work on now is a data modeling language 
>that IETF participants and network operators can understand, 
>so NETCONF content can be defined in a manner that provides 
>the highest degree of NETCONF protocol interoperability, 

Yes, but also here my preference is a format which can be easily
converted to different presentations.

>
>
>> Netconf is anyway based on XML both for signaling and payload, and 
>> thus implementations need to support XML, so why model layer 
>should be 
>> different?
>
>
>all us humans have to spend the next 20 years looking at XML 
>in NETCONF MIB modules.  These modules are primarily for 
>humans to understand the conceptual data model definitions.

If so, why is there difference between reader of configuration, compared
to reader of model. Both can be implementation or human readers. Model
can be seen as just one level of configuration, it configures generic
clients to support server specific data.

Regards,

Mikko

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 28 Feb 2008 13:26:50 +0100

> the user as part of the user interfaces.

I am now loooking into the problem of taking the schema of the entire
configuration and deriving formally
1. schema for edit-config PDUs
2. schema for a reply to get-config, also taking into account the
subtree filter specified in the request, if any

The grammar part is quite straightforward, the other parts of the data
model (semantic constraints, defaults) are more tricky.

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 Feb 2008 05:22:49 -0800

> presentations (such as the Yang format) fall out easily.

So the argument is that the DM readers and writers do not really need
to know the language because they will have UI (GUI?) tools
to hide the language from them?

We don't standardize screen snapshots in the IETF.
We need the entire semantics and syntax of a standard
expressed in English text.  These are IETF rules, not mine,
but I agree with them.  (If I implement the IPFIX model
5 years from now, will I need the 2008 GUI tool or the 2013 GUI tool
to view it?  How do I post mailing list comments on video frame 4327
of the YouTube FOOMIB proposal?)

Andy