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

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 May 2013 18:05:28 +0200

Hi,

here is a review of draft-ietf-netmod-system-mgmt-06.

a) The abstract needs work. I do not think the current sentence is
   correct nor do I think this is a useful description of the scope
   covered.

b) The same applies to the Introduction - this does not seem to be
   about a "management system". The bullets listed also do not line up
   well with what is now in the document, perhaps it should be

   o  system identification configuration and monitoring

   o  system time-of-day configuration and monitoring

   o  user authentication configuration

   o  local users configuration

   o  dns resolver configuration

   o  system control operations (shutdown, restart, setting time)

   (not sure monitoring is a good word but I have no better proposal)

   I also do not see what the definition of a term requires a new
   subsubsection (just get rid of the section header
   '1.1.1. Terms'). 

   The definition of 'system' is also rather unclear to me: "the
   embodiment of the entire set of management interfaces". Nor does
   the I-D do anything with managing physical entities. I think there
   should be a better definition or no definition at all.

   Any other terms that need to be 'imported' from other documents?

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

d) sec 2.1:

   s/operational data/operational state data/ (perhaps consider
   importing a definition for operational state)

e) Should section 2 not also have a subsection talking about DNS
   resolver configuration and a subsection talking about basic system
   control operations?

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.

g) Why are algorithm and key-data optional for an SSH key?

h) sec 3.5.2:

   s/system\/ auth/system\/auth/

i) First sentence of the module description may need improvements.

j) p12:

   s/correct/accepted/

k) What kind of device would not announce the feature "authentication"?
   Do not all NETCONF transports require some form of authentication?

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.)

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.)

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).

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?

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

q) Should the dns container be called resolver or dns-resolver?

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?

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.

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 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>
       
u) Please update the security considerations boilerplate so that we
   have an explicit reference to the access control model.

v) Where you list readable subtrees, I think it is fair to explicitly
   mention the local users subtree and the passwords contained in that
   subtree.

w) Are really all references normative? For example, RFC 6557 or RFC
   3688?

/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: Andy Bierman <[email-masked]>
Date: Fri, 17 May 2013 12:09:09 -0700

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

>    correct nor do I think this is a useful description of the scope
fixed

> b) The same applies to the Introduction - this does not seem to be

fixed

>    o  system control operations (shutdown, restart, setting time)
fixed

>    subsubsection (just get rid of the section header
fixed

>    should be a better definition or no definition at all.
removed

>    Any other terms that need to be 'imported' from other documents?
not sure -- none added

>    regenerate the tree figures. (Martin knows what I mean.)
left for Martin

>    importing a definition for operational state)
fixed; no RFC to import this term from.  I changed this term
to "non-configuration data" in the <get2> draft.  IMO, extra
classifications beyond config=false are not needed for
current NETCONF/YANG features.

>    resolver configuration and a subsection talking about basic system
fixed

>    seriously consider to move them to separate them from the config

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

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.

(IMO we should not have 2 top-level objects in the same module anyway).

> g) Why are algorithm and key-data optional for an SSH key?
made them mandatory

>    s/system\/ auth/system\/auth/
fixed

> i) First sentence of the module description may need improvements.
fixed

>    s/correct/accepted/

fixed

>    Do not all NETCONF transports require some form of authentication?

It means configuration of authentication -- fixed

>    servers - we completely disable password authentication. I guess

Left for Martin to answer

>    and the allowed set of characters. (In fact DisplayString has even
fixed

>    be part of the netconf-state data model (i.e. RFC 6022 bis).

fixed

>    is this not needed for DNS resolvers?

I think these extra settings were added to match how NTP is configured on
Linux.
I don't think they were requested for DNS.  (no change)

>    we not generally allow to configure complete transport layer
There is only a port number for RADIUS over UDP.
Not sure if these are needed or not.
(no changes)

> q) Should the dns container be called resolver or dns-resolver?

changed to dns-resolver so it won't be confused with DNS server
configuration.

>    configure complete transport layer endpoints?

same answer as (p)

>    The same applies to the timeout and attempts definitions for radius.
left for Martin to edit

>    if we want a simple key and transport extensibility).

I agree.  Named entries are better IMO anyway.
Should there be a unique-stmt for the addr:port pair?
(no changes)

>          <address>1.1.1.1</address>
I agree. Need WG to decide. I will leave for Martin to fix.

>    have an explicit reference to the access control model.
fixed

>    mention the local users subtree and the passwords contained in that

fixed

> w) Are really all references normative? For example, RFC 6557 or RFC
fixed

> /js
Andy