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

[Christian Huitema <[e-mail]>]

Will do. I was really busy with other projects!

On 8/20/2026 2:37 PM, Mahesh Jethanandani wrote:
> 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]
>
>
>
>
>
>
>