Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Mar 03, 2015 at 10:16:21PM +0000, Ersue, Mehmet (Nokia - DE/Munich) wrote:
> Dear NETCONF WG,
> 
> we hereby issue a WG Last Call for 2 weeks for the drafts below:
> 
> https://tools.ietf.org/html/draft-ietf-netconf-call-home-04
> https://tools.ietf.org/html/draft-ietf-netconf-server-model-06
> 
> Please review and send your comments to the NETCONF WG mailing list by March 17, 2015 EOB PT.
>

Here is my review of draft-ietf-netconf-server-model-06:

* sec 2.4: What is 'TLS _transport-level_ authentication'? Why not
  just use 'TLS authentication' or perhaps even clearer 'TLS client
  authentication'?

* sec 2.6: Do we really need 'northbound application' terminology? Why
  not call it simply a NETCONF/RESTCONF client? There might also be
  possible confusion with phrases such as "Assuming an application has
  more than one server" - the server here seems to be the NETCONF
  client to call home to. Anyway, if we do need new terminology, I
  think we should properly define it to avoid any confusion.

* sec 3: Is it a good idea to name the top-level node netconf-server?
  Is this name consistent with how we name other things?

* sec 3: Can I have a server listening for SSH and accepting call home
  over TLS? Would features work out in such a case or would such a
  server make a client believe that the server is also allowing call
  home via SSH and incoming connections via TLS?
   
* sec 3.1.4: s/when RFC 6187 is supported/when X.509v3 certificates for SSH are supported [RFC6187]/

* sec 3: Are certificates sometimes represented as strings and
  sometimes represented as binary?

* sec 4: Is it a good idea to name the top-level node restconf-server?
  Is this name consistent with how we name other things? (see also above)

* sec 3.2: also mention that the module imports an extension from [RFC6536].

* sec 3.2:

  - is import by revision needed?

  - s/supports RFC 6187/supports X.509v3 certificates for SSH authentication/

  - Are groupings useful that are only used once? Are they really
    improving readability?

  - s/issuing RPC requests/carrying any NETCONF messages/

  - is there any motivation for the upper bounds of hello-timeout and
    idle-timeout?

  - better description for 'listen'?

  - is there a motivation for the upper bound of max-sessions?

  - why is max-sessions part of the listen subtree? do call home
    sessions count in here as well? it seems that max-session may be
    another global session parameter

  - neither address nor port are mandatory for a listening endpoint;
    since the port has a default, should address be mandatory?

  - is it useful to reference the RFC itself in a reference clause of
    a specific leaf (e.g., 'keep-alives' given that there is a
    'global' reference to the RFC? Probably it is useful since it
    references a specific section but then the section references
    does not make much sense...

  - better description for 'call-home'?

  - The description of 'application' talks about NETCONF clients, so
    application == NETCONF clients?

  - is there a motivation for the 15 seconds default for the call home
    keep alive timer?

  - is there a motivation for 30 seconds default linger time and 5
    minutes default reconnect time?

  - What is the meaning of "NETCONF servers SHOULD support this flag
    across reboots."? Perhaps it is clearer if the text said "NETCONF
    servers SHOULD be able to remember the last endpoint connected to
    across reboots".

  - how do interval-secs and count-max work for reconnect-strategy if
    an endpoint resolves to multiple IP addresses? Does the
    interval-secs apply every address of an endpoint or to all
    addresses of an endpoint? Does count-max increment for each
    address of an endpoint or just once for a given endpoint?

  - would it make sense to introduce a typedef for the X509
    certificates?

  - for certs, we copy binary certs into the config but for ssh host
    keys, we reference them using some strings that act as unique
    identifiers into an undefined pool of host keys. This is somewhat
    asymmetric and how do I configure a host-key without knowing which
    host keys the box has available? The problem likely is that we
    lack a generic infrastructure for managing SSH and TLS
    credentials. But would the approach to model pools of keys not be
    the more practical solution?

* sec 4.2: also	mention that the module imports an extension from [RFC6536].

* sec 4.2:

  - is import by revision needed?

  - would it not make sense to factor out some common groupings so
    that things can be reused instead of being defined multiple times?

  - what is "RFC ZZZZ: Client Authentication over New TLS Connection"?
    the editor instructions refer to draft-thomson-httpbis-cant but
    this one does not exist anymore?

  - several of the comments for the netconf server module also apply
    to the restconf server module - I am not repeating them here,
    assuming that any changes will be applied consistently anyway

* sec 5: remove the first sentence?

* sec 5.2: is this document the right place to require (MUST) that
  call home servers advertise "peer_allowed_to_send" per [RFC6520]?
  If this is a general requirement, should it not be in the call home
  document?

* sec 6: the 2nd paragraph should also refer to ietf-restconf-server

* sec 6: there may be more that is worth saying, e.g., that
  misconfigured call home server could be used to DDOS some other
  victim by repeatedly connecting and starting a TLS conversation.

* sec A: please use IP addresses reserved for documentation in the
  examples.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>