idnits 2.17.1
draft-ietf-netconf-notification-messages-07.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 242 has weird spacing: '...gorithm str...'
== Line 246 has weird spacing: '...gorithm str...'
-- The document date (August 15, 2019) is 1708 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)
== Unused Reference: 'I-D.draft-ietf-netconf-restconf-notif' is defined on
line 846, but no explicit reference was found in the text
== Outdated reference: A later version (-26) exists of
draft-ietf-netconf-subscribed-notifications-16
Summary: 2 errors (**), 0 flaws (~~), 5 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: February 16, 2020 Fraunhofer SIT
6 A. Bierman
7 YumaWorks
8 A. Clemm
9 Futurewei
10 T. Jenkins
11 Cisco Systems
12 August 15, 2019
14 Notification Message Headers and Bundles
15 draft-ietf-netconf-notification-messages-07
17 Abstract
19 This document defines a new notification message format. Included
20 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 February 16, 2020.
50 Copyright Notice
52 Copyright (c) 2019 IETF Trust and the persons identified as the
53 document authors. All rights reserved.
55 This document is subject to BCP 78 and the IETF Trust's Legal
56 Provisions Relating to IETF Documents
57 (https://trustee.ietf.org/license-info) in effect on the date of
58 publication of this document. Please review these documents
59 carefully, as they describe your rights and restrictions with respect
60 to this document. Code Components extracted from this document must
61 include Simplified BSD License text as described in Section 4.e of
62 the Trust Legal Provisions and are provided without warranty as
63 described in the Simplified BSD License.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 4
72 4.2. Many Notifications per Message . . . . . . . . . . . . . 5
73 5. Configuration of Headers . . . . . . . . . . . . . . . . . . 8
74 6. Discovering Receiver Support . . . . . . . . . . . . . . . . 9
75 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 9
76 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18
77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
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 have been
93 defined in [I-D.draft-ietf-netconf-subscribed-notifications] and
94 [I-D.ietf-netconf-yang-push]. Work on those documents has shown that
95 notifications described in [RFC7950] section 7.16 could benefit from
96 transport independent headers. With such headers, communicating the
97 following information to receiving applications can be done without
98 explicit linkage to an underlying transport protocol:
100 o the time the notification was generated
102 o the time the notification was placed in a message and queued for
103 transport
105 o an identifier for the process generating the notification
107 o signatures to verify authenticity
109 o a subscription id which allows a notification be correlated with a
110 request for that notification
112 o multiple notifications bundled into one transportable message
114 o a message-id allowing a receiver to check for message loss/
115 reordering
117 The document describes information elements needed for the functions
118 above. It also provides instances of YANG structures
119 [I-D.draft-ietf-netmod-yang-data-ext] for sending messages containing
120 one or more notifications to a receiver.
122 2. Terminology
124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
126 "OPTIONAL" in this document are to be interpreted as described in BCP
127 14 [RFC2119] [RFC8174] when, and only when, they appear in all
128 capitals, as shown here.
130 The definition of notification is in [RFC7950] Section 4.2.10.
131 Publisher, receiver, subscription, and event occurrence time are
132 defined in [I-D.draft-ietf-netconf-subscribed-notifications].
134 3. Header Objects
136 There are a number of transport independent headers which should have
137 common definition. These include:
139 o subscription-id: provides a reference into the reason the
140 publisher believed the receiver wishes to be notified of this
141 specific information.
143 o notification-time: the origination time where a notification was
144 fully generated within the publisher.
146 o notification-id: Identifies an instance of an emitted notification
147 to a receiver.
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 A receiver which supporting this document MUST be able to handle
187 receipt of either type of message from a publisher.
189 4.1. One Notification per Message
191 This section has been deleted from previous versions. It will be re-
192 instated if NETCONF WG members are not comfortable with the
193 efficiency of the solution which can encode many notifications per
194 message, as described below.
196 4.2. Many Notifications per Message
198 While possible in some scenarios, it often inefficient to marshal and
199 transport every notification independently. Instead, scale and
200 processing speed can be improved by placing multiple notifications
201 into one transportable bundle.
203 The format of this bundle appears in the YANG structure below, and is
204 fully defined in the YANG module. There are three parts of this
205 bundle:
207 o a message header describing the marshaling, including information
208 such as when the marshaling occurred
210 o a list of encapsulated information
212 o an optional message footer for whole-message signing and message-
213 generator integrity verification.
215 Within the list of encapsulated notifications, there are also three
216 parts:
218 o a notification header defining what is in an encapsulated
219 notification
221 o the actual notification itself
223 o an optional notification footer for individual notification
224 signing and observation-domain integrity verification.
226 structure message
227 +--ro message!
228 +--ro message-header
229 | +--ro message-time yang:date-and-time
230 | +--ro message-id? uint32
231 | +--ro message-generator-id? string
232 | +--ro notification-count? uint16
233 +--ro notifications*
234 | +--ro notification-header
235 | | +--ro notification-time yang:date-and-time
236 | | +--ro yang-module? yang:yang-identifier
237 | | +--ro subscription-id* uint32
238 | | +--ro notification-id? uint32
239 | | +--ro observation-domain-id? string
240 | +--ro notification-contents?
241 | +--ro notification-footer!
242 | +--ro signature-algorithm string
243 | +--ro signature-value string
244 | +--ro integrity-evidence? string
245 +--ro message-footer!
246 +--ro signature-algorithm string
247 +--ro signature-value string
248 +--ro integrity-evidence? string
250 An XML instance of a message might look like:
252
254
255
256 2017-02-14T00:00:05Z
257
258
259 456
260
261
262 2
263
264
265
266
267
268
269 2017-02-14T00:00:02Z
270
271
272 823472
273
274
275 ietf-yang-push
276
277
278 push-change-update
279
280
281
282
284
285
286
288
289
290
291
292
293
294 ...(record #2)...
295
296
297
299 5. Configuration of Headers
301 A publisher MUST select the set of headers to use within any
302 particular message. The two mandatory headers which MUST always be
303 applied are 'message-time' and 'subscription-id'
305 Beyond these two mandatory headers, additional headers MAY be
306 included. Configuration of what these optional headers should be can
307 come from the following sources:
309 1. Publisher wide default headers which are placed on all
310 notifications. An optional header is a publisher default if its
311 identity is included within the 'additional-headers' leaf-list.
313 2. More notification specific headers may also be desired. If new
314 headers are needed for a specific type of YANG notification,
315 these can be populated through 'additional-notification-headers'
316 leaf-list.
318 3. An application process may also identify common headers to use
319 when transporting notifications for a specific subscription. How
320 such application specific configuration is accomplished within
321 the publisher is out-of-scope.
323 The set of headers selected and populated for any particular message
324 is derived from the union of the mandatory headers and configured
325 optional headers.
327 The YANG tree showing elements of configuration is depicted in the
328 following figure.
330 module: ietf-notification-messages
331 +--rw additional-default-headers {publisher}?
332 +--rw additional-headers* optional-header
333 +--rw yang-notification-specific-default*
334 | [yang-module yang-notification-name]
335 +--rw yang-module yang:yang-identifier
336 +--rw yang-notification-name notification-type
337 +--rw additional-notification-headers*
338 optional-notification-header
340 Configuration Model structure
342 Of note in this tree is the optional feature of 'publisher'. This
343 feature indicates an ability to send notifications. A publisher
344 supporting this specification MUST also be able to parse any messages
345 received as defined in this document.
347 6. Discovering Receiver Support
349 We need capability exchange from the receiver to the publisher at
350 transport session initiation to indicate support for this
351 specification.
353 For all types of transport connections, if the receiver indicates
354 support for this specification, then it MAY be used. In addition,
355 [RFC5277] one-way notifications MUST NOT be used if the receiver
356 indicates support for this specification to a publisher which also
357 supports it.
359 Where NETCONF transport is used, advertising this specification's
360 namespace during an earlier client capabilities discovery phase MAY
361 be used to indicate support for this specification:
363
364
365
366 urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0
367
368
369 4
370
372 NOTE: It is understood that even though it is allowed in [RFC6241]
373 section 8.1, robust NETCONF client driven capabilities exchange is
374 not something which is common in implementation. Therefore reviewers
375 are asked to submit alternative proposals to the mailing list.
377 For RESTCONF, a mechanism for capability discovery is TBD. Proposals
378 are welcome here.
380 The mechanism described above assumes that a capability discovery
381 phase happens before a subscription is started. This is not always
382 the case. There is no guarantee that a capability exchange has taken
383 place before the messages are emitted. A solution for this in the
384 case of HTTP based transport could be that a receiver would have to
385 reply "ok" and also return the client capabilities as part a response
386 to the initiation of the POST.
388 7. YANG Module
390 file "ietf-notification-messages@2019-08-16.yang"
391 module ietf-notification-messages {
392 yang-version 1.1;
393 namespace
394 "urn:ietf:params:xml:ns:yang:ietf-notification-messages";
395 prefix nm;
397 import ietf-yang-types { prefix yang; }
398 import ietf-yang-structure-ext { prefix sx; }
400 organization "IETF";
401 contact
402 "WG Web:
403 WG List:
405 Editor: Eric Voit
406
408 Editor: Henk Birkholz
409
411 Editor: Alexander Clemm
412
414 Editor: Andy Bierman
415
417 Editor: Tim Jenkins
418 ";
420 description
421 "This module contains conceptual YANG specifications for
422 messages carrying notifications with well-known header objects.";
424 revision 2019-08-16 {
425 description
426 "Initial version.";
428 reference
429 "draft-ietf-netconf-notification-messages-07";
430 }
432 /*
433 * FEATURES
434 */
436 feature publisher {
437 description
438 "This feature indicates that support for both publisher and
439 receiver of messages complying to the specification.";
440 }
441 /*
442 * IDENTITIES
443 */
445 /* Identities for common headers */
447 identity common-header {
448 description
449 "A well-known header which can be included somewhere within a
450 message.";
451 }
453 identity message-time {
454 base common-header;
455 description
456 "Header information consisting of time the message headers were
457 generated prior to being sent to transport";
458 }
460 identity subscription-id {
461 base common-header;
462 description
463 "Header information consisting of the identifier of the
464 subscription associated with the notification being
465 encapsulated.";
466 }
468 identity notification-count {
469 base common-header;
470 description
471 "Header information consisting of the quantity of notifications in
472 a bundled-message for a specific receiver.";
473 }
475 identity optional-header {
476 base common-header;
477 description
478 "A well-known header which an application may choose to include
479 within a message.";
480 }
482 identity message-id {
483 base optional-header;
484 description
485 "Header information that identifies a message to a specific
486 receiver";
487 }
488 identity message-generator-id {
489 base optional-header;
490 description
491 "Header information consisting of an identifier for a software
492 entity which created the message (e.g., linecard 1).";
493 }
495 identity message-signature {
496 base optional-header;
497 description
498 "Identifies two elements of header information consisting of a
499 signature and the signature type for the contents of a message.
500 Signatures can be useful for originating applications to
501 verify record contents even when shipping over unsecure
502 transport.";
503 }
505 identity message-integrity-evidence {
506 base optional-header;
507 description
508 "Header information consisting of the information which backs up
509 the assertions made as to the validity of the information
510 provided within the message.";
511 }
513 identity optional-notification-header {
514 base optional-header;
515 description
516 "A well-known header which an application may choose to include
517 within a message.";
518 }
520 identity notification-time {
521 base optional-notification-header;
522 description
523 "Header information consisting of the time an originating process
524 created the notification.";
525 }
527 identity notification-id {
528 base optional-notification-header;
529 description
530 "Header information consisting of an identifier for an instance
531 of a notification. If access control based on a message's receiver may
532 strip information from within the notification, this notification-id MUST
533 allow the identification of the specific contents of notification as it
534 exits the publisher.";
536 }
538 identity observation-domain-id {
539 base optional-notification-header;
540 description
541 "Header information identifying the software entity which created
542 the notification (e.g., process id).";
543 }
545 identity notification-signature {
546 base optional-notification-header;
547 description
548 "Header information consisting of a signature which can be used to prove
549 the authenticity that some asserter validates over the information
550 provided within the notification.";
551 }
553 identity notification-integrity-evidence {
554 base optional-notification-header;
555 description
556 "Header information consisting of the information which backs up
557 the assertions made as to the validity of the information
558 provided within the notification.";
559 }
561 /*
562 * TYPEDEFs
563 */
565 typedef optional-header {
566 type identityref {
567 base optional-header;
568 }
569 description
570 "Type of header object which may be included somewhere within a
571 message.";
572 }
574 typedef optional-notification-header {
575 type identityref {
576 base optional-notification-header;
577 }
578 description
579 "Type of header object which may be included somewhere within a
580 message.";
581 }
582 typedef notification-type {
583 type string {
584 pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
585 }
586 description
587 "The name of a notification within a YANG module.";
588 reference
589 "RFC-7950 Section 7.16";
590 }
592 /*
593 * GROUPINGS
594 */
596 grouping message-header {
597 description
598 "Header information included with a message.";
599 leaf message-time {
600 type yang:date-and-time;
601 mandatory true;
602 description
603 "Time the message was generated prior to being sent to
604 transport.";
605 }
606 leaf message-id {
607 type uint32;
608 description
609 "Id for a message going to a receiver from a message
610 generator. The id will increment by one with each message sent
611 from a particular message generator, allowing the message-id
612 to be used as a sequence number.";
613 }
614 leaf message-generator-id {
615 type string;
616 description
617 "Software entity which created the message (e.g., linecard 1).
618 The combination of message-id and message-generator-id must be
619 unique until reset or a roll-over occurs.";
620 }
621 leaf notification-count {
622 type uint16;
623 description
624 "Quantity of notifications in a bundled-message to a
625 specific receiver.";
626 }
627 }
629 grouping notification-header {
630 description
631 "Common informational objects which might help a receiver
632 interpret the meaning, details, or importance of a notification.";
633 leaf notification-time {
634 type yang:date-and-time;
635 mandatory true;
636 description
637 "Time the system recognized the occurrence of an event.";
638 }
639 leaf yang-module {
640 type yang:yang-identifier;
641 description
642 "Name of the YANG module supported by the publisher.";
643 }
644 leaf-list subscription-id {
645 type uint32;
646 description
647 "Id of the subscription which led to the notification being
648 generated.";
649 }
650 leaf notification-id {
651 type uint32;
652 description
653 "Identifier for the notification record.";
654 }
655 leaf observation-domain-id {
656 type string;
657 description
658 "Software entity which created the notification record (e.g.,
659 process id).";
660 }
661 }
663 grouping security-footer {
664 description
665 "Reusable grouping for common objects which apply to the signing of
666 notifications or messages.";
667 leaf signature-algorithm {
668 type string;
669 mandatory true;
670 description
671 "The technology with which an originator signed of some
672 delineated contents.";
673 }
674 leaf signature-value {
675 type string;
676 mandatory true;
677 description
678 "Any originator signing of the contents of a header and
679 content. This is useful for verifying contents even when
680 shipping over unsecure transport.";
681 }
682 leaf integrity-evidence {
683 type string;
684 description
685 "This mechanism allows a verifier to ensure that the use of the
686 private key, represented by the corresponding public key
687 certificate, was performed with a TCG compliant TPM
688 environment. This evidence is never included in within any
689 signature.";
690 reference
691 "TCG Infrastructure Workgroup, Subject Key Attestation Evidence
692 Extension, Specification Version 1.0, Revision 7.";
693 }
694 }
696 /*
697 * YANG encoded structures which can be sent to receivers
698 */
700 sx:structure message {
701 container message {
702 presence
703 "Indicates attempt to communicate notifications to a receiver.";
704 description
705 "Message to a receiver containing one or more notifications";
706 container message-header {
707 description
708 "Header info for messages.";
709 uses message-header;
710 }
711 list notifications {
712 description
713 "Set of notifications to a receiver.";
714 container notification-header {
715 description
716 "Header info for a notification.";
717 uses notification-header;
718 }
719 anydata notification-contents {
720 description
721 "Encapsulates objects following YANG's notification-stmt
722 grammar of RFC-7950 section 14. Within are the notified
723 objects the publisher actually generated in order to be
724 passed to a receiver after all filtering has completed.";
725 }
726 container notification-footer {
727 presence
728 "Indicates attempt to secure a notification.";
729 description
730 "Signature and evidence for messages.";
731 uses security-footer;
732 }
733 }
734 container message-footer {
735 presence
736 "Indicates attempt to secure the entire message.";
737 description
738 "Signature and evidence for messages.";
739 uses security-footer;
740 }
741 }
742 }
744 /*
745 * DATA-NODES
746 */
748 container additional-default-headers {
749 if-feature "publisher";
750 description
751 "This container maintains a list of which additional notifications
752 should use which optional headers if the receiver supports this
753 specification.";
754 leaf-list additional-headers {
755 type optional-header;
756 description
757 "This list contains the identities of the optional header types
758 which are to be included within each message from this
759 publisher.";
760 }
761 list yang-notification-specific-default {
762 key "yang-module yang-notification-name";
763 description
764 "For any included YANG notifications, this list provides
765 additional optional headers which should be placed within the
766 container notification-header if the receiver supports this
767 specification. This list incrementally adds to any headers
768 indicated within the leaf-list 'additional-headers'.";
769 leaf yang-module {
770 type yang:yang-identifier;
771 description
772 "Name of the YANG module supported by the publisher.";
773 }
774 leaf yang-notification-name {
775 type notification-type;
776 description
777 "The name of a notification within a YANG module.";
778 }
779 leaf-list additional-notification-headers {
780 type optional-notification-header;
781 description
782 "The set of additional default headers which will be sent
783 for a specific notification.";
784 }
785 }
786 }
787 }
789
791 8. Backwards Compatibility
793 With this specification, there is no change to YANG's 'notification'
794 statement
796 Legacy clients are unaffected, and existing users of [RFC5277],
797 [RFC7950], and [RFC8040] are free to use current behaviors until all
798 involved device support this specification.
800 9. Security Considerations
802 Certain headers might be computationally complex for a publisher to
803 deliver. Signatures or encryption are two examples of this. It MUST
804 be possible to suspend or terminate a subscription due to lack of
805 resources based on this reason.
807 Decisions on whether to bundle or not to a receiver are fully under
808 the purview of the Publisher. A receiver could slow delivery to
809 existing subscriptions by creating new ones. (Which would result in
810 the publisher going into a bundling mode.)
812 10. Acknowledgments
814 For their valuable comments, discussions, and feedback, we wish to
815 acknowledge Martin Bjorklund, Einar Nilsen-Nygaard, and Kent Watsen.
817 11. References
818 11.1. Normative References
820 [I-D.draft-ietf-netconf-subscribed-notifications]
821 Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A.,
822 and E. Nilsen-Nygaard, "Custom Subscription to Event
823 Streams", draft-ietf-netconf-subscribed-notifications-16
824 (work in progress), August 2019.
826 [I-D.draft-ietf-netmod-yang-data-ext]
827 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data
828 Structure Extensions", draft-ietf-netmod-yang-data-ext
829 (work in progress), July 2019.
831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
832 Requirement Levels", BCP 14, RFC 2119,
833 DOI 10.17487/RFC2119, March 1997,
834 .
836 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
837 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
838 .
840 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
841 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
842 May 2017, .
844 11.2. Informative References
846 [I-D.draft-ietf-netconf-restconf-notif]
847 Voit, Eric., Clemm, Alexander., Tripathy, A., Nilsen-
848 Nygaard, E., and Alberto. Gonzalez Prieto, "Restconf and
849 HTTP transport for event notifications", August 2019,
850 .
853 [I-D.ietf-netconf-yang-push]
854 Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto.,
855 Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B.
856 Lengyel, "YANG Datastore Subscription", August 2019,
857 .
860 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
861 and A. Bierman, Ed., "Network Configuration Protocol
862 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
863 .
865 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
866 RFC 7950, DOI 10.17487/RFC7950, August 2016,
867 .
869 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
870 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
871 .
873 Appendix A. Changes between revisions
875 (To be removed by RFC editor prior to publication)
877 v06 - v07
879 o Updated author affiliation.
881 v05 - v06
883 o With SN and YP getting RFC numbers, revisiting this document.
885 o Changed yang-data to draft-ietf-netmod-yang-data-ext's
886 'structure'.
888 o Removed the ability to reference structures other than YANG
889 notifications.
891 v04 - v05
893 o Revision before expiration. Awaiting closure of SN and YP prior
894 to update.
896 v03 - v04
898 o Terminology tweaks.
900 o Revision before expiration. Awaiting closure of SN prior to
901 update.
903 v02 - v03
905 o Removed the option for an unbundled message. This might be re-
906 added later for transport efficiency if desired by the WG
908 o New message structure driven by the desire to put the signature
909 information at the end.
911 v01 - v02
912 o Fixed the yang-data encapsulation container issue
914 o Updated object definitions to point to RFC-7950 definitions
916 o Added headers for module and notification-type.
918 v00 - v01
920 o Alternative to 5277 one-way notification added
922 o Storage of default headers by notification type
924 o Backwards compatibility
926 o Capability discovery
928 o Move to yang-data
930 o Removed dscp and record-type as common headers. (Record type can
931 be determined by the namespace of the record contents. Dscp is
932 useful where applications need internal communications within a
933 Publisher, but it is unclear as to whether this use case need be
934 exposed to a receiver.
936 Appendix B. Issues being worked
938 (To be removed by RFC editor prior to publication)
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 Need to ensure the proper references exist to a notification
949 definition driven by RFC-7950 which is acceptable to other eventual
950 users of this specification.
952 Appendix C. Subscription Specific Headers
954 (To be removed by RFC editor prior to publication)
956 This section discusses a future functional addition which could
957 leverage this draft. It is included for informational purposes only.
959 A dynamic subscriber might want to mandate that certain headers be
960 used for push updates from a publisher. Some examples of this
961 include a subscriber requesting to:
963 o establish this subscription, but just if transport messages
964 containing the pushed data will be encrypted,
966 o establish this subscription, but only if you can attest to the
967 information being delivered in requested notification records, or
969 o provide a sequence-id for all messages to this receiver (in order
970 to check for loss).
972 Providing this type of functionality would necessitate a new revision
973 of the [I-D.draft-ietf-netconf-subscribed-notifications]'s RPCs and
974 state change notifications. Subscription specific header information
975 would overwrite the default headers identified in this document.
977 Appendix D. Implications to Existing RFCs
979 (To be removed by RFC editor prior to publication)
981 YANG one-way exchanges currently use a non-extensible header and
982 encoding defined in section 4 of RFC-5277. These RFCs MUST be
983 updated to enable this draft. These RFCs SHOULD be updated to
984 provide examples
986 D.1. Implications to RFC-7950
988 Sections which expose netconf:capability:notification:1.0 are 4.2.10
990 Sections which provide examples using netconf:notification:1.0 are
991 7.10.4, 7.16.3, and 9.9.6
993 D.2. Implications to RFC-8040
995 Section 6.4 demands use of RFC-5277's netconf:notification:1.0, and
996 later in the section provides an example.
998 Authors' Addresses
1000 Eric Voit
1001 Cisco Systems
1003 Email: evoit@cisco.com
1004 Henk Birkholz
1005 Fraunhofer SIT
1007 Email: henk.birkholz@sit.fraunhofer.de
1009 Andy Bierman
1010 YumaWorks
1012 Email: andy@yumaworks.com
1014 Alexander Clemm
1015 Futurewei
1017 Email: ludwig@clemm.org
1019 Tim Jenkins
1020 Cisco Systems
1022 Email: timjenki@cisco.com