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

RE: Proposed Resolution to PROT I-D Issues List



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.

-steve

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