Subject: [netmod] XML encoding order

From: David Reid <[email-masked]>
Date: Thu, 14 May 2009 10:53:01 -0400

At the San Francisco meeting, consensus was to drop the requirement that
XML elements are encoded in the same order as defined in the yang module, 
except for RCP input and output.

I have 2 questions:

Why is order important for RPC input and output, but not other nodes? This
was discussed in S.F., but I can't remember the details. I'm not suggesting
we change anything, just trying to understand.

The current draft, section 7.14.2., says the child nodes in a notification
must be encoded in the same order as they are defined. Was the intent at the
S.F. meeting to also drop the order requirement for notifications? I don't 
think notifications were specifically discussed.

-David Reid

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 May 2009 17:23:28 +0200 (CEST)

Hi David,

> we change anything, just trying to understand.

The reason is that for some RPCs the order of input parameters may
affect how much buffering a NETCONF server must do.  The typical
example, which has been discussed on the NETCONF ML in the past, is
copy-config with inline data.  It takes two parameters, target and
source.  Suppose source was encoded first:

  <copy-config>
    <source>
      <config>
         <!-- very big config goes here -->
      </config>
    </source>
    <target>
       <running/>
    </target>
  </copy-config>

A server would in this case be required to buffer the enitre config.

However, if target is encoded before source, then servers may take
advantage of this fact and optimize the processing of the inline
config depending on target.

> think notifications were specifically discussed.

Andy suggested a nice and simple solution to the ordering problem - we
say that order matters on the "operations" layer, but not on the
"application" layer.

Hmm... I think you are right, according to the latest version of the
NETCONF layers diagram
(http://tools.ietf.org/html/draft-bierman-netmod-yang-usage-00) the
order should not matter in notifications.  Andy?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 May 2009 08:43:17 -0700

> order should not matter in notifications.  Andy?

I was just typing a response to the first part of the question,
and then I saw your post and stopped.  (I wonder if all the
RPC operation parameters in 4741 are ordered to minimize
buffering requirements? edit-config is the important one.
I will put a note in the guidelines draft about designing
for minimal buffering.)

Notification content order should not matter to the agent or manager,
but it seems like a good idea to follow schema order in the reply.
It might help visual inspection for 'diff' or other simple applications.
(I.e., SHOULD, not MUST)

Agent output is usually streamed and does not require any buffering.

> /martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 May 2009 21:02:12 +0200 (CEST)

Hi,

> It might help visual inspection for 'diff' or other simple applications.

So, I will remove this text from 7.14.3:

   The notifications's child nodes are encoded as subelements to the
   notification node's XML element, in the same order as they are
   defined within the notification statement.

/martin