Thanks for the comments Hector.
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.
Yep, take a look back in the archive for the subject "What happened
to the <format> parameter on <get-config>" for more discussion on this.
We need rpcOperationSourceType to remain the same since it's used
by copy-config, but we should use a different type for get-config.
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
Thanks, is fixed in -06 based on some XSD supplied by Steve Berl.
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?
This bugs me too, and in the NETCONF RNG schema (which won't
be in the draft/rfc) a common approach was used. I'll make the
naming in the XSD consistent. FWIW I believe the original
approach was to use dashes for the NETCONF names (get-config)
and the lower/upper case style for type names. Picking one
(lower/upper case sounds fine to me) makes sense.
Rob