Subject: [YANG] insert and key attributes

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Jan 2008 07:53:24 -0800

Hi,

1) sec. 7.8.6 mentions the 'key' attribute (great, another
    overloaded term ;-) but this is not formally defined anywhere.
    The terse definition of the 'insert' attribute is not a formal
    definition either.  In general, all the new requirements
    that YANG places on NETCONF agents is scattered throughout
    the document, and not entirely obvious.

2) para 4 in 7.8.6 says if insert is missing, then it defaults
    to last.  Even in a list indexed by an integer.  This seems
    strange to me, to use an integral key and then ignore the actual
    base type, but I guess 'ordered-by-user' implies that the base type
    of the key has no meaning to the agent.

3) The last example in 7.8.7 is confusing.
    (There is a typo "to move a the new user 'barney'".)
    If 'barney' was already inserted after 'fred' (previous page)
    then the merge of 'barney' before 'fred' will fail in NETCONF.
    There is no move operation in NETCONF.  You cannot edit the
    value of a key.  The example would actually have no affect
    in NETCONF, since the <name> field was already set to 'barney'.

Andy

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

---

From: Phil Shafer <[email-masked]>
Date: Fri, 11 Jan 2008 15:39:22 -0500

Andy Bierman writes:
>    definition either.

Yup, this needs some additional words.

>    In general, all the new requirements

What are you envisioning?  A section for NETCONF agent authors that
don't want to read the entire document?

>    of the key has no meaning to the agent.

Exactly.  The key gives uniqueness but not order.

>    in NETCONF, since the <name> field was already set to 'barney'.

YANG uses "merge" w/ insert to move existing data, since not having
a move operation is a bug.  Do we need to define our own
"yang:operation='move'" to achieve this?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Jan 2008 15:00:04 -0800

> "yang:operation='move'" to achieve this?

I do not agree.
The WG did not want a move operation.
The set of operations is decided by consensus.
Whatever DML is used for NETCONF, it needs to work
with the protocol the way it is defined.

I think the DML should be separate from the protocol.
The YANG document should not be defining any protocol extensions or changes.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sun, 13 Jan 2008 00:49:28 -0500

>The WG did not want a move operation.

s/did not want/could not agree/

We pitched an lot of very useful features during the dark ages
of netconf.

>with the protocol the way it is defined.

YANG adds "insert" also, which NETCONF does not define.  Are
we to pitch that also?  Assumably not, since YANG defines
not only the data model, but how to manipulate that model
in a non-stone age manner.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sun, 13 Jan 2008 06:54:25 -0800

> We pitched an lot of very useful features during the dark ages

In your opinion they were useful.
It takes WG consensus to make a standard -- that is my point.

> in a non-stone age manner.

How is a manager supposed to know that the agent uses the "-00 YANG"
version of the NETCONF protocol, vs. the "-01 YANG" version
vs. "RFC 4741 NETCONF"?

You can add these XML attributes to the waiting list of features
for the NETCONF WG to consider in a future version of the standard,
but since these additions directly assist configuration, don't
expect the WG to ever get to it.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 13 Jan 2008 17:35:32 +0100 (CET)

> version of the NETCONF protocol, vs. the "-01 YANG" version

If the manager knows the datamodel, then it knows how to manipulate an
ordered-by user list; it also knows which element(s) are keys, how
they are encoded to XML etc.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 13 Jan 2008 09:43:35 -0800

> they are encoded to XML etc.

IMO, it is important to separate the data modeling language
from the protocol, and to keep the NETCONF protocol as DML-neutral
as possible.

It doesn't seem like a good idea for interoperability to
have one flavor of NETCONF if the vendor uses YANG data models
and another if the vendor uses XSD or RelaxNG.  Even worse,
what if the vendor publishes some modules as YANG, others
as XSD, and there are different flavors of NETCONF within
the same agent.

Note that error-app-tag and error-message are not extensions
to the protocol at all -- they simply specify values for
fields already defined in <rpc-error>.

But the key and insert attributes change the behavior of
the <edit-config> operation.  It doesn't matter that they
change it for the better, by adding support for user-ordered lists.
What matters is that a standard protocol needs to be changed
by a WG, and should be done in a way that is not specific
to one particular DML.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 13 Jan 2008 19:01:13 +0100

> from the protocol, and to keep the NETCONF protocol as DML-neutral

A protocol and its data modeling language go hand in hand.

> as XSD, and there are different flavors of NETCONF within

XSD and RelaxNG without extensions and restrictions won't be terrible
useful for YANG. So if at all, we talk about XSD-+ and RelaxNG-+.

> But the key and insert attributes change the behavior of the
> <edit-config> operation.  It doesn't matter that they change it for
> the better, by adding support for user-ordered lists.  What matters
> is that a standard protocol needs to be changed by a WG, and should
> be done in a way that is not specific to one particular DML.

If there are things in YANG that really belong to the protocol, we
should turn them into proper protocol extension proposals for the
NETCONF working group to consider.

The end goal is to make NETCONF a success and if there are things
where the protocol needs improvement based on implementation
experience, then lets work out the details and get the NETCONF WG to
look at it. I think it would be good if the NETCONF WG would have a
plan to revise the NETCONF spec - if alone to fix known bugs and
ambiguities.

/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: Phil Shafer <[email-masked]>
Date: Sun, 13 Jan 2008 23:06:41 -0500

Andy Bierman writes:
>the <edit-config> operation.

Are you trying to say that NETCONF limits the ability of the data
model to use attributes to perform additional config operations
within an <edit-config>?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sun, 13 Jan 2008 21:59:54 -0800

> model to use attributes to perform additional config operations

Conformance to RFC 4741 does not require any additional
attributes for <edit-config>.  If the same operation
without the YANG attributes does not produce the same result,
like the 'move barney' example, then the agent is not RFC 4741
compliant.

You can redefine NETCONF all you want -- just don't
claim conformance to RFC 4741.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 14 Jan 2008 09:44:03 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> attributes for <edit-config>.

RFC4741 is pretty silent on the semantics of the edit-config
operations... by design.

> If the same operation

I don't agree with this statement.  Where in RFC4741 is this rule
described?  Are you saying that attributes are special, and that for
any NETCONF compliant request, I should be able to remove all
attributes and get the same result?  (This would of course rule out
any implementation that uses XML attributes for encoding of data,
which rfc 4741 does not do.)  If not, how am I supposed to know which
attributes I can remove?

Are you suggesting that we should remove 'ordered-by user' from YANG?

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 14 Jan 2008 08:40:55 -0500

>attributes for <edit-config>.

Nor does it prevent the use of additional attributes.

>like the 'move barney' example, then the agent is not RFC 4741

Operations on NETCONF data models are defined by the data model.
The data model is the contract between the agent and the manager,
and if neither party understands this contract, operations are not
possible.  NETCONF doesn't define a generic data model that all
parties must implement or understand.

There is no requirement that I support the xc:operation attribute
on every (or any) node in my data model.  NETCONF gives lots of
freedom to the data modelers.  This is by design.

If my data model defines additional operations, attributes, or
elements, this doesn't invalidate any claim of RFC 4741 conformance.

YANG is a means of defining data models which follow a particular
set of rules.  One of these rules is this move operation.  In order
to implement a YANG-based data model, an agent will need to support
this operation.  But this will not make that agent non-compliant
with 4741.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Jan 2008 07:22:07 -0800

> this operation.  But this will not make that agent non-compliant

This is your interpretation of RFC 4741.
I think a WG should decide matters of standards conformance.

I agree with Balazs that changes to protocol behavior belong
in a different document, and should not be part of the data
modeling language.

I do not think it promotes multi-vendor interoperability
to have each vendor come up with their own attribute extensions
to NETCONF <edit-config>.  The goal of the IETF should be to
converge on a standard <edit-config> operation, not simply
codify proprietary CLI with angle brackets.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 14 Jan 2008 12:10:28 -0500

>This is your interpretation of RFC 4741.

Yup, and it's my memory of the WG's repetition of "that's up
to the data modeler".

>The goal of the IETF should be to

RFC 4741 did neither of these extremes.  We said explicitly:

5.2.  Data Modeling

   Data modeling and content issues are outside the scope of the NETCONF
   protocol.  An assumption is made that the device's data model is
   well-known to the application and that both parties are aware of
   issues such as the layout, containment, keying, lookup, replacement,
   and management of the data, as well as any other constraints imposed
   by the data model.

   NETCONF carries configuration data inside the <config> element that
   is specific to device's data model.  The protocol treats the contents
   of that element as opaque data.  The device uses capabilities to
   announce the set of data models that the device implements.  The
   capability definition details the operation and constraints imposed
   by data model.

NETCONF gives all power to the data model.  It's an open spec that
allows expandability and evolution.  The goal of the IETF is to
deploy standards that people actually use, and past NM efforts that
have taken this fascist content model have failed due to lack of
flexibility and expressiveness.  NETCONF works hard not to repeat
those mistakes.

The operations in 4741 were not meant to be an exhaustive list that
limits what the DM can do, but to give a normal way to do the few
things that the WG could agree on.  There are many operations that
can only be defined once the data model is known.  YANG defines how
keys are encoded, making it possible to do use "insert" to reorder
lists.  Without lists, keys, and the semantics behind them, you
can't define that operation in any meaningful manner. (Yes, you can
to the "here's a blob to tell you what to move" and "here's a blob
to tell you where to move it", but even these need the data model
to tell you what you can move and where you can move it).

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Jan 2008 09:33:23 -0800

>> This is your interpretation of RFC 4741.

I think you are misunderstanding my concern.
Extending the set of standard edit-config operations is fine.

The document(s) specifying any new standard protocol operations should be
independent of the data modeling language.  This is done
simply by specifying the XML content (e.g., operation attribute)
instead of a particular DML representation of the XML.

The NETCONF WG should agree on this sort of new NETCONF protocol feature,
the same as any other.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 14 Jan 2008 13:35:13 -0500

>The NETCONF WG should agree on this sort of new NETCONF protocol feature,

The feature relies on the data modeling rules of YANG.  It will be
a standard part of YANG-based models, but not a standard part of
NETCONF.  Other data modeling languages are free to define their
own ordering schemes, which need not be compatible with what we
have in YANG.  The dependency would mean that spliting it into
another document is just adding world.  Leave it in the YANG draft.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Jan 2008 11:15:06 -0800

> another document is just adding world.  Leave it in the YANG draft.

I disagree that this is a good design approach for a standard protocol.
There is nothing YANG-specific about user-ordered lists or the
concept of inserting this entry before/after that one.  If the
WG agrees to add this sort of standard operation to the protocol,
then DMLs like YANG can take advantage of it (ala error-app-tag).

IMO, the NETCONF protocol should define a standard set of features
that does not change depending on the DML used to define NETCONF content.

Andy