[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Proposed Resolution to PROT I-D Issues List



 

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

-steve

> 
> >-steve
> >  
> >
> Andy
> 
> >  
> >
> >>-----Original Message-----
> >>From: Andy Bierman [mailto:ietf@andybierman.com]
> >>Sent: Tuesday, March 22, 2005 7:18 PM
> >>To: sberl@cisco.com
> >>Cc: 'McDonald, Ira'; 'Randy Presuhn'; netconf@ops.ietf.org
> >>Subject: Re: Proposed Resolution to PROT I-D Issues List
> >>
> >>Steven Berl (sberl) wrote:
> >>
> >>    
> >>
> >>>I would like to see text in the document that says something like:
> >>>
> >>>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 one of INVALID_VALUE, MISSING_ATTRIBUTE, BAD_ATTRIBUTE, 
> >>>UNKNOWN_ATTRIBUTE, MISSING_ELEMENT, BAD_ELEMENT, or 
> UNKNOWN_ELEMENT.
> >>> 
> >>>
> >>>      
> >>>
> >>This is fine with me.
> >>Echoing one last word on XSD vs. plaintext -- if the XSD 
> doesn't match 
> >>the text then we fix whichever one is broken.
> >>
> >>BTW, the draft already says the XSD is normative for syntax.  
> >>(I think I wrote this paragraph ;-)
> >>
> >> From PROT-05, sec. 7, last para:
> >>
> >>   The syntax and XML encoding of the protocol operations 
> are formally
> >>   defined in the XML schema in Appendix B.  The following sections
> >>   describe the semantics of each protocol operation.
> >>
> >>I think it would help if the XSD was annotated to indicate which 
> >>elements/values are associated with which capabilities.
> >>
> >>    
> >>
> >>>-steve
> >>> 
> >>>
> >>>      
> >>>
> >>Andy
> >>
> >>    
> >>
> >>> 
> >>>
> >>>      
> >>>
> >>>>-----Original Message-----
> >>>>From: owner-netconf@ops.ietf.org
> >>>>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> >>>>Sent: Tuesday, March 22, 2005 4:48 PM
> >>>>To: McDonald, Ira
> >>>>Cc: 'Randy Presuhn'; netconf@ops.ietf.org
> >>>>Subject: Re: Proposed Resolution to PROT I-D Issues List
> >>>>
> >>>>McDonald, Ira wrote:
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>Hi,
> >>>>>
> >>>>>It would be nice if there were some agreement in this advice.
> >>>>>
> >>>>>Randy says the XSD *is* normative, but the plaintext wins in
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>conflicts
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>(which Joel says is not true under the prevailing IESG
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>policy, because
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>nothing but plaintext can be normative).
> >>>>>
> >>>>>Joel says the IESG doesn't bother much about labelling
> >>>>>          
> >>>>>
> >>parts of RFCs
> >>    
> >>
> >>>>>normative or informative (the RFC Editor certainly doesn't
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>agree with
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>this one - a number of RFC's and I-Ds on proper RFC style
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>address which
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>body parts and appendices are or should be normative).
> >>>>>
> >>>>>I liked Steve's formulation very much, but it's broken by the 
> >>>>>"plaintext always wins" rule.  An incoming message could
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>_fail_ the XSD
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>check and still be valid under ambiguously written 
> plaintext body 
> >>>>>parts...
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>Are there specific portions of text that you are making
> >>>>        
> >>>>
> >>objections or
> >>    
> >>
> >>>>suggestions
> >>>>for changes?   We aren't going to change IESG policy on 
> >>>>        
> >>>>
> >>this mailing
> >>    
> >>
> >>>>list.  Unless
> >>>>there are specific changes to the -05 draft to discuss
> >>>>        
> >>>>
> >>here, I think
> >>    
> >>
> >>>>this topic is closed.
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>Cheers,
> >>>>>- Ira
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>Andy
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>Ira McDonald (Musician / Software Architect) Blue Roof
> >>>>>          
> >>>>>
> >>Music / High
> >>    
> >>
> >>>>>North Inc PO Box 221  Grand Marais, MI  49839
> >>>>>phone: +1-906-494-2434
> >>>>>email: imcdonald@sharplabs.com
> >>>>>
> >>>>>-----Original Message-----
> >>>>>From: owner-netconf@ops.ietf.org
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>[mailto:owner-netconf@ops.ietf.org]On
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>Behalf Of Randy Presuhn
> >>>>>Sent: Tuesday, March 22, 2005 1:36 PM
> >>>>>To: netconf@ops.ietf.org
> >>>>>Subject: Re: Proposed Resolution to PROT I-D Issues List
> >>>>>
> >>>>>
> >>>>>Hi -
> >>>>>
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>From: "McDonald, Ira" <imcdonald@sharplabs.com>
> >>>>>>To: "'Joel M. Halpern'" <joel@stevecrocker.com>; "'Wes 
> Hardaker'"
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>><wjhns1@hardakers.net>; <sberl@cisco.com>
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>Cc: "'Andy Bierman'" <abierman@cisco.com>; 
> <netconf@ops.ietf.org>
> >>>>>>Sent: Tuesday, March 22, 2005 5:27 AM
> >>>>>>Subject: RE: Proposed Resolution to PROT I-D Issues List
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>...
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>Joel, Randy, Wes, et al - could you please explain to
> >>>>>>            
> >>>>>>
> >>this list how
> >>    
> >>
> >>>>>>XSD is useful in NetConf if it's not Normative?
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>...
> >>>>>
> >>>>>It *is* normative.  It's just that in the case of conflict or 
> >>>>>ambiguity, the English takes precedence.  This is as it
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>should be.  I
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>recall fixing errors in ASN.1 and MIB modules, where the fix was 
> >>>>>justified by the fact that the English text captured the WG
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>intent and
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>the formal notation said something else.  This routinely
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>happens during
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>MIB review cycles.
> >>>>>
> >>>>>Randy
> >>>>>
> >>>>>
> >>>>>
> >>>>>--
> >>>>>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/>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>--
> >>>>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/>
> >>>
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >
> >--
> >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/>