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

Re: Proposed Resolution to PROT I-D Issues List

McDonald, Ira wrote:

Hi,

Agreed - XSD is not informal like pseudo-code (which is an eye of the beholder term).

XSD is a formal language, just like the ASN.1 we all darn well depend on in MIBs (which ASN.1 _does_ override any error in descriptive text in the MIB body or preface - an ASN.1 type
definition is a hard mathematical fact).

Conformance to an XSD is not sufficient to prove that a message
is valid (in most cases) or that it is not malicious. But non-conformance to a well-written XSD should always be treated as a mandatory failure in a protocol.


The difference here is the use of capabilities, not ASN.1 vs. XSD. I don't mind if the NETCONF XSD is normative, as long as it's understood
that XSD is not expressive enough to fully describe the precise set of XML
instance documents that a NETCONF agent will accept, and the text is assumed
to be the authoritative definition if there are conflicts discovered in the future.

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 Hector Trevino
Sent: Friday, March 18, 2005 3:41 PM
To: Andy Bierman
Cc: sberl@cisco.com; 'Wes Hardaker'; 'Andy Bierman';
netconf@ops.ietf.org
Subject: Re: Proposed Resolution to PROT I-D Issues List




in-line
Hector

Andy Bierman wrote:



Steven Berl (sberl) wrote:



<snip>





----------------------

New text for the beginning of appendix B:

The following XML schema is for informational purposes. It has reviewed but there is no guarantee that the schema exactly matches the definitions defined in the protocol description above.
Implementations MUST NOT assume that an incoming message is free from malicious intent because it has been successfully verified against this schema.


I think we should make the text normative and the XSD as correct as possible,
but not intended to override the text. The exact standard netconf XSD that
an agent should accept is different depending on the exact set of capability
values supported by that agent for a particular session.

The XSD represents a superset of all base + standard capability variants.
I think this is good enough.


Why couldn't the operation defintions in the XSDs be normative as well? Seems this is a way to help with interoperability.
I agree that "The XSD represents a superset of all base + standard capability variants" and it is an implementation decision as to what capabilities are supported/implemented but the definitions themselves should be normative. I guess I don't understand the objection to making the schemas normative.




Andy





Are you saying that we have a formal language description of the syntax of
the protocol messages, but that is there just for information? The real
definition of the syntax is in the narrative text? It seems to me that this
is kind of backwards. Is this the way that MIBs work? Is the ASN.1 there
just for information and the real description of the MIB is in the text? The
normative reference for message syntax should be the schema, and the text
should be there to describe the schema, and to explain things that are not
expressed in the schema such as the sequence of messages, or additional
constrains.

-steve

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