idnits 2.17.1
draft-ietf-netconf-notification-messages-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 :
----------------------------------------------------------------------------
** 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.)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (September 29, 2017) is 2401 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: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 NETCONF E. Voit
3 Internet-Draft Cisco Systems
4 Intended status: Standards Track A. Bierman
5 Expires: April 2, 2018 YumaWorks
6 A. Clemm
7 Huawei
8 T. Jenkins
9 Cisco Systems
10 September 29, 2017
12 Notification Message Headers and Bundles
13 draft-ietf-netconf-notification-messages-01
15 Abstract
17 This document defines a new notification message format, using yang-
18 data. Included are:
20 o a new notification mechanism and encoding to replace the one way
21 operation of RFC-5277
23 o a set of common, transport agnostic message header objects.
25 o how to bundle multiple event records into a single notification
26 message.
28 o how to ensure these new capabilities are only used with capable
29 receivers.
31 Status of This Memo
33 This Internet-Draft is submitted in full conformance with the
34 provisions of BCP 78 and BCP 79.
36 Internet-Drafts are working documents of the Internet Engineering
37 Task Force (IETF). Note that other groups may also distribute
38 working documents as Internet-Drafts. The list of current Internet-
39 Drafts is at https://datatracker.ietf.org/drafts/current/.
41 Internet-Drafts are draft documents valid for a maximum of six months
42 and may be updated, replaced, or obsoleted by other documents at any
43 time. It is inappropriate to use Internet-Drafts as reference
44 material or to cite them other than as "work in progress."
46 This Internet-Draft will expire on April 2, 2018.
48 Copyright Notice
50 Copyright (c) 2017 IETF Trust and the persons identified as the
51 document authors. All rights reserved.
53 This document is subject to BCP 78 and the IETF Trust's Legal
54 Provisions Relating to IETF Documents
55 (https://trustee.ietf.org/license-info) in effect on the date of
56 publication of this document. Please review these documents
57 carefully, as they describe your rights and restrictions with respect
58 to this document. Code Components extracted from this document must
59 include Simplified BSD License text as described in Section 4.e of
60 the Trust Legal Provisions and are provided without warranty as
61 described in the Simplified BSD License.
63 Table of Contents
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 3. Header Objects . . . . . . . . . . . . . . . . . . . . . . . 3
68 4. Encapsulation of Header Objects in Messages . . . . . . . . . 4
69 4.1. One Notification per Message . . . . . . . . . . . . . . 5
70 4.2. Many Notifications per Message . . . . . . . . . . . . . 6
71 4.3. Notification Type in Payload . . . . . . . . . . . . . . 9
72 5. Configuration of Headers . . . . . . . . . . . . . . . . . . 9
73 6. Discovering Receiver Support . . . . . . . . . . . . . . . . 10
74 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 11
75 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 17
76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
79 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
80 11.2. Informative References . . . . . . . . . . . . . . . . . 18
81 Appendix A. Changes between revisions . . . . . . . . . . . . . 19
82 Appendix B. Issues being worked . . . . . . . . . . . . . . . . 19
83 Appendix C. Subscription Specific Headers . . . . . . . . . . . 20
84 Appendix D. Implications to Existing RFCs . . . . . . . . . . . 20
85 D.1. Implications to RFC-7950 . . . . . . . . . . . . . . . . 20
86 D.2. Implications to RFC-8040 . . . . . . . . . . . . . . . . 21
87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
89 1. Introduction
91 Mechanisms to support subscription to event notifications and yang
92 datastore push are being defined in [subscribe] and [yang-push].
93 Work on those documents has shown that notifications described in
94 [RFC7950] section 7.16 could benefit from transport independent
95 headers. Communicating the following information to receiving
96 applications can be done without explicit linkage to an underlying
97 transport protocol:
99 o the time information was generated
101 o the time the information was sent
103 o a signature to verify authenticity
105 o the process generating the information
107 o an originating request correlation
109 o an ability to bundle information records into one a message
111 o the ability to check for message loss/reordering
113 The document describes information elements needed for the functions
114 above. It also provides YANG structures for sending messages
115 containing one or more events and/or update records to a receiver.
117 2. Terminology
119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
121 "OPTIONAL" in this document are to be interpreted as described in BCP
122 14 [RFC2119] [RFC8174] when, and only when, they appear in all
123 capitals, as shown here.
125 The definition of notification is in RFC 7950 [RFC7950]. Publisher,
126 receiver, and subscription are defined in [subscribe].
128 3. Header Objects
130 There are a number of transport independent headers which should have
131 common definition. These include:
133 o subscription-id: provides a reference into the reason the
134 publisher believed the receiver wishes to be notified of this
135 specific information.
137 o notification-time: the time an event, datastore update, or other
138 item is recognized and recorded within the publisher.
140 o notification-id: Identifies the name of the notification, per the
141 YANG notification statement. May also provide the name of a yang-
142 data statement (wheterh this is in scope is tbd).
144 o observation-domain-id: identifies the publisher process which
145 discovered and recorded the event notification. (note: look to
146 reuse the domains set up with IPFIX.)
148 o message-time: the time the message was packaged sent to the
149 transport layer for delivery to the receiver.
151 o signature: allows an application to sign a message so that a
152 receiver can verify the authenticity of the message.
154 o message-id: for a specific message generator, this identifies a
155 message which includes one or more event records.
157 o previous-message-id: the message-id of the message preceding the
158 current one intended for the same receiver. When used in
159 conjunction with the current message-id, this allows loss/
160 duplication across previous messages to be discovered. If there
161 was no previous message from a message generator, the reserved id
162 "0" must be sent.
164 o message-generator-id: identifier for the process which created the
165 message. This allows disambiguation of an information source,
166 such as the identification of different line cards sending the
167 messages. Used in conjunction with previous-message-id, this can
168 help find drops and duplications when messages are coming from
169 multiple sources on a device. If there is a message-generator-id
170 in the header, then the previous-message-id MUST be the message-id
171 from the last time that message-generator-id was sent.
173 4. Encapsulation of Header Objects in Messages
175 A specific set of well-known objects are of potential use to
176 networking layers prior being interpreted by some receiving
177 application layer process. By exposing this object information as
178 part of a header, and by using standardized object names, it becomes
179 possible for this object information to be leveraged in transit.
181 The objects defined in the previous section are these well-known
182 header objects. These objects are identified within a dedicated
183 header subtree which leads off a particular transportable message.
184 This allows header objects to be easily be decoupled, stripped, and
185 processed separately.
187 There are two types of transportable messages: one format is used
188 when there is one notification being encapsulated, and another format
189 used when there are many notifications being bundled into one
190 message.
192 A receiver which supporting this document MUST be able to handle
193 receipt of either type of message from an publisher. It is possible
194 that changes between message types can occur without any prior
195 indication.
197 4.1. One Notification per Message
199 Below are contents of a message when there is only one notification
200 in an encapsulated and encoded message:
202 yang-data message
203 +-- message-header
204 | +-- notification-time yang:date-and-time
205 | +-- subscription-id* uint32
206 | +-- notification-id? uint32
207 | +-- observation-domain-id? string
208 | +-- message-id? uint32
209 | +-- message-time? yang:date-and-time
210 | +-- previous-message-id? uint32
211 | +-- message-generator-id? string
212 | +-- signature? string
213 +-- receiver-record-contents?
215 An actual instance of such a message when encoded in XML might look
216 like:
218
220
221
222 2017-02-14T00:00:02Z
223
224
225 823472
226
227
228 2017-02-14T00:00:05Z
229
230
231 456
232
233
234 567
235
236
237 lKIo8s03fd23.....
238
239
240
242
243
244
246
247
248
249
251 4.2. Many Notifications per Message
253 In many implementations, it may be inefficient to transport every
254 notification independently. Instead, scale and processing speed can
255 be improved by placing multiple notifications into one transportable
256 bundle.
258 When this is done, one additional header field becomes valuable.
259 This is the "notification-count" which would tally the quantity of
260 records which make up the contents of the bundle. It is true that
261 the record count can be derived, but early access to this information
262 could change receiver processing.
264 The format of a bundle would look as below. When compared to the
265 unbundled notification, note that the headers have been split so that
266 one set of headers associated with the notification occur once at the
267 beginning of the message, and additional record specific headers
268 which occur before individual records.
270 yang-data bundled-message
271 +-- bundled-message-header
272 | +-- message-time yang:date-and-time
273 | +-- message-id? uint32
274 | +-- previous-message-id? uint32
275 | +-- message-generator-id? string
276 | +-- signature? string
277 | +-- notification-count? uint16
278 +-- notifications*
279 +-- notification-header
280 | +-- notification-time yang:date-and-time
281 | +-- subscription-id* uint32
282 | +-- notification-id? uint32
283 | +-- observation-domain-id? string
284 +-- receiver-record-contents?
286 An actual instance of a bundled notification might look like:
288
290
291
292 2017-02-14T00:00:05Z
293
294
295 456
296
297
298 567
299
300
301 lKIo8s03fd23...
302
303
304 2
305
306
307
308
309
310
311 2017-02-14T00:00:02Z
312
313
314 823472
315
316
317
319
320
321
323
324
325
326
327
328 ...(record #2)...
329
330
331
333 4.3. Notification Type in Payload
335 The type of notification transported within a record could be a
336 header. However the notification name and namespace is the first
337 element in the receiver record contents payload. As this can be
338 determined by the YANG module containing the notification-stmt as
339 represented within the first part of the encapsulated notification
340 message, this information need not replicated within a header.
342 5. Configuration of Headers
344 A publisher MUST select the set of headers to use for a particular
345 message. The two mandatory headers which MUST always be applied to
346 every message are 'message-time' and 'subscription-id'
348 Beyond these two mandatory headers, the following are additional
349 sources which can add common headers to a message.
351 1. Publisher wide default headers for all notifications. These are
352 included if a common header is inserted into 'additional-headers'
353 shown in the figure below.
355 2. More notification specific headers may also be desired. If new
356 headers are needed for a specific notification in the YANG model,
357 this can be populated through 'per-notification-headers'.
359 3. An application process may also identify common headers to use
360 when transporting notifications for a specific subscription. How
361 these are identified to a publisher is out-of-scope.
363 The set of headers used for any particular message is the superset of
364 headers for the items listed above.
366 The YANG tree showing elements of configuration is depicted in the
367 following figure.
369 module: ietf-notification-messages
370 +--rw additional-default-headers {publisher}?
371 +--rw additional-headers* common-header
372 +--rw notification-specific-default* [module notification]
373 +--rw module yang:yang-identifier
374 +--rw notification string
375 +--rw per-notification-headers* common-header
377 Configuration Model structure
379 Of note in this tree is the optional feature of 'publisher'. This
380 feature indicates an ability to send notifications. A publisher
381 supporting this specification MUST also be able to parse any messages
382 received as defined in this document.
384 6. Discovering Receiver Support
386 We need capability exchange from the receiver to the publisher at
387 transport session initiation to indicate support for this
388 specification.
390 For all types of transport connections, if the receiver indicates
391 support for this specification, then it MAY be used. In addition,
392 [RFC5277] one-way notifications MUST NOT be used if the receiver
393 indicates support for this specification to a publisher which also
394 supports it.
396 Where NETCONF transport is used, advertising this specification's
397 namespace during an earlier client capabilities discovery phase MAY
398 be used to indicate support for this specification:
400
401
402
403 urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0
404
405
406 4
407
409 NOTE: It is understood that even though it is allowed in [RFC6241]
410 section 8.1, robust NETCONF client driven capabilities exchange is
411 not something which is common in implementation. Therefore reviewers
412 are asked to submit alternative proposals to the mailing list.
414 For RESTCONF, a mechanism for capability discovery is TBD. Proposals
415 are also welcome here.
417 The mechanism described above assumes that a capability discovery
418 phase happens before a subscription is started. This is not always
419 the case. As an example, consider HTTP2 configured subscriptions
420 from section 3.1.3 of [http-push], there is no guarantee that a
421 capability exchange has taken place before the updates are pushed. A
422 solution for this could be that a receiver would reply "ok" and reply
423 with the client capabilities as part of the POST. (Or just use a
424 different HTTP status code like 202 instead of 200 'ok'). As such a
425 requirement creates a new dependency for [http-push] upon this
426 specification, more discussion is required to decide if this is a
427 viable solution.
429 7. YANG Module
431 file "ietf-notification-messages.yang"
432 module ietf-notification-messages {
433 yang-version 1.1;
434 namespace
435 "urn:ietf:params:xml:ns:yang:ietf-notification-messages";
436 prefix nm;
438 import ietf-yang-types { prefix yang; }
439 import ietf-restconf { prefix rc; }
441 organization "IETF";
442 contact
443 "WG Web:
444 WG List:
446 Editor: Eric Voit
447
449 Editor: Alexander Clemm
450
452 Editor: Andy Bierman
453
455 Editor: Tim Jenkins
456 ";
458 description
459 "This module contains conceptual YANG specifications for yang-data
460 messages carrying notifications with well known header objects.";
462 revision 2017-09-28 {
463 description
464 "Initial version.";
466 reference
467 "draft-ietf-netconf-notification-messages-01";
468 }
470 /*
471 * FEATURES
472 */
474 feature publisher {
475 description
476 "This feature indicates that support for both publisher and
477 receiver of messages complying to the specification.";
478 }
480 /*
481 * IDENTITIES
482 */
484 /* Identities for common headers */
486 identity common-header {
487 description
488 "A well known header which can be included somewhere within a
489 message.";
490 }
492 identity notification-time {
493 base common-header;
494 description
495 "Header information consisting of the time an originating process
496 created the notification or yang-data.";
497 }
499 identity notification-id {
500 base common-header;
501 description
502 "Header information consisting of an identifier for the
503 notification or yang-data record. ";
504 }
506 identity subscription-id {
507 base common-header;
508 description
509 "Header information consisting of the identifier of the
510 subscription associated with the notification or yang-data being
511 encapsulated.";
512 }
514 identity observation-domain-id {
515 base common-header;
516 description
517 "Header information identifying the software entity which created
518 the notification or yang-data (e.g., process id).";
519 }
521 identity message-id {
522 base common-header;
523 description
524 "Header information that identifies a message to a specific
525 receiver";
526 }
528 identity message-time {
529 base common-header;
530 description
531 "Header information consisting of time the message headers were
532 placed generated prior to being sent to transport";
533 }
535 identity previous-message-id {
536 base common-header;
537 description
538 "Header information consisting of a message id previously sent by
539 the publisher to a specific receiver (allows detection of
540 loss/duplication).";
541 }
543 identity message-generator-id {
544 base common-header;
545 description
546 "Header information consisting of an identifier for a software
547 entity which created the message (e.g., linecard 1).";
548 }
550 identity signature {
551 base common-header;
552 description
553 "Header information consisting of a signature on the contents of
554 a message. This can be useful for originating applications to
555 verify record contents even when shipping over unsecure
556 transport.";
557 }
559 identity notification-count {
560 base common-header;
561 description
562 "Header information consisting of the quantity of notifications in
563 a bundled-message for a specific receiver.";
564 }
566 /*
567 * TYPEDEFs
568 */
570 typedef common-header {
571 type identityref {
572 base common-header;
573 }
574 description
575 "Type of header object which may be included somewhere within a
576 message.";
577 }
579 /*
580 * GROUPINGS
581 */
583 grouping message-header {
584 description
585 "Header information included with a message.";
586 leaf message-id {
587 type uint32;
588 description
589 "Unique id for a message going to a receiver.";
590 }
591 leaf message-time {
592 type yang:date-and-time;
593 description
594 "time the message was generated prior to being sent to
595 transport.";
596 }
597 leaf previous-message-id {
598 type uint32;
599 description
600 "message id previously sent by publisher to a specific
601 receiver (allows detection of loss/duplication).";
602 }
603 leaf message-generator-id {
604 type string;
605 description
606 "Software entity which created the message (e.g., linecard 1).";
607 }
608 leaf signature {
609 type string;
610 description
611 "Any originator signing of the contents of a message. This can
612 be useful for originating applications to verify record contents
613 even when shipping over unsecure transport.";
614 }
615 }
617 grouping notification-header {
618 description
619 "Common informational objects which might help a receiver
620 interpret the meaning, details, or importance of a notification.";
621 leaf notification-time {
622 type yang:date-and-time;
623 mandatory true;
624 description
625 "Time the system recognized the occurrence of an event.";
626 }
627 leaf-list subscription-id {
628 type uint32;
629 description
630 "Id of the subscription which led to the notification being
631 generated.";
632 }
633 leaf notification-id {
634 type uint32;
635 description
636 "Identifier for the notification record.";
637 }
638 leaf observation-domain-id {
639 type string;
640 description
641 "Software entity which created the notification record (e.g.,
642 process id).";
643 }
644 }
646 /*
647 * YANG-DATA messages for receivers
648 */
650 /* Message to a receiver containing one notification.*/
651 rc:yang-data message {
652 container message-header {
653 description
654 "delineates header info from content for easy parsing.";
655 uses notification-header;
656 uses message-header;
657 }
658 anydata notification-contents {
659 description
660 "Non-header info of what actually got sent to receiver. This
661 includes after any content based security filtering. Need to
662 determine if/how it is viable not to include tag encapsulation
663 for this object.";
664 }
665 }
667 /* Message to a receiver containing many bundled notifications.*/
668 rc:yang-data bundled-message {
669 container bundled-message-header {
670 description
671 "Header info for messages.";
672 uses message-header {
673 refine message-time {
674 mandatory true;
675 }
676 }
677 leaf notification-count {
678 type uint16;
679 description
680 "Quantity of notification records in a bundled-message
681 specific receiver.";
682 }
683 }
684 list notifications {
685 description
686 "Set of notifications to a receiver.";
687 container notification-header {
688 description
689 "Header info for each bundled notification.";
690 uses notification-header;
691 }
692 anydata notification-contents {
693 description
694 "Non-header info of what actually got sent to receiver. This
695 includes after any content based security filtering. Need to
696 determine if/how it is viable not to include tag encapsulation
697 for this object.";
698 }
699 }
700 }
702 /*
703 * DATA-NODES
704 */
706 container additional-default-headers {
707 if-feature "publisher";
708 description
709 "This container maintains a list of which additional notifications
710 should use which common headers if the receiver supports this
711 specification. The name starts with additional because there are
712 some mandatory common headers not listed in the container. These
713 headers are (1) message-time and (2) subscription-id.";
714 leaf-list additional-headers {
715 type common-header;
716 description
717 "This list contains the additional default headers which are to
718 be applied to each message from this publisher.";
719 }
720 list notification-specific-default {
721 key "module notification";
722 description
723 "For any included notification, this list provides additional
724 common headers.";
725 leaf module {
726 type yang:yang-identifier;
727 description
728 "Name of the module containing a notification.";
729 }
730 leaf notification {
731 type string {
732 pattern 'notification $|yang-data $';
733 }
734 description
735 "The name of the notification or yang-data being sent.";
736 }
737 leaf-list per-notification-headers {
738 type common-header;
739 description
740 "The set of additional default headers for a specific
741 notification.";
742 }
743 }
744 }
745 }
746
748 8. Backwards Compatibility
750 With this specification, there is no change to YANG's 'notification'
751 statement
753 Legacy clients are unaffected, and existing users of [RFC5277],
754 [RFC7950], and [RFC8040] are free to use current behaviors until all
755 involved device support this specification.
757 9. Security Considerations
759 Certain headers might be computationally complex for a publisher to
760 deliver. Signatures or encryption are two examples of this. It MUST
761 be possible to suspend or terminate a subscription due to lack of
762 resources based on this reason.
764 Decisions on whether to bundle or not to a receiver are fully under
765 the purview of the Publisher. A receiver could slow delivery to
766 existing subscriptions by creating new ones. (Which would result in
767 the publisher going into a bundling mode.)
769 10. Acknowledgments
771 For their valuable comments, discussions, and feedback, we wish to
772 acknowledge Martin Bjorklund and Kent Watsen.
774 11. References
776 11.1. Normative References
778 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
779 Requirement Levels", BCP 14, RFC 2119,
780 DOI 10.17487/RFC2119, March 1997,
781 .
783 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
784 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
785 .
787 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
788 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
789 May 2017, .
791 [subscribe]
792 Voit, E., Clemm, A., Gonzalez Prieto, A., Prasad Tripathy,
793 A., and E. Nilsen-Nygaard, "Custom Subscription to Event
794 Notifications", September 2017,
795 .
798 11.2. Informative References
800 [http-push]
801 Voit, Eric., Clemm, Alexander., Tripathy, A., Nilsen-
802 Nygaard, E., and Alberto. Gonzalez Prieto, "Restconf and
803 HTTP transport for event notifications", August 2016,
804 .
807 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
808 and A. Bierman, Ed., "Network Configuration Protocol
809 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
810 .
812 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
813 RFC 7950, DOI 10.17487/RFC7950, August 2016,
814 .
816 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
817 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
818 .
820 [yang-push]
821 Clemm, A., Voit, E., Gonzalez Prieto, A., Prasad Tripathy,
822 A., and E. Nilsen-Nygaard, "Subscribing to YANG datastore
823 push updates", April 2017,
824 .
827 Appendix A. Changes between revisions
829 (To be removed by RFC editor prior to publication)
831 v00 - v01
833 o Alternative to 5277 one-way notification added
835 o Storage of default headers by notification type
837 o Backwards compatibility
839 o Capability discovery
841 o Move to yang-data
843 o Removed dscp and record-type as common headers. (Record type can
844 be determined by the namespace of the record contents. Dscp is
845 useful where applications need internal communications within a
846 Publisher, but it is unclear as to whether this use case need be
847 exposed to a receiver.
849 Appendix B. Issues being worked
851 (To be removed by RFC editor prior to publication)
853 Is this capability just for notifications, or is it for any yang-data
854 element too?
856 Improved discovery mechanisms for NETCONF
858 Do we want to have additional headers for a specific notification?
859 Right now this is included, but it could be excluded.
861 Should we defer support for HTTP2 configured subscriptions until this
862 draft is available? Without capabilities exchange, it might just be
863 easier to wait.
865 Encoding of notification-contents so that individual notification
866 framing isn't needed.
868 We need to link to Andy Bierman's anydata extensibility draft.
870 Appendix C. Subscription Specific Headers
872 (To be removed by RFC editor prior to publication)
874 This section discusses a future functional addition which could
875 leverage this draft. It is included for informational purposes only.
877 A dynamic subscriber might want to mandate that certain headers be
878 used for push updates from a publisher. Some examples of this
879 include a subscriber requesting to:
881 o establish this subscription, but just if transport messages
882 containing the pushed data will be encrypted,
884 o establish this subscription, but only if you can attest to the
885 information being delivered in requested notification records, or
887 o provide a sequence-id for all messages to this receiver (in order
888 to check for loss).
890 Providing this type of functionality would necessitate a new revision
891 of the [subscribe]'s RPCs and state change notifications.
892 Subscription specific header information would overwrite the default
893 headers identified in this document.
895 Appendix D. Implications to Existing RFCs
897 (To be removed by RFC editor prior to publication)
899 YANG one-way exchanges currently use a non-extensible header and
900 encoding defined in section 4 of RFC-5277. These RFCs MUST be
901 updated to enable this draft. These RFCs SHOULD be updated to
902 provide examples
904 D.1. Implications to RFC-7950
906 Sections which expose netconf:capability:notification:1.0 are 4.2.10
907 Sections which provide examples using netconf:notification:1.0 are
908 7.10.4, 7.16.3, and 9.9.6
910 D.2. Implications to RFC-8040
912 Section 6.4 demands use of RFC-5277's netconf:notification:1.0, and
913 later in the section provides an example.
915 Authors' Addresses
917 Eric Voit
918 Cisco Systems
920 Email: evoit@cisco.com
922 Andy Bierman
923 YumaWorks
925 Email: andy@yumaworks.com
927 Alexander Clemm
928 Huawei
930 Email: ludwig@clemm.org
932 Tim Jenkins
933 Cisco Systems
935 Email: timjenki@cisco.com