Subject: Netconf operation definitions

From: Hector Trevino <[email-masked]>
Date: Wed, 23 Mar 2005 10:40:10 -0700

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.

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

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?

-- 
Hector Trevino
Network Management Technology Group (NMTG)
Cisco Systems Inc.        Voice:  720-875-1369
Suite 400                      
9155 E. Nichols Ave     Fax:    720-875-3014
Englewood, CO             E-mail: [email-masked]
80112

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

---

From: Hector Trevino <[email-masked]>
Date: Wed, 23 Mar 2005 10:50:05 -0700

Hector Trevino wrote:

> identify areas where there may be discrepancies between the text and 
> the XSD.
>
>
> of type rpcOperationSourceType. One of the choices is "config" which 
> is config-inlineType 

Forgot to include the url element here

> 2) rpc element description. I think this was already brought up but 
> just to make sure it's captured
>
> (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?
>
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Mar 2005 10:57:11 -0800

> allow this  since a definition change can be made to enforce what the 

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>

> The XSD does not include definitions for additional attributes

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

> 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

---

From: "Steven Berl \(sberl\)" <[email-masked]>
Date: Wed, 23 Mar 2005 14:12:40 -0800

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

This one is already dealt with in email "RE: Attributes on rpcType elements"
on 3/15/05. Rob is adding xs:anyAttribute to the rpcType.

-steve

---

From: Hector Trevino <[email-masked]>
Date: Wed, 23 Mar 2005 17:04:08 -0700

Thanks Andy

Just catching up on e-mail and read Rob's response also. I'll send one 
more comment there.
Hector

Andy Bierman wrote:

>> 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
>>
> 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
>> 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)
>>
> any on-the-wire syntax (elements names).  The complexType naming 
> should be more consistent.