Re: Proposed Resolution to PROT I-D Issues List

[Andy Bierman <ietf@andybierman.com>]

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