idnits 2.17.1
draft-ietf-netconf-tcp-client-server-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 123 has weird spacing: '...address ine...'
== Line 130 has weird spacing: '...nterval uin...'
== Line 315 has weird spacing: '...nterval uin...'
== Line 317 has weird spacing: '...address ine...'
== Line 510 has weird spacing: '...nterval uin...'
== (1 more instance...)
-- The document date (June 7, 2019) is 1778 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 NETCONF Working Group K. Watsen
3 Internet-Draft Watsen Networks
4 Intended status: Standards Track M. Scharf
5 Expires: December 9, 2019 Hochschule Esslingen
6 June 7, 2019
8 YANG Groupings for TCP Clients and TCP Servers
9 draft-ietf-netconf-tcp-client-server-01
11 Abstract
13 This document defines three YANG modules: the first defines a
14 grouping for configuring a generic TCP client, the second defines a
15 grouping for configuring a generic TCP server, and the third defines
16 a grouping common to the TCP clients and TCP servers.
18 Editorial Note (To be removed by RFC Editor)
20 This draft contains many placeholder values that need to be replaced
21 with finalized values at the time of publication. This note
22 summarizes all of the substitutions that are needed. No other RFC
23 Editor instructions are specified elsewhere in this document.
25 Artwork in this document contains placeholder values for the date of
26 publication of this draft. Please apply the following replacement:
28 o "2019-06-07" --> the publication date of this draft
30 The following Appendix section is to be removed prior to publication:
32 o Appendix A. Change Log
34 Status of This Memo
36 This Internet-Draft is submitted in full conformance with the
37 provisions of BCP 78 and BCP 79.
39 Internet-Drafts are working documents of the Internet Engineering
40 Task Force (IETF). Note that other groups may also distribute
41 working documents as Internet-Drafts. The list of current Internet-
42 Drafts is at https://datatracker.ietf.org/drafts/current/.
44 Internet-Drafts are draft documents valid for a maximum of six months
45 and may be updated, replaced, or obsoleted by other documents at any
46 time. It is inappropriate to use Internet-Drafts as reference
47 material or to cite them other than as "work in progress."
48 This Internet-Draft will expire on December 9, 2019.
50 Copyright Notice
52 Copyright (c) 2019 IETF Trust and the persons identified as the
53 document authors. All rights reserved.
55 This document is subject to BCP 78 and the IETF Trust's Legal
56 Provisions Relating to IETF Documents
57 (https://trustee.ietf.org/license-info) in effect on the date of
58 publication of this document. Please review these documents
59 carefully, as they describe your rights and restrictions with respect
60 to this document. Code Components extracted from this document must
61 include Simplified BSD License text as described in Section 4.e of
62 the Trust Legal Provisions and are provided without warranty as
63 described in the Simplified BSD License.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
69 3. The TCP Client Model . . . . . . . . . . . . . . . . . . . . 3
70 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3
71 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 3
72 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 4
73 4. The TCP Server Model . . . . . . . . . . . . . . . . . . . . 7
74 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 7
75 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 7
76 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8
77 5. The TCP Common Model . . . . . . . . . . . . . . . . . . . . 11
78 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 11
79 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 12
80 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 12
81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
83 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 16
84 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 16
85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
86 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
87 8.2. Informative References . . . . . . . . . . . . . . . . . 17
88 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18
89 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 18
90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
92 1. Introduction
94 This document defines three YANG 1.1 [RFC7950] modules: the first
95 defines a grouping for configuring a generic TCP client, the second
96 defines a grouping for configuring a generic TCP server, and the
97 third defines a grouping common to the TCP clients and TCP servers.
99 It is intended that these groupings will be used either standalone,
100 for TCP-based protocols, as part of a stack of protocol-specific
101 configuration models. For instance, these groupings could help
102 define the configuration module for SSH, TLS, or HTTP based
103 applications.
105 2. Terminology
107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
109 "OPTIONAL" in this document are to be interpreted as described in BCP
110 14 [RFC2119] [RFC8174] when, and only when, they appear in all
111 capitals, as shown here.
113 3. The TCP Client Model
115 3.1. Tree Diagram
117 This section provides a tree diagram [RFC8340] for the "ietf-tcp-
118 client" module.
120 module: ietf-tcp-client
122 grouping tcp-client-grouping
123 +-- remote-address inet:host
124 +-- remote-port? inet:port-number
125 +-- local-address? inet:ip-address {local-binding-supported}?
126 +-- local-port? inet:port-number {local-binding-supported}?
127 +-- keepalives! {keepalives-supported}?
128 +-- idle-time uint16
129 +-- max-probes uint16
130 +-- probe-interval uint16
132 3.2. Example Usage
134 This section presents an example showing the tcp-client-grouping
135 populated with some data.
137
138 www.example.com
139 443
140 0.0.0.0
141 0
142
143 15
144 3
145 30
146
147
149 3.3. YANG Module
151 The ietf-tcp-client YANG module references [RFC6991].
153 file "ietf-tcp-client@2019-06-07.yang"
154 module ietf-tcp-client {
155 yang-version 1.1;
156 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client";
157 prefix tcpc;
159 import ietf-inet-types {
160 prefix inet;
161 reference
162 "RFC 6991: Common YANG Data Types";
163 }
165 import ietf-tcp-common {
166 prefix tcpcmn;
167 reference
168 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
169 }
171 organization
172 "IETF NETCONF (Network Configuration) Working Group and the
173 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
175 contact
176 "WG Web:
177
178 WG List:
179
180 Authors: Kent Watsen
181 Michael Scharf
182 ";
184 description
185 "This module defines reusable groupings for TCP clients that
186 can be used as a basis for specific TCP client instances.
188 Copyright (c) 2019 IETF Trust and the persons identified
189 as authors of the code. All rights reserved.
191 Redistribution and use in source and binary forms, with
192 or without modification, is permitted pursuant to, and
193 subject to the license terms contained in, the Simplified
194 BSD License set forth in Section 4.c of the IETF Trust's
195 Legal Provisions Relating to IETF Documents
196 (https://trustee.ietf.org/license-info).
198 This version of this YANG module is part of RFC XXXX
199 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
200 itself for full legal notices.;
202 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
203 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
204 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
205 are to be interpreted as described in BCP 14 (RFC 2119)
206 (RFC 8174) when, and only when, they appear in all
207 capitals, as shown here.";
209 revision 2019-06-07 {
210 description
211 "Initial version";
212 reference
213 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
214 }
216 // Features
218 feature local-binding-supported {
219 description
220 "Indicates that the server supports configuring local bindings,
221 the 'local-address' and 'local-port' nodes.";
222 }
224 feature tcp-client-keepalives {
225 description
226 "Per socket TCP keepalive parameters are configurable for
227 TCP clients on the server implementing this feature.";
228 }
230 // Groupings
232 grouping tcp-client-grouping {
233 description
234 "A reusable grouping for configuring a TCP client.
236 Note that this grouping uses fairly typical descendent
237 node names such that a stack of 'uses' statements will
238 have name conflicts. It is intended that the consuming
239 data model will resolve the issue (e.g., by wrapping
240 the 'uses' statement in a container called
241 'tcp-client-parameters'). This model purposely does
242 not do this itself so as to provide maximum flexibility
243 to consuming models.";
245 leaf remote-address {
246 type inet:host;
247 mandatory true;
248 description
249 "The IP address or hostname of the remote peer to
250 establish a connection with. If a domain name is
251 configured, then the DNS resolution should happen on
252 each connection attempt. If the the DNS resolution
253 results in multiple IP addresses, the IP addresses
254 are tried according to local preference order until
255 a connection has been established or until all IP
256 addresses have failed.";
257 }
258 leaf remote-port {
259 type inet:port-number;
260 default "0";
261 description
262 "The IP port number for the remote peer to establish a
263 connection with. An invalid default value (0) is used
264 (instead of 'mandatory true') so that as application
265 level data model may 'refine' it with an application
266 specific default port number value.";
267 }
268 leaf local-address {
269 if-feature "local-binding-supported";
270 type inet:ip-address;
271 description
272 "The local IP address/interface (VRF?) to bind to for when
273 connecting to the remote peer. INADDR_ANY ('0.0.0.0') or
274 INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to
275 explicitly indicate the implicit default, that the server
276 can bind to any IPv4 or IPv6 addresses, respectively.";
277 }
278 leaf local-port {
279 if-feature "local-binding-supported";
280 type inet:port-number;
281 default "0";
282 description
283 "The local IP port number to bind to for when connecting
284 to the remote peer. The port number '0', which is the
285 default value, indicates that any available local port
286 number may be used.";
287 }
288 uses tcpcmn:tcp-connection-grouping {
289 augment "keepalives" {
290 if-feature "tcp-client-keepalives";
291 description
292 "Add an if-feature statement so that implementations
293 can choose to support TCP client keepalives.";
294 }
295 }
296 }
297 }
298
300 4. The TCP Server Model
302 4.1. Tree Diagram
304 This section provides a tree diagram [RFC8340] for the "ietf-tcp-
305 server" module.
307 module: ietf-tcp-server
309 grouping tcp-server-grouping
310 +-- local-address inet:ip-address
311 +-- local-port? inet:port-number
312 +-- keepalives! {keepalives-supported}?
313 | +-- idle-time uint16
314 | +-- max-probes uint16
315 | +-- probe-interval uint16
316 +-- external-endpoint-values! {external-endpoints}?
317 +-- address inet:ip-address
318 +-- port? inet:port-number
320 4.2. Example Usage
322 This section presents an example showing the tcp-server-grouping
323 populated with some data.
325
326 10.20.30.40
327 7777
328
329 15
330 3
331 30
332
333
335 4.3. YANG Module
337 The ietf-tcp-server YANG module references [RFC6991].
339 file "ietf-tcp-server@2019-06-07.yang"
340 module ietf-tcp-server {
341 yang-version 1.1;
342 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server";
343 prefix tcps;
345 import ietf-inet-types {
346 prefix inet;
347 reference
348 "RFC 6991: Common YANG Data Types";
349 }
351 import ietf-tcp-common {
352 prefix tcpcmn;
353 reference
354 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
355 }
357 organization
358 "IETF NETCONF (Network Configuration) Working Group and the
359 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
361 contact
362 "WG Web:
363
364 WG List:
365
366 Authors: Kent Watsen
367 Michael Scharf
368 ";
370 description
371 "This module defines reusable groupings for TCP servers that
372 can be used as a basis for specific TCP server instances.
374 Copyright (c) 2019 IETF Trust and the persons identified
375 as authors of the code. All rights reserved.
377 Redistribution and use in source and binary forms, with
378 or without modification, is permitted pursuant to, and
379 subject to the license terms contained in, the Simplified
380 BSD License set forth in Section 4.c of the IETF Trust's
381 Legal Provisions Relating to IETF Documents
382 (https://trustee.ietf.org/license-info).
384 This version of this YANG module is part of RFC XXXX
385 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
386 itself for full legal notices.;
388 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
389 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
390 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
391 are to be interpreted as described in BCP 14 (RFC 2119)
392 (RFC 8174) when, and only when, they appear in all
393 capitals, as shown here.";
395 revision 2019-06-07 {
396 description
397 "Initial version";
398 reference
399 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
400 }
402 // Features
404 feature tcp-server-keepalives {
405 description
406 "Per socket TCP keepalive parameters are configurable for
407 TCP servers on the server implementing this feature.";
408 }
410 feature external-endpoints {
411 description
412 "Per socket TCP keepalive parameters are configurable for
413 TCP servers on the server implementing this feature.";
414 }
416 // Groupings
418 grouping tcp-server-grouping {
419 description
420 "A reusable grouping for configuring a TCP server.
422 Note that this grouping uses fairly typical descendent
423 node names such that a stack of 'uses' statements will
424 have name conflicts. It is intended that the consuming
425 data model will resolve the issue (e.g., by wrapping
426 the 'uses' statement in a container called
427 'tcp-server-parameters'). This model purposely does
428 not do this itself so as to provide maximum flexibility
429 to consuming models.";
430 leaf local-address {
431 type inet:ip-address;
432 mandatory true;
433 description
434 "The local IP address to listen on for incoming
435 TCP client connections. INADDR_ANY (0.0.0.0) or
436 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be
437 used when the server is to listen on all IPv4 or
438 IPv6 addresses, respectively.";
439 }
440 leaf local-port {
441 type inet:port-number;
442 default "0";
443 description
444 "The local port number to listen on for incoming TCP
445 client connections. An invalid default value (0)
446 is used (instead of 'mandatory true') so that an
447 application level data model may 'refine' it with
448 an application specific default port number value.";
449 }
450 uses tcpcmn:tcp-connection-grouping {
451 augment "keepalives" {
452 if-feature "tcp-server-keepalives";
453 description
454 "Add an if-feature statement so that implementations
455 can choose to support TCP server keepalives.";
456 }
457 }
458 container external-endpoint-values {
459 if-feature external-endpoints;
460 presence
461 "Indicates that external endpoint values are configured.";
462 description
463 "External endpoint values described the values used by
464 an external system that terminates connections before
465 passing them onto server. Such systems may include,
466 e.g., a network address translator (NAT) or a load
467 balancer (LB).
469 These values have no effect on the local operation of
470 this server, but MAY be used by the application when
471 sending messages including response contact information
472 (e.g., URL).";
473 leaf address {
474 type inet:ip-address;
475 mandatory true;
476 description
477 "The external IP address used to listen for incoming
478 TCP client connections that are forwarded to this
479 server.";
480 }
481 leaf port {
482 type inet:port-number;
483 default "0";
484 description
485 "The external port number used to listen for incoming
486 TCP client connections that are forwarded to this
487 server. An invalid default value (0) is used (instead
488 of 'mandatory true') so that an application level data
489 model may 'refine' it with an application specific
490 default port number value.";
491 }
492 }
493 }
494 }
495
497 5. The TCP Common Model
499 5.1. Tree Diagram
501 This section provides a tree diagram [RFC8340] for the "ietf-tcp-
502 common" module.
504 module: ietf-tcp-common
506 grouping tcp-common-grouping
507 +-- keepalives! {keepalives-supported}?
508 +-- idle-time uint16
509 +-- max-probes uint16
510 +-- probe-interval uint16
511 grouping tcp-connection-grouping
512 +-- keepalives! {keepalives-supported}?
513 +-- idle-time uint16
514 +-- max-probes uint16
515 +-- probe-interval uint16
517 5.2. Example Usage
519 This section presents an example showing the tcp-common-grouping
520 populated with some data.
522
523
524 15
525 3
526 30
527
528
530 5.3. YANG Module
532 The ietf-tcp-common YANG module references [RFC6991].
534 file "ietf-tcp-common@2019-06-07.yang"
535 module ietf-tcp-common {
536 yang-version 1.1;
537 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common";
538 prefix tcpcmn;
540 organization
541 "IETF NETCONF (Network Configuration) Working Group and the
542 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
544 contact
545 "WG Web:
546
547 WG List:
548
549 Authors: Kent Watsen
550 Michael Scharf
551 ";
553 description
554 "This module defines reusable groupings for TCP commons that
555 can be used as a basis for specific TCP common instances.
557 Copyright (c) 2019 IETF Trust and the persons identified
558 as authors of the code. All rights reserved.
560 Redistribution and use in source and binary forms, with
561 or without modification, is permitted pursuant to, and
562 subject to the license terms contained in, the Simplified
563 BSD License set forth in Section 4.c of the IETF Trust's
564 Legal Provisions Relating to IETF Documents
565 (https://trustee.ietf.org/license-info).
567 This version of this YANG module is part of RFC XXXX
568 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
569 itself for full legal notices.;
571 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
572 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
573 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
574 are to be interpreted as described in BCP 14 (RFC 2119)
575 (RFC 8174) when, and only when, they appear in all
576 capitals, as shown here.";
578 revision 2019-06-07 {
579 description
580 "Initial version";
581 reference
582 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
583 }
585 // Features
586 feature keepalives-supported {
587 description
588 "Indicates that keepalives are supported.";
589 }
591 // Groupings
593 grouping tcp-common-grouping {
594 description
595 "A reusable grouping for configuring TCP parameters common
596 to TCP connections as well as the operating system as a
597 whole.";
598 container keepalives {
599 if-feature "keepalives-supported";
600 presence "Indicates that keepalives are enabled.";
601 description
602 "Configures the keep-alive policy, to proactively test the
603 aliveness of the TCP peer. An unresponsive TCP peer is
604 dropped after approximately (idle-time * 60) + (max-probes
605 * probe-interval) seconds.";
606 leaf idle-time {
607 type uint16 {
608 range "1..max";
609 }
610 units "seconds";
611 mandatory true;
612 description
613 "Sets the amount of time after which if no data has been
614 received from the TCP peer, a TCP-level probe message
615 will be sent to test the aliveness of the TCP peer.";
616 }
617 leaf max-probes {
618 type uint16 {
619 range "1..max";
620 }
621 mandatory true;
622 description
623 "Sets the maximum number of sequential keep-alive probes
624 that can fail to obtain a response from the TCP peer
625 before assuming the TCP peer is no longer alive.";
626 }
627 leaf probe-interval {
628 type uint16 {
629 range "1..max";
630 }
631 units "seconds";
632 mandatory true;
633 description
634 "Sets the time interval between failed probes.";
635 }
636 } // container keepalives
637 } // grouping tcp-common-grouping
639 grouping tcp-connection-grouping {
640 description
641 "A reusable grouping for configuring TCP parameters common
642 to TCP connections.";
643 uses tcp-common-grouping;
644 }
646 /*
647 The following is for a future bis...
648 This comment is here now so as support discussion with TCPM.
649 This comment will be removed before publication.
651 Should future system-level parameters be defined as a
652 grouping or a container?
654 grouping tcp-system-grouping {
655 description
656 "A reusable grouping for configuring TCP parameters common
657 to the operating system as a whole.";
659 // currently just a placeholder
661 }
662 */
664 }
665
667 6. Security Considerations
669 The YANG modules defined in this document are designed to be accessed
670 via YANG based management protocols, such as NETCONF [RFC6241] and
671 RESTCONF [RFC8040]. Both of these protocols have mandatory-to-
672 implement secure transport layers (e.g., SSH, TCP) with mutual
673 authentication.
675 The NETCONF access control model (NACM) [RFC8341] provides the means
676 to restrict access for particular users to a pre-configured subset of
677 all available protocol operations and content.
679 Since the modules defined in this document only define groupings,
680 these considerations are primarily for the designers of other modules
681 that use these groupings.
683 There are a number of data nodes defined in the YANG modules that are
684 writable/creatable/deletable (i.e., config true, which is the
685 default). These data nodes may be considered sensitive or vulnerable
686 in some network environments. Write operations (e.g., edit-config)
687 to these data nodes without proper protection can have a negative
688 effect on network operations. These are the subtrees and data nodes
689 and their sensitivity/vulnerability:
691 None of the writable/creatable/deletable data nodes in
692 the YANG modules defined in this document are considered more
693 sensitive or vulnerable then standard configuration.
695 Some of the readable data nodes in the YANG modules may be considered
696 sensitive or vulnerable in some network environments. It is thus
697 important to control read access (e.g., via get, get-config, or
698 notification) to these data nodes. These are the subtrees and data
699 nodes and their sensitivity/vulnerability:
701 None of the readable data nodes in the YANG modules
702 defined in this document are considered more sensitive or vulnerable
703 then standard configuration.
705 This document does not define any RPC actions and hence this section
706 does not consider the security of RPCs.
708 7. IANA Considerations
710 7.1. The IETF XML Registry
712 This document registers two URIs in the "ns" subregistry of the IETF
713 XML Registry [RFC3688]. Following the format in [RFC3688], the
714 following registrations are requested:
716 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client
717 Registrant Contact: The NETCONF WG of the IETF.
718 XML: N/A, the requested URI is an XML namespace.
720 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server
721 Registrant Contact: The NETCONF WG of the IETF.
722 XML: N/A, the requested URI is an XML namespace.
724 7.2. The YANG Module Names Registry
726 This document registers two YANG modules in the YANG Module Names
727 registry [RFC6020]. Following the format in [RFC6020], the following
728 registrations are requested:
730 name: ietf-tcp-common
731 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common
732 prefix: tcpcmn
733 reference: RFC XXXX
735 name: ietf-tcp-client
736 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client
737 prefix: tcpc
738 reference: RFC XXXX
740 name: ietf-tcp-server
741 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server
742 prefix: tcps
743 reference: RFC XXXX
745 8. References
747 8.1. Normative References
749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
750 Requirement Levels", BCP 14, RFC 2119,
751 DOI 10.17487/RFC2119, March 1997,
752 .
754 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
755 the Network Configuration Protocol (NETCONF)", RFC 6020,
756 DOI 10.17487/RFC6020, October 2010,
757 .
759 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
760 RFC 6991, DOI 10.17487/RFC6991, July 2013,
761 .
763 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
764 RFC 7950, DOI 10.17487/RFC7950, August 2016,
765 .
767 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
768 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
769 May 2017, .
771 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
772 Access Control Model", STD 91, RFC 8341,
773 DOI 10.17487/RFC8341, March 2018,
774 .
776 8.2. Informative References
778 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
779 DOI 10.17487/RFC3688, January 2004,
780 .
782 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
783 and A. Bierman, Ed., "Network Configuration Protocol
784 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
785 .
787 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
788 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
789 .
791 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
792 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
793 .
795 Appendix A. Change Log
797 A.1. 00 to 01
799 o Added 'local-binding-supported' feature to TCP-client model.
801 o Added 'keepalives-supported' feature to TCP-common model.
803 o Added 'external-endpoint-values' container and 'external-
804 endpoints' feature to TCP-server model.
806 Authors' Addresses
808 Kent Watsen
809 Watsen Networks
811 EMail: kent+ietf@watsen.net
813 Michael Scharf
814 Hochschule Esslingen - University of Applied Sciences
816 EMail: michael.scharf@hs-esslingen.de