Re: [netconf] comments on Re: I-D Action: draft-ietf-netconf-tcp-client-server-15.txt

[Kent Watsen <[e-mail]>]

Hi Tom,

Thank you for your review of the tcp-client-server draft.
Please see below for my responses to your comments.

PS: you have now reviewed all but one of the suite of
       client-server drafts, with draft-ietf-netconf-trust-anchors
       being the only one not reviewed.  Not that there is an
       expectation, but do you plan to review the trust-anchors
       draft as well?

Kent


> My last attempts to comment on the tcp-client-server got mixed up with those on tls so I send them again with a few additions.

Np


> Should there be a name string for the local/remote configuration of client and server?  I expect to see one in a design document.


It is expected that the importing module will name names where needed.  For example, this snippet is in the restconf-client-server draft:

<restconf-client xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-client">
  <initiate>
    <restconf-server>
      <name>corp-fw1</name>
      <endpoints>
        <endpoint>
          <name>corp-fw1.example.com</name>
          <https>
            <tcp-client-parameters>
              <remote-address>corp-fw1.example.com</remote-address>
              ...
            </tcp-client-parameters>
            ...
        <endpoint>
      <endpoints>
    <restconf-server>
  <initiate>

So here "endpoint" has a name, as does each "restconf-server".  Having another name at the TCP-level would be unwarranted.  Do you agree?



> The language for me is not quite right in several places in e.g. the choice of verb or preposition and we have   had ADs who are rather keen on this, but this is late in the process so I am inclined to let it ride.
> 
> s1.1
>   Hyperlinks to each RFC are provided below the diagram.
> 
> Well, it depends on the format and they are absent in mine.  URL yes, hyperlink no.

This was addressed per a previous comment of yours.  Replaced "Hyperlinks" with "URLs".


> Examples  could do with IPv6, again something that some ADs are keen on.

What are you saying?  Is there a general preference to use IPv6 addresses in examples over IPv4 addresses.  Is this subtle encouragement to transition to IPv6?


> s.3,3
> YANG  features could (always) do with references.  I do not know what proxy-connect is and cannot find it in a TCP RFC.  

refs added.  Description improved.

> Ditto local binding.  

The feature-description seems sufficient.  Are you asking for a reference?  I have no idea, but it goes back to the beginning of IP, as every Socket API I've used has had the ability the specify local bindings for a socket.


> Keepalives are in RFC793 and its replacement and should be referenced since that is a more authoritative source than s.2.1.5 of this I-D IMHO

Added refs to RFC 9293.

>         username/password when initiating TCP connections via
>          and SOCKS Version 5 proxy server.";
> I cannot parse this

Rewritten (both instances)

>            (instead of 'mandatory true') so that as application
> ditto

Rewritten.


>          "The local IP address/interface (VRF?) to bind to for when
> ditto twice

I removed the "(VRF?)" string, but otherwise don't see an issue...?



>    <local-address>10.20.30.40</local-address>
> should be  documentation address

I fixed this issue from your previous comment.  Now 192.0.2.2.


>     <local-port>7777</local-port>
> should be a private port 49152-
> no ports are reserved for documentation

Now 49152 - thanks.


> s.5.1
> Both of these protocols
>   have mandatory-to-implement secure transport layers (e.g., SSH, TLS)
>   with mutual authentication.
> Well the mutual authentication is optional so I think you need something like
> Both of these protocols
>   have mandatory-to-implement secure transport layers (e.g., SSH, TLS);
>  mutual (client?) authentication is optional and SHOULD be configured.

That line regards NETCONF and RESTCONF and, indeed, mutual auth is required for both protocols.

> crypto-types is an import so should be  a Normative reference in the I-D.

Fixed.

K.


> Tom Petch