Subject: [netmod] draft-ietf-netmod-system-mgmt-00

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Mon, 12 Mar 2012 14:22:21 -0400

I was looking over the draft-ietf-netmod-system-mgmt-00 but I had a
quick question.  How do you envision the DNS and NTP settings being used
in a situation where these values are being obtained from a DHCP server?
Would a read of these values reflect an admin or an operational state?
Should there be some way of specifying that the values should be
obtained from DHCP vs a static configuration?

Also for any of the containers that use a list of hosts (Radius, ntp)
should there be a config false leaf that can show which of the specified
servers is actually being used?  Although I could see this being more of
a implementation specific thing as perhaps some users might use all in
some round-robin fashion.  I'm just curious if there is any merit in
adding that functionality.

Thanks!

-Jeff Lange

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Mar 2012 11:54:09 -0700

On 03/12/2012 11:22 AM, Lange, Jeffrey K (GE Energy) wrote:
> I was looking over the draft-ietf-netmod-system-mgmt-00 but I had a quick question. How do you envision the DNS and NTP settings being used in a situation where these values are being obtained from a
> DHCP server? Would a read of these values reflect an admin or an operational state? Should there be some way of specifying that the values should be obtained from DHCP vs a static configuration?
>

I agree some sort of 'provided-by-DHCP' option needs to be added.

> Also for any of the containers that use a list of hosts (Radius, ntp) should there be a config false leaf that can show which of the specified servers is actually being used? Although I could see
> this being more of a implementation specific thing as perhaps some users might use all in some round-robin fashion. I’m just curious if there is any merit in adding that functionality.
>

We discussed this and then did not add it, not sure how much state
information to add.  I think you are right -- 'enabled' does not mean 'in-use'.
(The old adminStatus/operStatus problem.)

> -Jeff Lange

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Mar 2012 21:01:34 +0100

> I agree some sort of 'provided-by-DHCP' option needs to be added.

I think DHCP provides operational state and not config. Since the 
YANG definitions are config true, I assume that the DHCP provided
operational state does not show up in the config datastore.

Sections 4.3 and 4.4 of RFC 6244 might be interesting background
reading.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Tue, 13 Mar 2012 08:57:40 -0400

I agree that DHCP provides operational (config false) info, however I
need a config true method of telling my device to either use the DNS/NTP
entries from DHCP or to ignore them and to use the static entries.  And
in an ideal world if I have more than one DHCP interface (on different
subnets), I would like to be able to specify which interface I want to
use the DHCP DNS/NTP entries from, although I admit, this is a bit more
implementation specific. 

Thanks!
-Jeff

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Monday, March 12, 2012 4:02 PM
To: Andy Bierman
Cc: Lange, Jeffrey K (GE Energy); [email-masked]
Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00

On Mon, Mar 12, 2012 at 11:54:09AM -0700, Andy Bierman wrote:
> >quick question. How do you envision the DNS and NTP settings being
used in a situation where these values are being obtained from a DHCP
server? Would a read of these values reflect an admin or an operational
state? Should there be some way of specifying that the values should be
obtained from DHCP vs a static configuration?
> I agree some sort of 'provided-by-DHCP' option needs to be added.

I think DHCP provides operational state and not config. Since the YANG
definitions are config true, I assume that the DHCP provided operational
state does not show up in the config datastore.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Mar 2012 14:40:01 +0100

> use the DHCP DNS/NTP entries from, although I admit, this is a bit more

My understanding is that right now the I-D does not cover DHCP
configuration. If you want to draft a proposal how to cover this, I am
sure will be appreciated as potential material to add.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Mar 2012 21:43:44 +0100 (CET)

Hi,

> Would a read of these values reflect an admin or an operational

The *values* provided by DHCP would be config false, i.e. operational
state.  However, the fact that DHCP should be used at all would be
config data.  This needs to be per interface.  As Juergen wrote, it is
currently not part of the data models we have, but maybe it should
be... it is not entirely clear where it would fit though.

> some round-robin fashion.

Actually, if the standard allows an implementation to have this
freedom, it must be clear from the data model.  For radius, a single
leaf indicating which server is being used is maybe not possible.  I
guess you _could_ keep track of which server you got the last reply
from, but I am not sure it is very useful.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Mar 2012 21:45:40 +0100 (CET)

> use the DHCP DNS/NTP entries from, although I admit, this is a bit more

If someone made a DHCP config data model, this should be part of that
model.  I think there is merit in having a standard solution for this.

/martin

---

From: "t.petch" <[email-masked]>
Date: Wed, 14 Mar 2012 09:50:18 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 13, 2012 9:45 PM
> model.  I think there is merit in having a standard solution for this.

I think that this is much wider than DHCP.  There is an ongoing debate in IPv6,
unresolved after many years, as to which takes precedence, values from DHCP or
RA values from a router, and there could be more than one of each (if v6ops ever
reach a conclusion, I am sure that we can model it:-).

Currently, there is a debate about which of multiple SANs to use with Netconf
when a certificate is so configured, something that isms did consider.

Then any router may get routing table updates statically, from an IGP, EGP and
so on, an issue that Cisco addressed a long time ago.

etc etc

I think we are usually too narrow in our view, and need to remember that there
may be different ways in which configuration information may come in and be
prepared to create a suitable list of priorities for cases such as the above and
all the others I haven't thought of.  Whether there should be something generic
for this recurrent issue, or whether each case needs to be taken on its
individual merits, I am unsure.

By the time we get to a DHCP model, it will be too late.  It is when we are
modelling e.g. the IPv6 prefix information that we need to recognise that
options exist and build them in.

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 14 Mar 2012 11:18:51 +0100

> options exist and build them in.

From the narrow point of view of a datastore schema, it is a plausible option to leave it to the future DHCP data model to augment a core module (e.g. system) with a knob that turns DHCP on or off.

IMO a more serious problem is with semantics, be it expressed in descriptions or 'must' statements: for example, semantics of IP address configuration in the "ip" module alone may be different from the combination of "ip" and "dhcp", unless the "ip" module really foresees the integration with "dhcp".

Lada

> 
> Tom Petch
> 
>> 
>> /martin
>> 
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 14 Mar 2012 11:55:01 +0100 (CET)

"t.petch" <[email-masked]> wrote:
> all the others I haven't thought of.

Yes we are somewhat narrow - we currently model only the "static", or
configured-by-the-operator parts.

>  Whether there should be something generic

There are probably some recurring patterns, but I think it needs to be
done on a case-by-case basis.  Sometimes you might want to merge the
dynamically learned info with the configured, sometimes you might want
one take precedence over the other, and sometimes the fact that you
have configured for example DHCP to return the DNS server addresses
means that it should be used instead of the statically configured
addresses.

> options exist and build them in.

So are you saying you think we should try to solve this issue now?

I think the *modelling* can be done quite easily - we just have to
agree *what* to model...

/martin

---

From: "t.petch" <[email-masked]>
Date: Wed, 14 Mar 2012 11:45:28 +0100

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; "Martin Bjorklund" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, March 14, 2012 11:18 AM

>From the narrow point of view of a datastore schema, it is a plausible option to
leave it to the future DHCP data model to augment a core module (e.g. system)
with a knob that turns DHCP on or off.

IMO a more serious problem is with semantics, be it expressed in descriptions or
'must' statements: for example, semantics of IP address configuration in the
"ip" module alone may be different from the combination of "ip" and "dhcp",
unless the "ip" module really foresees the integration with "dhcp".

<tp>
I am saying that when we specify the configuring of IP (I know, this thread is
system mgt), we should be alive to this situation.  In the case of IPv6, the WG
are trying to come up with protocol rules about precedence of configuration and
have defined two bits to control this and have failed to reach a consensus, over
many years, because different uses of IPv6 have different requirements.  It is
dead obvious (to me:-) that they need a configurable table, as Cisco specify for
routing table entries, which gives a default set of rules for precedence and
allow the user to configure a different set, at least by protocol, perhaps by
some other criterion within the protocol, as for example the absolute value of
router id is used as a tie breaker in routing protocols to decide which router
should be used.

As long as IPv6 try to achieve by protocol what is probably unachievable, then
there is nothing we can do for them; if and when they accept the need for
configuration, then we should provide the mechanics as in a table of precedence.
Even if they do not accept the need, we should probably provide a history saying
that this value (e.g. prefix) came from e.g. DHCP or RA or static or ......

The original question here was about NTP and Martin suggested that that would be
part of the DHCP model as and when we did one.  Wrong (IMHO)! it is part of the
NTP model to specify what the order of precedence should be when the box has
multiple sources of data.  That is what I want us to be alive to, for IPv6, for
routing and for ....

Tom Petch
</tp>

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 14 Mar 2012 13:07:23 +0100 (CET)

"t.petch" <[email-masked]> wrote:
> part of the DHCP model as and when we did one.

I don't think that was what I wrote.  But it doesn't matter - I agree
with you that the precedence thingie should not be part of the DHCP
model.  The precedence cannot really be part of any of the mechanisms
we define (DHCP, RA, ...) - but should it be part of the static
configuration?  That's also just one mechanism...

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 14 Mar 2012 14:18:45 +0100

> So are you saying you think we should try to solve this issue now?

On thing we should probably tackle is a representation of IP addresses as state data. Many subsystems will need to refer to addresses assigned to interfaces but currently the addresses are not available anywhere in the data tree unless they are manually configured.
Even without DHCP, this can already happen for autoconfigured IPv6 addresses.

The "ip" module seems to be the right place for such a config=false structure.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Mar 2012 08:30:07 -0700

On 03/14/2012 03:55 AM, Martin Bjorklund wrote:
> "t.petch"<[email-masked]>  wrote:

Something like:

    leaf learn-from-dhcp {
       type bits {
          bit addressing {
            description "Use IP addressing information from DHCP if available.";
          }
          bit dns {
            description "Use DNS information from DHCP if available.";
          }
          // any others?
       }
       // any default?
    }

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Mar 2012 16:56:49 +0100

>            description "Use DNS information from DHCP if available.";

That looks a bit too simplistic to me. DHCP is used widely and I would
be not surprised if for many usages the only config choice is really
just DHCP on/off for most users. Once we go beyond on/off, I think the
world is not that simple anymore. And in fact, you configure your DHCP
client what it requests. How that information is then _used_ if
provided by the server especially, if it competes with other
information, is the v6ops problem. So the text would be really "obtain
xxx information" rather than "use xxx information" (and the proper way
of modeling is likely to list the DHCP options that are requests or
provided as hints to the DHCP server, that is it goes beyond a simple
bits type.

/js

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Wed, 14 Mar 2012 11:58:41 -0400

>            description "Use DNS information from DHCP if available.";

This wouldn't address the more generic priority issue,
What if there was something like:

grouping settings-priority {
  list settings-priority-list {
    ordered-by user;
    leaf source-type{
      type enumeration {
        enum static;
        enum dhcp;
        enum ...;
      }
    }

    leaf source-iface {
    // this could be used if you want to specify a particular interface
      type leaf-ref {
        path "/interface/name";
      }
    }
  }
}

...

container ntp {
      leaf use-ntp {
...
      }
      list ntp-server {
...
        } 
        leaf enabled {
...
        }
      uses settings-priority;
      }
    }

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Mar 2012 09:35:27 -0700

> provided as hints to the DHCP server, that is it goes beyond a simple

The GUI in Ubuntu has "Automatic (DHCP)" and "Automatic (DHCP) Addresses Only".
I think Fedora has the same thing.  So maybe it is an enumeration:

   leaf learn-from-dhcp {
      type enumeration {
         enum none {
            description "Do not use DHCP";
         }
         enum addressing {
            description "Use IP addressing information from DHCP if available.";
         }
         enum addressing-and-dns {
             description "Use IP addressing information and DNS information
               from DHCP if available.";
         }
      }
   }

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 14 Mar 2012 12:14:47 -0400

>I think Fedora has the same thing.  So maybe it is an enumeration:

FWIW: The ISC dhclient allows you to override/ignore any option
returned from the server.  Here's a good write-up:

http://www.lamolabs.org/blog/6194/how-to-override-dhcp-settings-on-a-fedoracentosrhel-linux-box/

I keep home name, domain name, etc, getting only dns, router, and
address.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Mar 2012 17:47:35 +0100

>               from DHCP if available.";

I am not sure a GUI is the right model. Linus systems using the
Debian(?)  interfaces config have this (quoting from interfaces(5)):

  The dhcp Method
      This  method  may be used to obtain an address via DHCP with any of the
      tools: dhclient, pump, udhcpc, dhcpcd. (They have been listed in  their
      order  of  precedence.) If you have a complicated DHCP setup you should
      note that some of these clients use their own configuration  files  and
      do not obtain their configuration information via ifup.

      Options

             hostname hostname
                    Hostname to be requested (pump, dhcpcd, udhcpc)

             leasehours leasehours
                    Preferred lease time in hours (pump)

             leasetime leasetime
                    Preferred lease time in seconds (dhcpcd)

             vendor vendor
                    Vendor class identifier (dhcpcd)

             client client
                    Client identifier (dhcpcd, udhcpc)

             hwaddress class address
                    Hardware  Address. class is one of ether, ax25, ARCnet or
                    netrom. address is dependent on this choice.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Mar 2012 10:11:48 -0700

>                      netrom. address is dependent on this choice.

This module is about the system configuration, not the DHCP configuration.
A prioritized list of configuration sources is a system knob.
I was trying to pick a couple system options that are very widely supported.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Mar 2012 18:39:45 +0100

> I was trying to pick a couple system options that are very widely supported.

The question is likely whether the model is the average GUI on a
desktop OS or the average CLI of routers/switches and the like.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 14 Mar 2012 19:56:37 +0100 (CET)

> This wouldn't address the more generic priority issue,

Right.  Andy's leaf targets the DHCP client config (which I think
should go into some other data model).

>   list settings-priority-list {

Yes, but it can be made more extensible by using identities (see
'user-authentication-order' in 	draft-ietf-netmod-system-mgmt).

       leaf-list settings-priority {
         type identityref {
           base settings-priority-mechanism;
         }
       }

  identity from-config {
    base settings-priority-mechanism;
  }
  
  identity dhcp {
    base settings-priority-mechanism;
  }

  identity ra {
    base settings-priority-mechanism;
  }

By using this model, whenever a new mechanism is modelled, a new
identity can be defined (in some other model) along with the config
for that mechanism:

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 14 Mar 2012 20:23:08 +0100

> identity can be defined (in some other model) along with the config

Identities are nice but they do not work reliably in XPath expressions, and this would be a problem in this case.

Lada

---

From: "t.petch" <[email-masked]>
Date: Sat, 17 Mar 2012 12:35:09 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 14, 2012 4:56 PM
> provided as hints to the DHCP server, that is it goes beyond a simple

This is more like what I was thinking of, that there is DHCP configuration/state
but that there is also configuration/state for the protocols for which DHCP
provides raw data.  The DHCP module would specify what DHCP options should be
requested and what data came back in response, while the module for the other
protocols would specify the mechanism for selecting between which of several
options should be chosen in order to arrive at a configuration.

IPv6, in its attempt to be auto-configuring, has created such a situation, with
the prefix, which could come from a router RA (or more than one) or from DHCP
and the WG cannot produce a set of rules which satisfy the varying needs; and
something similar arises with address selection, which of the many possible
source and destination address pairs should be used for a packet.

The case we already have is the selection of security credentials for SNMP over
TLS, snmpTlstmCertToTSNTable, (not that I expect to see that modelled in yang
any time soon:-) where the table specifies a priority, but I do think that
priority, probably unique in the yang sense, is the way to do it, a bit not
being enough to ensure a unique selection.

Tom Petch

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 17 Mar 2012 10:49:20 -0700

Hi -

> From: "t.petch" <[email-masked]>
> To: "Juergen Schoenwaelder" <[email-masked]>; "Andy Bierman" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, March 17, 2012 4:35 AM
...
...
> being enough to ensure a unique selection.

I think these issues need to be separated.
   1) Configuring whether a particular mechanism should try to
        *obtain* a given piece of configuration information.  This
       seems to be part of the configuration of that mechanism,
       since it's not necessarily configurable for all mechanism.

   2) Configuring whether that configuration information, once
        obtained by a particular mechanism, should be used.  Beyond
        a simple enable / disable of the use of a particular mechanism,
        which might be reasonably modeled in the configuration of that
        mechanism,  this is not a binary decision if there is need to
        support anything more elaborate than (a) or (b) below to select
        from among the values provided by various sources:
          a) use only the first mechanism to supply a value
               (begs the question of what to do if that mechanism later
               provides another value)
          b) use the most recent (regardless of source)
          c) use this source only if a value has not been obtained from a
              (prioritized) preferred mechanism.
               (begs the question of what to do if that or a more preferred
                mechanism later provides another value)
        Since implementing these policies requires knowledge of all the
        configuration mechanisms supported by a system, modeling these
        policies is distinct from the modeling of the individual mechanisms.

Randy