Re: few quick comments on notification-07

[Andy Bierman <ietf@andybierman.com>]

Martin Bjorklund wrote:
> 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?

no -- it doesn't even make sense to apply the edit-config
operations to type 'any' in every case.

For your example, my code would produce the following result,
since type 'any' means zero or more instances of arbitrary
unnamed nodes. (As always, attributes are zero or one instance.)

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


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

yes.
A giant red flag goes up when I see massive implementation complexity
for a loosely defined standard, since this always leads to interoperability
problems.

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

The concern I have is that the protocol defines the edit-config operations
and it doesn't say in RFC 4741 that if the agent identifies a sub-node
within the configuration contents of type 'any', then all 'operation'
attribute declarations within that subtree will be ignored, and a 'replace'
operation will be performed on the node of type 'any' instead.

This is a hack, not a CLR.

This is an important issue because these named profiles are
mandatory-to-implement.  They are completely redundant as well.
There are no interoperability problems possible when type 'any'
is passed as an RPC parameter, but this is not true for the
edit-config operation on configuration data of type 'any'.

We have nothing in SMIv2 like type 'any'.
IMO, it is an extremely bad idea to use this data type
in a NETCONF configuration database.  All data should
be named and strongly typed instead.  This is a case where
the protocol WG is getting into data modeling issues it
doesn't fully understand.

Perhaps named profiles should be removed (deferred) until NETMOD
figures out what rules should be defined for standard NETCONF data models.


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