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

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 22 Mar 2005 12:05:05 -0800

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

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 Randy Presuhn
Sent: Tuesday, March 22, 2005 1:36 PM
To: [email-masked]
Subject: Re: Proposed Resolution to PROT I-D Issues List

Hi -

> From: "McDonald, Ira" <[email-masked]>
> To: "'Joel M. Halpern'" <[email-masked]>; "'Wes Hardaker'"
<[email-masked]>; <[email-masked]>
> Cc: "'Andy Bierman'" <[email-masked]>; <[email-masked]>
> 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 [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: "Randy Presuhn" <[email-masked]>
Date: Tue, 22 Mar 2005 12:59:13 -0800

Hi -

> To: "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, March 22, 2005 12:05 PM
?

> IESG policy, because nothing but plaintext can be normative).

I base my claim on the statement "We therefore expect that people
will continue using English to describe protocols, with formal
languages as a supporting mechanism" from
http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt

> proper RFC style address which body parts and appendices are

Even within a normative section, there may be material which is obviously
non-normative.  Phrases like "for example" are frequently a clue.
The normal MIB boilerplate contains non-normative material: "For
a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410]."  Helpful background material is a Good Thing,
even though it may be non-normative.

...

When such cases arise, the document should go back to the WG.
However, to make up an example, if the English says "it MAY
contain an optional element Z", but the XSD says Z is mandatory,
then I think the burden of proof is clearly on those who would claim
that the XSD is not in error.  I trust humans to spot errors in human-
readable text more than I trust them to spot semantic errors in
formal notations.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Mar 2005 16:48:17 -0800

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

>- Ira
Andy

---

From: "Steven Berl \(sberl\)" <[email-masked]>
Date: Tue, 22 Mar 2005 17:40:56 -0800

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.

-steve 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Tuesday, March 22, 2005 4:48 PM
> To: McDonald, Ira
> Cc: 'Randy Presuhn'; [email-masked]
> 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
> 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
> >>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 
> [email-masked] with the 
> >word 'unsubscribe' in a single line as the message text body.
> >to unsubscribe send a message to 
> [email-masked] with the 
> >word 'unsubscribe' in a single line as the message text body.
> to unsubscribe send a message to [email-masked] 
> with the word 'unsubscribe' in a single line as the message text body.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Mar 2005 19:17:41 -0800

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

Andy

>>[mailto:[email-masked]]On
>>    
>>
>>>Behalf Of Randy Presuhn

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 22 Mar 2005 20:12:58 -0800

>>>>> On Tue, 22 Mar 2005 12:59:13 -0800, "Randy Presuhn" <[email-masked]> said:

Randy> When such cases arise, the document should go back to the WG.
Randy> However, to make up an example, if the English says "it MAY
Randy> contain an optional element Z", but the XSD says Z is
Randy> mandatory, then I think the burden of proof is clearly on those
Randy> who would claim that the XSD is not in error.  I trust humans
Randy> to spot errors in human- readable text more than I trust them
Randy> to spot semantic errors in formal notations.

It's actually the reverse that caused me to post the original
message.  I've seen stupid programmers do validation against an XSD
and assume that because the results came back positive that they don't
have to do error checking.  That got me to thinking that I doubt you
want to readers to assume that the XSD included with the RFC is
perfectly sufficient for validation and is 100% error free.  It's when
the RFC text says MUST but the XSD says MAY that worries me because
programmers will assume the XSD is sufficient and then they fail to
check in code against the NULL for that tag because they assumed the
XSD would have caught the error and then BOOM.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 22 Mar 2005 23:26:28 -0500

If XSDs are anything like MIB modules, the XSD will probably be
distributed without the accompanying text.
Sigh.

David Harrington
[email-masked]

> [mailto:[email-masked]] On Behalf Of Wes Hardaker
> Sent: Tuesday, March 22, 2005 11:13 PM
> To: Randy Presuhn
> Cc: [email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 22 Mar 2005 22:29:22 -0800

Andy> Echoing one last word on XSD vs. plaintext -- if the XSD doesn't
Andy> match the text then we fix whichever one is broken.

Nice in theory, but not nice in the IETF.

1) the IETF standards track provides strict controls on updating documents.

2) updates never happen quickly.  The editor queue alone would be too
   long to change something.

One solution would be to host the XSD elsewhere and reference it, but
that's likely not acceptable from a standards process either.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Mar 2005 07:14:36 -0800

>that's likely not acceptable from a standards process either.

Solution?  What problem are we trying to solve here?
Have you found a problem with the XSD and text in disagreement?
If so, post it to the list. 

This whole thread feels like an SNMP CLR discussion.
You want to protect stupid programmers from themselves.
If developers ignore arbitrary portions of the specification
then their code probably won't work.

Andy

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 23 Mar 2005 11:03:31 -0500

Hi,

Since this group works on consensus, let me speak up and say I'm tired
of this discussion and would like to move on. I suspect that is the
consensus of the WG.

I favor following the IETF standards track process: 

When the WG consensus is that the specification is sufficiently clear
that people can implement the specs, then we should ask it to be
published as a Proposed Standard. If the people in this thread find
**specific** text or XSD or a combination of the two that they believe
are ambiguous, please point out the relevant faulty clause and propose
an alternative. The WG can decide whether to accept the proposed
revision or not, and we can move on. 

If we miss ambiguities in the spec after publishing as a PS, we should
fix the specs until we are satisfied we have resolved the ambiguities,
and then should recycle the specs at Proposed. Does this take time?
You betcha! That's why the IETF is respected as a standards body; they
don't just rush things out the door, they take the time to test it for
certain characteristics between stages in the process.

If you think the process is too slow, then I suggest spending FAR less
time in meta-discussions like this one, and focus on getting the specs
right in the first place. This WG is not chartered to redesign the
IETF process, or to impose new requirements on the existing IETF
process. If you don't like the IETF standards track process, then I
suggest you a) try to get the process changed by participating in the
newtrk WG (rather than raising the issues in this WG), or b) develop
your standards in other standards development organizations that are
more to your liking. 

Can we move on now?

David Harrington
[email-masked]

> Sent: Wednesday, March 23, 2005 1:29 AM
> To: Andy Bierman
> Cc: [email-masked]; 'McDonald, Ira'; 'Randy Presuhn'; 
> [email-masked]

---

From: "Steven Berl \(sberl\)" <[email-masked]>
Date: Wed, 23 Mar 2005 08:24:13 -0800

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.

-steve

> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Tuesday, March 22, 2005 7:18 PM
> To: [email-masked]
> Cc: 'McDonald, Ira'; 'Randy Presuhn'; [email-masked]
> >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 ;-)
> 
> I think it would help if the XSD was annotated to indicate 
> which elements/values are associated with which capabilities.
> 
> >-steve
> >  
> >
> Andy
> 
> >  
> >
> objections or

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Mar 2005 09:43:10 -0800

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

Andy

>>>>>Joel says the IESG doesn't bother much about labelling 
>>>>>          
>>>>>
>>parts of RFCs 
>>    
>>
>>>>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 
>>    
>>
>>>>>>Joel, Randy, Wes, et al - could you please explain to 
>>>>>>            
>>>>>>
>>this list how 
>>    
>>

---

From: "Steven Berl \(sberl\)" <[email-masked]>
Date: Wed, 23 Mar 2005 10:18:40 -0800

> Sent: Wednesday, March 23, 2005 9:43 AM
> To: [email-masked]
> Cc: [email-masked]
> >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:
> >
> >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.

I think you misunderstood what I was proposing. I am not suggesting to
remove the errors from NETCONF. I am just suggesting that we not be too
specific about which subset of those errors are allowed to be returned in
this particular error situation (XML not valid with respect to the schema). 

The reason I want to leave this clause out is that the list I sent in the
original proposed replacement text 1) doesn't cover all cases where the XML
is not valid, and 2) the granularity of how specific the error which can be
reported will depend on the details of the implementations XML parser.

-steve

> doesn't match 
> >>the text then we fix whichever one is broken.
> >>
> >>elements/values are associated with which capabilities.
> >>
> >>    
> >>
> >>>-steve
> >>> 
> >>>
> >>>      
> >>>
> >>Andy
> >>
> >>    
> >>
> >>> 
> >>>
> >>>      
> >>>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Mar 2005 10:41:29 -0800

>reported will depend on the details of the implementations XML parser.
Okay.  I thought you wanted to remove the error list appendix.
I'm not clear about the exact text you want to replace.

As per my previous email on multiple rpc-errors, I am not
that concerned that every agent process messages and return
errors in exactly the same manner.  I want to avoid implementation
specification in the standard.  The important thing is that it is
clear in the standard what constitutes valid and invalid messages.

Do you think we need any special error codes for namespaces?
(e.g., MISSING_NAMESPACE, UNKNOWN_NAMESPACE)

Andy

---

From: "Steven Berl \(sberl\)" <[email-masked]>
Date: Wed, 23 Mar 2005 14:22:04 -0800

> Sent: Wednesday, March 23, 2005 10:41 AM
> To: [email-masked]
> Cc: [email-masked]
> errors from 
> >specific about which subset of those errors are allowed to 
> be returned 
> >in this particular error situation (XML not valid with 
> respect to the schema).
> >
> >The reason I want to leave this clause out is that the list 
> I sent in 
> >the original proposed replacement text 1) doesn't cover all 
> cases where 
> >the XML is not valid, and 2) the granularity of how specific 
> the error 
> >which can be reported will depend on the details of the 
> implementations XML parser.
> >  
> >

Well I'm not sure exactly where it should go, but I do think we need a
statement like the above someplace. Perhaps at the beginning of appendix B?

> errors in exactly the same manner.  I want to avoid 
> implementation specification in the standard.  The important 
> thing is that it is clear in the standard what constitutes 
> valid and invalid messages.
> 

I think that these would be good errors in a multivendor environment. I can
see it being confusing when I send an edit-config to 2 different devices
from 2 different vendors, and I accidentally send XML with the Cisco
namespace to a Juniper box or visa versa. 

I think that UNKNOWN_NAMESPACE is a good one when a parse doesn't recognize
the value of the xmlns attribute and that should be added to the list. 

I'm not as sure about the MISSING_NAMESPACE error. I'm not sure what the XML
rules are, but isn't everything in the document in some namespace? I think
it would be hard to tell the difference between a missing namespace
qualifier, and an misspelled element or attribute name in a known namespace.
Someone that knows more about XML than me might be able to comment on this.

-steve