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

RE: Proposed Resolution to PROT I-D Issues List



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.

Cheers,
- Ira

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

-- 
Hector Trevino
Network Management Technology Group (NMTG)
Cisco Systems Inc.        Voice:  720-875-1369
Suite 400                      
9155 E. Nichols Ave     Fax:    720-875-3014
Englewood, CO             E-mail: htrevino@cisco.com
80112



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