Subject: [NGO] comments on draft-presuhn-rcdml-01

From: Balazs Lengyel <[email-masked]>
Date: Fri, 15 Feb 2008 12:21:57 +0100

Hello
Reading the document it strikes me that a good number of requirements will not really help us
when we try to choose between YANG, RelaXNG+-, XSD+- etc.

Many of the requirements e.g. compliance related, compatibility rules, basic types, keys, data
characterization are features that can and should be implemented in all of the DMLs. The real
difference is only that some DMLs already today have many of these features while other not
yet. The risk is not that they can not be added to YANG, RelaxNg etc. rather that there might
be a lack of manpower to implement these features. So here the only question is how many of
these features are already there, and how much work is still needed.

There are other requirements like readability, ownership and change control for which the
different DMLs will definitely offer different solutions.

In my view we should concentrate on just the latter requirements and on the "how much more
work" needed question.

Balazs

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 15 Feb 2008 10:10:40 -0800

Hi -

> From: "Balazs Lengyel" <[email-masked]>
> To: "NETCONF Goes On" <[email-masked]>
> Sent: Friday, February 15, 2008 3:21 AM
> Subject: [NGO] comments on draft-presuhn-rcdml-01
...
> when we try to choose between YANG, RelaXNG+-, XSD+- etc.

This shouldn't surprise anyone.  The proponents of these proposals are smart people,
and wouldn't be advancing their proposals if they felt their solutions weren't able to
handle these basic kinds of requirements.  (Though in several cases, they will
still dispute the validity of the requirement, even though their solution can meet it.)

> these features are already there, and how much work is still needed.

This gets to the "existing tools" requirement - whether "off-the-shelf" tools implement the
complete solution today.  Though some find this argument compelling, I personally,
based on the ASN.1 experience, think it's actually a red herring.  The "domain specific"
stuff is where things get interesting.  The resulting customization of off-the-shelf technology
may result in a perfectly usable product, but from a code maintenance perspective, it could
well have been easier to start from scratch. There are good reasons that commercial
SNMP toolkits and SMI compilers were not built using off-the-shelf ASN.1 tools.

> different DMLs will definitely offer different solutions.

I think they all have plausibale stories for ownership and change control.
Despite what the CHI people will tell us, I regard readability and the closely
related usability as rather subjective.  However, I think they will end up being
deciding factors for some of us, in the absence of a clear technical "winner".
 
> In my view we should concentrate on just the latter requirements and on the "how much more
...

It's really instructive to see what a non-trivial model looks like under
each proposal, particularly if there are constraints like the ones we
run into all the time in MIBs or in CLIs.

However, for the canmod BOF in Philadelphia we've been asked to focus on
requirements, and go into specific proposals only as a way of illustrating
ways in which requirements might be addressed.  Seeing how, for example,
a machine-readable uniqueness contraint is formulated, is instructive.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Feb 2008 12:03:24 -0800

Randy Presuhn wrote:
>....

We need manager application and agent engine experts to agree on the hooks
in the DML required to support their tools.  I am much more familiar with
the agent side of the equation, and IMO, YANG is exactly the DML I need
to build the most efficient and most automated agent code for handling
NETCONF PDUs.   On the manager-side, the problems are a bit different,
and strict version control, data organization and management, and
capability-driven conditional conformance are much more interesting
than whether the 'foo-knob' is a string or an integer.

IMO schema validation is useless for NETCONF PDU validation,
and it should be obvious that no off-the-shelf tools for XML would
have the slightest clue how to generate the correct <rpc-error>
for any given PDU, and any given problem -- since most of the
errors are like 'lock-denied',  where a schema doesn't help at all.
An NM protocol like SNMP or NETCONF needs to have very flexible PDU
structures (that Postel Principle thing, you know).

The NETCONF XSD is designed so that anyone can define content
(rpc, data, or notification), and hook it into the content layer for
the PDU.  This allows managers to build PDUs, and it doesn't
matter (outside that application) how the content layer is
defined or generated.

Here's the main thing we learned from 3 years of SMING WG:

DML Priority #1:

    DM readers can easily understand the data model without mis-interpretation
    or extensive training in the DML itself

DML Prioriry #2:

    DM writers can easily create and manage DM modules without errors in them

DML Priority #3:

   DM toolmakers can extract enough semantics and protocol meta-data to automate
   or semi-automate DM protocol operations

These priorities are still the same today.

> Randy

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 15 Feb 2008 12:32:07 -0800

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: "NETCONF Goes On" <[email-masked]>
> Sent: Friday, February 15, 2008 12:03 PM
> Subject: Re: [NGO] comments on draft-presuhn-rcdml-01
...
>     or extensive training in the DML itself

I'd put this as "Minimal training needed to be able to read a data model" but
I think we're in violent agreement on this one.

>     DM writers can easily create and manage DM modules without errors in them

Depends on the kind of errors you're talking about.  Certainly language usability
is important, but I think something like "simple things should be simple to model"
is also relevant.  The problem is that as a power tool becomes more powerful,
the easier it is to accidentally remove body appendages.

>    or semi-automate DM protocol operations

I'd consider this as slightly higher priority than "ease of writing", but definitely
of lower priority than "ease of reading".  But we're definitely in agreement that
machine-extractible semantics are valuable.

> These priorities are still the same today.

Whatever they are, I do agree they haven't changed.  :-)

One other priority, which we did *not* have in the SNMP era,
and which the operators hammered home at the IAB workshop,
was the ease of reading and of manipulating on-the-wire representations
of instances of a model.  I'm not sure any of the proposals really does
very much for this set of concerns.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 16 Feb 2008 00:53:23 +0100

On Fri, Feb 15, 2008 at 12:32:07PM -0800, Randy Presuhn wrote:
 
> One other priority, which we did *not* have in the SNMP era, and
> which the operators hammered home at the IAB workshop, was the ease
> of reading and of manipulating on-the-wire representations of
> instances of a model.  I'm not sure any of the proposals really does

The on the wire encoding pretty much has been decided when NETCONF was
defined; data modeling proposals have not much impact here (except
perhaps minor things like (non)usage of XML attributes or elimination
of mixed content and similar things). So I am not really sure how to
understand your last sentence.

/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: "Randy Presuhn" <[email-masked]>
Date: Fri, 15 Feb 2008 16:05:13 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> Sent: Friday, February 15, 2008 3:53 PM
> of mixed content and similar things).

Agreed.

> So I am not really sure how to

Simply that from some perspectives, all this work completely misses the
point of the operators' comments.  But it's too late to do anything about
that.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 16 Feb 2008 01:12:45 +0100

On Fri, Feb 15, 2008 at 04:05:13PM -0800, Randy Presuhn wrote:
 
> Simply that from some perspectives, all this work completely misses
> the point of the operators' comments.  But it's too late to do
> anything about that.

I think "completely misses" is too strong a word. There are many tools
and libraries to deal with XML documents; much more than there will
ever be generic BER en/decoders.

Perhaps the encoding could have been made simpler. But then we likely
would have had to go through another requirements process first and
NETCONF might not even be defined today. ;-)

/js

---

From: "David Harrington" <[email-masked]>
Date: Fri, 15 Feb 2008 19:26:01 -0500

Hi,
 
> very much for this set of concerns.

It is important to understand that operators don't trust applications
that translate from a non-readable on-the-wire representation to
something more user-friendly, because many translators end up
mis-representing the information that was sent.

When encryption is a requirement, the requirement seems to be making
the data accessible immediately after it has been decrypted and before
it has been massaged by applications; that is an implementation
detail. 

The other way to interpret the requirement is to make the on-the-wire
format readable when there is no encryption present, so an operator
can verify that the data presented as a translation of the original
information is accurate.

dbh

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Feb 2008 17:01:17 -0800

> Hi,

The first order problem is whether to have any sort of deep
keys or not.  If yes, then the key leaf reordering in YANG
will not work.  If not, then it will.  The second order
problem is whether instances of list elements should be
encoded in XML with key leafs first, or whether they should
be encoded in the defined order (as any XML tool would expect).
(The XSD translation would move the leafs around, and just the
YANG file would be in an order that did not match the 'wire order').

IMO, this whole thing is a huge hack to keep from buffering
a NETCONF <edit-config> PDU -- which is going to be relative
in maximum size to the device size, so it isn't really a memory
concern anyway.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 15 Feb 2008 17:11:32 -0800

Hi -

> To: "David Harrington" <[email-masked]>
> Cc: "'Randy Presuhn'" <[email-masked]>; "'NETCONF Goes On'" <[email-masked]>
> Sent: Friday, February 15, 2008 5:01 PM
...
...

It's interesting (to me at least) that the rcdml design team didn't
see this requirement in the lists of requirements from past IETF
meetings.  I doubt we could have agreed on it as a requirement,
but it would still have been nice to have had it in our list.

Randy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 15 Feb 2008 22:22:07 -0500

Andy Bierman writes:
>keys or not.

IMHO there's little need for deep keys and the complexity
isn't warranted.

>The second order

I don't see the "or" here.  They can be encoded key leafs
first and that should be the defined order, which XML tools
can handle.

>YANG file would be in an order that did not match the 'wire order').

So if YANG required key leafs to appear before non-key leafs, would
that suffice?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sun, 17 Feb 2008 08:01:30 -0800

> IMHO there's little need for deep keys and the complexity

Why is it complicated?
A leaf can be nested within containers, and nothing else.
IMO the nest level will not need to be > 2, but that would
be a bad CLR to have in the spec.

This would allow the important use-case, where a DM writer decides
that reusable containers are needed, and a grouping of
sibling nodes that cannot be recognized on-the-wire is
not needed.

As long as a leaf is a child of the list node,
and static (always exactly 1 instance of the named leaf within
each list node), it should eligible as a key leaf.
The kind of small reusable containers applicable to NM standards
are likely to be needed as key leafs in the future.

This is clearly more effort to implement within an agent,
but so what?  The highest priority is that humans have
the best possible DML to work with, not that agent software
should save 1 NETCONF PDU's worth of memory.

The DM designer should be allowed to decide whether reusable
containers or groupings are the appropriate tool for the job.
Once you put the handful of leafs in a container (even in
grouping), then none of those leafs can ever be used in a YANG list
as part of the key.

> So if YANG required key leafs to appear before non-key leafs, would

No, this would mean key leafs from groupings would likely be in the
wrong place.  The current hack is better than this hack.

Andy