Subject: Canonical configuration database order

From: Andy Bierman <[email-masked]>
Date: Fri, 02 Jun 2006 08:30:21 -0700

Hi,

This may be data-model specific, but maybe not.
The SMI uses OIDs to name data, which implies a
canonical order of all possible data (lexi-next in this case).

A canonical order is useful for implementing a diff-config RPC.
CLIs maintain an internal canonical order, even if the user
enters instanced data in a different order (e.g., interface command).

In XML you need to distinguish between multiple named instances
(e.g., a key is defined) vs. multiple unnamed instances (e.g., maxOccurs 
 > 1).
The canonical order for named sibling instances is the natural sort order,
based on the key associated with the nodes.  For multiple unnamed
instances, the ordinal position (0 to N-1) uniquely identifies each
node within a set of sibling nodes.  The canonical order of unnamed
instances should not be changed from the PDU order.  However, agent
merge order of unnamed instances is data-model specific.

Is this something of interest to the WG, or something that
every vendor should (potentially) do differently?

Andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 2 Jun 2006 08:50:47 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Netconf (E-mail)" <[email-masked]>
> Sent: Friday, June 02, 2006 8:30 AM
> Subject: Canonical configuration database order
...
> based on the key associated with the nodes.  For multiple unnamed
...

What is meant by "the natural sort order"?

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 02 Jun 2006 09:33:00 -0700

> What is meant by "the natural sort order"?

Ascending order for each component of the key.
Keys are evaluated 'top to bottom', where the
topmost component represents the major index,
and each successive key component represents
successive minor index components.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 2 Jun 2006 09:52:19 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: "Netconf (E-mail)" <[email-masked]>
> Sent: Friday, June 02, 2006 9:33 AM
> Subject: Re: Canonical configuration database order
>
> Randy Presuhn wrote:
> > Hi -
> > 
...

Yes, but what is meant by "ascending order"?
I'm wondering whether, for example, strings are
canonicalized before comparison (e.g. is "A" plus
"Umlaut" the same thing as "A-Umlaut"), whether
locales matter (e.g. does "tra" come before or
after "tuy"), and what happens with numbers
(e.g. does 9.9 come before or after 999)?

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 02 Jun 2006 10:07:41 -0700

> (e.g. does 9.9 come before or after 999)?

I should have seen this coming, based on who asked the question ;-)
Hopefully, there are rules in place for canonical representation
and sort order of UTF-8 strings, including internationalization
and localization details.

I guess it is data type (and data modeling language) specific
as to the exact meaning of ascending order.  I compare numbers
as numbers, not strings, so 9.9 is less than 999 and -4 is less
than 2.1.  Enumerations ascend in the order they are defined
(aligns with SMIv2 and C), not alphabetic order of the enum values.

Andy

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 2 Jun 2006 10:21:18 -0700 (PDT)

HI,

Yes, and remember that the sort order for values is
not just the order if the values were text strings,
but the order is based on the type of the value.
For example, sorting as text, string "10" preceeds
string "2". But sorting as numbers, value "2"
preceeds value "10".

> successive minor index components.
Regards,
/david t. perkins

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 2 Jun 2006 11:35:56 -0700

Hi -

> Sent: Friday, June 02, 2006 10:07 AM
...
> and localization details.

There are lots of rules available.  We need to chose a set that
can reasonably be implemented in a way that will ensure interoperability.
I think that permitting localization to affect representation or ordering
would be a recipe for disaster, since it would require any entity potentially
needing to compare configuration data to be privy to the localization
parameters used by whatever thing(s) generated the data.

...

A consequence of doing things this way is that data could be compared
only by things with full knowledge of the schema.  That's not necessary
in the case of SNMP, and is quite useful.  This may be a bug or a feature,
but we should be aware of the implications for, for example, configuration
management systems that, in trying to identify changes in configuration,
will need to know which differences in representation are significant and
which are not.

Randy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 02 Jun 2006 16:38:38 -0400

Andy Bierman writes:
>based on the key associated with the nodes.

FWIW, JUNOS has both auto-sorted and user-sorted lists.  For example,
the terms of an import policy are named by the user and ordered by
the user, since the order matters.  But for interface definitions,
the order doesn't matter, so we sort them automatically.  Both have
keys (term name and interface name), to allow users to refer to
them.  The term name for policies is not important to the routing
code, which simply applies the terms in the order they appear in
the configuration, but is necessary to allow users to do stuff like:

    edit policy foo term goo
    copy term goo to term zoo
    delete term goo
    insert term goo before term moo

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 02 Jun 2006 20:32:03 -0700

>     insert term goo before term moo

Your user-sorted list is a position-dependent (unnamed) list.
For automation purposes, I always leave the order unchanged.

Presumably, these CLI commands can be NV-stored, so they
will appear in a specific place in the <running> config.
Now consider a 'merge' <edit-config> operation.
There is no deterministic algorithm you can use to reliably
automate the merge operation for unnamed instances.
(That's one area where data-model callbacks are difficult to eliminate.)

In some data models concatenation may be the algorithm,
but it doesn't have to be.  In your example, if I merged
these commands with an identical existing set by concatenation,
the result would be syntactically correct, but operational garbage.

Andy