Re: [netmod] operational knobs
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [netmod] operational knobs
Andy Bierman writes:
> ietf-start-dhcp(P1, P2, P3)
>
> [server implementation]
> ---> Junos 'dhcp' container; P1 --> Junos(P1), etc.
>
>Your expert customers will just use the complex vendor config data,
>but if they do not care about the details, they may use ietf-start-dhcp.
I'd rather see:
<edit-config>
<config>
<ietf>
<dhcp>
<thing>
<p1>v1</p1>
<p2>v2</p2>
<p3>v3</p3>
</thing>
<dhcp>
<ietf>
</config>
</edit-config>
Then the incremental cost is adding a new parameter (vendor specific or not)
is just adding the appropriate element under <thing>.
<edit-config>
<config>
<ietf>
<dhcp>
<thing>
<p1>v1</p1>
<p2>v2</p2>
<p3>v3</p3>
<acme:hardware-accelerated-dhcp>
<acme:fusion/>
<acme:bandwidth>10g</acme:bandwidth>
<acme:cool>
<acme:rating>very</acme:rating>
<acme:target-audience>18-25</acme:target-audience>
</acme:cool>
</acme:hardware-accelerated-dhcp>
</thing>
<dhcp>
<ietf>
</config>
</edit-config>
In the end, you'll build your content and make a call to your
netconf library to say "add this chunk of xml to this device's
configuration", and the library will hide all the netconf-layer
stuff, like :candidate, :distinct-startup, :confirmed-commit, etc.
So the upper-level call will be "add this config", which is close
enough to your "command-oriented interface".
Thanks,
Phil
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.