Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9900.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1.Introduction

The "Service Name and Transport Protocol Port Number Registry"[IANA-SERVICE] records several NETCONF-related port and service name assignmentssuch as 830 for NETCONF over Secure Shell (SSH)[RFC6242], 831 for NETCONF over the Blocks Extensible Exchange Protocol (BEEP)[RFC4744],832 for NETCONF over the Simple Object Access Protocol (SOAP)[RFC4743], 4334 for NETCONF Call Home[RFC8071],and 6513 for NETCONF over Transport Layer Security (TLS)[RFC7589][NETCONF-over-TLS].¶

However, three of these assignments (831, 832, and 833) are for protocols that are not deployed, and the relevant RFCs ([RFC4743] and[RFC4744]) have been marked Historic. All these assignments are thus no longer required to support these services.¶

This document de-assigns these unused port numbers.¶

Consistent withSection 8.2 of [RFC6335], this document does not de-assign service names; only port numbers are de-assigned for better usage of available scarce resources.¶

2.Operational Considerations

There are no known implementations and deployments of protocols that rely upon the port numbers released back by this document.¶

Existing configurations (if any) that associate the released port numbers with the service names "netconf-beep" and "netconfsoaphttp" need to be reassessed and updated according to the actions inSection 4.¶

Other than that, there are no new operations or manageability requirements introduced by this document.¶

3.Security Considerations

This document does not describe any protocol. As such, this document does not introduce any new security vulnerability.¶

4.IANA Considerations

Per this document, IANA has updated the "Service Name and Transport Protocol Port Number Registry"[IANA-SERVICE] as specified in the following subsections.¶

De-assigned allocations are marked perSection 8.2 of [RFC6335]. These actions are not repeated here.¶

5.References

Acknowledgments

Thanks toAmanda Baber andZahed Sarker for the guidance. Thanks toTom Petch for the comments.¶

Thanks toKent Watsen for the Shepherd review,Mahesh Jethanandani for the AD review,Bernie Volz for the INTDIR review,Roni Even for Gen-ART review,Barry Leiba for ARTART review,Dhruv Dhody for the OPSDIR review,Michael Tüxen for TSVART review, andJoe Touch for the port review.¶

Thanks toGorry Fairhurst for the IESG review.¶

Author's Address