[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,

My apologies to Joel for misrepresenting our offline
discussion and his point of view.  I meant only to
summarize what Joel was trying to explain to me about
IESG policy.

[Juergen - I made that MIB ASN.1 argument offline
to Joel - and was told that the ASN.1 loses and
the plaintext wins - which I utterly disbelieve.
No MIB implementor ever ignored a SYNTAX or
MAX-ACCESS clause in favor of some plaintext.
And certainly no MIB compiler ever did this.]


MIB developers routinely interpret plaintext and SYNTAX together
in order to correctly implement a specification.   For example,
the MAX-ACCESS clause is not expressive enough to specify the
allowable write operation set for MIB tables which lock columns
if the row is active.  The sentence "This object may not be modified
if the associated fooRowStatus object is equal to 'active'" appears
in many DESCRIPTION clauses to get around this problem.

In the case of the NETCONF XSD, an implementor better understand how
capabilities affect the operation set that an agent accepts, the
transaction model it uses, etc., in order to do anything useful.

But this list is still not addressing Hector's real
question, to whit:

Will the IESG allow the NetConf XSD to be used in
the protocol as a Normative _part_ of the incoming message validation logic?

Joel, Randy, Wes, et al - could you please explain
to this list how XSD is useful in NetConf if it's
not Normative?


I don't think there is WG consensus to add the "informative only" text that
Wes proposed. I think the "continuing WG consensus" is that we need an XSD
and namespace definition for the NETCONF protocol. I don't know why we
need to add text to declare the XSD as normative or informative anyway.
This issue was already declared closed with "no changes required", and I don't
see any reason to change that now.

The XSD is a superset of all syntax allowed for the base plus standard capabilities. A real agent is not likely to support all the standard capabilities (e.g., agent will allow
writes to the <candidate> or to <running>, but not both). So it's true that "if it's not
in the XSD, it's not in NETCONF", however no real agent will ever support the full XSD.

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: Joel M. Halpern [mailto:joel@stevecrocker.com]
Sent: Monday, March 21, 2005 6:16 PM
To: McDonald, Ira; 'Wes Hardaker'; sberl@cisco.com
Cc: 'Andy Bierman'; netconf@ops.ietf.org
Subject: RE: Proposed Resolution to PROT I-D Issues List


Just to be clear, I certainly never claimed to speak for the IESG. I did describe IETF and IESG practice.

And I certainly never suggested that removing the XSD would in any way help the situation.

I objected privately to Ira's claim that making the English normative and the XSD informative was indefensible. He seems to be taking objection to my attempting to illustrate other points of view which have a lot of history and are well tested in our community.

Yours,
Joel M. Halpern

At 06:06 PM 3/21/2005, McDonald, Ira wrote:


Hi,

I've been having a long, fruitless offline discussion with Joel
Halpern about this.  The results may be summarized as follows:

(1) The IESG policy is that the plaintext English is always
   normative.

(2) The IESG policy does NOT allow an appendix of XSD (or any
   other relatively formal language) to override the plaintext
   English, because then _parts_ of plaintext English sentences
   or paragraphs might become invalid.

I'm strongly opposed to this logic, because it implies that an RFC
should not include any formal language appendices, since they're
to be ignored anyway.

Analogy - In English and US contract law, if an illegal or invalid
statement is later found, then the clause or the subclause is
invalid, but the rest of the contract remains legally valid.

I suggest deleting all XSD from Appendices and references.  It
won't do you any good anyway.  And changing the IESG policy
is just hopeless.

Discouraged,
- 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 Wes Hardaker
Sent: Monday, March 21, 2005 5:00 PM
To: sberl@cisco.com
Cc: 'Wes Hardaker'; 'Andy Bierman'; netconf@ops.ietf.org
Subject: Re: Proposed Resolution to PROT I-D Issues List




On Fri, 18 Mar 2005 09:03:01 -0800, "Steven Berl (sberl)"


<sberl@cisco.com> said:

Steven> Are you saying that we have a formal language description of
Steven> the syntax of the protocol messages, but that is there just
Steven> for information?

My only intent was to state that it hasn't been proven to be perfect,
and thus implementers should not rely on it as a check that an
incoming packet is indeed perfect.

The problem I've seen with XML applications is that many of them pass
an incoming packet to a validator (which is merely validating the XML,
not the data within) and then doesn't implement its own sanity error
checking afterward.  Thus, I've actually seen many security problems
in XML applications because they assume that the packet contains
everything it needs in the exact form it needs when in fact it may
not.

Andy is right, however, that an XSD probably couldn't be written which
meet every implementations requirements.

If you're going to make it normative, I don't think it should go into
the appendix as it is currently.  (If memory serves, appendices in
RFCs are supposed to be normative).

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

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