"David B Harrington" <dbharrington@comcast.net> wrote:
> Hi,
>
> This sounds to me like a detail related solely to implementation
> choices.
I agree. But edit-config seems to be done that way (maybe
unintentional?!?), and I think it's nice to specify a protocol so that
it can be implemented as efficient as possible.
> I suggest you read the whole command so you know both the
> source and target, and then you can, in your implementation, process
> the arguments in the order you choose.
This is of course trivial, but the point is that an implementation
will have to do more buffering than necessary.
> It would probably be a good idea to validate the whole command before
> starting processing, because this could make your implementation more
> robust against mal-formed requests
Of course we handle mal-formed requests - the processing done in our
implementation at this point is more than plain parsing, but it does
not involve any side effects.
And (of course) we do validate everything before doing any side
effects.
As a somewhat simplified example, suppose I know that the target config is
valid, and I get a copy-config which contains:
...
<interfaces>
<interface>
<ifName>eth0</ifName>
<ifAddr>10.0.0.1</ifAddr>
... more params follow ...
</interface> (*)
...
</interfaces>
...
Now, at point (*) if the interface eth0 is unchanged, I can throw away
that part of the data. But if I don't know which target to compare
against, I can't do this trick.
> including deliberate attempts to
> cause denial of service to other users of the system.
If the agent has to buffer everything, it might be easier to do a dos
attack!
/martin
> > -----Original Message-----
> > From: owner-netconf@ops.ietf.org
> > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Martin Bjorklund
> > Sent: Friday, December 09, 2005 6:17 AM
> > To: netconf@ops.ietf.org
> > Subject: copy-config
> >
> > Hi,
> >
> > The <copy-config> operation takes source and target as parameters.
> I
> > think the order of these is wrong - an implementation needs to
> buffer
> > the entire inline config before knowing which target is used. I
> > suggest that the order is reversed - target before source.
> >
> > The order is correct for edit-config.
> >
> > (our implementation makes use of this for both edit-config and
> > copy-config in order to find a small set of diffs to apply to the
> db)
> >
> >
> >
> > /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/>
> >
>
>
--
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/>