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

[Christian Huitema <[e-mail]>]

I did not find how to update a review in the datatracker review page 
https://datatracker.ietf.org/doc/review-ietf-netconf-yp-transport-capabilities-06-secdir-lc-huitema-2026-08-07/, 
and thus I am sending this via e-mail.

First, I want to thank the authors for the work they did to improve the 
draft. My feedback on draft 06 was that terminology and references were 
a bit loose, and that a reader like me, not familiar with the working 
group, had trouble discerning how the proposed Yang module would be 
used. Draft 07 answers all these issue. The introduction makes it easy 
to understand the context, the terminology section clears ambiguities 
around words like "transport", the capabilities section explains the 
role of the orchestrator. I have no strong opinion about the actual YML 
syntax, but I do appreciate the mention that DTLS 1.2 is not recommended 
anymore, pushing for use of DTLS 1.3.

The security section follows the template suggested in RFC 9907, and is 
fine.

I think the document is now ready.

-- Christian Huitema

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