Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft

[NICK HANCOCK <[e-mail]>]

> -----Original Message-----
> From: Kent Watsen <[e-mail]>
> Sent: 10 April 2019 20:30
> To: NICK HANCOCK <[e-mail]>
> Cc: Mahesh Jethanandani <[e-mail]>; [e-mail]
> Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-
> server draft
> 
> [Even though I do have an HTML-rendering SMTP client, I also found this
> message difficult to read, mostly due to the inline-level not changing.  It took
> me awhile to realize that I have to search for "[Nick]".  I've converted this
> message to plain-text...]

Thanks for the feedback, I'll avoid HTML in the future.

> 
> 
> 
> > You will notice in the latest tcp-client-server update [1] that there is now a
> "presence" statement on the "keepalives" containers.  Do you think any
> more "mandatory true" statements are needed?
> >
> > [Nick] Given that ‘max-probes’ and ‘probe-interval’ are optional in the
> current revision, a client or operator has the option not to configure them.
> Since they are also without default values, the actual behavior after the
> ‘idle–time’ expires would be defined by the specific implementation and not
> by the operator. On the other hand, for the YANG model to specify arbitrary
> default values may not really be helpful to an operator as meaningful values
> would surely depend on the operators specific requirements.
> >
> > Consequently, I believe that all 3 leafs within the container ‘keepalives’
> should be mandatory.
> 
> Fair enough.
> 
> 
> > I don't understand your last comment or, rather, I think it is the case
> already that the TCP keepalives configuration is outside the SSH/TLS
> configuration.  Note the "keepalives" configuration inside the SSH/TLS
> configuration is actually to separately configure keepalives at the SSH/TLS
> levels - makes sense?
> >
> > [Nick] My initial expectation was that since the security layer runs over the
> TCP connections, the tcp-client-parameters would be configured
> independently of the security protocol, i.e., to be found directly under
> ‘endpoint’ and not under ssh or tls.
> 
> Still, I think that this is the case already.  Can you please provide a concrete
> example illustrating the concern?

No real concern. If I read the cases 'ssh' and 'tls' as 'ssh over tcp' 
and 'tls over tcp', it makes sense. Initially the duplication of the 
TCP configuration bugged me.

> 
> 
> 
> Thanks,
> Kent // contributor
> 

Nick