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

I'm not sure that's the correct error code.  Compare with this case.
Suppose a 'service' has two keys, 'ip' and 'port'.  What error message
do you get if you send:

   <service nc:operation="create">
     <ip>10.0.0.1</ip>
     <port nc:operation="delete">80</port>
     ...
   </service>

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

In the same way as merge "silently turns into a replace" on an
integer:

   <ifMtu nc:operation="merge">1500</ifMtu>

vs.

   <ifMtu nc:operation="replace">1500</ifMtu>



> I think the specification of this clean way to handle 'any'
> needs much more thought around the corner-cases.

Well, it's not even written down, so you're probably right.  We
currently do not support 'any' in this way, but this is the way I've
planned to support it.

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

Ok.


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