RE: Proposed Resolution to PROT I-D Issues List

["Steven Berl \(sberl\)" <sberl@cisco.com>]

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Wednesday, March 23, 2005 10:41 AM
> To: sberl@cisco.com
> Cc: netconf@ops.ietf.org
> Subject: Re: Proposed Resolution to PROT I-D Issues List
> 
> Steven Berl (sberl) wrote:
> 
> > 
> >
> >  
> >
> >>-----Original Message-----
> >>From: Andy Bierman [mailto:ietf@andybierman.com]
> >>Sent: Wednesday, March 23, 2005 9:43 AM
> >>To: sberl@cisco.com
> >>Cc: netconf@ops.ietf.org
> >>Subject: Re: Proposed Resolution to PROT I-D Issues List
> >>
> >>Steven Berl (sberl) wrote:
> >>
> >>    
> >>
> >>>After a little more thought, the list of <error-tag> values
> >>>      
> >>>
> >>needs to be
> >>    
> >>
> >>>more open ended. Can we just leave out that list. Here's some new 
> >>>replacement
> >>>text:
> >>>
> >>>Any message that is not valid with respect to the XML schema in 
> >>>appendix B, is not a valid netconf message and MUST be
> >>>      
> >>>
> >>rejected by the
> >>    
> >>
> >>>netconf server that receives it. In the <rpc-reply> the 
> >>><error-severity> MUST be set to "error" and the <error-tag> MUST 
> >>>contain an error code indicating the reason for rejecting
> >>>      
> >>>
> >>the message.
> >>    
> >>
> >>> 
> >>>
> >>>      
> >>>
> >>I strongly object to this proposal to remove the standard 
> errors from 
> >>NETCONF.
> >>There are plenty of ways for vendors to add their own error 
> >>information if they want.
> >>    
> >>
> >
> >I think you misunderstood what I was proposing. I am not 
> suggesting to 
> >remove the errors from NETCONF. I am just suggesting that we 
> not be too 
> >specific about which subset of those errors are allowed to 
> be returned 
> >in this particular error situation (XML not valid with 
> respect to the schema).
> >
> >The reason I want to leave this clause out is that the list 
> I sent in 
> >the original proposed replacement text 1) doesn't cover all 
> cases where 
> >the XML is not valid, and 2) the granularity of how specific 
> the error 
> >which can be reported will depend on the details of the 
> implementations XML parser.
> >  
> >
> Okay.  I thought you wanted to remove the error list appendix.
> I'm not clear about the exact text you want to replace.

Well I'm not sure exactly where it should go, but I do think we need a
statement like the above someplace. Perhaps at the beginning of appendix B?

> 
> As per my previous email on multiple rpc-errors, I am not 
> that concerned that every agent process messages and return 
> errors in exactly the same manner.  I want to avoid 
> implementation specification in the standard.  The important 
> thing is that it is clear in the standard what constitutes 
> valid and invalid messages.
> 
> Do you think we need any special error codes for namespaces?
> (e.g., MISSING_NAMESPACE, UNKNOWN_NAMESPACE)

I think that these would be good errors in a multivendor environment. I can
see it being confusing when I send an edit-config to 2 different devices
from 2 different vendors, and I accidentally send XML with the Cisco
namespace to a Juniper box or visa versa. 

I think that UNKNOWN_NAMESPACE is a good one when a parse doesn't recognize
the value of the xmlns attribute and that should be added to the list. 

I'm not as sure about the MISSING_NAMESPACE error. I'm not sure what the XML
rules are, but isn't everything in the document in some namespace? I think
it would be hard to tell the difference between a missing namespace
qualifier, and an misspelled element or attribute name in a known namespace.
Someone that knows more about XML than me might be able to comment on this.

-steve 

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

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