Subject: [Netconf] XML element order

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Aug 2008 14:12:25 -0700

Hi,

Is the NETCONF agent allowed to accept XML elements
out of the specified order?  It does not seem to
break anything.  This rule seems to be an XML CLR
which violates the Postel Principle.

SNMP never had a specified order for individual var-binds.
The CLI does not enforce any (sibling) command order
either.  A NETCONF database does not even have a
canonical ordering.

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Aug 2008 23:18:56 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> out of the specified order? 

Do you mean inside the protocol or inside the data?

> It does not seem to

This is an interesting question.  The protocol is defined with an XSD
which specifies an order of the XML elements.  One of the main
arguments for using XML and XSD has always been that one can use
existing tools.  But existing XML tools are not liberal.  For example,
they will not accept a missing namespace or that some elements are out
of order.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Aug 2008 23:18:56 +0200 (CEST)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Aug 2008 14:31:38 -0700

> Do you mean inside the protocol or inside the data?

both

> they will not accept a missing namespace or that some elements are out

Show me an 'off-the-shelf' XML tool that generates <rpc-error>
elements compliant with RFC 4741, or one with 'virtual nodes'
that facilitates sub-agent implementation.  I suppose an
implementation could gather all its distributed data into
one giant XML document for processing with such tools.
Implementation details should not matter that much to the IETF.

And what about agents that go fishing in any namespace if
the manager does not specify any?  Clearly broken wrt/ XML,
but clearly useful trying to get some useful work done.

I should let the manager tell the agent "I don't care if
you ignore out-of-order errors, but I don't.  It's done
with a CLI flag on the agent.

This is the difference between 'with-defaults' and let
the agent do whatever they want wrt/ defaults.  It is OK
if the manager says in the PDU "I do not want you to follow
the filtering rules exactly.  I want you to leave out the
defaults."  The agent should only be non-compliant on demand :-)

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Aug 2008 14:31:38 -0700

both

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Aug 2008 14:45:02 -0700

> Do you mean inside the protocol or inside the data?

Inside the data, a leaf-list is sensitive to order.
There is of course the CLR about encoding list keys first,
as well.  (My agent has to generate an error even if
it does not care if the key leaf is first?)
Obviously ordered-by user lists and leaf-lists
are sensitive to element order as well.

I already have code to make the agent as robust
and bullet-proof as possible.  It seems dumb to
add code to make the agent as picky as possible.
This is a OPS-NM no-no.

Andy

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/liFrom [email-masked]  Thu Aug  7 14:45:18 2008
Date: Thu, 07 Aug 2008 14:45:02 -0700
From: Andy Bierman <[email-masked]>
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] XML element order
Sender: [email-masked]

> Do you mean inside the protocol or inside the data?

Inside the data, a leaf-list is sensitive to order.
There is of course the CLR about encoding list keys first,
as well.  (My agent has to generate an error even if
it does not care if the key leaf is first?)
Obviously ordered-by user lists and leaf-lists
are sensitive to element order as well.

I already have code to make the agent as robust
and bullet-proof as possible.  It seems dumb to
add code to make the agent as picky as possible.
This is a OPS-NM no-no.

Andy

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfostinfo/netconf

/netconf

---

From: Leif Johansson <[email-masked]>
Date: Fri, 8 Aug 2008 10:27:58 +0200

> Andy Bierman <[email-masked]> wrote:

Sorry for cross-posting this but this is probably critically important
for netmod wg too...

> Do you mean inside the protocol or inside the data?

I think this question may be related to the question I asked at the 
mic in Dublin about the uniqueness of representation of a yang 
model in xml form. A necessary (but probably not sufficient) 
requirement that since yang lists are order-preserving the 
corresponging xml representation needs to be order-preserving
too.

It is absolutely critical for yang that there is a *unique* mapping 
between yang and xml since yang uses xpath.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Fri, 8 Aug 2008 10:27:58 +0200

Cheers Leif

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 08 Aug 2008 10:07:13 +0200

> which violates the Postel Principle.
AFAIK the Postel principle states that you should be strict in what you send. So at least for 
sending the draft should still mandate the order. It is up to the receiving side to accept a 
free order even if it is, strictly speaking, non-compliant. On the other hand the receiver 
might also reject it.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 08 Aug 2008 10:07:13 +0200

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 08 Aug 2008 09:17:00 -0700

> between yang and xml since yang uses xpath.

I am talking about XML elements within NETCONF PDUs on the wire.
There are a few corner-cases in the YANG mapping
(leaf-list, ordered-by user, keys) in which relative order
among a sibling node set is significant.

I don't see what XPath has to do with it.
As long as the agent maintains the same conceptual
XML instance document for a database, XPath will
always work the same on that agent.  XPath in NETCONF
only applies to this database, not the PDUs.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 08 Aug 2008 09:17:00 -0700

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 08 Aug 2008 14:23:27 -0400

>between yang and xml since yang uses xpath.

XML encoding should be predictable and consistent, but need for
"uniqueness" implies a level of exactness that XML is meant to be
the solution for.  If you define two leafs in a container, your
program (and certainly any XPath expressions you write) should not
can which order those elements arrive in, _unless_ that order carries
some semantic information.

    rpc ping {
        input {
            leaf size { ... }
            leaf count { ... }
            leaf wait { ... }
        }
    }

There is no semantic difference between:

   <rpc>
      <ping>
          <size>1024</size>
          <count>10</count>
          <wait>5</wait>
      </ping>
   </rpc>

and:

   <rpc>
      <ping>
          <count>10</count>
          <size>1024</size>
          <wait>5</wait>
      </ping>
   </rpc>

or:

   <rpc><ping><count>10</count><size>1024</size><wait>5</wait>
   </ping></rpc>

Order and whitespace differences only matter when they matter,
and shouldn't become CLRs any other time.  The XPath expression
"ping/count" finds the count no matter the order.  Assuming that
"ping/*[position() = 1]" is the count will give you fragile code.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Fri, 08 Aug 2008 14:23:27 -0400

rpc ping {
        input {
            leaf size { ... }
            leaf count { ... }
            leaf wait { ... }
        }
    }

   <rpc>
      <ping>
          <size>1024</size>
          <count>10</count>
          <wait>5</wait>
      </ping>
   </rpc>

and:

   <rpc>
      <ping>
          <count>10</count>
          <size>1024</size>
          <wait>5</wait>
      </ping>
   </rpc>

or:

Thanks,
 Phil