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

[Kent Watsen <[e-mail]>]

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

Good catch.  Will use "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.

The term "application" is coming from the YANG model, where we have:

   module: ietf-netconf-server
      +--rw netconf-server
         +--rw call-home {call-home}?
            +--rw application* [name]
               ...

My intent was to pick a term that would make sense in GUI and CLI.  But
maybe this is better:

   module: ietf-netconf-server
      +--rw netconf-server
         +--rw call-home {call-home}?
            +--rw netconf-client* [name]
               ...

What do you think?   The term used throughout the draft will fallout from
this.  If we decide to use "application", I will add a proper Terminology
section, per Martin's comment.



>* 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?

What else would you have?  FWIW, RFC 6022 has "netconf-state".

In case it helps, example A.1 shows:

  <netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
    <session-options>...</session-options>
    <listen>...</listen>

    <call-home>...</call-home>
    <ssh>...</ssh>
  </netconf-server>



>* 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?

You can certainly configure that, but the model doesn't support the
NETCONF server being able to only support those specific variations.
This is why I was trying to use the YANG 1.1 style if-feature statements
in -04.  We could use long feature names to cover these specific
variations, but I didn't think it worth the bother.  Do you?



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

That's an oversight, they should all be 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)

Let's apply the resolution to the above comment here as well.



>* sec 3.2:
>
>  - is import by revision needed?

At the time I submitted this draft, it was my understanding that import by
revision was best practice, and that prior YANG modules were in violation.
 Recent YANG 1.1 conformance discussions seem to be swinging the other
direction now, but with potential to swing back again.  I don't know what
to *right* thing to do is.   Perhaps taking it out is the way to go
because, even if it's wrong, it will at least be in the company of other
published modules  ;)


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

Guess not.  I tried twice, but it doesn't seem popular.  I will remove all
groupings that are used only once.


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

This came from a YANG snippet Andy provided.  I'm sure that it's along the
lines of "if more than an hour, it might as well use infinity".
Personally, I don't see a reason to limit it, but I do think that only
having "seconds" units can become unwieldy and thus might suggest a
2-tuple whereby one value is a numeric and the other an enum like
{seconds, minutes, hours, days}.  What do you think?


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

This YANG snippet also came from Andy, but I don't see a reason to limit
it here.   Andy?


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

Yes, this makes sense to me as well, though what happens if we get into
the pathological case of the number of call-home sessions configured is
greater than the configured max-sessions count?  Is there a way to write
a validation expression to test for this?


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

Sounds reasonable.  An alternative might be to have a default to represent
"all configured interfaces" - what do you think?


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

Maybe only mildly useful, but definitely inconsistent to other YANG
modules.  Take it out?



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

Yes.  This is related to comment above as well.



>  - 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?

For all of these, I just figured they were sensible choices.  Do they
seem OK to you?


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

Martin had a similar comment - will clarify in the text


>  - 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?

Interesting point, that a hostname may expand into a list of IPs.  What
makes sense to me is that the list of IPs would be treated as if they were
specified explicitly.  For example, let's say a configured application
(netconf client?) has 3 endpoints (EP1, EP2, and EP3), but they're all
hostnames that expand into two IP addresses, then the netconf server
behavior would be as if it had them configured explicitly: EP1.1, EP1.2,
EP2.1, EP2.2, EP3.1, EP3.2.  That is, with would try EP1.1 count-max times
before trying EP1.2 count-max times, and so on. Does this also make sense
to you?  If so, then I think that it's just a matter of writing it up so
the text spells it out.





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

Maybe, but I wonder if you're saying this after seeing this:

      leaf-list certificate {
        type string;
        min-elements 1;
        description
          "An unordered list of certificates the TLS server can pick
           from when sending its Server Certificate message.  The value
           of the string is the unique identifier for a certificate
           configured on the system.  How valid values are discovered
           is outside the scope of this module, but they are envisioned
           to be the keys for a list of certificates provided
           by another YANG module";
        reference
          "RFC 5246: The TLS Protocol, Section 7.4.2";
      }


Or this?

      leaf-list trusted-ca-cert {
        type binary;
        ordered-by system;
        nacm:default-deny-write;
        description
          "The binary certificate structure as specified by RFC
           5246, Section 7.4.6, i.e.,: opaque ASN.1Cert<1..2^24>;
          ";


The former was by yours truly later was lifted from another draft.  My
plan from Martin's review was to make the former look like the later, but
you think a typedef would be better?



>  - 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?


The binary certs we're copying into the configuration are being used for
client-cert authentication.  Here I'm referring to
/netconf-server/[ssh|tls]/x509/trusted-ca-certs and
/netconf-server/[ssh|tls]/x509/trusted-client-certs.  There is no SSH
equivalent for authenticating clients when the clients use password or key
based authentication, because ietf-system.yang module from 7317 does it
already.  So, yes, there is an asymmetry here, but what can we do?

Separately, there is configuration for what host-keys the SSH-server
presents and what server-certificates the TLS-server presents.  Here I'm
referring to 
/netconf-server/listen/endpoint/[ssh/host-keys|tls/certificates] and
/netconf-server/call-home/application/[ssh/host-keys|tls/certificates].
Currently these are as you say, a named reference to a value presumed to
be configured elsewhere.  The good news is that how this is done is
symmetric for both SSH and TLS.  As for modeling pools of keys, I think
that this is what sever-model-04 had - read-only lists of SSH host-keys
and certificates just so they could be referenced here.  This was
discussed at IETF 91 meeting with the resolution to remove them from this
draft.  This issue was tracked here as well:
https://github.com/netconf-wg/server-model/issues/20.



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

Do you mean between the ietf-netconf-server and ietf-restconf-server
modules?


>  - 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?

It is here, but expired:
https://tools.ietf.org/html/draft-thomson-httpbis-cant-01

I've been discussing with Martin Thomson about it.  I'll probably work
with him in the httpbis WG to resurrect it and get it done.


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

Yes, understood, symmetric changes would be made to both


>* 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?

Er, yes, I think that you're right


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

I didn't know there was such a thing - can you provide a pointer to the
RFC for this?


Thanks,
Kent