Re: <validate> operation somewhat broken

[Martin Bjorklund <mbj@tail-f.com>]

Andy Bierman <ietf@andybierman.com> wrote:
> 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.

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




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