Subject: Re: [netmod] comments on draft-ietf-netmod-system-mgmt-06

From: Martin Bjorklund <[email-masked]>
Date: Sat, 01 Jun 2013 16:14:36 +0200 (CEST)

Hi,

Andy Bierman <[email-masked]> wrote:
> Hi,
> 
> Thanks for your review.  Comments in-line.
> Summary:
>   - all fixed except:
>        (c, l, s) left for Martin
>        (f, o, p, r, t) need WG to decide
> 
> 
> Andy
> 
> 
> 
> On Thu, May 16, 2013 at 9:05 AM, Juergen Schoenwaelder <
> [email-masked]> wrote:
> 
> > Hi,
> >
> > here is a review of draft-ietf-netmod-system-mgmt-06.

> > c) Update section 1.2 to the new format which supports * for lists and
> >    regenerate the tree figures. (Martin knows what I mean.)
> >
> >
> left for Martin

Fixed.

> > f) Even though there are only a few config false data nodes, I would
> >    seriously consider to move them to separate them from the config
> >    true data nodes.
> >
> 
> 
> I think you are right.  There should not have to be a couple NP containers
> in the running config just to hold non-config sub-trees.  If I have a
> completely
> default system configuration then the /system sub-tree does not need
> to exist.  I should still be able to read the time and platform info in any
> case.
> 
> I could move the 3 nodes if there is WG consensus to do so:
> 
>    /system-state/platform
>    /system-state/current-datetime
>    /system-state/boot-datetime

I don't think this is necessary, but I won't object if this change is
made.

> IMO, we should even move these objects to a new module.
> We want to make sure that every NETCONF server supports
> the read-only /system-state objects (especially current-datetime).
> Currently, a server has to implement 3 rpc statements
> and a lot of config objects in order to provide this information
> and advertise the YANG module.

I don't think we need to move them to a new module though.  IMO, our
main focus is on configuration of system parameters.  If the minimum
compliance means only monitoring I don't think we have improved much
over the current situation.

> > l) The feature local-users is bound to password authentication. Can I
> >    not have a system with local user accounts that only permits SSH
> >    public key authentication? (This is actually how I run all my
> >    servers - we completely disable password authentication. I guess
> >    this is not uncommon.)

Sure you can, but I think this is a deployment decision, rather than
an implementation decision.  I would think that all implementations
that support local users also support password authentication.  If
this is not the case, we could make it a feature.

> > m) Note that system/contact and system/location only map to SNMP if
> >    you are lucky due to the different character sets involved. With
> >    UTF8, also the size restriction does not mean the same. Perhaps
> >    remove the size restriction completely and add explicit text that
> >    implementations mapping this to SNMP objects may restrict the size
> >    and the allowed set of characters. (In fact DisplayString has even
> >    more details.)
> >
> >
> fixed
> 
> 
> > n) Should boot-datetime really be the time the NETCONF server last
> >    restarted? I would be more interested to know when the system last
> >    restarted. The NETCONF restart time (if ever needed) should really
> >    be part of the netconf-state data model (i.e. RFC 6022 bis).
> >
> >
> 
> fixed
> 
> 
> > o) The ntp objects allow to configure multiple IP addresses and each
> >    one can be disabled individually. Is this really needed? If so, why
> >    is this not needed for DNS resolvers?
> >
> >
> 
> I think these extra settings were added to match how NTP is configured on
> Linux.

A disabled server would probably be commented out in ntp.conf, right?

I agree w/ Juergen, I think we can remove the enable leaf for the
individual servers.

> > p) The ntp objects do not allow me to configure a port number. Should
> >    we not generally allow to configure complete transport layer
> >    endpoints?

[...]

> > r) The model does not allow me to configure a DNS server using a
> >    non-standard port number. Should we not generally allow to
> >    configure complete transport layer endpoints?

I agree that we in general should allow complete transport config.
Often a choice of the applicable transports, tcp, ssh, tls, ... since
they need different parameters.

However, for the DNS resolver and NTP, it would be difficult to
implement; it is not possible to set in resolv.conf or ntp.conf (on
linux).

> > s) I think timeout and attempts are not clear enough defined. Consider
> >    a server that never responds. With N attempts and a timeout t, do I
> >    get N attempts with a timeout of t for each attempt or a timeout of
> >    t with N attempts? Looking at the bind header files (the man pages
> >    are also unclear), it seems bind does N attempts with a timeout of
> >    t for each attempt.
> >
> >    The same applies to the timeout and attempts definitions for radius.

How about this:

        leaf timeout {
          type uint8 {
            range "1..max";
          }
          units "seconds";
          default "5";
          description
            "The amount of time the resolver will wait for a
             response from each remote name server before
             retrying the query via a different name server.";
        }

        leaf attempts {
          type uint8 {
            range "1..max";
          }
          default "2";
          description
            "The number of times the resolver will send a query to
             all its name servers before giving up and returning an
             error to the calling application.";
        }

Maybe also add this to the description of the server (leaf-)list:

           When the resolver is invoked by a calling application, it
           sends the query to the first name server in this list.
           If no response has been received within 'timeout' seconds,
           the resolver continues with the next name server in the
           list.  If no response is received from any name server
           in this list, the resolver continues with the first server
           again.  When the resolver has traversed the list
           'attempts' times without receiving any response, it gives
           up and returns an error to the calling application.

It is easy to describe in pseudo-code:

   while (attempts-- > 0):
     foreach server:
       send request to server
       if got reply within timeout:
         return

And similar for radius.

> > t) The radius server list is keyed by an address. Now with Radius,
> >    there is the official default port number and there was a different
> >    port number widely used before the official got allocated. Hence,
> >    in practice, both are used. So I like to be able to configure
> >    things such that the system tries both. However, this won't work
> >    because the list is keyed by the address. I can't have this:
> >
> >    <server>
> >      <address>1.1.1.1</address>
> >      <udp>
> >        <authentication-port>1812</authentication-port>
> >      </udp>
> >    </server>
> >    <server>
> >      <address>1.1.1.1</address>
> >      <udp>
> >        <authentication-port>1645</authentication-port>
> >      </udp>
> >    </server>
> >
> >    Note that this also applies to the other lists keyed by simply an
> >    address. (We may have to introduce names to refer to the endpoints
> >    if we want a simple key and transport extensibility).
> >
> >
> 
> I agree.  Named entries are better IMO anyway.

Agreed.

> >    I also find the separation of the udp port from the address
> >    strange.  I can't have something like this either (if I want to add
> >    tcp support):
> >
> >    <server>
> >      <address>1.1.1.1</address>
> >      <udp>
> >        <authentication-port>1812</authentication-port>
> >      </udp>
> >    </server>
> >    <server>
> >      <address>1.1.1.1</address>
> >      <tcp>
> >        <authentication-port>1645</authentication-port>
> >      </tcp>
> >    </server>
> >
> >    For me, it would make more sense leave the address and port number
> >    together and to support something like this.
> >
> >    <server>
> >      <authentication>
> >        <udp>
> >          <address>1.1.1.1</address>
> >          <port>1812</port>
> >        </udp>
> >        <udp>
> >          <address>1.1.1.1</address>
> >          <port>1645</port>
> >        </udp>
> >        <tcp>
> >          <address>1.1.1.1</address>
> >          <port>1645</port>
> >        </tcp>
> >      <authentication>
> >    </server>
> >
> >
> I agree. Need WG to decide. I will leave for Martin to fix.

Ok, I have introduced this change.  I think it is correct since we
try to model for different transports.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 1 Jun 2013 09:54:28 -0700

> over the current situation.

SNMP experience shows us that the system's notion of the current time
is the most referenced object in the entire device.  All timestamps
and all time-deltas need to be derived from this common base object.

Since YANG conformance in not granular enough to to express
conformance to just the current-datetime object, it will cause problems
later if a vendor has to implement the system config module in
order to provide the current time.

> I agree w/ Juergen, I think we can remove the enable leaf for the
OK with me

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 2 Jun 2013 09:40:13 +0200

> this is not the case, we could make it a feature.

OK. Lets consider l) closed - no change.

> implement; it is not possible to set in resolv.conf or ntp.conf (on

I think we should do be able to represent what is architecturally
possible. Perhaps we need to add text or features to deal with widely
deployed real-world implementations that may have restrictions.

>        if got reply within timeout:

Yes, this provides a clear interpretation. I am not sure, however,
whether this is really what implementations generally do. Ideally, the
protocols would specify this - if not, we would likely define
something that the protocol specific RFCs maintained by other working
groups should be defining.

/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: Martin Bjorklund <[email-masked]>
Date: Sun, 02 Jun 2013 12:14:26 +0200 (CEST)

> deployed real-world implementations that may have restrictions.

Ok, this makes sense.  We'd have something like this:

     +--rw ntp
      |  +--rw enabled?   boolean
      |  +--rw server* [name]
      |     +--rw name                string
      |     +--rw (transport)
      |     |  +--:(udp)
      |     |     +--rw udp
      |     |        +--rw address    inet:host
      |     |        +--rw port?      inet:port-number
      |     +--rw association-type?   enumeration
      |     +--rw iburst?             boolean
      |     +--rw prefer?             boolean
      +--rw dns-resolver
      |  +--rw search*    inet:domain-name
      |  +--rw server* [name]
      |  |  +--rw name    string
      |  |  +--rw (transport)
      |  |     +--:(udp)
      |  |        +--rw udp
      |  |           +--rw address    inet:ip-address
      |  |           +--rw port?      inet:port-number
      |  +--rw options
      |     +--rw timeout?    uint8
      |     +--rw attempts?   uint8
      +--rw radius
      |  +--rw server* [name]
      |  |  +--rw name                   string
      |  |  +--rw (transport)
      |  |  |  +--:(udp)
      |  |  |     +--rw udp
      |  |  |        +--rw address                inet:host
      |  |  |        +--rw authentication-port?   inet:port-number
      |  |  |        +--rw shared-secret          string
      |  |  +--rw authentication-type?   identityref
      |  +--rw options
      |     +--rw timeout?    uint8
      |     +--rw attempts?   uint8

Should we have features on ntp/server/port and dns/server/port?  

              leaf port {
                if-feature ntp-udp-port;

> whether this is really what implementations generally do.

I checked glibc's resolver.

> Ideally, the

So ... are you suggesting we should remove even these options?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Jun 2013 09:12:08 +0200

> Should we have features on ntp/server/port and dns/server/port?  

Introducing these features probably makes sense for NTP and DNS. I
checked a few sources and it is interesting that the port number
sometimes not even has a #define and sits literally in a htons().

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 04 Jun 2013 09:34:08 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> Introducing these features probably makes sense for NTP and DNS.

Ok.  Yes, I think this results in a pretty good model.  It supports
multiple transports and configuration of ports, while at the same time
accepting the fact that implementations have hard coded ports...

Something like this:

  feature ntp-udp-port {
    description
      "Indicates that the device supports the configuration of
       the UDP port for NTP servers.

       This is a 'feature' since many implementations do not support
       any other port than the default port.";
  }

  feature dns-udp-port {
    description
      "Indicates that the device supports the configuration of
       the UDP port for DNS servers.

       This is a 'feature' since many implementations do not support
       any other port than the default port.";
  }

/martin