[Netconf] Comments on draft-ietf-netconf-server-model-03.txt

[Alan Luchuk <[e-mail]>]

Hello,

Included below are comments about draft-ietf-netconf-server-model-03.txt.
I gave the most thought to the sections relating to NETCONF over TLS, but
did look over the rest of the document fairly carefully.  I hope these
are helpful and useful to the WG.


Section 1, Page 2-3:  Nit
-------------------------

s/what ports does the server listen on/what port the server listens on/


Section 2:  Page 3:   Nit
-------------------------

s/the NETCONF service on the/the NETCONF communication service on the/


Sections 2.1 and 2.3, Pages 3 and 4  Nit
----------------------------------------

s/Since/Because/


Section 2.4.2, Page 4:  Spelling
--------------------------------

s/any of the applications/any of the application's/


Section 2.4.6, Page 5:  Nit
---------------------------

s/aliveness/"aliveness"/


Section 2.4.6, Page 5:  Spelling
--------------------------------

s/applications requirements/applications' requirements/


General comments
----------------

Not sure if all of the groupings would be useful outside of this document.
Some of the groupings have only a single "uses" within the document; e.g.,
call-home-transport-config, call-home-config, etc.  It seems as if this
was done to break up one large config into smaller chunks.  I find this use 
of grouping/uses makes the YANG module more difficult to read and understand 
than if these single-use grouping/users were simply inserted in-line.


Comments on the listen-per-transport-config grouping, Page 12:
--------------------------------------------------------------

Under the description of the address leaf:

    s/IP address\/name/IP address or host name/

Under the port leaf:

    Should this leaf be mandatory, or have a default of 0?


The  listen-per-transport-config  grouping seems roughly like a 
"sockaddr_storage" structure.  An "endpoint", or perhaps a "sockaddr"
or "socket" grouping seems like it would be useful in many YANG
modules beyond this one.

Would it be worthwhile to generalize this grouping, and simplify its
use either by putting it in its own (non-server-specific) YANG module,
or possibly by promoting into a new rev of the ietf-inet-types YANG
module?

Perhaps the following might be a generalized grouping:

     grouping endpoint {
       description
         "Specifies the address and port for a transport endpoint."

       leaf address {
         type inet:host;
         mandatory true;
         description
           "The IP address or host name for the transport endpoint.";
       }

       leaf port {
         type inet:port-number;
         description
           "The port number for the transport endpoint.";
         default 0;
       }
     }  /* grouping endpoint */


Comments on the call-home-per-transport-config grouping, Page 14:
-----------------------------------------------------------------

This grouping seems generally useful beyond the configuration of 
call-home configuration.  It looks like basically like a list of
endpoints, or "sockaddrs".  Perhaps generalizing this and putting it
into the same YANG module with the revised listen-per-transport-config
grouping might simplify its wider use.

I _suspect_ I know the answer to this, but what is the purpose of the
"endpoints" container around the "endpoint" list?

The name leaf seems to serve basically as a key for the list.  Would
it be possible to eliminate this leaf, and use the address and port
leaves as keys?  This would slightly simplify the grouping.   It might
also use the "endpoint" grouping suggested above, and further re-use
definitions.

Perhaps the following might be a generalized grouping?

     grouping endpoints-grouping {
       description
         "Grouping for a list of transport endpoints.";

       container endpoints {
         description
           "Container for the list of endpoints.";

         list endpoint-list {
           key "address port";
           /* min-elements 1;    Necessary or useful if generalized? */
           /* ordered-by user;   Necessary or useful if generalized? */
           description
             "List of transport endpoints."

           uses endpoint;
         }  /* list endpoint-list */
       }    /* container endpoints */
     }      /* grouping endpoints-grouping */


Comments on the listen-config grouping, Page 11:
------------------------------------------------

It seems like the  listen-per-transport-config  could be promoted from
from below each case branch to above the "choice transport".  Does the
name leaf does have a function other than providing a list key?  If the  
listen-per-transport-config  were promoted, then the address and port 
could be used as keys, no?  This would simplify the grouping.  Perhaps
something like:

     grouping listen-config {
       description
         "Grouping for listen configuration.";

       uses endpoint;   /* The new grouping, described above */
       
       choice transport {
         mandatory true;
         description
           "Selects between SSH and TLS transports.";

         case ssh {
           if-feature ssh-listen;
           container ssh {
             description
               "SSH-specific listening configuration for inbound
                connections.";
              refine port {
                 default 830;
              }
           }
         }
         case tls {
           if-feature tls-listen;
           container tls {
             description
               "TLS-specific listening configuration for inbound
                connections.";
             refine port {
               default 6513;
             }
           }
         }
       }
     }

Then, where this grouping is used:

     container netconf-server {
       description
         "Top-level container for NETCONF server configuration.";

       list listen {
         key "address port";

         description
           "List of endpoints to listen for connections on.";
         //if-feature "(ssh-listen or tls-listen)";
         uses listen-config;


Comments on the call-home-connection-type-config grouping, Page 15:
-------------------------------------------------------------------

Under the persistent-connection case, there is a "container persistent"
and, under that, a "container keep-alives".  What is the function of the 
extra containment layer?  Would it make sense to remove one of these 
containment layers?


Comments on the call-home-reconnection-strategy-config grouping, Page 17:
-------------------------------------------------------------------------

What determines the order in which management applications are contacted
by call-home connections?   Is it the  name key  of the  endpoint  list
in the  call-home-per-transport-config  grouping?

How is the  last-connected  reconnection strategy handled across reboots
of devices without stable storage?  Or is the "no stable storage" situ-
ation out-of-scope?


Comments on the trusted-ca-certs-grouping grouping, Page 17:
------------------------------------------------------------

Is it expected that this grouping may be used elsewhere in other YANG
modules?

Is it intended that the  trusted-ca-cert  leaf-list is used for root
(self-signed) CA certs only, or are subordinate CA certs allowed also?

If this leaf-list is intended for self-signed CA certs only, then how
are CA cert chains handled?


Comments on the trusted-client-certs-grouping grouping, Page 17:
----------------------------------------------------------------

What is the purpose of this grouping?  As it is documented, this 
grouping may be unnecessary.  

When a management application connects to the NETCONF Server, either
by forward or reverse (call-home) TLS, the management application
will present an application cert (or cert chain) that identifies it.  
Two things have to happen for the NETCONF Server to authenticate the 
management application:  1)  The application cert presented by the
management application must pass certificate verification up through
one of the CA certs configured (in the NETCONF server) in the 
trusted-ca-certs-grouping, and  2) the NETCONF server must be able 
to convert this application cert to the NETCONF NACM username.  

Based upon the way the TLS authentication works (described in the
previous paragraph), and the description of the trusted-client-certs
container, I don't see what the function of this grouping is.  What
am I missing here?  Should the trusted-client-certs-grouping be
deleted?


Comments on the cert-maps-grouping, Page 19:
--------------------------------------------

The  x509c2n:cert-to-name  grouping defined in the  ietf-x509-cert-to-name  
YANG module defined in  draft-ietf-netmod-snmp-cfg-08.txt  looks fine.


Other comments on the  NETCONF-over-TLS  configuration:
-------------------------------------------------------

When a NETCONF over TLS session is initiated, the NETCONF server must
present an X.509 certificate to the NETCONF client so the client can
verify the identity of the NETCONF server.  I do not see any mechanism 
for configuring an X.509 certificate that identifies the NETCONF server.

Should there be such an object, or is this something that can only be
configured out-of-band, or perhaps only by the manufacturer?



Regards,
--Alan

 ------------------------------------------------------------------------------
 Alan Luchuk               SNMP Research, Inc.          Voice:  [phone]
 Senior Software Engineer  3001 Kimberlin Heights Road  FAX:    [phone]
 luchuk at snmp.com        Knoxville, TN  37920-9716    http://www.snmp.com/
 ------------------------------------------------------------------------------