Re: [NGO] NETCONF-related sessions at IETF 70

Hi John,

John Dickinson <jad@jadickinson.co.uk> wrote:
> There has, for example, been some discussion in the dnsop WG about  
> developing a protocol for configuring and controlling nameservers (http://tools.ietf.org/wg/dnsop/minutes?item=minutes69.html 
> ) and I am one of the authors of a draft (http://www.ietf.org/internet-drafts/draft-arends-nscp-00.txt 
> ) that suggests using NETCONF.
> 
> The biggest issue for me in choosing NETCONF was and is to be sure I  
> am using NETCONF appropriately and that it really is the correct  
> solution to my problem.

I have read your draft and I do believe (and hope!) that NETCONF is
a good solution to this problem.

> I am currently looking at such things as, what  
> would be an appropriate data model, how to correctly use capabilities  
> and how to engineer things that are not strictly configuration, such  
> as control commands, monitoring and statistics gathering.

In your draft you also listed:

  Be extensible to allow implementors to extend to cover new objects
  and methods.

Maybe not suprising, but these are exactly the problems that YANG is
designed to help you with.

To be more specific, with YANG, you can write a standard data model
with the the (most) common configuration parameters.  Vendors can then
augment this standard data model with vendor-specific config params.

As an example (NOTE: I don't know what parameters actually would make
sense, this is just an example):

  container server {
      container panorama {
          list view {
              key view-name;
              leaf-list match-client { type inet:ip-prefix; }
              leaf recursion         { type boolean; }
              ...
          }
      }
  }

Then vendor X can add its own proprietary stuff:

   augment /dns:server/dns:panorama/dns:view {
       leaf funky-cache-option { ... }
       ...
   }

And in the NETCONF XML you might see:

   <server>
     <panorama>
       <view>
         <view-name>mybiew</view-name>
         <match-client>192.168.23.0/24</match-client>
         <match-client>172.16.30.0/16</match-client>
         <recursion>true</recursion>
         <x:funky-cache-option>magic</x:funky-cache-option>
       </view>
     </panorama>
   </server>

The same goes for commands (rpcs).  You can define standard rpc, and
vendors can e.g. add new rpcs, or augment the standard rpcs.

/martin

_______________________________________________
NGO mailing list
NGO@ietf.org
https://www1.ietf.org/mailman/listinfo/ngo