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.