Impact of XSD design on NETCONF operations

[Andy Bierman <ietf@andybierman.com>]

Hi,

Without trying to start an actual data modeling discussion,
I want to point out some data model examples in the NETCONF
protocol itself that impact implementations.

1) Use of choice vs. complexType(choice)

Here is the rpcOperationTargetType and <edit-config> parameter set from RFC 4741:

    <xs:complexType name="rpcOperationTargetType">
       <xs:choice>
         <xs:element ref="config-name"/>
         <xs:element name="url" type="configURIType"/>
       </xs:choice>
    </xs:complexType>

    <xs:complexType name="editConfigType">
       <xs:complexContent>
         <xs:extension base="rpcOperationType">
           <xs:sequence>
             <xs:annotation>
               <xs:documentation>
                 Use of the test-option element requires the
                 :validate capability.  Use of the url element
                 requires the :url capability.
               </xs:documentation>
             </xs:annotation>
             <xs:element name="target"
                         type="rpcOperationTargetType"/>
             <xs:element name="default-operation"
                         type="defaultOperationType"
                         minOccurs="0"/>
             <xs:element name="test-option"
                         type="testOptionType"
                         minOccurs="0"/>
             <xs:element name="error-option"
                         type="errorOptionType"
                         minOccurs="0"/>
             <xs:choice>
               <xs:element name="config"
                           type="configInlineType"/>
               <xs:element name="url"
                           type="configURIType"/>
             </xs:choice>
           </xs:sequence>
         </xs:extension>
       </xs:complexContent>
     </xs:complexType>


Note that there is one more layer in the path name to get to the choice
in the 'target' parameter, as opposed to the 'config or url' choice
directly in the editConfigType.

IMO, the first approach (complexType) is better than the 'inline choice' approach
for NETCONF.  Since 'target' is a stable element in a fixed position
in the tree, it is simpler to generate <rpc-error> elements (e.g.,
missing-element error -- is it for 'config' or 'url'? Pick one at random?
Always pick the first one?)

Also, access control configuration is safer if the extra (top) layer is
there, in the event new choices are added to a data model in the future.
With the first approach, a rule for /rpc/edit-config/target will cover
any variant of that parameter.   Twice as many ACL entries (/rpc/edit-config/config
and /rpc/edit-config/url) would be needed with the other approach.

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/>