idnits 2.17.1
draft-ietf-netconf-notification-messages-05.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
== Line 249 has weird spacing: '...gorithm str...'
== Line 253 has weird spacing: '...gorithm str...'
-- The document date (February 15, 2019) is 1896 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)
== Outdated reference: A later version (-26) exists of
draft-ietf-netconf-subscribed-notifications-16
Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 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 H. Birkholz
5 Expires: August 19, 2019 Fraunhofer SIT
6 A. Bierman
7 YumaWorks
8 A. Clemm
9 Huawei
10 T. Jenkins
11 Cisco Systems
12 February 15, 2019
14 Notification Message Headers and Bundles
15 draft-ietf-netconf-notification-messages-05
17 Abstract
19 This document defines a new notification message format, using yang-
20 data. Included are:
22 o a new notification mechanism and encoding to replace the one way
23 operation of RFC-5277
25 o a set of common, transport agnostic message header objects.
27 o how to bundle multiple event records into a single notification
28 message.
30 o how to ensure these new capabilities are only used with capable
31 receivers.
33 Status of This Memo
35 This Internet-Draft is submitted in full conformance with the
36 provisions of BCP 78 and BCP 79.
38 Internet-Drafts are working documents of the Internet Engineering
39 Task Force (IETF). Note that other groups may also distribute
40 working documents as Internet-Drafts. The list of current Internet-
41 Drafts is at https://datatracker.ietf.org/drafts/current/.
43 Internet-Drafts are draft documents valid for a maximum of six months
44 and may be updated, replaced, or obsoleted by other documents at any
45 time. It is inappropriate to use Internet-Drafts as reference
46 material or to cite them other than as "work in progress."
48 This Internet-Draft will expire on August 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
69 3. Header Objects . . . . . . . . . . . . . . . . . . . . . . . 3
70 4. Encapsulation of Header Objects in Messages . . . . . . . . . 4
71 4.1. One Notification per Message . . . . . . . . . . . . . . 5
72 4.2. Many Notifications per Message . . . . . . . . . . . . . 5
73 5. Configuration of Headers . . . . . . . . . . . . . . . . . . 8
74 6. Discovering Receiver Support . . . . . . . . . . . . . . . . 9
75 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 10
76 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18
77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
80 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
81 11.2. Informative References . . . . . . . . . . . . . . . . . 19
82 Appendix A. Changes between revisions . . . . . . . . . . . . . 20
83 Appendix B. Issues being worked . . . . . . . . . . . . . . . . 21
84 Appendix C. Subscription Specific Headers . . . . . . . . . . . 21
85 Appendix D. Implications to Existing RFCs . . . . . . . . . . . 22
86 D.1. Implications to RFC-7950 . . . . . . . . . . . . . . . . 22
87 D.2. Implications to RFC-8040 . . . . . . . . . . . . . . . . 22
88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
90 1. Introduction
92 Mechanisms to support subscription to event notifications and yang
93 datastore push are being defined in
94 [I-D.draft-ietf-netconf-subscribed-notifications] and
95 [I-D.ietf-netconf-yang-push]. Work on those documents has shown that
96 notifications described in [RFC7950] section 7.16 could benefit from
97 transport independent headers. Communicating the following
98 information to receiving applications can be done without explicit
99 linkage to an underlying transport protocol:
101 o the time information was generated
103 o the time the information was placed in a message and queued for
104 transport
106 o a signature to verify authenticity
108 o the process generating the information
110 o an originating request correlation
112 o an ability to bundle information records into one a message
114 o the ability to check for message loss/reordering
116 The document describes information elements needed for the functions
117 above. It also provides YANG structures for sending messages
118 containing one or more events and/or update records 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 RFC 7950 [RFC7950]. Publisher,
129 receiver, subscription, and event occurence time are defined in
130 [I-D.draft-ietf-netconf-subscribed-notifications].
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 time an event, datastore update, or other
142 item is recognized and recorded within the publisher.
144 o notification-id: Identifies the name of the notification, per the
145 YANG notification statement. May also provide the name of a yang-
146 data statement (whether transporting other types of messages is in
147 scope is tbd).
149 o observation-domain-id: identifies the publisher process which
150 discovered and recorded the event notification. (note: look to
151 reuse the domains set up with IPFIX.)
153 o message-time: the time the message was packaged sent to the
154 transport layer for delivery to the receiver.
156 o signature: allows an application to sign a message so that a
157 receiver can verify the authenticity of the message.
159 o message-id: for a specific message generator, this identifies a
160 message which includes one or more event records. The message-id
161 increments by one with sequential messages.
163 o message-generator-id: identifier for the process which created the
164 message. This allows disambiguation of an information source,
165 such as the identification of different line cards sending the
166 messages. Used in conjunction with previous-message-id, this can
167 help find drops and duplications when messages are coming from
168 multiple sources on a device. If there is a message-generator-id
169 in the header, then the previous-message-id MUST be the message-id
170 from the last time that message-generator-id was sent.
172 4. Encapsulation of Header Objects in Messages
174 A specific set of well-known objects are of potential use to
175 networking layers prior being interpreted by some receiving
176 application layer process. By exposing this object information as
177 part of a header, and by using standardized object names, it becomes
178 possible for this object information to be leveraged in transit.
180 The objects defined in the previous section are these well-known
181 header objects. These objects are identified within a dedicated
182 header subtree which leads off a particular transportable message.
183 This allows header objects to be easily be decoupled, stripped, and
184 processed separately.
186 There are two types of transportable messages: one format is used
187 when there is one notification being encapsulated, and another format
188 used when there are many notifications being bundled into one
189 message.
191 A receiver which supporting this document MUST be able to handle
192 receipt of either type of message from an publisher. It is possible
193 that changes between message types can occur without any prior
194 indication.
196 4.1. One Notification per Message
198 This section will be re-instated if NETCONF WG members are not
199 comfortable with the efficiency of the solution which can encode many
200 notifications per message described below.
202 4.2. Many Notifications per Message
204 While possible in some scenarios, it often inefficient to marshal and
205 transport every notification independently. Instead, scale and
206 processing speed can be improved by placing multiple notifications
207 into one transportable bundle.
209 The format of this bundle appears in the yata-data tree below, and is
210 more completely defined in the yang module. There are three parts of
211 this bundle:
213 o a message header describing the marshaling, including information
214 such as when the marshaling occurred
216 o a list of encapsulated information
218 o an optional message footer for whole-message signing and message-
219 generator integrity verification.
221 Within the list of encapsulated notifications, there are also three
222 parts:
224 o a notification header defining what is in an encapsulated
225 notification
227 o the actual notification itself
229 o an optional notification footer for individual notification
230 signing and observation-domain integrity verification.
232 yang-data message
233 +--ro message!
234 +--ro message-header
235 | +--ro message-time yang:date-and-time
236 | +--ro message-id? uint32
237 | +--ro message-generator-id? string
238 | +--ro notification-count? uint16
239 +--ro notifications*
240 | +--ro notification-header
241 | | +--ro notification-time yang:date-and-time
242 | | +--ro yang-module? yang:yang-identifier
243 | | +--ro yang-notification-name? notification-type
244 | | +--ro subscription-id* uint32
245 | | +--ro notification-id? uint32
246 | | +--ro observation-domain-id? string
247 | +--ro notification-contents?
248 | +--ro notification-footer!
249 | +--ro signature-algorithm string
250 | +--ro signature-value string
251 | +--ro integrity-evidence? string
252 +--ro message-footer!
253 +--ro signature-algorithm string
254 +--ro signature-value string
255 +--ro integrity-evidence? string
257 An XML instance of a message might look like:
259
261
262
263 2017-02-14T00:00:05Z
264
265
266 456
267
268
269 2
270
271
272
273
274
275
276 2017-02-14T00:00:02Z
277
278
279 823472
280
281
282 ietf-yang-push
283
284
285 push-change-update
286
287
288
289
291
292
293
295
296
297
298
299
300
301 ...(record #2)...
302
303
304
306 5. Configuration of Headers
308 A publisher MUST select the set of headers to use within any
309 particular message. The two mandatory headers which MUST always be
310 applied are 'message-time' and 'subscription-id'
312 Beyond these two mandatory headers, additional headers MAY be
313 included. Configuration of what these optional headers should be can
314 come from the following sources:
316 1. Publisher wide default headers for all notifications. These are
317 included if an optional header is inserted into 'additional-
318 headers' leaf-list shown in the yang tree below.
320 2. More notification specific headers may also be desired. If new
321 headers are needed for a specific type of YANG notification,
322 these can be populated through 'additional-notification-headers'
323 leaf-list.
325 3. An application process may also identify common headers to use
326 when transporting notifications for a specific subscription. How
327 these are identified to a publisher is out-of-scope.
329 The set of headers used for any particular message is the superset of
330 headers for the items listed above.
332 The YANG tree showing elements of configuration is depicted in the
333 following figure.
335 module: ietf-notification-messages
336 +--rw additional-default-headers {publisher}?
337 +--rw additional-headers* optional-header
338 +--rw yang-notification-specific-default*
339 | [yang-module yang-notification-name]
340 +--rw yang-module yang:yang-identifier
341 +--rw yang-notification-name notification-type
342 +--rw additional-notification-headers*
343 optional-notification-header
345 Configuration Model structure
347 Of note in this tree is the optional feature of 'publisher'. This
348 feature indicates an ability to send notifications. A publisher
349 supporting this specification MUST also be able to parse any messages
350 received as defined in this document.
352 6. Discovering Receiver Support
354 We need capability exchange from the receiver to the publisher at
355 transport session initiation to indicate support for this
356 specification.
358 For all types of transport connections, if the receiver indicates
359 support for this specification, then it MAY be used. In addition,
360 [RFC5277] one-way notifications MUST NOT be used if the receiver
361 indicates support for this specification to a publisher which also
362 supports it.
364 Where NETCONF transport is used, advertising this specification's
365 namespace during an earlier client capabilities discovery phase MAY
366 be used to indicate support for this specification:
368
369
370
371 urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0
372
373
374 4
375
377 NOTE: It is understood that even though it is allowed in [RFC6241]
378 section 8.1, robust NETCONF client driven capabilities exchange is
379 not something which is common in implementation. Therefore reviewers
380 are asked to submit alternative proposals to the mailing list.
382 For RESTCONF, a mechanism for capability discovery is TBD. Proposals
383 are also welcome here.
385 The mechanism described above assumes that a capability discovery
386 phase happens before a subscription is started. This is not always
387 the case. As an example, consider HTTP2 configured subscriptions
388 from section 3.1.3 of [I-D.draft-ietf-netconf-restconf-notif], there
389 is no guarantee that a capability exchange has taken place before the
390 updates are pushed. A solution for this could be that a receiver
391 would reply "ok" and reply with the client capabilities as part of
392 the POST. (Or just use a different HTTP status code like 202 instead
393 of 200 'ok'). As such a requirement creates a new dependency for
394 [I-D.draft-ietf-netconf-restconf-notif] upon this specification, more
395 discussion is required to decide if this is a viable solution.
397 7. YANG Module
399 file "ietf-notification-messages@2018-01-31.yang"
401 module ietf-notification-messages {
402 yang-version 1.1;
403 namespace
404 "urn:ietf:params:xml:ns:yang:ietf-notification-messages";
405 prefix nm;
407 import ietf-yang-types { prefix yang; }
408 import ietf-restconf { prefix rc; }
410 organization "IETF";
411 contact
412 "WG Web:
413 WG List:
415 Editor: Eric Voit
416
418 Editor: Henk Birkholz
419
421 Editor: Alexander Clemm
422
424 Editor: Andy Bierman
425
427 Editor: Tim Jenkins
428 ";
430 description
431 "This module contains conceptual YANG specifications for yang-data
432 messages carrying notifications with well known header objects.";
434 revision 2018-01-31 {
435 description
436 "Initial version.";
438 reference
439 "draft-ietf-netconf-notification-messages-03";
440 }
442 /*
443 * FEATURES
444 */
446 feature publisher {
447 description
448 "This feature indicates that support for both publisher and
449 receiver of messages complying to the specification.";
450 }
452 /*
453 * IDENTITIES
454 */
456 /* Identities for common headers */
458 identity common-header {
459 description
460 "A well known header which can be included somewhere within a
461 message.";
462 }
464 identity message-time {
465 base common-header;
466 description
467 "Header information consisting of time the message headers were
468 placed generated prior to being sent to transport";
469 }
471 identity subscription-id {
472 base common-header;
473 description
474 "Header information consisting of the identifier of the
475 subscription associated with the notification being
476 encapsulated.";
477 }
479 identity notification-count {
480 base common-header;
481 description
482 "Header information consisting of the quantity of notifications in
483 a bundled-message for a specific receiver.";
484 }
486 identity optional-header {
487 base common-header;
488 description
489 "A well known header which an application may choose to include
490 within a message.";
491 }
492 identity message-id {
493 base optional-header;
494 description
495 "Header information that identifies a message to a specific
496 receiver";
497 }
499 identity message-generator-id {
500 base optional-header;
501 description
502 "Header information consisting of an identifier for a software
503 entity which created the message (e.g., linecard 1).";
504 }
506 identity message-signature {
507 base optional-header;
508 description
509 "Identifies two elements of header information consisting of a
510 signature and the signtature type for the contents of a message.
511 Signatures can be useful for originating applications to
512 verify record contents even when shipping over unsecure
513 transport.";
514 }
516 identity message-integrity-evidence {
517 base optional-header;
518 description
519 "Header information consisting of the information which backs up
520 the assertions made as to the validity of the information
521 provided within the message.";
522 }
524 identity optional-notification-header {
525 base optional-header;
526 description
527 "A well known header which an application may choose to include
528 within a message.";
529 }
531 identity notification-time {
532 base optional-notification-header;
533 description
534 "Header information consisting of the time an originating process
535 created the notification.";
536 }
538 identity notification-id {
539 base optional-notification-header;
540 description
541 "Header information consisting of an identifier for an instance
542 of a notification egressing a publisher. ";
543 }
545 identity observation-domain-id {
546 base optional-notification-header;
547 description
548 "Header information identifying the software entity which created
549 the notification (e.g., process id).";
550 }
552 identity notification-signature {
553 base optional-notification-header;
554 description
555 "Header information consisting of the information which backs up
556 the assertions made as to the validity of the information
557 provided within the notification.";
558 }
560 identity notification-integrity-evidence {
561 base optional-notification-header;
562 description
563 "Header information consisting of the information which backs up
564 the assertions made as to the validity of the information
565 provided within the notification.";
566 }
568 /*
569 * TYPEDEFs
570 */
572 typedef optional-header {
573 type identityref {
574 base optional-header;
575 }
576 description
577 "Type of header object which may be included somewhere within a
578 message.";
579 }
581 typedef optional-notification-header {
582 type identityref {
583 base optional-notification-header;
584 }
585 description
586 "Type of header object which may be included somewhere within a
587 message.";
588 }
590 typedef notification-type {
591 type string {
592 pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
593 }
594 description
595 "The name of a notification within a YANG module.";
596 reference
597 "RFC-7950 Section 7.16";
598 }
600 /*
601 * GROUPINGS
602 */
604 grouping message-header {
605 description
606 "Header information included with a message.";
607 leaf message-time {
608 type yang:date-and-time;
609 mandatory true;
610 description
611 "time the message was generated prior to being sent to
612 transport.";
613 }
614 leaf message-id {
615 type uint32;
616 description
617 "Id for a message going to a receiver from a message
618 generator. The id will increment by one with each message sent
619 from a particular message generator, allowing the message-id
620 to be used as a sequence number.";
621 }
622 leaf message-generator-id {
623 type string;
624 description
625 "Software entity which created the message (e.g., linecard 1).
626 The combination of message-id and message-generator-id must be
627 unique until reset or a roll-over occurs.";
628 }
629 leaf notification-count {
630 type uint16;
631 description
632 "Quantity of notification records in a bundled-message
633 specific receiver.";
634 }
635 }
637 grouping notification-within-a-module {
638 description
639 "A location of a notification within a yang model.";
640 leaf yang-module {
641 type yang:yang-identifier;
642 description
643 "Name of the YANG module supported by the publisher.";
644 }
645 leaf yang-notification-name {
646 type notification-type;
647 description
648 "The name of a notification likely from a YANG module. Note
649 that this object should be in the notification contents, so a
650 debate is needed whether this is redundant.";
651 }
652 }
654 grouping notification-header {
655 description
656 "Common informational objects which might help a receiver
657 interpret the meaning, details, or importance of a notification.";
658 leaf notification-time {
659 type yang:date-and-time;
660 mandatory true;
661 description
662 "Time the system recognized the occurrence of an event.";
663 }
664 uses notification-within-a-module;
665 leaf-list subscription-id {
666 type uint32;
667 description
668 "Id of the subscription which led to the notification being
669 generated.";
670 }
671 leaf notification-id {
672 type uint32;
673 description
674 "Identifier for the notification record.";
675 }
676 leaf observation-domain-id {
677 type string;
678 description
679 "Software entity which created the notification record (e.g.,
680 process id).";
682 }
683 }
685 grouping security-footer {
686 description
687 "Reusable grouping for common objects which apply to the the
688 signing of notifications or messages.";
689 leaf signature-algorithm {
690 type string;
691 mandatory true;
692 description
693 "The technology with which an originator signed of some
694 delineated contents.";
695 }
696 leaf signature-value {
697 type string;
698 mandatory true;
699 description
700 "Any originator signing of the contents of a header and
701 content. This is useful for verifying contents even when
702 shipping over unsecure transport.";
703 }
704 leaf integrity-evidence {
705 type string;
706 description
707 "This mechanism allows a verifier to ensure that the use of the
708 private key, represented by the corresponding public key
709 certificate, was performed with a TCG compliant TPM
710 environment. This evidence is never included in within any
711 signature.";
712 reference
713 "TCG Infrastructure Workgroup, Subject Key Attestation Evidence
714 Extension, Specification Version 1.0, Revision 7.";
715 }
716 }
718 /*
719 * YANG-DATA messages for receivers
720 */
722 rc:yang-data message {
723 container message {
724 presence
725 "Indicates attempt to communicate notifications to a receiver.";
726 description
727 "Message to a receiver containing one or more notifications";
729 container message-header {
730 description
731 "Header info for messages.";
732 uses message-header;
733 }
734 list notifications {
735 description
736 "Set of notifications to a receiver.";
737 container notification-header {
738 description
739 "Header info for a notification.";
740 uses notification-header;
741 }
742 anydata notification-contents {
743 description
744 "Encapsulates objects following YANG's notification-stmt
745 grammar of RFC-7950 section 14. Within are the notified
746 objects the publisher actually generated in order to be
747 passed to a receiver after all filtering has completed.";
748 }
749 container notification-footer {
750 presence
751 "Indicates attempt to secure a notification.";
752 description
753 "Signature and evidence for messages.";
754 uses security-footer;
755 }
756 }
757 container message-footer {
758 presence
759 "Indicates attempt to secure the entire message.";
760 description
761 "Signature and evidence for messages.";
762 uses security-footer;
763 }
764 }
765 }
767 /*
768 * DATA-NODES
769 */
771 container additional-default-headers {
772 if-feature "publisher";
773 description
774 "This container maintains a list of which additional notifications
775 should use which optional headers if the receiver supports this
776 specification.";
778 leaf-list additional-headers {
779 type optional-header;
780 description
781 "This list contains the identities of the optional header types
782 which are to be included within each message from this
783 publisher.";
784 }
785 list yang-notification-specific-default {
786 key "yang-module yang-notification-name";
787 description
788 "For any included YANG notifications, this list provides
789 additional optional headers which should be placed within the
790 container notification-header if the receiver supports this
791 specification. This list incrementally adds to any headers
792 indicated within the leaf-list 'additional-headers'.";
793 uses notification-within-a-module;
794 leaf-list additional-notification-headers {
795 type optional-notification-header;
796 description
797 "The set of additional default headers which will be sent
798 for a specific YANG notification.";
799 }
800 }
801 }
802 }
804
806 8. Backwards Compatibility
808 With this specification, there is no change to YANG's 'notification'
809 statement
811 Legacy clients are unaffected, and existing users of [RFC5277],
812 [RFC7950], and [RFC8040] are free to use current behaviors until all
813 involved device support this specification.
815 9. Security Considerations
817 Certain headers might be computationally complex for a publisher to
818 deliver. Signatures or encryption are two examples of this. It MUST
819 be possible to suspend or terminate a subscription due to lack of
820 resources based on this reason.
822 Decisions on whether to bundle or not to a receiver are fully under
823 the purview of the Publisher. A receiver could slow delivery to
824 existing subscriptions by creating new ones. (Which would result in
825 the publisher going into a bundling mode.)
827 10. Acknowledgments
829 For their valuable comments, discussions, and feedback, we wish to
830 acknowledge Martin Bjorklund, Einar Nilsen-Nygaard, and Kent Watsen.
832 11. References
834 11.1. Normative References
836 [I-D.draft-ietf-netconf-subscribed-notifications]
837 Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A.,
838 and E. Nilsen-Nygaard, "Custom Subscription to Event
839 Streams", draft-ietf-netconf-subscribed-notifications-16
840 (work in progress), August 2018.
842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
843 Requirement Levels", BCP 14, RFC 2119,
844 DOI 10.17487/RFC2119, March 1997,
845 .
847 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
848 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
849 .
851 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
852 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
853 May 2017, .
855 11.2. Informative References
857 [I-D.draft-ietf-netconf-restconf-notif]
858 Voit, Eric., Clemm, Alexander., Tripathy, A., Nilsen-
859 Nygaard, E., and Alberto. Gonzalez Prieto, "Restconf and
860 HTTP transport for event notifications", June 2018,
861 .
864 [I-D.ietf-netconf-yang-push]
865 Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto.,
866 Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B.
867 Lengyel, "YANG Datastore Subscription", August 2018,
868 .
871 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
872 and A. Bierman, Ed., "Network Configuration Protocol
873 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
874 .
876 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
877 RFC 7950, DOI 10.17487/RFC7950, August 2016,
878 .
880 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
881 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
882 .
884 Appendix A. Changes between revisions
886 (To be removed by RFC editor prior to publication)
888 v04 - v05
890 o Revision before expiration. Awaiting closure of SN and YP prior
891 to update.
893 v03 - v04
895 o Terminology tweaks.
897 o Revision before expiration. Awaiting closure of SN prior to
898 update.
900 v02 - v03
902 o Removed the option for an unbundled message. This might be re-
903 added later for transport efficiency if desired by the WG
905 o New message structure driven by the desire to put the signature
906 information at the end.
908 v01 - v02
910 o Fixed the yang-data encapsulation container issue
912 o Updated object definitions to point to RFC-7950 definitions
914 o Added headers for module and notification-type.
916 v00 - v01
918 o Alternative to 5277 one-way notification added
920 o Storage of default headers by notification type
922 o Backwards compatibility
923 o Capability discovery
925 o Move to yang-data
927 o Removed dscp and record-type as common headers. (Record type can
928 be determined by the namespace of the record contents. Dscp is
929 useful where applications need internal communications within a
930 Publisher, but it is unclear as to whether this use case need be
931 exposed to a receiver.
933 Appendix B. Issues being worked
935 (To be removed by RFC editor prior to publication)
937 Is this capability just for notifications, or is it for any yang-data
938 element too?
940 A complete JSON document is supposed to be sent as part of Media Type
941 "application/yang-data+json". As we are sending separate
942 notifications after each other, we need to choose whether we start
943 with some extra encapsulation for the very first message pushed, or
944 if we want a new Media Type for streaming updates.
946 Improved discovery mechanisms for NETCONF
948 Should we defer support for HTTP2 configured subscriptions until this
949 draft is available? Without capabilities exchange, it might just be
950 easier to wait. In addition, JSON encoding still needs a
951 notification type which is not exising or represented in
952 referenceable in existing yang-models.
954 Need to ensure the proper references exist to a notification
955 definition driven by RFC-7950 which is acceptable to other eventual
956 users of this specification.
958 We need to link to Andy Bierman's anydata extensibility draft for
959 informational purposes. This is under a WG adoption call.
961 Appendix C. Subscription Specific Headers
963 (To be removed by RFC editor prior to publication)
965 This section discusses a future functional addition which could
966 leverage this draft. It is included for informational purposes only.
968 A dynamic subscriber might want to mandate that certain headers be
969 used for push updates from a publisher. Some examples of this
970 include a subscriber requesting to:
972 o establish this subscription, but just if transport messages
973 containing the pushed data will be encrypted,
975 o establish this subscription, but only if you can attest to the
976 information being delivered in requested notification records, or
978 o provide a sequence-id for all messages to this receiver (in order
979 to check for loss).
981 Providing this type of functionality would necessitate a new revision
982 of the [I-D.draft-ietf-netconf-subscribed-notifications]'s RPCs and
983 state change notifications. Subscription specific header information
984 would overwrite the default headers identified in this document.
986 Appendix D. Implications to Existing RFCs
988 (To be removed by RFC editor prior to publication)
990 YANG one-way exchanges currently use a non-extensible header and
991 encoding defined in section 4 of RFC-5277. These RFCs MUST be
992 updated to enable this draft. These RFCs SHOULD be updated to
993 provide examples
995 D.1. Implications to RFC-7950
997 Sections which expose netconf:capability:notification:1.0 are 4.2.10
999 Sections which provide examples using netconf:notification:1.0 are
1000 7.10.4, 7.16.3, and 9.9.6
1002 D.2. Implications to RFC-8040
1004 Section 6.4 demands use of RFC-5277's netconf:notification:1.0, and
1005 later in the section provides an example.
1007 Authors' Addresses
1009 Eric Voit
1010 Cisco Systems
1012 Email: evoit@cisco.com
1014 Henk Birkholz
1015 Fraunhofer SIT
1017 Email: henk.birkholz@sit.fraunhofer.de
1018 Andy Bierman
1019 YumaWorks
1021 Email: andy@yumaworks.com
1023 Alexander Clemm
1024 Huawei
1026 Email: ludwig@clemm.org
1028 Tim Jenkins
1029 Cisco Systems
1031 Email: timjenki@cisco.com