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

[[e-mail]]

Hi Kent,

Please see inline.

Cheers,
Med

De : Kent Watsen <[e-mail]>
Envoyé : vendredi 5 avril 2024 15:42
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : [e-mail]
Objet : Re: [netconf] I-D Action: draft-ietf-netconf-tcp-client-server-26.txt

Hi Med,

Thanks for taking a look.
Comments below.

The net-net is that I think we can ask RFC Editor to
tweak the tree-diagram and move the 2119/8174-ref
to the Normative section.

Kent



On Apr 5, 2024, at 1:43 AM, [e-mail]<mailto:[e-mail]> wrote:

Hi Kent,

Thank you for taking care of this.

(1) There is a nit in the tree diagram:

OLD:
      |  +-- local-address?   inet:ip-address

NEW:
      |  +-- local-address   inet:ip-address

I use scripts to build the draft.
These scripts auto-generate a new tree diagram each time...

Is pyang broken?  I’m using the latest (2.6.0)
My command is:
    pyang -f tree --tree-line-length 69 --tree-print-groupings --tree-no-expand-uses ietf-tcp-server@*.yang<mailto:ietf-tcp-server@*.yang>

Running manually I get the same thing.
Removing the “min-elements” has no effect.

Adding a “mandatory true” to the “local-address” leaf fixes
  - but shouldn’t be necessary!

Wrapping the grouping in a “container” also fixes
  - but we’re trying to print a grouping
  - still, it shows inconsistency in pyang

I can either manually edit the XML before submission, or ask RFC Editor to fix…


(2) When going through the text, I see that the security template was not followed, e.g.,

OLD:
   The "ietf-tcp-server" YANG module defines "grouping" statements that
   are designed to be accessed via YANG based management protocols, such
   as NETCONF [RFC6241] and RESTCONF [RFC8040].  Both of these protocols
   have mandatory-to-implement secure transport layers (e.g., SSH, TLS)
   with mutual authentication.

NEW:
   The "ietf-tcp-server" YANG module defines "grouping" statements that
   are designed to be accessed via network management protocols such
   as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
   is the secure transport layer, and the mandatory-to-implement secure
   transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure transport is TLS
   [RFC8446].

rfc8407bis isn’t published yet…
[Med] This is the actual template since 2018! Please see https://wiki.ietf.org/group/ops/yang-security-guidelines

My text is better:
  - more concise
  - more accurate
             - NETCONF supports other transports besides SSH
             - RESTCONF supports other transports beside TLS

I suggest fixing rfc8407bis



+ Add 6242/8446 as normative.

My text does not reference these two RFCs (see above)
  - no update needed.
[Med] It should per “Note: [RFC 8446<https://datatracker.ietf.org/doc/rfc8446/>], [RFC6241<https://datatracker.ietf.org/doc/rfc6241/>], [RFC6242<https://datatracker.ietf.org/doc/rfc6242/>], [RFC8341<https://datatracker.ietf.org/doc/rfc8341/>], and [RFC8040<https://datatracker.ietf.org/doc/rfc8040/>] must be "normative references" from the template.


(4) Idem for 5.2, 5.3

ACK, but see above.


(5) Also, at least the following should be moved to be listed as Normative:

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

IMO, understanding this RFC isn’t required to implement this document.
  - e.g., server only needs to know what the namespace is, which is defined in this document



   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

IMO, understanding this RFC isn’t required to implement this document.
  - e.g., implementation may not be a NETCONF server
[Med] Please see the note above



   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

IMO, understanding this RFC isn’t required to implement this document.
  - e.g., implementation may not be a NETCONF server
[Med] Please see the note above.



   [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "Network Management Datastore Architecture
              (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
              <https://www.rfc-editor.org/info/rfc8342>.

IMO, understanding this RFC isn’t required to implement this document.
  - e.g., only servers implementing NMDA care, right?
[Med] I also cited it as informative in few RFCs (RFC9181/RFC9408), but when I started the work in the bis, I convinced myself that it is normative for the simple reason that the statement can’t be assessed without know what NDMA is about. It seems that few of us went for informative vs. normative: Please see https://datatracker.ietf.org/doc/rfc8342/referencedby/.



I think the same ref issue applies for the other documents in the set. For some of them (e.g., draft-ietf-netconf-keystore), the following should be moved to the normative list as well:

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

This is probably true.

Note that *this* draft has 2119/8174 in the Normative section.

I can fix for future drafts, and ask RFC Editor to drafts in their queue.



Apologies for not reporting this earlier as I was not following these doc.

Thank you.

No worries and thank you!

Kent



Cheers,
Med

De : netconf <[e-mail]<mailto:[e-mail]>> De la part de Kent Watsen
Envoyé : jeudi 4 avril 2024 23:01
À : [e-mail]<mailto:[e-mail]>
Objet : Re: [netconf] I-D Action: draft-ietf-netconf-tcp-client-server-26.txt


Dear WG,

-25 reflects what I sent for review last week.
-26 just adds a “min-elements 1” statement to the local-bind list to ensure at least one is configured.

The -26 update is safe as [1] says:

              o  A leaf-list or list node may get a different "min-elements" or
                  "max-elements" statement.

Which means consuming models can still adjust the min-elements value as needed.

[1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.13.2

Kent // author





On Apr 4, 2024, at 4:53 PM, [e-mail]<mailto:[e-mail]> wrote:

Internet-Draft draft-ietf-netconf-tcp-client-server-26.txt is now available.
It is a work item of the Network Configuration (NETCONF) WG of the IETF.

  Title:   YANG Groupings for TCP Clients and TCP Servers
  Authors: Kent Watsen
           Michael Scharf
  Name:    draft-ietf-netconf-tcp-client-server-26.txt
  Pages:   39
  Dates:   2024-04-04

Abstract:

  This document presents three YANG 1.1 modules to support the
  configuration of TCP clients and TCP servers.  The modules include
  basic parameters of a TCP connection relevant for client or server
  applications, as well as client configuration required for traversing
  proxies.  The modules can be used either standalone or in conjunction
  with configuration of other stack protocol layers.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-netconf-tcp-client-server-26.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netconf-tcp-client-server-26

Internet-Drafts are also available by rsync at:
rsync.ietf.org<http://rsync.ietf.org/>::internet-drafts


_______________________________________________
netconf mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf


____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.