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

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.

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