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

[Christian Huitema <[e-mail]>]

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://author-tools.ietf.org/diff?doc_1=draft-ietf-netconf-yp-transport-capabilities-06&url_2=https://raw.githubusercontent.com/network-analytics/draft-netana-netconf-yang-push-transport-capabilities/refs/heads/main/draft-ietf-netconf-yp-transport-capabilities-07.txt 
> <https://author-tools.ietf.org/diff?doc_1=draft-ietf-netconf-yp-transport-capabilities-06&url_2=https://raw.githubusercontent.com/network-analytics/draft-netana-netconf-yang-push-transport-capabilities/refs/heads/main/draft-ietf-netconf-yp-transport-capabilities-07.txt>
>
> And the document: 
> https://github.com/network-analytics/draft-netana-netconf-yang-push-transport-capabilities/blob/main/draft-ietf-netconf-yp-transport-capabilities-07.txt
>
> 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://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#name-secured-layer-for-udp-notif)
>
>>
>> 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]
>
>