Re: XML namespace advice

[Andy Bierman <[e-mail]>]

Hare, Michael wrote:
> If it doesn't have the NETCONF NS, then how do you know you are parsing a true NETCONF message and not some other <rpc> construct?
> It seems to me NS should be mandatory, if even defaulted they still exist in the internal DOM.
> 
> The contents of a <config> or <filter> should also be proprietary NS'd by the vendor associated with the payload.
> 
> I raised this a few weeks ago, the NETCONF base schema needs to allow <any> content inside a <config> or <filter> node, with the added attribute: namespace="##other" to force the payload to be of a different NS than NETCONF.
> 

If it is another RPC mechanism that exactly matches
and namespaces are not used at all, then the agent will be fooled into
thinking it was a NETCONF RPC.  Why is this other RPC
mechanism using the NETCONF well-known assigned port numbers
in the first place?  That's the broken, non-conformant part.

If the orther RPC does not match then the agent will respond with <rpc-errors>
for the parts it did not understand.

I want operators to be able to type a <get-config> PDU by hand
if required.  Currently, the namespace URI is the only
CLR junk in the PDU.  Nobody remembers what the value
is by memory (just as bad as OIDs!).  I'm not going to force
operators to remember NETCONF nonsense by heart so they
can get the picky agent to accept a PDU.  But you don't have
to assume the netconf namespace.  Your agent can reject
a PDU without the netconf namespace if you think that helps.
(This hack only works for simple PDUs without <config> content,
but that's all it's intended to do.)

We did not put namespace="##other" in the schema
because it may not always be true that the netconf
namespace does not contain any data objects.



Andy


> as in:
> 	<xs:complexType name="configInlineType">
> 		<xs:sequence>
> 			<xs:any namespace="##other"/>
> 		</xs:sequence>
> 	</xs:complexType>
> 
> My payloads look something like:
> 		<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
> 			<Top xmlns="urn:nmie:fnc:fujitsu:com">
> 				<Equipments>
> 					<Equipment>
> 						<Name>Ethernet0</Name>
> 						<AdminState  xc:operation="replace">DOWN</AdminState>
> 					</Equipment>
> 				</Equipments>
> 			</Top>
> 		</config>
> 
> I validate against my propietary schema, which in turn imports the NETCONF schema. My entire <rpc> passes schema validation.
> 
> ---------------------------------
> Michael Hare
> NMI Engineering
> 
> GnuPG Key fingerprint = 1AD4 726D E359 A31D 05BF  ACE5 CA93 7AD5 D8E3 A876
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Andy Bierman
> Sent: Saturday, June 10, 2006 2:38 PM
> To: Martin Bjorklund
> Cc: [e-mail]
> Subject: Re: XML namespace advice
> 
> 
> Martin Bjorklund wrote:
>> Andy Bierman <[e-mail]> wrote:
>>> Hi,
>>>
>>> 3 XML questions:
>>>
>>> Section 3.1 of prot-12 clearly states that the NETCONF elements
>>> reside in a specific namespace.
>>>
>>>    Q1: Is it an error if a PDU (e.g., <hello> or <rpc>) is received by
>>>        the peer, which does not use namespaces?  Or is it okay to set
>>>        the default namespace to the NETCONF NS in this case?
>> Isn't the namespace in the <hello> message supposed to indicate which
>> version of the NETCONF protocol the peer supports?  If there is no
>> namespace, which version should we guess the other side is using?
>> (Ok, the answer is pretty obvious right now :)
> 
> 
> Since it is implementation-dependent which namespace
> the peer picks as a default, the answer isn't obvious.
> I would pick the most current version the agent supports
> as the default (usual choice).
> 
> 
>> Also, if you take the schema from the draft, and an instance document
>> which is a valid <hello> message but w/o the namespace, xmllint failes
>> to validate.
>>
>> Although it's easy enough to implement both these cases, I think it's
>> better if the namespace declaration is required.
> 
> 
> Not so fast!
> I don't want to force an agent to reject an otherwise valid
> RPC request because the netconf namespace is missing.
> 
> And, as 8.1 clearly indicates, the <hello> PDU
> does not rely on the xmlns decl anywhere in the PDU
> to identify the version.  In the example, the first
> capability for the protocol itself seems redundant,
> but this mechanism works even if the namespace decl is missing.
> 
> 
>> A follow-up question is if a peer is non-compliant if it requires a
>> correct xmlns attribute on the <hello> and <rpc> messages?
>>
> 
> I knew you would ask that!
> I read through the draft.
> I can't find any text that says that PDUs must use namespaces.
> It's just shown that way in all the examples.
> 
> This requires more thought, before we start creating any CLRs.
> 
> 
>>> My understanding of sec. 4.1 is that all of the attributes,
>>> including the xmlns declarations, in the <rpc>, need to be
>>> replicated exactly in the <rpc-reply> element. 
>>> However, an agent may add attributes to the end of the list.
>>>
>>>    Q2: Are xmlns declarations special, and not supposed to be
>>>        included in the list of replicated attributes?  All the
>>>        document examples show them replicated in the <rpc-reply>.
>> We replicate the xmlns attributes, but I honestly can't see why this
>> is important or even useful.
> 
> 
> It's a lot of work for not much value.
> If anything, it might help the operator more easily
> analyze the reply by sight, instead of with tools.
> That's why I bother doing it.  But just for <rpc-reply>,
> no other nested elements.
> 
> 
>>>    Q3: Are there more xmlns processing and generation rules and/or
>>>        guidelines to follow here? 
>> If you accept a rpc w/o namespaces, you have to decide what to do with
>> e.g. an edit-config w/o namespaces.  But I think you mentioned that
>> you allow that.
>>
>> However, if you get a <rpc> *with* a correct xmlns, and an edit-config
>> *without* a xmlns, I think you should generate an error, since it's
>> invalid per the XML Namespace Recommendation.
> 
> 
> Yes -- I do.  But not for the rpc method, unless it is in
> a different namespace than NETCONF.
> 
> I think you mean the namespace of the edit-config data:
> 
>    <rpc message-id="101" xmlns="netconf-blah">
>      <edit-config>
>        ...
>        <config>
>          <x:top xmlns:x="example.com-blah">
>             <x:foo/>
>          </x:top>
>        </config>
>      </edit-config>
>    </rpc>
> 
> (Note the prefix 'x' is not required; the xmlns decl in the 'top'
> element could have overridden the default namespace instead.)
> 
> Actually, if namespaces are not used at all, there is a
> default 'owner' which happens to own the netconf RPCs
> and the core data models.
> 
> However, an error will be generated if the "netconf-blah"
> namespace decl is present but the "example.com" decl is
> missing.  The parser knows if namespaces are being used or not
> in the PDU.
> 
> Even if namespaces are used, attributes without namespace prefixes
> will be classified by the libxml2 parser as "not in any namespace".
> I'm not picky wrt/ stuff like:
> 
>    operation="create"
>    ns:operation="create"
> 
> You have to check for both cases. (Love XML! ;-)
> 
> 
> 
> 
>>
>> /martin
>>
> 
> Andy
> 
> 
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 


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