[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: few quick comments on notification-07

Martin Bjorklund wrote:

Andy Bierman <ietf@andybierman.com> wrote:

2) There is nothing in the XSD that would indicate to an XSD tool that
   the read-only timestamp in the namedProfile must not be sent as part
   of the <edit-config> to configure a named profile.  I don't think
   this object should be in the data model, but if others think this
   is important, then I guess it will stay.  The value of this object
   is not explained anywhere -- it is just assumed that read-only
timestamps should be mixed with config data without even mentioning it at all. 

It is mentioned in the description clause.

But I think that there are more serious issues with this data model,
and I have pointed it out before.   The intention is that this DM can
be modified with an edit-config.  But there is nothing in the schema
that says what the key for a namedProfile is.  So how do you modify
one?

Also, it says that the 'name' paramater (which I would guess is
supposed to be the key) is modifiable.  How is this done using an
edit-config?

filter has minOccurs=0.  What exactly does that mean?  Can I create a
namedProfile w/o filter?  I.e. does the minOccurs=0 apply to the
contents of the device's datastore, and not an instance document?

The filter itself is also supposed to be modifiable.  Now, the filter
can contain _any_ XML (if it's a subtree filter), and we're supposed
to be able to use edit-config to modify parts of it...?

IMO, if we are going to include this DM, the text needs to describe
how this is supposed to work, otherwise we won't see interoperable
implementations.

I suggest that for the filter parameter, the XML should be treated as
an opaque data structure, which can be deleted, created and replaced
in its entirety only.



I am concerned about adding poorly understood CLRs on top of a poorly
designed data model as a band-aid, and ending up with a non-interoperable
standard.

Due to the nature of subtree filtering, it cannot be implemented
with 'conventional' XML parsers at all.  Invalid declarations are
just no-match conditions, not errors.  Applying the <edit-config>
operation attribute to the filter is difficult, if not impossible,
in such cases.

The real issue is having a data model object of type 'any' in a
configuration database.  The real issue is that we don't
have much common understanding of the differences between XML instance
documents and NETCONF configuration databases.



/martin


Andy

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