[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-shafer-netconf-syslog-00.txt

Phil Shafer wrote:

Andy Bierman writes:

 <rpc-reply> element in the netconf NS
   <rpc-error>*    - Zero or more <rpc-error> elements in the netconf  NS
   <data>?         - Zero or one <data> element in the netconf NS, which
                     can contain zero or more XML elements from any namespace,
                     or no namespace at all.
 </rpc-reply>


The text in netconf-prot does not constrain the top level element
of the reply, nor does it mandate that it be under a <data> element.

   The response name and response data are encoded as the contents of
   the <rpc-reply> element.  The name of the reply is an element
   directly inside the <rpc-reply> element, and any data is encoded
   inside this element.

Unfortunately, the xml schema does constain the reply to <data>.
So the question is: can we correct the schema?

<rant>
In a standard, consistency and interoperability are far more
important than saving the 13 bytes on the wire that the <data>
element represents.


<taking-the-bait>
I fail to see how the existence of the <data> element does anything
to improve consistency or interoperability.  It's just a noise word
that we'll be stuck putting in rpc replies, xpath expressions and
sax filters for the rest of our lives, unless we can fix it now.



I disagree.
It allows generic tools a consistent format to work with,
instead of a different ad-hoc format for every RPC.

If the reply does not contain 0 - N <rpc-error>,
followed by 1 optional <data>, then SW to pre-process the replies
before the application gets it is much more complicated.
It has to understand every schema instead of just the netconf
schema, just to validate the "RPC layer" portion of the reply.


Currently, we have a consistent way to say "your request
yielded no data":

  <rpc-reply>
    <data/>
  </rpc-reply>

This would be lost if the XSD were changed.


I don't want to give vendors an opportunity to ignore
the standard <rpc-error> requirements.  Allowing the
<rpc-reply> to contain 'anything' will do that.





Thanks,
 Phil


Andy


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