Subject: [NGO] completed CANMOD agenda

From: Andy Bierman <[email-masked]>
Date: Sat, 23 Feb 2008 12:54:15 -0800

Hi,

Is there an updated CANMOD BoF charter?
The BoF wiki page was not working last time I tried.

The SMING WG did, in fact, have consensus on the
relative priority of readers, writers, and then tools.
It was understood that within the MIB standards process,
and throughout the lifetime of a MIB module, there are
far more readers than writers or tool developers.

Therefore, I think it is appropriate to reaffirm these
priorities in the CANMOD BoF, and try to understand
how each DML proposal impacts all 3 classes of user,
especially the readers.

The next biggest class of user is the DM writer.
The goal here should be to provide the highest level of
modeling capability in the simplest form possible,
applying the usual engineering trade-offs.

IMO, YANG provides enough features to support NM configuration,
but ultimate modeling complexity/capability is sacrificed for
ultimate ease-of-use, extensibility, and modularity.
Kalua and DSDL seem more machine-oriented than human-oriented.
That's fine for the applications that can utilize the
arcane and rigid syntax, but not for IETFers who are
trying to standardize data models, and have to read the drafts.

Ease-of-use is not just a slogan.
It is critical to mistake-free configuration management,
which (I think) is the problem NETCONF is chartered to work on.

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

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Sun, 24 Feb 2008 18:30:44 +0100

I certainly agree with the prioritty that Andy lists below.

Bert Wijnen 

> -----Oorspronkelijk bericht-----
> Van: [email-masked] [mailto:[email-masked]]Namens Andy
> Bierman
> Verzonden: zaterdag 23 februari 2008 21:54
> Aan: NETCONF Goes On
> Onderwerp: [NGO] completed CANMOD agenda
> 
> 
> Hi,
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Feb 2008 09:27:05 +0100

> far more readers than writers or tool developers.
I think there are other aspects that should also be taken into account.
For me an important priority is that the data modelling framework allow
for creating vendor-independent building blocks that
(1) give the vendors more flexibility in choosing some standard building
blocks and adding other proprietary parts,
(2) enable development of certain parts of the model without influencing
those parts that need no change,
(3) clearly separate different validation steps - in different phases
and contexts of NETCONF operation (e.g., validating PDUs on the wire
versus candidate configuration versus running configuration) some parts
of the full data model are not applicable but other parts can still be
used.
 
Doing everything - data types, grammar-based validation, semantic
constraints and defaults - in one big shot (albeit a nicely readable
one) is IMO much less likely to achieve such a goal. DSDL is better than
YANG in this respect.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Feb 2008 09:57:59 +0100 (CET)

> one) is IMO much less likely to achieve such a goal. DSDL is better than

Just to clarify: This is of course not what YANG does.  Data type
validation is done per "PDU", and semantic validation when a
configuration is validated.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Feb 2008 10:50:57 +0100

> configuration is validated.

You are probably talking about behaviour of a specific implementation
whereas I am talking about what is declared in the data model and
whether its different aspects are formally separated or not. How can you
say that something is valid wrt to a data model if it can mean different
things in different contexts?

To be concrete: While validating PDUs, default values have no meaning -
so, let me take an example from the YANG draft:

typedef listen-ipv4-address {
         type inet:ipv4-address;
         default "0.0.0.0";
}

Now, assume a leaf is declared as "listen-ipv4-address" in a DM. Is it
OK to claim that an actual value found in a PDU conforms to the
"listen-ipv4-address" datatype if the information about the default
value is neglected/not known? In fact, all you can do here is to check
that the value is an inet:ipv4-address, while in another context you can
also use the info about default - so this should IMO be clearly
separated.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Feb 2008 11:11:48 +0100 (CET)

> You are probably talking about behaviour of a specific implementation

I meant the behaviour as defined in the specification (which is based
on the three independent implementations of course... (I just realized
that the specification should probably be clarified in this area))

> "listen-ipv4-address" datatype

Yes.

> if the information about the default
> value is neglected/not known?

I don't understand how the default value is involved in this.  If a
leaf is of type listen-ipv4-address, and the leaf is present in any
PDU, the type MUST match.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Feb 2008 11:33:34 +0100

> that the specification should probably be clarified in this area))

The data models (or certain parts thereof) and statements of validity
with respect to them should be clear and unambiguous, without any
reference to a particular processing chain.
  
> PDU, the type MUST match.

Well, how does it match the default substatement?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Feb 2008 12:38:11 +0100 (CET)

> Well, how does it match the default substatement?

I'm sorry, I don't understand the question.  Could you elaborate?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Feb 2008 03:58:42 -0800

> blocks and adding other proprietary parts,

Vendor extensibility is not the same the thing as vendor flexibility.
The point of these 5 year, excruciating ordeals is standardization.
That means multi-vendor interoperability is the highest priority.
Vendors already have ultimate flexibility to support or ignore standards
in arbitrary ways.

> those parts that need no change,

Yes -- this is critical -- something SMIv2 and YANG both provide
(but none of the other proposals).  It is mandatory that a WG
or a vendor be able to extend a module defined in an existing
document -- without touching the original document at all.
The 'augment' clause is a critical feature for real network management.

> of the full data model are not applicable but other parts can still be

This is within the scope of the NETCONF protocol, not the DML.
RFC 4741 clearly states that the contents of a <config> parameter
(as opposed to a simple RPC method knob like <error-option>)
can only be fully validated when considering the conceptual <running/>
database, not the real PDUs on-the-wire.

The same is true for SNMP Set or Get PDUs.
Referential integrity, operation fragmentation, and error recovery
are defined in terms of the conceptual database on the agent.
The PDUs on the wire are quite flexible, and referential integrity
within a PDU is not considered interesting.

> one) is IMO much less likely to achieve such a goal. DSDL is better than

NETCONF needs its MIB definition language, just as SNMP has SMIv2.
The bar has already been set higher than you suggest, for the last
decade at least.  We need to raise the bar for NETCONF, not throw it away.
Configuration is much harder than monitoring, and the DML needs
to be comprehensive and focused, in order to achieve multi-vendor
interoperability at the content layer.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Feb 2008 13:18:33 +0100

> I'm sorry, I don't understand the question.  Could you elaborate?

The listen-ipv4-address specifies two things: the datatype in the true
sense of the word (IPv4 address) and the default value. If you say that
a concrete value matches this datatype, it is reasonable to expect that
both parts of the datatype are relevant, which is not the case when
checking the PDU - the only thing you can tell is that it is a valid
IPv4 address, the default statement makes no sense in this context. 

The alternative I am advocating is to allow NETCONF devices to advertise
separately e.g.,

(1) a capability defining the supported schema (grammar + datatypes),
(2) another capability specifying the set of defaults the device uses.

DSDL is designed to be used in this way, YANG isn't.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Feb 2008 04:34:51 -0800

> IPv4 address, the default statement makes no sense in this context. 

You don't seem to understand (or agree) that the PDU validation
is rather trivial, and not the interesting part of the NM problem
we are trying to solve.

It is a feature that there are lots of clauses that refer to
the structure of the conceptual database -- that is what we
are managing.  The validation of PDUs is not that hard
in comparison.

> DSDL is designed to be used in this way, YANG isn't.

How does this help interoperability?
This seems to complicate the NETCONF protocol without benefit.
There are 2 non-overlapping states for 'real' default
standardization (not the worthless DEFVAL in SMIv2):

   - the WG agrees there is no appropriate default value
   - the WG aggress these is an appropriate default value,
     and specifies in in the standard

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 25 Feb 2008 14:17:26 +0100

> those parts that need no change,
Yes this is requirement 3.3.3 Modular extension in the presuhn draft. YANG complies with it 
with the augment statement. Please describe how does DSDL meet it?
> of the full data model are not applicable but other parts can still be
I think separating validation into 3 parts: PDU, candidate, running is an interesting idea, but 
I don't  see this as a basic difference between YANG, DSDL or others. What you can validate 
depends on the rules set by NETCONF, not by the modeling language. You can do the same things 
based on YANG or DSDL. Or could you give me please an example to the contrary! Giving the 
PRECISE (!!!) rules for each step of validation is not included in any of the drafts as I see.

As I mentioned earlier, many of the features that one language boasts over the other can be 
lifted to all of them. IMHO the really important differences are the ones that are intrinsic in 
the chosen base language (own stuff for Yang, RelaxNg for DSDL, XML+own for Kalua):
readability, ownership, tools, the credibility of the workforce behind each draft (will there 
be enough people with enough time to do all the missing details?)
Balazs
_______________________________________________
NGO mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ngo

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Feb 2008 14:21:50 +0100

> (but none of the other proposals).  It is mandatory that a WG

I disagree. The extension mechanisms of RELAX NG are considerably more
flexible than those in YANG (you can selectively rewrite existing
patterns or add new stuff using either "choice" or "interleave"
combination mode).

However, my point is not so much about comparing extension mechanisms
but rather about explicit separation of different validation aspects and
semantics in the data model via different URIs/capabilities. 

> The 'augment' clause is a critical feature for real network management.

Augment in YANG doesn't allow you to replace parts of the existing
model. If a vendor (or a new version of a standard) just wanted to
change a single default value from what is specified in the existing
standard data model, the only option is to come up with a new data model
(= new URI). This would affect even subsystems that are not interested
in default values.

> within a PDU is not considered interesting.

Some validation can be efficiently done on PDUs as well, at least the
datatypes. Or consider candidate configuration - it should be almost
valid except that some semantic constraints may be broken, like missing
link targets.

> interoperability at the content layer.

I am not suggesting to throw anything away, just the opposite - it is
not wise to throw away most of what has been done by the XML (and SGML)
community in the past 20 years or so, just because it is not exactly the
way how it has been done in SNMP and SMI. In my view, NETCONF is after
all not that much different from other XML applications around.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Feb 2008 14:51:00 +0100

> are managing.  The validation of PDUs is not that hard

It is not limited to PDU, it is the same if you validate a full running
configuration. For the values going in the direction manager -> device,
the defaults have no meaning whatsoever but still their datatype has to
be validated.

>    - the WG agrees there is no appropriate default value

The device could advertise via (2) the actual default values it uses
even if they are not standardised.

>      and specifies in in the standard

If the standard default value changes, only (2) will have to be updated.
Applications that don't care about defaults need not do anything. If you
change the entire data model, such apps will be affected, too.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Feb 2008 14:56:12 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> For the values going in the direction manager -> device,

The default value is defined in the YANG model, and MUST match the
type.  This is thus something that tools are supposed to check (and
something that the existing tools do check).

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Feb 2008 15:22:46 +0100

> with the augment statement. Please describe how does DSDL meet it?

The example with changed default value in my previous mail illustrates
that YANG's augment statement doesn't help - you will end up with a
different (entire) data model. DSDL meets it because the defaults are
specified separately, using the DSLR language whose namespace is
different from that of RELAX NG, Schematron etc., so the DSLR part can
be easily distinguished and dealt with separately.

> PRECISE (!!!) rules for each step of validation is not included in any of the drafts as I see.

With YANG, you have a single monolithic data model, in DSDL you work
with several clearly separated parts. Arguably, YANG will be more
readable, DSDL more flexible.

> be enough people with enough time to do all the missing details?)

ISO 19757 folks are working on the missing details of DSDL, but the
basis - RELAX NG and Schematron - is already quite solid, stable and
supported by applications.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 25 Feb 2008 15:30:27 +0100

>> DSDL is designed to be used in this way, YANG isn't.

While I might agree or disagree with your idea of default handling, as I see it this concept 
could be introduced both in YANG and RelaxNg. Do you see any reason why RelaxNg is 
intrinsically better at your preferred way of default handling?

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Feb 2008 06:52:43 -0800

> Balazs Lengyel píše v Po 25. 02. 2008 v 14:17 +0100:
....

> readable, DSDL more flexible.

Explain monolithic here.
Not only is YANG fully modular, but it also supports
self-compiling sub-modules.

If by monolithic, do you mean that when the DM writer creates
a module, all the information for the 'foo-knob' is contained
in one place, with a minimum of redundant data entry?
That's a feature, not a bug.

Another lesson learned from the SMING WG, as Juergen pointed out
many times, is that manually splitting the data model object definition
into multiple parts (e.g., 1 protocol independent and N protocol
dependent parts) in the DML was very difficult to read, and made
it way easier for the DM writer to introduce bugs.

> supported by applications.

I don't think it is very readable, which is a big
problem for network operators and other people,
who like to understand what they read.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 25 Feb 2008 10:15:38 -0500

>readable, DSDL more flexible.

These are key elements of the design debate.  First, YANG sees
readable as a priority, since review and understanding of the data
model is a key for developing quality specifications.  (If you can't
read it, you can't find bugs in it.)  The population of readers
will vastly exceed the number of model writers, and the reviewers
time is a scarce resource which we cannot abuse.  (If they don't
read it, they won't find bugs in it.)

Second, YANG sees the data model as a contract between the device
and the application.  The model works like an API, and a device
which violates it should be regarded as broken.  Imagine trying to
make portable C code if the return value from fork() was vendor
dependent.  The cost of interoperability would be immense.  YANG
gives the application the ability to trust the device will behave
in accordance with the contract as written in the data model.

Third, YANG tries to put flexibility where it is needed and in
places where extensions won't impact the basic contract of the data
model.  If different implementations of a standard data model are
allowed to use different default values, the cost is that my
application needs to discover those defaults, or that my app can't
count on defaults at all and must explicitly instantiate default
values according to its understanding of the defaults.  Neither is
acceptable.

Finally, DSDL is working to join an existing set of solutions (RNG,
SCHEMATRON, NVDL, DTLL, CRDL, DSRL, etc) into a single framework.
The "clearly separated parts" is an artifact of the origins of the
cats placed into the sack.  YANG has a more freehand approach,
allowing us to make a simpler, cleaner solution that fits our problem
space more accurately.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Feb 2008 16:53:30 +0100

> intrinsically better at your preferred way of default handling?

RELAX NG is not intrinsically better because it cannot do it at all
(even the support for attribute defaults that is in DTD was removed -
for good reasons) but DSDL can. I don't see how you can formally
separate different aspects of a YANG model - structure, datatypes,
semantic, defaults - in order to be able to accept some of them and
replace the others.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Mon, 25 Feb 2008 11:29:43 -0500

Ladislav Lhotka writes:
>I don't see how you can formally

You can't, and YANG doesn't want you to.  The data model is the
contract between the device and the application.  You can't accept
some of it any more than you can ignore that clause in your mortgage
contract that says you need to send them money.

Or from the data-model as API point of view, you can't replace the
argument to shutdown() and still claim POSIX compatibility.  You
are allowed to extend the values this argument takes (ala augmentation),
but you need to Do The Right Thing when called with arguments defined
in the base API contract.

Random compliance is not a good thing.  It puts us back into the
lawless Wild West, where you can do anything that doesn't get you
shot.  We need more than that if we want to be able to make
network-wide automation trustworthy and dependable.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Feb 2008 18:02:15 +0100

Andy Bierman píše v Po 25. 02. 2008 v 06:52 -0800:> 
> self-compiling sub-modules.

By way of a remote analogy, Linux kernel is monolithic but also
considerably modular.

> in one place, with a minimum of redundant data entry?

In DSDL you can have it in one place, too - it is common to have
Schematron embedded in RELAX NG. The difference is that namespaces of
Schematron and RELAX NG are different, so their separation is explicit.
Sure, namespaces can hardly make the data model more readable, but the
point I wanted to make is that it could help to deal with the data
models in a more lego-like fashion.

As for defaults, I would find it actually easier even for humans to have
them all in one place outside the data model linked to the data tree via
XPath. 

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Feb 2008 18:53:43 +0100

> contract that says you need to send them money.

If your goal is to make the contract reusable for many different
parties, the best strategy is to divide it into identifiable blocks and
combine them as necessary.

If we end up with too many data models, their readability won't be very
helpful.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 25 Feb 2008 18:56:40 +0100

>> intrinsically better at your preferred way of default handling?
Sorry I meant DSDL.
> semantic, defaults - in order to be able to accept some of them and
First I see this separation of validation phases as rather implementation specific. E.g. if an 
edit config on the running database results in a valid configuration then we are OK. Validating 
the PDU early is a good idea (our tools do it), but that is just an implementation decision 
whether we do early validation or we try to build the database and fail e.g. because an input 
parameter is a string instead of an int32.

You could easily give a similar recommendation for YANG implementers that a few things should 
be checked already on the PDU. Just by saying that we will use schematron instead of C++ will 
not make life easier.

E.g.
YANG PDU checks: namespaces, basic XML hierarchy, element types, ranges, patterns
YANG presence of keys, uniqueness, etc.
YANG full checks: everything

However the idea of labeling model defined constraints (YANG's must statements) according to 
the validation phase might be a good one.

Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Feb 2008 20:35:14 +0100

> If we end up with too many data models, their readability won't be very

Luckily, there are reusable groupings in YANG.

/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/>
_______________________________________________
NGO mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ngo

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 25 Feb 2008 22:15:41 +0100

> them all in one place outside the data model linked to the data tree via
So you say it is easier to track down a default in another document based on a 6 level 
XPAth expression then to read

leaf max-interfaces {
   type integer;
   default 50;
}

I admit a separate file can give you some extra (unwanted?) flexibility, but calling it 
easier is something I fail to understand.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 25 Feb 2008 22:26:49 +0100

Hello Ladislaw,
I think your viewpoint is that of an expert in both modeling and in XML/RelaxNg/...
I on the other hand  fear that my customers (the operators) will never use a model they 
cant understand, and most of the operators are not experts in modeling or schematron.
Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 26 Feb 2008 10:06:18 +0100

> easier is something I fail to understand.

It could be easier because you needn't consult the (main) data model,
the position of the leaf is apparent from the instance configuration and
you are just interested in what default value is in that specific
location. With YANG approach, you have to know/find out the type of that
leaf (is it foo-ipv4-address, bar-ipv4-address or ...) and then the
default value in the typedef.

It will also allow for specifying actual default values used by the
device even if they are not standardised.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Feb 2008 10:44:46 +0100

> default value in the typedef.

YANG allows defaults on leafs. I assume that defaults on types will be
extremely rare. That said, I do hear your request to separate defaults
from the data model so that they can be changed easier. This can be a
requirement to discuss.

What I fail to understand is an argument that one language is better
than the other based on the way it deals with defaults. I am sure YANG
can be made to address such a requirement if there would be agreement
on the requirement. So lets focus on this specific requirement and
whether there is agreement to separate defaults from data models.

Section 3.5.9 of the requirements ID talks about defaults. Perhaps you
can phrase your concern relative to the text in this section? Do you
agree with any of the text? If not, what is missing? Can you come up
with a concrete suggestion to add to this section?

/js

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 26 Feb 2008 11:38:06 +0100

Juergen, thanks for coming to the core of this discussion.

I must say that the discussion sofar seem to be sort of a
"fight" between YANG and RELAXng solutions. In fact
I find the repeated statements quite frustrating.

I think we should indeed see if we can form consensus on this in
terms of "Is this a specific requirement that must be met.".

I am now going to read section 3.4.9 of the requirements ID again
in draft-presuhn-rcdml-03.txt.

Bert Wijnen

> Van: [email-masked] [mailto:[email-masked]]Namens Juergen
> Schoenwaelder
> Verzonden: dinsdag 26 februari 2008 10:45
> Aan: Ladislav Lhotka
> CC: [email-masked]
> Onderwerp: Re: [NGO] completed CANMOD agenda
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 26 Feb 2008 12:56:29 +0100

> with a concrete suggestion to add to this section?

The suggestion is: Specification of defaults should be explicitly
separable from the rest of the data model and carry an independent
identification (URI). It is thus possible to use the same data model
with different sets of defaults without changing the main data model
URI.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Feb 2008 14:08:25 +0100

> with different sets of defaults without changing the main data model

Is that an extension to what is in the requirements ID concerning
defaults or a replacement? Do you agree with the other text concerning
defaults in the requirements ID?

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Feb 2008 06:40:09 -0800

> I find the repeated statements quite frustrating.

IMO, we don't have a structured process for this discussion,
so you can't complain that there is no moderator or WG Chair
steering the discussion towards consensus.

Do we all understand XSD, RNG, and Schematron well enough
to use it to write a data model?  How important
is a quick learning curve in the requirements?

So let's forget about the big picture and focus on the
defaults problem instead.  Where is the text defining this
feature proposal?  The problem to solve is that an agent
implementation may have platform-specific default values,
so an registry is needed to store the array:

default[vendor, platform, platform-version, object, object-version] = string;

This allows an application to look-up the default value
that a particular agent implementation should be using.

Does this describe the requirement and general solution approach?

Is there also an assumption that since this registry exists,
there MUST NOT be any mechanism in the data model to
define a default value for a data model leaf (since
the DM writer can just add an entry to the registry instead).

I have no objections to an IANA registry for anything you want to store.
I have a strong objection to the notion that such a registry
should be the mechanism a data model writer uses to define a default value
for a typedef or a leaf.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 26 Feb 2008 10:05:21 -0500

Ladislav Lhotka writes:
>With YANG approach, you have to know/find out the type of that

YANG supports defaults on both user-defined types (typedefs) and
on specific leafs.  This feature allows the typedef to contain a
reasonable default, but to allow specific leafs to override it or
to provide a default when the base type has none.

And if a leaf is defined within a grouping, the default may be
overridden when the grouping is used, via the refinement mechanism.

This allows the modeler to define their defaults in the location
that makes the most sense, and to avoid repeatedly specifying
defaults for each location.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 26 Feb 2008 16:28:05 +0100

> defaults in the requirements ID?

An extension, yes. I agree with the rest.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Tue, 26 Feb 2008 11:37:09 -0500

Andy Bierman writes:
>defaults problem instead.

I'm happy to work on big picture issues, but big picture
issues require big honkin' emails.  Brace yourselves.....

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

So the question becomes simply this:  does the benefit derived from
applying the "embrace and extend" model to an existing (XSD) or
emerging (DSDL) standard from another standards body override the
cost of developing a new standard (YANG) more tailored to the
problem at hand?

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.

 - XSD and DSDL software may exist, but this code is unlikely to
 be integrated into NETCONF engines and the XSD- and DSDL-based
 models will target the syntax of the database (or the PDUs (but
 not both)), not the semantics of what's really going on when you
 talk to a NETCONF server.

So by these measures, the benefits are minimal.

The "cost" side should be easier for a standards body
to measure.  What is the cost of the IETF making a
standard DML for NETCONF?  Given the quality of the
existing YANG draft and the work the design group
has put into this effort, I'd predict a modest cost.

And the cost of developing our own standard will have
to be paid by the XSD and DSDL groups also, since these
solutions are not complete and will need to introduce
into an existing standard(s) the mechanism that are needed
by NETCONF.

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)

While the IETF should be leveraging work in other standards bodies
when it makes sense, in this case it is not reasonable.  The needs
of NETCONF will require a solution that can't be achieved with these
standards, and the cost of bolting the NETCONF material on to their
side (really into their guts) will give us a complex outcome that
will not be accepted in the NM community.

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.

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.

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?

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 26 Feb 2008 19:13:02 +0100

Hi Phil,

let me add few more bullets and some comments:

>   - w3c standard
    - used in RFC 4741
    - good support in apps and libraries
>   - people like the condensed syntax (cause it looks like YANG ;^)
      (under development)
    - the major parts (RELAX NG, Schematron) are well supported by apps
and libraries
    - considerable experience gained by large projects in W3C, ISO and
elsewhere
    - DTLL (part 5 of DSDL) addresses aspects that none of the
alternatives does (equality in value space, complex constraints beyond
regexps)
>   - incomplete solution: requires NETCONF extensions
      (much less than XSD)
    - extensions damage readability of compact syntax
    - most parts (except RELAX NG and Schematron) are under development
and lack application support
>   - simple syntax
    - excellent readability
>   - new work: IETF standard
    - no one knows it (in the XML world)
    - minimal experience
> emerging (DSDL) standard from another standards body override the

It is problematic to compare XSD with DSDL - XSD is more or less
comaparable to RELAX NG only.

> knowledge base and existing software tools.  IMHO these are both

My suggestion is to let the supporters of each methodology create few
non-trivial data models and show how they can be used. Without practical
experience, these discussions are indeed academic.

>  either XSD or DSDL and are unlikely to learn them until forced

How can YANG - as a completely new thing - be any better? On the other
hand, it is IMO not that difficult to learn any of these formalisms.

>  talk to a NETCONF server.

I don't agree, we are using the libxml2 library in our NETCONF engine.
> into an existing standard(s) the mechanism that are needed

Minor extensions of a solid framework are IMO less risky than an entire
new framework.

>   - already enough cats in that sack

I don't really see significant things that need customisation.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Feb 2008 10:57:51 -0800

Hi,

...
> experience, these discussions are indeed academic.

Great idea.

An IPFIX configuration data model was just published:
http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt

This is a real data model, developed by a real WG.
This is exactly the scenario that the NETCONF WG is looking for:
non-NETCONF and non-XML DM writers who are creating a domain-specific
data model.

The true measure of 'ease-of-use' is not whether the authors
know their own proposal, or a few experts know the technology,
but whether or not the intended audience (NETCONF data modelers)
actually think it is easy to use.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 26 Feb 2008 15:06:15 -0500

Ladislav Lhotka writes:
>How can YANG - as a completely new thing - be any better?

YANG is simpler and easier to learn.   The syntax is trivial and
regular.  The hierarchy is clean, the role of elements is obvious,
and the use of braces for containment is consistent.  YANG stresses
readability, but still gives sufficient flexibility, extensibility,
and power to allow it to be useful for large schemas.  YANG is
better, easier to read, to learn, and to use.

>Minor extensions of a solid framework are IMO less risky than an entire

We differ over the "minor"-ness, but the risks are:

- DSDL will be unreadable and folks will not see errors
  in specs, leading to interoperability issues.  This
  was the experience with XSD in RFC4741.

- People will see the stack of documents they need to read to
  understand DSDL and will not bother.  This is what we've
  seen with XSD.

- DSDL will not win the schema war on the fronts _outside_ the IETF.
  This not a given.  The best quote I've seen on this is Robert
  Koberg's: 'I wonder if the people who think RNG won have "Re-elect
  Gore" bumper stickers...'  ;^)

- DSDL will diverge from our interests (ala ASN.1)

The IETF has done well with SMI developing MIBs for operational
data.  This framework was unsuitable for configuration data, so we
moved to XML and NETCONF.  I don't really see the concern over
building our own DML for this scenario.  And we can generate XSD,
RNG, etc from YANG, so if your engine needs these formats, YANG can
support you.

Maybe we should turn this around:  does the cost of developing a
NETCONF DML based on YANG exceed the benefits of having such a
YANG-based DML?  What are the costs of using YANG?  Are the benefits
of readability, simplicity, and control sufficient to justify that
cost?  My opinion is obvious yes, since the costs aren't that high
and readability is a priority.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Feb 2008 00:46:03 +0100

> hand, it is IMO not that difficult to learn any of these formalisms.

a) YANG is NETCONF specific; it does not try to compete with XSD and
   of course not with something as big and ambitious as DSDL; YANG
   actually does not assume that you know any of these technologies
   since it is self-contained

b) YANG is a domain specific language designed to do what it needs to
   do well; it is not constrained by any framework it is derived from
   (making augmentations for example really easy, natural and powerful)

c) YANG is not "a completely new thing" if you look at how it came
   along - YANG is based on years of experience with proprietary
   NETCONF data modeling languages and shares some history as well
   with the SMIng project and the SMIv2

I do find things in various proposals that look like ideas taken from
YANG and then framed into a different syntax or a different framework.
I consider this a success of YANG since this tells me that YANG seems
to get many things right. In fact, I wonder how many of the recently
proposed NETCONF data modeling languages would actually exist if YANG
would not have come along in Fall 2007 to trigger their creation.

While certainly being biased, I believe YANG has...

- a reasonable self-contained specification
- running code (something the IETF in the past seemed to value)
- an open active mailing list with discussions on technical details
- people outside the YANG team using it in other WGs in the IETF
- a design based on experience with proprietary data modeling languages
- the backing of several NETCONF implementors

/js

---

From: Tomoyuki Iijima <[email-masked]>
Date: Wed, 27 Feb 2008 15:03:47 +0900

Hi,

Since CANMOD WG was established for a comparison of Data Model 
languages, discussing pros and cons of those languages is reasonable per 
se. I feel, however, that in a sense defining Information Model(IM) is 
more important than comparing languages that are used to define Data 
Model(DM).

Explanations of IM and DM are made in RFC3433 as follows.
   "The main purpose of an IM is to model managed objects at a 
conceptual level, independent of any specific implementations or 
protocols used to transport the data", "DMs, conversely, are defined at 
a lower level of abstraction and include many details" and "Since 
conceptual models can be implemented in different ways, multiple DMs can 
be derived from a single IM."

As long as IM are not defined, discussing the pros and cons of DM 
languages becomes furtile.

On top of that, RFC3433 also says the following.
   "One of the possibilities to formally specify IMs is to use class 
diagrams of the Unified Modeling Language(UML)."

IPFIX WG seems to have done that in a style of UML.

 >http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-04.txt

I think those efforts of defining IM/DM for other protocols as well 
should not be left behind. I'm concerned about that.

Kind regards,

-- 
Tomoyuki Iijima
Alaxala Networks Corp.
TEL:+81-44-549-1200
FAX:+81-44-549-1272
E-mail:[email-masked]

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 26 Feb 2008 22:28:22 -0800

Hi -

> From: "Tomoyuki Iijima" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, February 26, 2008 10:03 PM
> Subject: Re: [NGO] completed CANMOD agenda
...
> Since CANMOD WG

It is only a BOF, not a WG.  One of the things we will discuss at the meeting
is whether there is sufficient interest and technical cohesion to make the
formation of a WG worthewhile.

>  was established for a comparison of Data Model 

Perhaps, and a well-presented information model makes a data model
much easier to understand, but the data models are what gets standardized.
It's not clear to me what "interoperability" would even mean
for information models.

...
> languages becomes furtile.

Not necessarily.  We hope to be able to compare how specific
information models would map into the specific data modeling proposals
at the BOF.
 
> diagrams of the Unified Modeling Language(UML)."

I've been away from UML for a while.  Is there a standardized way to
use it for aspect-oriented modeling (rather than an inheritance-
oriented class hierarchy) in UML?

Randy

---

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

>IPFIX WG seems to have done that in a style of UML.

My read of the "rfc- and email- friendly" requirement (as well as
the "diff- and cvs- friendly one) is that it rules out UML.  Trying
to learn something from a diff of ascii art is a lose, let alone
the binary uml files.

Thanks,
 Phil

---

From: Tomoyuki Iijima <[email-masked]>
Date: Wed, 27 Feb 2008 16:51:09 +0900

Hi,

I'm sorry. I wrote a different RFC number.

Kind regards,

> Explanations of IM and DM are made in RFC3433 as follows.
RFC3433 -> RFC3444
> On top of that, RFC3433 also says the following.
RFC3433 -> RFC3444

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 27 Feb 2008 11:04:23 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tomoyuki Iijima
> 
> As long as IM are not defined, discussing the pros and cons 
> of DM languages becomes furtile.
> 

I disagree. The IETF (and other organizations) have a good record of
defining data models for specific tasks (like configuration and status
of network devices) without going through the stage of defining an
information model first. 

Dan