Martin Bjorklund wrote:
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'.
So an operation-not-supported error gets returned instead? The actual edit-operation in effect at any node depends on the operation attribute(s) and the default-operation parameter. The default is 'merge'. So a merge on type 'any' can silently turn into a 'replace' instead? I think the specification of this clean way to handle 'any' needs much more thought around the corner-cases.
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.
Yes, but that is monitoring data that is not affected by edit-config. I should of said "writable data". This is not a problem for read-only data.
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
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/>