Subject: <validate> operation somewhat broken

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Oct 2006 12:40:02 -0700

Hi,

IMO, the <validate> command is not actually useful for 'inline'
configuration validation.

The reason the edit-config operation does not have a 'test-only' mode
is because the validate operation is supposed to provide that feature.
Except it doesn't actually work.

Problem 1) Assumed target.  Since the <source> parameter is a choice,
the manager cannot specify a target -- it is assumed to be either
the <running> or <candidate> config.  There is no way to specify
a user-named config (url) as the target if the <config> inline mode is used.

Problem 2) Assumed default operation.  There is no way to pass the
default-operation parameter that would be used in the <edit-config>
along with the <config> element.  The <validate> operation is supposed
to come up with the same answer as an <edit-config> would in this mode,
but without this critical parameter, that is impossible.

The text in 8.6.4.1 does not match the XSD.
It does not indicate that 'inline config' or 'url' modes
are allowed here.  The only example shows the 'config name' variant.
Why didn't anybody bring this up until now?  Does anybody support
this operation?

Andy

--
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: Tue, 17 Oct 2006 14:47:02 -0700

> configuration validation.

I think the WG should decide what to do about this problem:

    1) Ignore it
    2) Document it
    3) Fix it

IMO, the proper engineering fix requires 2 independent changes:

  1) Add a 'test-only' enumeration to the (edit-config) test-option
     parameter.  (Remember that this entire parameter is only supported
     if the :validate capability is supported. This change could
     be done as a validate-2.0 capability, and not change the 1.0 capability.

  2) Remove configInlineType as one of the options for the 'source'
     parameter in the validate operation. (Make it the same data type
     as the getConfig source parameter).  The normative text only
     mentions 'config name' as a possible value for the 'source' parameter,
     so perhaps the URL support in the XSD is wrong as well.

     The validate command is only used to check an entire configuration,
     so configInlineType is wrong, even if no other change is made.
     The 'operation' attribute should not be present in the data nodes,
     for the validate operation, unlike the edit-config operation.

I remember we had a test-only mode for edit-config and took it out because
the validate operation covered it.  Maybe this is not important
enough to people that we fix it.  We will see.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 18 Oct 2006 10:07:51 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> are allowed here.

It says 

            Name of the configuration datastore being validated, such as
            <candidate> or the <config> element containing the
            configuration subtree to validate.

So inline config is mentioned, but url is not.

> The only example shows the 'config name' variant.
> Why didn't anybody bring this up until now?

I think we touched on this in the thread leading up to
http://ops.ietf.org/lists/netconf/netconf.2006/msg00189.html and other
mails.

I brought it up at that time, and I still think that <validate> (as it
is defined) is useful for complete configs only.  But the complete
config can be inline or a local file or a datastore name.

> Does anybody support this operation?

Do you mean validation of inline config?  Yes, we support that, but it
will be on a syntactical level only, i.e. it can't do integrity
checks (as discussed in the email thread mentioned above).

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 18 Oct 2006 10:20:09 +0200 (CEST)

>      be done as a validate-2.0 capability, and not change the 1.0 capability.

I think this would be a very useful enhancement.

>      as the getConfig source parameter).

That means that you could only <validate> the 'candidate', 'running'
or 'startup'?  I think this would be fine, b/c test-only is a much
more useful operation.  [side note: does it make sense to validate
'running'?]

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 24 Oct 2006 17:28:43 +0200

Hello,
The document has improved a LOT.

General)
Do we really need 3 namespaces, wouldn't one or two suffice?
targetNamespace="urn:ietf:params:xml:ns:netconf:subscription:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:notification:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:replayNotification:1.0"
and the targetnamespace in 3.2.5.3 is missing

I find it confusing that we have several separate XML Schemas. I would like to see them 
merged, it would make the draft easier to understand.

I feel the XML Schema should start with a top level element (e.g. <top>) and specify the 
containing elements all the way down.

I would prefer to see examples for each and every defined message/operation/RPC.

Chapter 1.4)
What does the one but last requirement mean?

Chapter 3.1) The capability string should be defined under it's own heading like in 
chapter 7.3.

Chapter 3.2.5.2) Why do we need this chapter? What is the difference between this and the 
previous query? I propose to remove it.

Chapter 3.2.5.2) Targetnamespace is missing

Chapter 5)
"Currently, the NETCONF family of specification allows for running
    NETCONF over a number of transport protocols, some of which support
    multiple configurations."

What does it mean that they support multiple configurations. Isn't that valid for all 
protocols?

Chapter 5) I think this example (without the ]]>]]> string) would be better placed in 
chapter 2.2.1 where I am really missing an example.
I think all that's written in this chapter is trivial. We could live without this chapter.

Chapter 7.5.2) Put here some text or remove it.

Chapter 8) I feel that much of this chapter is trivial and does not contain any real new 
information. For me the only meaningful part is the last paragraph.
I would add to the last paragraph that the security of the receiving manager application 
might be different for the different protocols e.g. netconf, Syslog, Snmp. Based on this 
it should be considered whether it is appropriate to send Snmp, Syslog, etc. information 
via Netconf.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 25 Oct 2006 10:50:43 +0200

Hello,
Ericsson actually defined an own, non-standard capability because we need this test-only 
type/edit-config like operation. We often have datamodels/datastores that are not possible 
to validate completely because:
- they are simply to big
- they are divided into multiple semi-independent parts like in a sub-agent architecture. 
The different parts are possibly handled by completely different management systems, so 
validating in one step means problems.
In http://ops.ietf.org/lists/netconf/netconf.2006/msg00192.html
I asked for such possibility.
So I would be very happy with Andy's proposal, I completely support it. I think we should 
fix this, but certainly not ignore it.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]