idnits 2.17.1
draft-ietf-netconf-notification-messages-08.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 :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** There are 5 instances of too long lines in the document, the longest one
being 7 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 240 has weird spacing: '...gorithm str...'
== Line 244 has weird spacing: '...gorithm str...'
-- The document date (November 15, 2019) is 1622 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: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 NETCONF E. Voit
3 Internet-Draft T. Jenkins
4 Intended status: Standards Track Cisco Systems
5 Expires: May 18, 2020 H. Birkholz
6 Fraunhofer SIT
7 A. Bierman
8 YumaWorks
9 A. Clemm
10 Futurewei
11 November 15, 2019
13 Notification Message Headers and Bundles
14 draft-ietf-netconf-notification-messages-08
16 Abstract
18 This document defines a new notification message format. Included
19 are:
21 o a new notification mechanism and encoding to replace the one way
22 operation of RFC-5277
24 o a set of common, transport agnostic message header objects.
26 o how to bundle multiple event records into a single notification
27 message.
29 o how to ensure these new capabilities are only used with capable
30 receivers.
32 Status of This Memo
34 This Internet-Draft is submitted in full conformance with the
35 provisions of BCP 78 and BCP 79.
37 Internet-Drafts are working documents of the Internet Engineering
38 Task Force (IETF). Note that other groups may also distribute
39 working documents as Internet-Drafts. The list of current Internet-
40 Drafts is at https://datatracker.ietf.org/drafts/current/.
42 Internet-Drafts are draft documents valid for a maximum of six months
43 and may be updated, replaced, or obsoleted by other documents at any
44 time. It is inappropriate to use Internet-Drafts as reference
45 material or to cite them other than as "work in progress."
47 This Internet-Draft will expire on May 18, 2020.
49 Copyright Notice
51 Copyright (c) 2019 IETF Trust and the persons identified as the
52 document authors. All rights reserved.
54 This document is subject to BCP 78 and the IETF Trust's Legal
55 Provisions Relating to IETF Documents
56 (https://trustee.ietf.org/license-info) in effect on the date of
57 publication of this document. Please review these documents
58 carefully, as they describe your rights and restrictions with respect
59 to this document. Code Components extracted from this document must
60 include Simplified BSD License text as described in Section 4.e of
61 the Trust Legal Provisions and are provided without warranty as
62 described in the Simplified BSD License.
64 Table of Contents
66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
68 3. Header Objects . . . . . . . . . . . . . . . . . . . . . . . 3
69 4. Encapsulation of Header Objects in Messages . . . . . . . . . 4
70 4.1. One Notification per Message . . . . . . . . . . . . . . 4
71 4.2. Many Notifications per Message . . . . . . . . . . . . . 5
72 5. Configuration of Headers . . . . . . . . . . . . . . . . . . 8
73 6. Discovering Receiver Support . . . . . . . . . . . . . . . . 9
74 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 9
75 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18
76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
79 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
80 11.2. Informative References . . . . . . . . . . . . . . . . . 19
81 Appendix A. Changes between revisions . . . . . . . . . . . . . 19
82 Appendix B. Issues being worked . . . . . . . . . . . . . . . . 21
83 Appendix C. Subscription Specific Headers . . . . . . . . . . . 21
84 Appendix D. Implications to Existing RFCs . . . . . . . . . . . 22
85 D.1. Implications to RFC-7950 . . . . . . . . . . . . . . . . 22
86 D.2. Implications to RFC-8040 . . . . . . . . . . . . . . . . 22
87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
89 1. Introduction
91 Mechanisms to support subscription to event notifications have been
92 defined in [RFC8639] and [RFC8641]. Work on those documents has
93 shown that notifications described in [RFC7950] section 7.16 could
94 benefit from transport independent headers. With such headers,
95 communicating the following information to receiving applications can
96 be done without explicit linkage to an underlying transport protocol:
98 o the time the notification was generated
100 o the time the notification was placed in a message and queued for
101 transport
103 o an identifier for the process generating the notification
105 o signatures to verify authenticity
107 o a subscription id which allows a notification be correlated with a
108 request for that notification
110 o multiple notifications bundled into one transportable message
112 o a message-id allowing a receiver to check for message loss/
113 reordering
115 The document describes information elements needed for the functions
116 above. It also provides instances of YANG structures
117 [I-D.draft-ietf-netmod-yang-data-ext] for sending messages containing
118 one or more notifications to a receiver.
120 2. Terminology
122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
124 "OPTIONAL" in this document are to be interpreted as described in BCP
125 14 [RFC2119] [RFC8174] when, and only when, they appear in all
126 capitals, as shown here.
128 The definition of notification is in [RFC7950] Section 4.2.10.
129 Publisher, receiver, subscription, and event occurrence time are
130 defined in [RFC8639].
132 3. Header Objects
134 There are a number of transport independent headers which should have
135 common definition. These include:
137 o subscription-id: provides a reference into the reason the
138 publisher believed the receiver wishes to be notified of this
139 specific information.
141 o notification-time: the origination time where a notification was
142 fully generated within the publisher.
144 o notification-id: Identifies an instance of an emitted notification
145 to a receiver.
147 o observation-domain-id: identifies the publisher process which
148 discovered and recorded the event notification. (note: look to
149 reuse the domains set up with IPFIX.)
151 o message-time: the time the message was packaged sent to the
152 transport layer for delivery to the receiver.
154 o signature: allows an application to sign a message so that a
155 receiver can verify the authenticity of the message.
157 o message-id: for a specific message generator, this identifies a
158 message which includes one or more event records. The message-id
159 increments by one with sequential messages.
161 o message-generator-id: identifier for the process which created the
162 message. This allows disambiguation of an information source,
163 such as the identification of different line cards sending the
164 messages. Used in conjunction with previous-message-id, this can
165 help find drops and duplications when messages are coming from
166 multiple sources on a device. If there is a message-generator-id
167 in the header, then the previous-message-id MUST be the message-id
168 from the last time that message-generator-id was sent.
170 4. Encapsulation of Header Objects in Messages
172 A specific set of well-known objects are of potential use to
173 networking layers prior being interpreted by some receiving
174 application layer process. By exposing this object information as
175 part of a header, and by using standardized object names, it becomes
176 possible for this object information to be leveraged in transit.
178 The objects defined in the previous section are these well-known
179 header objects. These objects are identified within a dedicated
180 header subtree which leads off a particular transportable message.
181 This allows header objects to be easily be decoupled, stripped, and
182 processed separately.
184 A receiver which supporting this document MUST be able to handle
185 receipt of either type of message from a publisher.
187 4.1. One Notification per Message
189 This section has been deleted from previous versions. It will be re-
190 instated if NETCONF WG members are not comfortable with the
191 efficiency of the solution which can encode many notifications per
192 message, as described below.
194 4.2. Many Notifications per Message
196 While possible in some scenarios, it often inefficient to marshal and
197 transport every notification independently. Instead, scale and
198 processing speed can be improved by placing multiple notifications
199 into one transportable bundle.
201 The format of this bundle appears in the YANG structure below, and is
202 fully defined in the YANG module. There are three parts of this
203 bundle:
205 o a message header describing the marshaling, including information
206 such as when the marshaling occurred
208 o a list of encapsulated information
210 o an optional message footer for whole-message signing and message-
211 generator integrity verification.
213 Within the list of encapsulated notifications, there are also three
214 parts:
216 o a notification header defining what is in an encapsulated
217 notification
219 o the actual notification itself
221 o an optional notification footer for individual notification
222 signing and observation-domain integrity verification.
224 structure message
225 +--ro message!
226 +--ro message-header
227 | +--ro message-time yang:date-and-time
228 | +--ro message-id? uint32
229 | +--ro message-generator-id? string
230 | +--ro notification-count? uint16
231 +--ro notifications*
232 | +--ro notification-header
233 | | +--ro notification-time yang:date-and-time
234 | | +--ro yang-module? yang:yang-identifier
235 | | +--ro subscription-id* uint32
236 | | +--ro notification-id? uint32
237 | | +--ro observation-domain-id? string
238 | +--ro notification-contents?
239 | +--ro notification-footer!
240 | +--ro signature-algorithm string
241 | +--ro signature-value string
242 | +--ro integrity-evidence? string
243 +--ro message-footer!
244 +--ro signature-algorithm string
245 +--ro signature-value string
246 +--ro integrity-evidence? string
248 An XML instance of a message might look like:
250
252
253
254 2017-02-14T00:00:05Z
255
256
257 456
258
259
260 2
261
262
263
264
265
266 2017-02-14T00:00:02Z
267
268
269 823472
270
271
272 ietf-yang-push
273
274
275 push-change-update
276
277
278
279
281
282
283
285
286
287
288
289
290 ...(notification header, contents, footer)...
291
292
293
295 5. Configuration of Headers
297 A publisher MUST select the set of headers to use within any
298 particular message. The two mandatory headers which MUST always be
299 applied are 'message-time' and 'subscription-id'
301 Beyond these two mandatory headers, additional headers MAY be
302 included. Configuration of what these optional headers should be can
303 come from the following sources:
305 1. Publisher wide default headers which are placed on all
306 notifications. An optional header is a publisher default if its
307 identity is included within the 'additional-headers' leaf-list.
309 2. More notification specific headers may also be desired. If new
310 headers are needed for a specific type of YANG notification,
311 these can be populated through 'additional-notification-headers'
312 leaf-list.
314 3. An application process may also identify common headers to use
315 when transporting notifications for a specific subscription. How
316 such application specific configuration is accomplished within
317 the publisher is out-of-scope.
319 The set of headers selected and populated for any particular message
320 is derived from the union of the mandatory headers and configured
321 optional headers.
323 The YANG tree showing elements of configuration is depicted in the
324 following figure.
326 module: ietf-notification-messages
327 +--rw additional-default-headers {publisher}?
328 +--rw additional-headers* optional-header
329 +--rw yang-notification-specific-default*
330 | [yang-module yang-notification-name]
331 +--rw yang-module yang:yang-identifier
332 +--rw yang-notification-name notification-type
333 +--rw additional-notification-headers*
334 optional-notification-header
336 Configuration Model structure
338 Of note in this tree is the optional feature of 'publisher'. This
339 feature indicates an ability to send notifications. A publisher
340 supporting this specification MUST also be able to parse any messages
341 received as defined in this document.
343 6. Discovering Receiver Support
345 We need capability exchange from the receiver to the publisher at
346 transport session initiation to indicate support for this
347 specification.
349 For all types of transport connections, if the receiver indicates
350 support for this specification, then it MAY be used. In addition,
351 [RFC5277] one-way notifications MUST NOT be used if the receiver
352 indicates support for this specification to a publisher which also
353 supports it.
355 Where NETCONF transport is used, advertising this specification's
356 namespace during an earlier client capabilities discovery phase MAY
357 be used to indicate support for this specification:
359
360
361
362 urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0
363
364
365 4
366
368 NOTE: It is understood that even though it is allowed in [RFC6241]
369 section 8.1, robust NETCONF client driven capabilities exchange is
370 not something which is common in implementation. Therefore reviewers
371 are asked to submit alternative proposals to the mailing list.
373 For RESTCONF, a mechanism for capability discovery is TBD. Proposals
374 are welcome here.
376 The mechanism described above assumes that a capability discovery
377 phase happens before a subscription is started. This is not always
378 the case. There is no guarantee that a capability exchange has taken
379 place before the messages are emitted. A solution for this in the
380 case of HTTP based transport could be that a receiver would have to
381 reply "ok" and also return the client capabilities as part a response
382 to the initiation of the POST.
384 7. YANG Module
386 file "ietf-notification-messages@2019-10-10.yang"
387 module ietf-notification-messages {
388 yang-version 1.1;
389 namespace
390 "urn:ietf:params:xml:ns:yang:ietf-notification-messages";
391 prefix nm;
393 import ietf-yang-types { prefix yang; }
394 import ietf-yang-structure-ext { prefix sx; }
396 organization "IETF";
397 contact
398 "WG Web:
399 WG List:
401 Editor: Eric Voit
402
404 Editor: Henk Birkholz
405
407 Editor: Alexander Clemm
408
410 Editor: Andy Bierman
411
413 Editor: Tim Jenkins
414 ";
416 description
417 "This module contains conceptual YANG specifications for
418 messages carrying notifications with well-known header objects.";
420 revision 2019-10-10 {
421 description
422 "Initial version.";
424 reference
425 "draft-ietf-netconf-notification-messages-08";
426 }
428 /*
429 * FEATURES
430 */
432 feature publisher {
433 description
434 "This feature indicates that support for both publisher and
435 receiver of messages complying to the specification.";
436 }
437 /*
438 * IDENTITIES
439 */
441 /* Identities for common headers */
443 identity common-header {
444 description
445 "A well-known header which can be included somewhere within a
446 message.";
447 }
449 identity message-time {
450 base common-header;
451 description
452 "Header information consisting of time the message headers were
453 generated prior to being sent to transport";
454 }
456 identity subscription-id {
457 base common-header;
458 description
459 "Header information consisting of the identifier of the
460 subscription associated with the notification being
461 encapsulated.";
462 }
464 identity notification-count {
465 base common-header;
466 description
467 "Header information consisting of the quantity of notifications in
468 a bundled-message for a specific receiver.";
469 }
471 identity optional-header {
472 base common-header;
473 description
474 "A well-known header which an application may choose to include
475 within a message.";
476 }
478 identity message-id {
479 base optional-header;
480 description
481 "Header information that identifies a message to a specific
482 receiver";
483 }
484 identity message-generator-id {
485 base optional-header;
486 description
487 "Header information consisting of an identifier for a software
488 entity which created the message (e.g., linecard 1).";
489 }
491 identity message-signature {
492 base optional-header;
493 description
494 "Identifies two elements of header information consisting of a
495 signature and the signature type for the contents of a message.
496 Signatures can be useful for originating applications to
497 verify record contents even when shipping over unsecure
498 transport.";
499 }
501 identity message-integrity-evidence {
502 base optional-header;
503 description
504 "Header information consisting of the information which backs up
505 the assertions made as to the validity of the information
506 provided within the message.";
507 }
509 identity optional-notification-header {
510 base optional-header;
511 description
512 "A well-known header which an application may choose to include
513 within a message.";
514 }
516 identity notification-time {
517 base optional-notification-header;
518 description
519 "Header information consisting of the time an originating process
520 created the notification.";
521 }
523 identity notification-id {
524 base optional-notification-header;
525 description
526 "Header information consisting of an identifier for an instance
527 of a notification. If access control based on a message's receiver may
528 strip information from within the notification, this notification-id MUST
529 allow the identification of the specific contents of notification as it
530 exits the publisher.";
532 }
534 identity observation-domain-id {
535 base optional-notification-header;
536 description
537 "Header information identifying the software entity which created
538 the notification (e.g., process id).";
539 }
541 identity notification-signature {
542 base optional-notification-header;
543 description
544 "Header information consisting of a signature which can be used to prove
545 the authenticity that some asserter validates over the information
546 provided within the notification.";
547 }
549 identity notification-integrity-evidence {
550 base optional-notification-header;
551 description
552 "Header information consisting of the information which backs up
553 the assertions made as to the validity of the information
554 provided within the notification.";
555 }
557 /*
558 * TYPEDEFs
559 */
561 typedef optional-header {
562 type identityref {
563 base optional-header;
564 }
565 description
566 "Type of header object which may be included somewhere within a
567 message.";
568 }
570 typedef optional-notification-header {
571 type identityref {
572 base optional-notification-header;
573 }
574 description
575 "Type of header object which may be included somewhere within a
576 message.";
577 }
578 typedef notification-type {
579 type string {
580 pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
581 }
582 description
583 "The name of a notification within a YANG module.";
584 reference
585 "RFC-7950 Section 7.16";
586 }
588 /*
589 * GROUPINGS
590 */
592 grouping message-header {
593 description
594 "Header information included with a message.";
595 leaf message-time {
596 type yang:date-and-time;
597 mandatory true;
598 description
599 "Time the message was generated prior to being sent to
600 transport.";
601 }
602 leaf message-id {
603 type uint32;
604 description
605 "Id for a message going to a receiver from a message
606 generator. The id will increment by one with each message sent
607 from a particular message generator, allowing the message-id
608 to be used as a sequence number.";
609 }
610 leaf message-generator-id {
611 type string;
612 description
613 "Software entity which created the message (e.g., linecard 1).
614 The combination of message-id and message-generator-id must be
615 unique until reset or a roll-over occurs.";
616 }
617 leaf notification-count {
618 type uint16;
619 description
620 "Quantity of notifications in a bundled-message to a
621 specific receiver.";
622 }
623 }
625 grouping notification-header {
626 description
627 "Common informational objects which might help a receiver
628 interpret the meaning, details, or importance of a notification.";
629 leaf notification-time {
630 type yang:date-and-time;
631 mandatory true;
632 description
633 "Time the system recognized the occurrence of an event.";
634 }
635 leaf yang-module {
636 type yang:yang-identifier;
637 description
638 "Name of the YANG module supported by the publisher.";
639 }
640 leaf-list subscription-id {
641 type uint32;
642 description
643 "Id of the subscription which led to the notification being
644 generated.";
645 }
646 leaf notification-id {
647 type uint32;
648 description
649 "Identifier for the notification record.";
650 }
651 leaf observation-domain-id {
652 type string;
653 description
654 "Software entity which created the notification record (e.g.,
655 process id).";
656 }
657 }
659 grouping security-footer {
660 description
661 "Reusable grouping for common objects which apply to the signing of
662 notifications or messages.";
663 leaf signature-algorithm {
664 type string;
665 mandatory true;
666 description
667 "The technology with which an originator signed of some
668 delineated contents.";
669 }
670 leaf signature-value {
671 type string;
672 mandatory true;
673 description
674 "Any originator signing of the contents of a header and
675 content. This is useful for verifying contents even when
676 shipping over unsecure transport.";
677 }
678 leaf integrity-evidence {
679 type string;
680 description
681 "This mechanism allows a verifier to ensure that the use of the
682 private key, represented by the corresponding public key
683 certificate, was performed with a TCG compliant TPM
684 environment. This evidence is never included in within any
685 signature.";
686 reference
687 "TCG Infrastructure Workgroup, Subject Key Attestation Evidence
688 Extension, Specification Version 1.0, Revision 7.";
689 }
690 }
692 /*
693 * YANG encoded structures which can be sent to receivers
694 */
696 sx:structure message {
697 container message-header {
698 description
699 "Header info for messages.";
700 uses message-header;
701 }
702 list notifications {
703 description
704 "Set of notifications to a receiver.";
705 container notification-header {
706 description
707 "Header info for a notification.";
708 uses notification-header;
709 }
710 anydata notification-contents {
711 description
712 "Encapsulates objects following YANG's notification-stmt
713 grammar of RFC-7950 section 14. Within are the notified
714 objects the publisher actually generated in order to be
715 passed to a receiver after all filtering has completed.";
716 }
717 container notification-footer {
718 presence
719 "Indicates attempt to secure a notification.";
720 description
721 "Signature and evidence for messages.";
723 uses security-footer;
724 }
725 }
726 container message-footer {
727 presence
728 "Indicates attempt to secure the entire message.";
729 description
730 "Signature and evidence for messages.";
731 uses security-footer;
732 }
733 }
735 /*
736 * DATA-NODES
737 */
739 container additional-default-headers {
740 if-feature "publisher";
741 description
742 "This container maintains a list of which additional notifications
743 should use which optional headers if the receiver supports this
744 specification.";
745 leaf-list additional-headers {
746 type optional-header;
747 description
748 "This list contains the identities of the optional header types
749 which are to be included within each message from this
750 publisher.";
751 }
752 list yang-notification-specific-default {
753 key "yang-module yang-notification-name";
754 description
755 "For any included YANG notifications, this list provides
756 additional optional headers which should be placed within the
757 container notification-header if the receiver supports this
758 specification. This list incrementally adds to any headers
759 indicated within the leaf-list 'additional-headers'.";
760 leaf yang-module {
761 type yang:yang-identifier;
762 description
763 "Name of the YANG module supported by the publisher.";
764 }
765 leaf yang-notification-name {
766 type notification-type;
767 description
768 "The name of a notification within a YANG module.";
769 }
770 leaf-list additional-notification-headers {
771 type optional-notification-header;
772 description
773 "The set of additional default headers which will be sent
774 for a specific notification.";
775 }
776 }
777 }
778 }
780
782 8. Backwards Compatibility
784 With this specification, there is no change to YANG's 'notification'
785 statement
787 Legacy clients are unaffected, and existing users of [RFC5277],
788 [RFC7950], and [RFC8040] are free to use current behaviors until all
789 involved device support this specification.
791 9. Security Considerations
793 Certain headers might be computationally complex for a publisher to
794 deliver. Signatures or encryption are two examples of this. It MUST
795 be possible to suspend or terminate a subscription due to lack of
796 resources based on this reason.
798 Decisions on whether to bundle or not to a receiver are fully under
799 the purview of the Publisher. A receiver could slow delivery to
800 existing subscriptions by creating new ones. (Which would result in
801 the publisher going into a bundling mode.)
803 10. Acknowledgments
805 For their valuable comments, discussions, and feedback, we wish to
806 acknowledge Martin Bjorklund, Einar Nilsen-Nygaard, and Kent Watsen.
808 11. References
810 11.1. Normative References
812 [I-D.draft-ietf-netmod-yang-data-ext]
813 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data
814 Structure Extensions", draft-ietf-netmod-yang-data-ext
815 (work in progress), July 2019.
817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
818 Requirement Levels", BCP 14, RFC 2119,
819 DOI 10.17487/RFC2119, March 1997,
820 .
822 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
823 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
824 .
826 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
827 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
828 May 2017, .
830 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
831 E., and A. Tripathy, "Subscription to YANG Notifications",
832 RFC 8639, DOI 10.17487/RFC8639, September 2019,
833 .
835 11.2. Informative References
837 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
838 and A. Bierman, Ed., "Network Configuration Protocol
839 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
840 .
842 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
843 RFC 7950, DOI 10.17487/RFC7950, August 2016,
844 .
846 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
847 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
848 .
850 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
851 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
852 September 2019, .
854 Appendix A. Changes between revisions
856 (To be removed by RFC editor prior to publication)
858 v06 - v08
860 o Removed redundant container from message
862 o References and example updates
864 v05 - v06
865 o With SN and YP getting RFC numbers, revisiting this document.
867 o Changed yang-data to draft-ietf-netmod-yang-data-ext's
868 'structure'.
870 o Removed the ability to reference structures other than YANG
871 notifications.
873 v04 - v05
875 o Revision before expiration. Awaiting closure of SN and YP prior
876 to update.
878 v03 - v04
880 o Terminology tweaks.
882 o Revision before expiration. Awaiting closure of SN prior to
883 update.
885 v02 - v03
887 o Removed the option for an unbundled message. This might be re-
888 added later for transport efficiency if desired by the WG
890 o New message structure driven by the desire to put the signature
891 information at the end.
893 v01 - v02
895 o Fixed the yang-data encapsulation container issue
897 o Updated object definitions to point to RFC-7950 definitions
899 o Added headers for module and notification-type.
901 v00 - v01
903 o Alternative to 5277 one-way notification added
905 o Storage of default headers by notification type
907 o Backwards compatibility
909 o Capability discovery
911 o Move to yang-data
912 o Removed dscp and record-type as common headers. (Record type can
913 be determined by the namespace of the record contents. Dscp is
914 useful where applications need internal communications within a
915 Publisher, but it is unclear as to whether this use case need be
916 exposed to a receiver.
918 Appendix B. Issues being worked
920 (To be removed by RFC editor prior to publication)
922 A complete JSON document is supposed to be sent as part of Media Type
923 "application/yang-data+json". As we are sending separate
924 notifications after each other, we need to choose whether we start
925 with some extra encapsulation for the very first message pushed, or
926 if we want a new Media Type for streaming updates.
928 Improved discovery mechanisms for NETCONF
930 Need to ensure the proper references exist to a notification
931 definition driven by RFC-7950 which is acceptable to other eventual
932 users of this specification.
934 Appendix C. Subscription Specific Headers
936 (To be removed by RFC editor prior to publication)
938 This section discusses a future functional addition which could
939 leverage this draft. It is included for informational purposes only.
941 A dynamic subscriber might want to mandate that certain headers be
942 used for push updates from a publisher. Some examples of this
943 include a subscriber requesting to:
945 o establish this subscription, but just if transport messages
946 containing the pushed data will be encrypted,
948 o establish this subscription, but only if you can attest to the
949 information being delivered in requested notification records, or
951 o provide a sequence-id for all messages to this receiver (in order
952 to check for loss).
954 Providing this type of functionality would necessitate a new revision
955 of the [RFC8639]'s RPCs and state change notifications. Subscription
956 specific header information would overwrite the default headers
957 identified in this document.
959 Appendix D. Implications to Existing RFCs
961 (To be removed by RFC editor prior to publication)
963 YANG one-way exchanges currently use a non-extensible header and
964 encoding defined in section 4 of RFC-5277. These RFCs MUST be
965 updated to enable this draft. These RFCs SHOULD be updated to
966 provide examples
968 D.1. Implications to RFC-7950
970 Sections which expose netconf:capability:notification:1.0 are 4.2.10
972 Sections which provide examples using netconf:notification:1.0 are
973 7.10.4, 7.16.3, and 9.9.6
975 D.2. Implications to RFC-8040
977 Section 6.4 demands use of RFC-5277's netconf:notification:1.0, and
978 later in the section provides an example.
980 Authors' Addresses
982 Eric Voit
983 Cisco Systems
985 Email: evoit@cisco.com
987 Tim Jenkins
988 Cisco Systems
990 Email: timjenki@cisco.com
992 Henk Birkholz
993 Fraunhofer SIT
995 Email: henk.birkholz@sit.fraunhofer.de
997 Andy Bierman
998 YumaWorks
1000 Email: andy@yumaworks.com
1001 Alexander Clemm
1002 Futurewei
1004 Email: ludwig@clemm.org