Subject: RE: Proposed Resolution to PROT I-D Issues List

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 18 Mar 2005 13:52:44 -0800

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: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Hector Trevino
Sent: Friday, March 18, 2005 3:41 PM
To: Andy Bierman
Cc: [email-masked]; 'Wes Hardaker'; 'Andy Bierman';
[email-masked]
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 [email-masked] 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 [email-masked] 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: [email-masked]
80112

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Mar 2005 09:39:30 -0800

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

Andy

---

From: Hector Trevino <[email-masked]>
Date: Mon, 21 Mar 2005 10:55:59 -0700

Hi, thanks for the response.
in-line
Hector

>definition is a hard mathematical fact).
right & that's what I would've thought the messages defined in netconf 
should be as well.

>is valid (in most cases) or that it is not malicious.  
>
 I agree that with he current definitions this is the case but seems to 
me they could be tighten up so that they enforce validity of the message 
(syntactically).
Or is there something else I'm missing here?

>But 
Agree

---

From: Hector Trevino <[email-masked]>
Date: Mon, 21 Mar 2005 10:59:38 -0700

Hi, in-line
Hector

Andy Bierman wrote:

> 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
>> 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
> to be the authoritative definition if there are conflicts discovered 
> in the future. 

If I compare the netconf capabilities to the old CMIS functional 
units... they are the same type of approach. That is, some 
implementation either support or not the functionality above an beyond 
the required base set. Determination of whether or not & which ones of 
these bonus capabilities/functions are supported is negotiated/learned 
at session establishment and it is not tied to the syntactical defintion 
of the messages.

>>> but not intended to override the text.  The exact standard netconf 
>>> XSD that
>> Why couldn't the operation defintions in the XSDs be normative as 
>> well? Seems this is a way to help with interoperability.
>> should be normative. I guess I don't understand the objection to 
>> making the schemas normative.
>>
>>  
>>
>>>
>>> Andy
>>>
>>>   
>>>
>>>>>  
>>>>>       
>>>>
>>>> normative reference for message syntax should be the schema, and 
>>>> the text

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 21 Mar 2005 12:15:15 -0800

Hi -

> From: "Hector Trevino" <[email-masked]>
> To: "McDonald, Ira" <[email-masked]>
> Cc: "Andy Bierman" <[email-masked]>; <[email-masked]>; "'Wes Hardaker'" <[email-masked]>; "'Andy Bierman'"
<[email-masked]>; <[email-masked]>
> Sent: Monday, March 21, 2005 9:55 AM
...
> Or is there something else I'm missing here?
...

The point is that there is more to a protocol than syntax.
There are constraints on the validity of a message that
cannot be enforced by syntactic means alone.

Randy

---

From: Hector Trevino <[email-masked]>
Date: Mon, 21 Mar 2005 13:31:17 -0700

>cannot be enforced by syntactic means alone.
Right. All I was asking for is to tighthen up the definitions to enforce 
syntax - at least that's what I tried to say -.