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

[Kent Watsen <[e-mail]>]

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

Ack, but that text is broken for the reasons I mentioned true.


> My text is better:
>   - more concise
>   - more accurate
>              - NETCONF supports other transports besides SSH
>              - RESTCONF supports other transports beside TLS
>  
> I suggest fixing rfc8407bis

Please fix the broken text in rfc8704bis.



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

I’m not following you.  The template is broken. 

Also, from IESG Statement: Normative and Informative References <https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-normative-and-informative-references-20060419>:

Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. An informative reference is not normative; rather, it only provides additional information.

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

The template contains broken text.


>    [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 RESTCONF server
> [Med] Please see the note above.

The template contains broken text.


>    [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 seehttps://datatracker.ietf.org/doc/rfc8342/referencedby/.

I’ll grant you that, with the new text, it does seem that RFC8342 should be normative.

FWIW:
	- all of the client-server suite of drafts have RFC8342 as informative.
		- the client-server work predates rfc8704bis
	- since rfc8704bis isn’t published yet, we’re in a grey area.

Nonetheless, I’ll do the right thing, mentioned below:
	I can fix for future drafts, and ask RFC Editor to fix in drafts in their queue.


K.



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