Re: Netconf operation definitions

[Andy Bierman <ietf@andybierman.com>]

Hector Trevino wrote:

> Hi, following up on the previous discussions and the suggestion to 
> identify areas where there may be discrepancies between the text and 
> the XSD.
>
>
> 1) The current get-config definition for source says:
>
> "source:
>
>         Name of the configuration datastore being queried, such as
>         <running/>.  If this element is unspecified, the <running/>
>         configuration is used."
>
> The definition for get-config the XSD includes element source which is 
> of type rpcOperationSourceType. One of the choices is "config" which 
> is config-inlineType
>
>     <xs:complexType name="rpcOperationSourceType">
>       <xs:choice>
>         <xs:element ref="config"/>
>         <xs:element ref="config-name"/>
>         <xs:element ref="url"/>
>       </xs:choice>
>     </xs:complexType>
>
> My suggestion would be for the XSD definition to be modified to not 
> allow this  since a definition change can be made to enforce what the 
> text says.

I think the text and XSD are both wrong here, since we changed the 
<get-config>
operation to add the <filter> parameter.  It doesn't make sense for the 
source
to be inline configuration XML (choice=config).  That made sense before 
we moved
the filter specification to its own parameter. 

The 'source' parameter needs to be changed to 'target', and
the type is changed from rpcOperationSourceType to rpcOperationTargetType.

Here is the XSD from the draft to point out the difference:

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

> 2) rpc element description. I think this was already brought up but 
> just to make sure it's captured
>
> "If additional attributes are present in an <rpc> element, a NETCONF
>   peer must return them unmodified in the <rpc-reply> element."
>
> The XSD does not include definitions for additional attributes

Perhaps all other (non-standard) attributes would need to be specified
with a namespace prefix?

> Slightly out of subject but related to XSDs
>
> 3) Naming conventions
> There seems to be two different naming conventions followed in the XSD 
> (for first word first letter is lower case then use upper case for 
> first letter of sub-sequent words - rpcOperationSourceType) and also 
> dash "-" separated words (config-inlineType and get-config)
>
> For consistency purposes it may be good if one of the naming 
> conventions was followed instead of inter-mixing. The former?

I agree.  We're only talking about changing the names of some 
complexTypes, not changing
any on-the-wire syntax (elements names).  The complexType naming should 
be more consistent.
The "rpcOperationSourceType" style naming convention should be used 
throughout the XSD.
(Not very important but this is the only chance to fix it.)

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