Re: few quick comments on notification-07

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

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

The idea was that the agent would just *allow* these operations, not
silently convert a delete into a replace.  So if it receives a
'operation' attribute somewhere within the 'filter', it would raise an
error.

I think this is a clean way to handle 'any'.

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

I agree, but I can see that it is useful in some circumstances,
e.g. a logging mib is much easier to define with an 'any' type.

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

Unless we can agree on how 'any' should be handled (at least in this
case), I think it's best to defer this.


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