[secdir] Re: [Last-Call] [netconf] draft-ietf-netconf-yp-transport-capabilities-06 ietf last call Secdir review

[Mahesh Jethanandani <[e-mail]>]

Hi Christian,

Let me know if this update addresses your comments, and that you would be willing to update your review.

Thanks.

> On Aug 17, 2026, at 1:29 AM, [e-mail] wrote:
> 
> Dear Christian,
> 
> I just submitted -07 to datatracker: https://datatracker.ietf.org/doc/draft-ietf-netconf-yp-transport-capabilities/07/
> 
> Apologies for the confusion.
> 
> Regards,
> Alex
> 
>> On 14 Aug 2026, at 17:48, Christian Huitema <[e-mail]> wrote:
>> 
>> Did you actually submit draft 07? I did not find it yesterday in the IETF data tracker.
>> 
>> -- Christian  Huitema
>> 
>> On 8/13/2026 4:57 AM, Alex.Huang-Feng=[e-mail] wrote:
>>> Dear Christian,
>>> 
>>> Thanks for the review.
>>> 
>>> We addressed these comments in -07.
>>> 
>>> Please find the diff in: https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fdiff%3Fdoc_1%3Ddraft-ietf-netconf-yp-transport-capabilities-06%26url_2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fnetwork-analytics%2Fdraft-netana-netconf-yang-push-transport-capabilities%2Frefs%2Fheads%2Fmain%2Fdraft-ietf-netconf-yp-transport-capabilities-07.txt&data=05%7C02%7CAlex.Huang-Feng%40t-systems.com%7C3be8c5606359441ae3ab08defa1b9b64%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C639223194739836714%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=3URe%2B0Fbnb%2BdKUVwYqlcBVKN%2B49%2FmjXOxWXL%2FGAaSdc%3D&reserved=0 <https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fdiff%3Fdoc_1%3Ddraft-ietf-netconf-yp-transport-capabilities-06%26url_2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fnetwork-analytics%2Fdraft-netana-netconf-yang-push-transport-capabilities%2Frefs%2Fheads%2Fmain%2Fdraft-ietf-netconf-yp-transport-capabilities-07.txt&data=05%7C02%7CAlex.Huang-Feng%40t-systems.com%7C3be8c5606359441ae3ab08defa1b9b64%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C639223194739852733%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=p1JlVxSUTJEWny3mMAhN43tErhOoSHgwZzqJfIBzfdY%3D&reserved=0>
>>> 
>>> And the document: https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnetwork-analytics%2Fdraft-netana-netconf-yang-push-transport-capabilities%2Fblob%2Fmain%2Fdraft-ietf-netconf-yp-transport-capabilities-07.txt&data=05%7C02%7CAlex.Huang-Feng%40t-systems.com%7C3be8c5606359441ae3ab08defa1b9b64%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C639223194739862995%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=sNqNfGDxjkKKAXH28wywnp4qqvED0RESVgf2WRPR5e8%3D&reserved=0
>>> 
>>> Please see inline.
>>> 
>>>> On 8 Aug 2026, at 02:58, Christian Huitema via Datatracker <[e-mail]> wrote:
>>>> 
>>>> Document: draft-ietf-netconf-yp-transport-capabilities
>>>> Title: YANG Notification Transport Capabilities
>>>> Reviewer: Christian Huitema
>>>> Review result: Not Ready
>>>> 
>>>> I have reviewed draft-ietf-netconf-yp-transport-capabilities-06
>>>> as part of the security directorate's ongoing effort to review all
>>>> IETF documents being processed by the IESG. Theses comments were written
>>>> primarily for the benefit of the security area directors. Document editors and
>>>> WG chairs should treat these comments just like any other last call comments.
>>>> 
>>>>  The summary of the review is Not Ready.
>>>> 
>>>> I find this document confusingbecause it uses generic terms like "server"
>>>> or "transport" outside of the general understanding of these terms in IETF RFCs.
>>>> 
>>>> Let's start with the introduction: The "ietf-system-capabilities" YANG module
>>>> defined in [RFC9196] allows a client to discover a set of capabilities
>>>> supported by a server (including, basic system capabilities and YANG-Push
>>>> related capabilities) both at implementation time and at runtime. OK. What kind
>>>> of server are we speaking about? A web server? An SMTP server? A server
>>>> implementing protocols like NETCONF? A VPN server? Capabilities of servers tend
>>>> to be very dependent on the type of application that the server is
>>>> implementing. The split of functions between client and servers is also very
>>>> dependent on the application. For example, a recursive DNS server is both a
>>>> server for stub DNS resolvers and a client to authoritative DNS resolvers.
>>>> 
>>>> If we mean any server on the Internet, then the review could just as well stop
>>>> here. The concept of a unifying model for all Internet nodes that happen to
>>>> accept a request and do something for another node is just silly.
>>>> 
>>>> If we mean specialized servers used in network management such as NETCONF or
>>>> RESTCONF, the draft should say so.
>>> Yes, we meant NETCONF/RESTCONF server.
>>> 
>>> We changed the wording throughout the document to refer to the NETCONF/RESTCONF client/server explicitly.
>>> Additionally, note we have client/server definitions in the terminology section where we refer to RFC8342 for their definitions.
>>> 
>>> These changes can be found in the abstract, introduction and section 2.
>>>> 
>>>> Let's continue with the second paragraph of the introduction, the notion of
>>>> transport protocol. At the lowest level, mentioning transport protocols on the
>>>> Internet means something like TCP, UDP or QUIC. But then, the examples go on to
>>>> include TLS, DTLS. I suspect that the authors' cocnept of what "transport"
>>>> means is different from the regular understanding in, say, the IETF Web and
>>>> Internet Transport Area. Again, it would be nice if the draft was rewritten to
>>>> explain what is mean here by "transport", and if possible pick another name.
>>> Good point. I changed the wording to "notification delivery protocol”. I also added the term “transport protocol” in the terminology section to specify that we refer to the protocol used to deliver notifications between a publisher and a receiver.
>>> As this term comes from RFC8639, we refrain from changing it in the YANG module.
>>>> 
>>>> The draft goes on to differentiate between TLS 1.2 and TLS 1.3, DTLS 1.2 and
>>>> DTLS 1.3, which seems wrong. TLS 1.3 is defined in RFC 9846, which obsoletes
>>>> older RFCa including RFC 5246 (TLS 1.2) and RFC 8446 (the original
>>>> specification of TLS 1.3). RFC 6347 (DTLS 1.2) is obsoleted by RFC 9147 (DTLS
>>>> 1.3). The draft should not make normative references to RFCs that are obsolete.
>>>> I do not think that the draft should differentiate "identity dtls12" and
>>>> "identity dtls13" -- these are just two version of the same protocol, that
>>>> certainly do not change the "identity" of the server.
>>> Such modelling was agreed by the WG and YANG doctors. The use of identities directly rather than the protocol and its version is because it would allow future users/developers to directly augment such YANG identities.
>>> RFC9645 already uses this structure and we followed for consistency.
>>> 
>>> Regarding referencing obsoleted RFCs as normative is because we define those identities. Shall we move these obsoleted references to informative?
>>>> 
>>>> I can understand the need to provide the list of supported
>>>> TLS or DTLS versions for management purposes, but this should be achieved by
>>>> something like a supported version parameter. The TLS and DTLS negotiations
>>>> include the capability of "negotiating down" from [D]TLS 1.3 to [D]TLS 1.2, if
>>>> the server and the client are specifically configured to tolerate such
>>>> downgrade. Maybe that acceptance or refusal of downgrade should be documented
>>>> in the YML text?
>>> The current document is not recommending any version of TLS or DTLS. The scope of the document is rather providing the NETCONF/RESTCONF server the capability to advertise what it supports for the notification delivery protocols, it does not define which protocols should be configured.
>>> 
>>> Recommendations about which version to use are defined in their respective transport protocols (e.g. https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-udp-notif%23name-secured-layer-for-udp-notif&data=05%7C02%7CAlex.Huang-Feng%40t-systems.com%7C3be8c5606359441ae3ab08defa1b9b64%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C639223194739872646%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=yRj649kRFHC97PXr72mH%2BIa%2BE20QpSoJ7rFJVrQGGDA%3D&reserved=0)
>>> 
>>>> 
>>>> I also do not really understand the relation between this "transport capability"
>>>> description and the "HTTPS" or "CSVRV" DNS records that clients use to
>>>> determine how to contact a server. Maybe that should be explained? Are clients
>>>> expected to retrieve the YML description of the server before establishing a
>>>> connection? It is pretty hard to review the security properties of this
>>>> proposal without understanding its planned usage.
>>> The intended usage of this model is between an orchestrator and a network device. Such network is configured beforehand by an operator and is typically dedicated to exchange configuration information.
>>> We added the following paragraph, helping the reader about the expected usage:
>>> 
>>>    This model is intended to be used between an orchestrator and a
>>>    network device that provides YANG notifications.  A management
>>>    network between the orchestrator and the network device is assumed to
>>>    be available for exchanging YANG management information.  The
>>>    management connectivity and endpoint of the network device are
>>>    expected to be provisioned as part of the management network
>>>    configuration.  The orchestrator can use the established management
>>>    connection to discover the notification transport capabilities of the
>>>    network device before establishing the notification subscription.
>>> 
>>> I hope this text makes the document clearer.
>>> 
>>> Regards,
>>> Alex
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> netconf mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>> 
>>> 
> 


Mahesh Jethanandani
[e-mail]