Subject: Re: [netmod] draft-ietf-netmod-system-mgmt NTP server issues

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Jun 2012 08:41:36 -0700

Hi,

On Fri, Mar 30, 2012 at 6:39 AM, Per Hedeland <[email-masked]> wrote:

> On 2012-03-27 14:23, Andrew McGregor wrote:....
>
> Thus the tree should be something more like:
> >
> > +--rw system
> >       ...
> >          +--rw ntp
> >             +--rw use-ntp?      boolean
> >             +--rw ntp-server [address]
> >                +--rw type       ntp-association-type
> >                +--rw address    inet:host
> >                +--rw enabled    boolean
> >                +--rw iburst     boolean
> >                +--rw prefer     boolean
> >                +--rw true       boolean
> >
> > where ntp-association-type is an enum with values 'server' 'peer' or
> > 'pool' and the booleans iburst, noselect, prefer and true are as
> > defined by the NTP reference implementation.
>
> I guess the question here is wether this should be a model for a generic
> standard NTP client, or for the (so-called) reference implementation.
> Personally I think the only reasonable choice is the former, among other
> things there exists viable freely-available alternatives to the reference
> implementation, and vendors can presumably augment the model with
> proprietary knobs.
>
> I'm pretty sure that 'pool' and 'iburst', although useful and relevant
> here, are not part of the NTP standard, and I don't believe 'prefer' is
> either. The 'true' as a configuration option is unknown to me even for
> the reference implementation, but I may be missing it in the plethora of
> options. Traditionally the reference implementation uses "magic"
> 127.127.x.x addresses to indicate a reference clock. In any case I doubt
> that it is meaningful for this model to cover the configuration of
> reference clocks.
>
> The concept of 'server' and 'peer' association modes are part of the
> standard, and may be useful to be able to configure, the alternative
> being to have 'server' be implicit. I'm not sure that 'peer' has more
> merit than the possibility to configure broadcast/multicast client
> modes, though.
>
> Another viewpoint is that the model should also - or maybe instead -
> cover the configuration of a SNTP client, which may well be the only
> thing that many devices have. As far as the standard is concerned, a
> SNTP client has a single server - i.e. the obviously desirable
> possibility to have multiple servers for redundancy, and the manner in
> which they are selected/combined, is outside the standard. In this case
> the ordered-by user prioritized list in the current draft may make
> sense.
>
> I'm afraid I don't have good specific suggestions for alternate text at
> this point, just wanted to give another opinion...
>

We need to decide what to do.
The module current has the leafs described above.
If the WG wants to expand the NTP support, then I am ready
to punt the entire NTP configuration to the NTP WG, not NETMOD WG.
If the WG wants to remove 'iburst', 'prefer', and/or 'true', and let other
data models augment or replace this container in the ietf-system module,
then that would be good to know.

At this point I am leaving these 3 objects in the module, and not
adding any new ones.

> --Per Hedeland

Andy