Re: few quick comments on notification-07

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

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

Absolutely.

> Applying the <edit-config>
> operation attribute to the filter is difficult, if not impossible,
> in such cases.

Suppose we have this filter stored in a namedProfile:

  <foo hoo="1">
    <bar>2</bar>
    <baz>3</baz>
  </foo>

And I do the following edit-config:

  <foo hoo="2" nc:operation="merge">
    <bar>3</bar>
    <baz>3</baz>
  </foo>

Are you saying that there's a single correct data-model agnostic
answer what the resulting config looks like?

> The real issue is having a data model object of type 'any' in a
> configuration database.

Yes.

> The real issue is that we don't
> have much common understanding of the differences between XML instance
> documents and NETCONF configuration databases.

So what's your suggestion?  Do you agree that this is a problem?

I don't think this is a CLR - if the type is 'any', we do
delete/replace/create on the entire thing.   One alternative would be
to not allow 'any', which in this case means remove namedProfiles.


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