idnits 2.17.1
draft-ietf-netconf-tcp-client-server-02.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 124 has weird spacing: '...address ine...'
== Line 131 has weird spacing: '...nterval uin...'
== Line 311 has weird spacing: '...address ine...'
== Line 316 has weird spacing: '...nterval uin...'
== Line 467 has weird spacing: '...nterval uin...'
== (1 more instance...)
-- The document date (July 2, 2019) is 1758 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: January 3, 2020 Hochschule Esslingen
6 July 2, 2019
8 YANG Groupings for TCP Clients and TCP Servers
9 draft-ietf-netconf-tcp-client-server-02
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-07-02" --> 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 January 3, 2020.
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 . . . . . . . . . . . . . . . . . . . . 10
78 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10
79 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11
80 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 11
81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
83 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 15
84 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 15
85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
86 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
87 8.2. Informative References . . . . . . . . . . . . . . . . . 16
88 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18
89 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 18
90 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 18
91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
93 1. Introduction
95 This document defines three YANG 1.1 [RFC7950] modules: the first
96 defines a grouping for configuring a generic TCP client, the second
97 defines a grouping for configuring a generic TCP server, and the
98 third defines a grouping common to the TCP clients and TCP servers.
100 It is intended that these groupings will be used either standalone,
101 for TCP-based protocols, as part of a stack of protocol-specific
102 configuration models. For instance, these groupings could help
103 define the configuration module for SSH, TLS, or HTTP based
104 applications.
106 2. Terminology
108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
110 "OPTIONAL" in this document are to be interpreted as described in BCP
111 14 [RFC2119] [RFC8174] when, and only when, they appear in all
112 capitals, as shown here.
114 3. The TCP Client Model
116 3.1. Tree Diagram
118 This section provides a tree diagram [RFC8340] for the "ietf-tcp-
119 client" module.
121 module: ietf-tcp-client
123 grouping tcp-client-grouping
124 +-- remote-address inet:host
125 +-- remote-port? inet:port-number
126 +-- local-address? inet:ip-address {local-binding-supported}?
127 +-- local-port? inet:port-number {local-binding-supported}?
128 +-- keepalives! {keepalives-supported}?
129 +-- idle-time uint16
130 +-- max-probes uint16
131 +-- probe-interval uint16
133 3.2. Example Usage
135 This section presents an example showing the tcp-client-grouping
136 populated with some data.
138
139 www.example.com
140 443
141 0.0.0.0
142 0
143
144 15
145 3
146 30
147
148
150 3.3. YANG Module
152 The ietf-tcp-client YANG module references [RFC6991].
154 file "ietf-tcp-client@2019-07-02.yang"
155 module ietf-tcp-client {
156 yang-version 1.1;
157 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-client";
158 prefix tcpc;
160 import ietf-inet-types {
161 prefix inet;
162 reference
163 "RFC 6991: Common YANG Data Types";
164 }
166 import ietf-tcp-common {
167 prefix tcpcmn;
168 reference
169 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
170 }
172 organization
173 "IETF NETCONF (Network Configuration) Working Group and the
174 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
176 contact
177 "WG Web:
178
179 WG List:
180
181 Authors: Kent Watsen
182 Michael Scharf
183 ";
185 description
186 "This module defines reusable groupings for TCP clients that
187 can be used as a basis for specific TCP client instances.
189 Copyright (c) 2019 IETF Trust and the persons identified
190 as authors of the code. All rights reserved.
192 Redistribution and use in source and binary forms, with
193 or without modification, is permitted pursuant to, and
194 subject to the license terms contained in, the Simplified
195 BSD License set forth in Section 4.c of the IETF Trust's
196 Legal Provisions Relating to IETF Documents
197 (https://trustee.ietf.org/license-info).
199 This version of this YANG module is part of RFC XXXX
200 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
201 itself for full legal notices.;
203 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
204 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
205 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
206 are to be interpreted as described in BCP 14 (RFC 2119)
207 (RFC 8174) when, and only when, they appear in all
208 capitals, as shown here.";
210 revision 2019-07-02 {
211 description
212 "Initial version";
213 reference
214 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
215 }
217 // Features
219 feature local-binding-supported {
220 description
221 "Indicates that the server supports configuring local
222 bindings (i.e., the local address and local port) for
223 TCP clients.";
224 }
226 feature tcp-client-keepalives {
227 description
228 "Per socket TCP keepalive parameters are configurable for
229 TCP clients on the server implementing this feature.";
230 }
232 // Groupings
233 grouping tcp-client-grouping {
234 description
235 "A reusable grouping for configuring a TCP client.
237 Note that this grouping uses fairly typical descendent
238 node names such that a stack of 'uses' statements will
239 have name conflicts. It is intended that the consuming
240 data model will resolve the issue (e.g., by wrapping
241 the 'uses' statement in a container called
242 'tcp-client-parameters'). This model purposely does
243 not do this itself so as to provide maximum flexibility
244 to consuming models.";
246 leaf remote-address {
247 type inet:host;
248 mandatory true;
249 description
250 "The IP address or hostname of the remote peer to
251 establish a connection with. If a domain name is
252 configured, then the DNS resolution should happen on
253 each connection attempt. If the the DNS resolution
254 results in multiple IP addresses, the IP addresses
255 are tried according to local preference order until
256 a connection has been established or until all IP
257 addresses have failed.";
258 }
259 leaf remote-port {
260 type inet:port-number;
261 default "0";
262 description
263 "The IP port number for the remote peer to establish a
264 connection with. An invalid default value (0) is used
265 (instead of 'mandatory true') so that as application
266 level data model may 'refine' it with an application
267 specific default port number value.";
268 }
269 leaf local-address {
270 if-feature "local-binding-supported";
271 type inet:ip-address;
272 description
273 "The local IP address/interface (VRF?) to bind to for when
274 connecting to the remote peer. INADDR_ANY ('0.0.0.0') or
275 INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') MAY be used to
276 explicitly indicate the implicit default, that the server
277 can bind to any IPv4 or IPv6 addresses, respectively.";
278 }
279 leaf local-port {
280 if-feature "local-binding-supported";
281 type inet:port-number;
282 default "0";
283 description
284 "The local IP port number to bind to for when connecting
285 to the remote peer. The port number '0', which is the
286 default value, indicates that any available local port
287 number may be used.";
288 }
289 uses tcpcmn:tcp-connection-grouping {
290 augment "keepalives" {
291 if-feature "tcp-client-keepalives";
292 description
293 "Add an if-feature statement so that implementations
294 can choose to support TCP client keepalives.";
295 }
296 }
297 }
298 }
299
301 4. The TCP Server Model
303 4.1. Tree Diagram
305 This section provides a tree diagram [RFC8340] for the "ietf-tcp-
306 server" module.
308 module: ietf-tcp-server
310 grouping tcp-server-grouping
311 +-- local-address inet:ip-address
312 +-- local-port? inet:port-number
313 +-- keepalives! {keepalives-supported}?
314 +-- idle-time uint16
315 +-- max-probes uint16
316 +-- probe-interval uint16
318 4.2. Example Usage
320 This section presents an example showing the tcp-server-grouping
321 populated with some data.
323
324 10.20.30.40
325 7777
326
327 15
328 3
329 30
330
331
333 4.3. YANG Module
335 The ietf-tcp-server YANG module references [RFC6991].
337 file "ietf-tcp-server@2019-07-02.yang"
338 module ietf-tcp-server {
339 yang-version 1.1;
340 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-server";
341 prefix tcps;
343 import ietf-inet-types {
344 prefix inet;
345 reference
346 "RFC 6991: Common YANG Data Types";
347 }
349 import ietf-tcp-common {
350 prefix tcpcmn;
351 reference
352 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
353 }
355 organization
356 "IETF NETCONF (Network Configuration) Working Group and the
357 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
359 contact
360 "WG Web:
361
362 WG List:
363
364 Authors: Kent Watsen
365 Michael Scharf
366 ";
368 description
369 "This module defines reusable groupings for TCP servers that
370 can be used as a basis for specific TCP server instances.
372 Copyright (c) 2019 IETF Trust and the persons identified
373 as authors of the code. All rights reserved.
375 Redistribution and use in source and binary forms, with
376 or without modification, is permitted pursuant to, and
377 subject to the license terms contained in, the Simplified
378 BSD License set forth in Section 4.c of the IETF Trust's
379 Legal Provisions Relating to IETF Documents
380 (https://trustee.ietf.org/license-info).
382 This version of this YANG module is part of RFC XXXX
383 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
384 itself for full legal notices.;
386 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
387 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
388 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
389 are to be interpreted as described in BCP 14 (RFC 2119)
390 (RFC 8174) when, and only when, they appear in all
391 capitals, as shown here.";
393 revision 2019-07-02 {
394 description
395 "Initial version";
396 reference
397 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
398 }
400 // Features
402 feature tcp-server-keepalives {
403 description
404 "Per socket TCP keepalive parameters are configurable for
405 TCP servers on the server implementing this feature.";
406 }
408 // Groupings
410 grouping tcp-server-grouping {
411 description
412 "A reusable grouping for configuring a TCP server.
414 Note that this grouping uses fairly typical descendent
415 node names such that a stack of 'uses' statements will
416 have name conflicts. It is intended that the consuming
417 data model will resolve the issue (e.g., by wrapping
418 the 'uses' statement in a container called
419 'tcp-server-parameters'). This model purposely does
420 not do this itself so as to provide maximum flexibility
421 to consuming models.";
422 leaf local-address {
423 type inet:ip-address;
424 mandatory true;
425 description
426 "The local IP address to listen on for incoming
427 TCP client connections. INADDR_ANY (0.0.0.0) or
428 INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be
429 used when the server is to listen on all IPv4 or
430 IPv6 addresses, respectively.";
431 }
432 leaf local-port {
433 type inet:port-number;
434 default "0";
435 description
436 "The local port number to listen on for incoming TCP
437 client connections. An invalid default value (0)
438 is used (instead of 'mandatory true') so that an
439 application level data model may 'refine' it with
440 an application specific default port number value.";
441 }
442 uses tcpcmn:tcp-connection-grouping {
443 augment "keepalives" {
444 if-feature "tcp-server-keepalives";
445 description
446 "Add an if-feature statement so that implementations
447 can choose to support TCP server keepalives.";
448 }
449 }
450 }
451 }
452
454 5. The TCP Common Model
456 5.1. Tree Diagram
458 This section provides a tree diagram [RFC8340] for the "ietf-tcp-
459 common" module.
461 module: ietf-tcp-common
463 grouping tcp-common-grouping
464 +-- keepalives! {keepalives-supported}?
465 +-- idle-time uint16
466 +-- max-probes uint16
467 +-- probe-interval uint16
468 grouping tcp-connection-grouping
469 +-- keepalives! {keepalives-supported}?
470 +-- idle-time uint16
471 +-- max-probes uint16
472 +-- probe-interval uint16
474 5.2. Example Usage
476 This section presents an example showing the tcp-common-grouping
477 populated with some data.
479
480
481 15
482 3
483 30
484
485
487 5.3. YANG Module
489 The ietf-tcp-common YANG module references [RFC6991].
491 file "ietf-tcp-common@2019-07-02.yang"
492 module ietf-tcp-common {
493 yang-version 1.1;
494 namespace "urn:ietf:params:xml:ns:yang:ietf-tcp-common";
495 prefix tcpcmn;
497 organization
498 "IETF NETCONF (Network Configuration) Working Group and the
499 IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";
501 contact
502 "WG Web:
503
504 WG List:
505
506 Authors: Kent Watsen
507 Michael Scharf
508 ";
510 description
511 "This module defines reusable groupings for TCP commons that
512 can be used as a basis for specific TCP common instances.
514 Copyright (c) 2019 IETF Trust and the persons identified
515 as authors of the code. All rights reserved.
517 Redistribution and use in source and binary forms, with
518 or without modification, is permitted pursuant to, and
519 subject to the license terms contained in, the Simplified
520 BSD License set forth in Section 4.c of the IETF Trust's
521 Legal Provisions Relating to IETF Documents
522 (https://trustee.ietf.org/license-info).
524 This version of this YANG module is part of RFC XXXX
525 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
526 itself for full legal notices.;
528 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
529 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
530 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
531 are to be interpreted as described in BCP 14 (RFC 2119)
532 (RFC 8174) when, and only when, they appear in all
533 capitals, as shown here.";
535 revision 2019-07-02 {
536 description
537 "Initial version";
538 reference
539 "RFC XXXX: YANG Groupings for TCP Clients and TCP Servers";
540 }
542 // Features
543 feature keepalives-supported {
544 description
545 "Indicates that keepalives are supported.";
546 }
548 // Groupings
550 grouping tcp-common-grouping {
551 description
552 "A reusable grouping for configuring TCP parameters common
553 to TCP connections as well as the operating system as a
554 whole.";
555 container keepalives {
556 if-feature "keepalives-supported";
557 presence "Indicates that keepalives are enabled.";
558 description
559 "Configures the keep-alive policy, to proactively test the
560 aliveness of the TCP peer. An unresponsive TCP peer is
561 dropped after approximately (idle-time * 60) + (max-probes
562 * probe-interval) seconds.";
563 leaf idle-time {
564 type uint16 {
565 range "1..max";
566 }
567 units "seconds";
568 mandatory true;
569 description
570 "Sets the amount of time after which if no data has been
571 received from the TCP peer, a TCP-level probe message
572 will be sent to test the aliveness of the TCP peer.";
573 }
574 leaf max-probes {
575 type uint16 {
576 range "1..max";
577 }
578 mandatory true;
579 description
580 "Sets the maximum number of sequential keep-alive probes
581 that can fail to obtain a response from the TCP peer
582 before assuming the TCP peer is no longer alive.";
583 }
584 leaf probe-interval {
585 type uint16 {
586 range "1..max";
587 }
588 units "seconds";
589 mandatory true;
590 description
591 "Sets the time interval between failed probes.";
592 }
593 } // container keepalives
594 } // grouping tcp-common-grouping
596 grouping tcp-connection-grouping {
597 description
598 "A reusable grouping for configuring TCP parameters common
599 to TCP connections.";
600 uses tcp-common-grouping;
601 }
603 /*
604 The following is for a future bis...
606 This comment is here now so as support discussion with TCPM.
607 This comment will be removed before publication.
609 Should future system-level parameters be defined as a
610 grouping or a container?
612 grouping tcp-system-grouping {
613 description
614 "A reusable grouping for configuring TCP parameters common
615 to the operating system as a whole.";
617 // currently just a placeholder
618 }
619 */
621 }
622
624 6. Security Considerations
626 The YANG modules defined in this document are designed to be accessed
627 via YANG based management protocols, such as NETCONF [RFC6241] and
628 RESTCONF [RFC8040]. Both of these protocols have mandatory-to-
629 implement secure transport layers (e.g., SSH, TCP) with mutual
630 authentication.
632 The NETCONF access control model (NACM) [RFC8341] provides the means
633 to restrict access for particular users to a pre-configured subset of
634 all available protocol operations and content.
636 Since the modules defined in this document only define groupings,
637 these considerations are primarily for the designers of other modules
638 that use these groupings.
640 There are a number of data nodes defined in the YANG modules that are
641 writable/creatable/deletable (i.e., config true, which is the
642 default). These data nodes may be considered sensitive or vulnerable
643 in some network environments. Write operations (e.g., edit-config)
644 to these data nodes without proper protection can have a negative
645 effect on network operations. These are the subtrees and data nodes
646 and their sensitivity/vulnerability:
648 None of the writable/creatable/deletable data nodes in
649 the YANG modules defined in this document are considered more
650 sensitive or vulnerable then standard configuration.
652 Some of the readable data nodes in the YANG modules may be considered
653 sensitive or vulnerable in some network environments. It is thus
654 important to control read access (e.g., via get, get-config, or
655 notification) to these data nodes. These are the subtrees and data
656 nodes and their sensitivity/vulnerability:
658 None of the readable data nodes in the YANG modules
659 defined in this document are considered more sensitive or vulnerable
660 then standard configuration.
662 This document does not define any RPC actions and hence this section
663 does not consider the security of RPCs.
665 7. IANA Considerations
667 7.1. The IETF XML Registry
669 This document registers two URIs in the "ns" subregistry of the IETF
670 XML Registry [RFC3688]. Following the format in [RFC3688], the
671 following registrations are requested:
673 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-client
674 Registrant Contact: The NETCONF WG of the IETF.
675 XML: N/A, the requested URI is an XML namespace.
677 URI: urn:ietf:params:xml:ns:yang:ietf-tcp-server
678 Registrant Contact: The NETCONF WG of the IETF.
679 XML: N/A, the requested URI is an XML namespace.
681 7.2. The YANG Module Names Registry
683 This document registers two YANG modules in the YANG Module Names
684 registry [RFC6020]. Following the format in [RFC6020], the following
685 registrations are requested:
687 name: ietf-tcp-common
688 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-common
689 prefix: tcpcmn
690 reference: RFC XXXX
692 name: ietf-tcp-client
693 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-client
694 prefix: tcpc
695 reference: RFC XXXX
697 name: ietf-tcp-server
698 namespace: urn:ietf:params:xml:ns:yang:ietf-tcp-server
699 prefix: tcps
700 reference: RFC XXXX
702 8. References
704 8.1. Normative References
706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
707 Requirement Levels", BCP 14, RFC 2119,
708 DOI 10.17487/RFC2119, March 1997,
709 .
711 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
712 the Network Configuration Protocol (NETCONF)", RFC 6020,
713 DOI 10.17487/RFC6020, October 2010,
714 .
716 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
717 RFC 6991, DOI 10.17487/RFC6991, July 2013,
718 .
720 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
721 RFC 7950, DOI 10.17487/RFC7950, August 2016,
722 .
724 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
725 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
726 May 2017, .
728 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
729 Access Control Model", STD 91, RFC 8341,
730 DOI 10.17487/RFC8341, March 2018,
731 .
733 8.2. Informative References
735 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
736 DOI 10.17487/RFC3688, January 2004,
737 .
739 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
740 and A. Bierman, Ed., "Network Configuration Protocol
741 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
742 .
744 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
745 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
746 .
748 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
749 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
750 .
752 Appendix A. Change Log
754 A.1. 00 to 01
756 o Added 'local-binding-supported' feature to TCP-client model.
758 o Added 'keepalives-supported' feature to TCP-common model.
760 o Added 'external-endpoint-values' container and 'external-
761 endpoints' feature to TCP-server model.
763 A.2. 01 to 02
765 o Removed the 'external-endpoint-values' container and 'external-
766 endpoints' feature from the TCP-server model.
768 Authors' Addresses
770 Kent Watsen
771 Watsen Networks
773 EMail: kent+ietf@watsen.net
775 Michael Scharf
776 Hochschule Esslingen - University of Applied Sciences
778 EMail: michael.scharf@hs-esslingen.de