Subscription to YANG Notifications
draft-ietf-netconf-subscribed-notifications-26
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-09-07
|
26 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-08-12
|
26 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-07-08
|
26 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2019-07-02
|
26 | (System) | RFC Editor state changed to AUTH from RFC-EDITOR |
2019-06-27
|
26 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2019-06-21
|
26 | (System) | RFC Editor state changed to AUTH from EDIT |
2019-05-30
|
26 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-05-30
|
26 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-05-30
|
26 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-05-30
|
26 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-05-30
|
26 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-05-23
|
26 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-05-21
|
26 | (System) | RFC Editor state changed to EDIT |
2019-05-21
|
26 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-05-21
|
26 | (System) | Announcement was received by RFC Editor |
2019-05-21
|
26 | (System) | IANA Action state changed to In Progress |
2019-05-21
|
26 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-05-21
|
26 | Amy Vezza | IESG has approved the document |
2019-05-21
|
26 | Amy Vezza | Closed "Approve" ballot |
2019-05-21
|
26 | Amy Vezza | Ballot approval text was generated |
2019-05-21
|
26 | Ignas Bagdonas | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-05-10
|
26 | Jean Mahoney | Request closed, assignment withdrawn: Jari Arkko Last Call GENART review |
2019-05-10
|
26 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Team Will not Review Version' |
2019-05-10
|
26 | Magnus Westerlund | [Ballot comment] Thanks for addressing the discuss and issues. I understand that there is significant work in defining a solution that actually is capable of … [Ballot comment] Thanks for addressing the discuss and issues. I understand that there is significant work in defining a solution that actually is capable of expressing the receiver's need and provides the publisher with reasonable to process rules and avoids the randomness in what happens in an overload situation. I hope the community will consider how they deal with this issue going forward. |
2019-05-10
|
26 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss |
2019-05-08
|
26 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-05-08
|
26 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-05-08
|
26 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-26.txt |
2019-05-08
|
26 | (System) | New version approved |
2019-05-08
|
26 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto |
2019-05-08
|
26 | Eric Voit | Uploaded new revision |
2019-05-06
|
25 | Roman Danyliw | [Ballot comment] Thank you for resolving my DISCUSS. |
2019-05-06
|
25 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2019-05-06
|
25 | Benjamin Kaduk | [Ballot comment] Thank you for resolving my Discuss points! |
2019-05-06
|
25 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-05-03
|
25 | Benjamin Kaduk | [Ballot discuss] It looks like the description of filter-failure-hint in modify-subscription-stream-error-info needs the same treatment that establish-subscription-stream-error-info received. |
2019-05-03
|
25 | Benjamin Kaduk | [Ballot comment] [original comment section replaced] In the updated security considerations: The replay mechanisms described in Sections Section 2.4.2.1 and Section 2.5.6 provides … [Ballot comment] [original comment section replaced] In the updated security considerations: The replay mechanisms described in Sections Section 2.4.2.1 and Section 2.5.6 provides access to historical event records. By design, the access control model that protects these records could enable subscribers to view data to which they were not authorized at the time of collection. Looks like there's some xml2rfc redundancy ("Sections Section"). o "excluded-event-records": leaf can provide information about filtered event records. A network operator should have permissions to know about such filtering. Improper configuration could provide a receiver with information leakage consisting of the dropping of event records. In mail I had proposed "Improper configuration could allow a receiver to learn that event records were dropped due to an ACL when the existence of that ACL would otherwise be transparent."; repeating it here just in case it got missed (but this remains the non-blocking comment section). |
2019-05-03
|
25 | Benjamin Kaduk | Ballot comment and discuss text updated for Benjamin Kaduk |
2019-05-02
|
25 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-05-02
|
25 | Magnus Westerlund | [Ballot discuss] My focus when reviewing this document was from a perspective of how to handle overload. I have a hard time understanding how this … [Ballot discuss] My focus when reviewing this document was from a perspective of how to handle overload. I have a hard time understanding how this will actually work, especially in a fashion that preservers goodput and ensure what is considered the most important subscriptions are delivered. Not having good undertanding into netconf and restconf don't hesitate to call out likely missunderstanding by me and provide clarification and pointers. A) The QoS and priority sending mechanism discussed in 2.3 and furhter defined by the YANG model. I do want to raise the usage of the DSCP code point to a discuss. As the DSCP defines different PHB and relative priorities in the router queues a DSCP value does not provide the publisher any information about priority. I get the feeling from the text that this may be intended. If the only intention is to have the transport perform differential treatment in the network between the publisher and the receiver there are still more considerations are needed. First of all I think these sentence needs a total rewrite: If the publisher supports the "dscp" feature, then a subscription with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP marking being placed within the IP header of any resulting notification messages and subscription state change notifications. Where TCP is used, a publisher which supports the "dscp" feature SHOULD ensure that a subscription's notification messages are returned within a single TCP transport session where all traffic shares the subscription's "dscp" leaf value. I think one need to put a requriement on the transport to use a transport that utilize the DSCP marking on its traffic. Which for the current set of connection oriented transport protocols, TCP, SCTP, and QUIC all currently only support using a single DSCP per connection. Implying multiple transport protocol connections using a particular transport to enable this mapping. A.2 Queuing model of a publisher. With the DSCP and the Weight and dependency model I think it is important to clarify the model of the queueing in the publisher. So is the intention that several subscriptions with different weights and possibly dependencies have their individual queues that goes into a scheduler? To avoid complex queue interactions on this level I think there need to be seperate scheduler instances per DSCP. I would also note that Dependency mechanism can't ensure that a dependent stream arrive at receiver after the identified dependency if they are on different DSCP. In fact if one would have HTTP/3 (over QUIC) we may not even guarantee it within a single connection and same DSCP due to packet loss impact. To me this model and what relationship one need to consider here need to be clarified. I think RFC 7540 Section 5.3.1 is an excellent indication of just the importance of considering what is in the same dependency tree and what it means to have different weighting. To conclude I think this needs a model description and clearer definition and possibly requirements towards the transport. Espceially if you actually need an in-order delivery requirement? B. The unpredictability of the circuit breaker overload mechanism. My description of the overload handling in this document is that it is a circuit breaker based mechanism that can blow a fuse on subscriptions that it fails to honor in overload situations. What worries me deply is the total unpredictability of this mechanism. First, is it the intention to derive what subscriptions are least important from the DSCP, weighting and Dependency parameters? If it is, I think that may be a misstake as priority on what subscriptions are most important to retain are not necessarily reflected in their QoS parameters. Secondly, what are the values when a subscription are considered to be to heavy or not be handled accordingly. Are there any parameter sets that actually describe what SLA the subscriber expect that can be converted into timeout timers or buffer depth thresholds to indicate that publisher side isn't delivering these in time? Third, I what I understand there are no any additional back pressure mechanism between the receiver and the publisher than the transport protocols flow control? So a receiver that is not keeping up processing the data it process will not read out the data out of the flow controlled buffers in the receiver and thus prevent the publisher to write to the transport conncetion, thus causing the publisher to eventually trigger a suspension due to its queue build up? To my understanding the current mechanism places all subscriptions on the same importance and with the same SLA. Thus likely causing short term overload situations to cause subscription suspensions in random subscriptions. Is the WG fine with this type of randomness occuring and expecting that normally there will be such amount of overprovisioning that being able to indicate priority and SLA are overkill? At a minimal a change of this sentence in Section 2.5.1 is needed: This could be for reasons of an unexpected but sustained increase in an event stream's event records, degraded CPU capacity, a more complex referenced filter, or other higher priority subscriptions which have usurped resources. As it states that subscriptions has priorities without reference to a mechanism that provides that priority. C. 2.4.5. Killing a Dynamic Subscription The "kill-subscription" operation permits an operator to end a dynamic subscription which is not associated with the transport session used for the RPC. A publisher MUST terminate any dynamic subscription identified by the "id" parameter in the RPC request, if such a subscription exists. Can someone please clarify the use case for this functionality. To my understanding it allows another receiver given authority to kill the subscription being delivered to another receiver. Based on the otherwise rather strict that all manipulations of dynamic subscriptions happens from the transport session context that established it I want to better understand the use case it appears out place. D. The Requirements on a transport supporting Configured Subscriptions Reading through Section 2.5 I arrived at a number of questions. I tried to understand what the requirements are for the transport that supports Configured Subscriptions. I did note that neither draft-ietf-netconf-restconf-notif-13 nor draft-ietf-netconf-netconf-event-notifications-17 supports configured subscriptions. Thus, there appear no template for a solution either, or does there exist another document that is being worked on defining such a transport? Questions that arose for me related to Configured Susbription Transport where the following: 1. Can Transport Session be initiated in both direction. RFC 8071 provides a solution for Publisher to Receiver initiation. It is unclear if all parts are in place to have a receiver to publisher initiated transport to be bound to the subscription. 2. What is "name" really? It appears to be defined as an empty container. Despite that it appears to have requirements on being both a security identity as well as network address. 3. In Figure 9, which is stated to be for the receiver. What information does the receiver use to determine the transition (d)? And what does it do in this step. Related to Discuss part B). 4. RFC 8071 appears to lack any considerations for how often and how many times it attempts to connect to the receiver. So applying that mechanism appears to require some usage guidance to avoid causing overload situations or DoS potential by misconfiguring network devices with this soltution to dial out frequently to a target. As the transport solution requirements are not detail it is actually hard to determine if there are short comings in the description in Section 2.5 and the corresponding YANG model. Is it an reasonable request to document these requirements? |
2019-05-02
|
25 | Magnus Westerlund | [Ballot comment] 1. Section 2.3: DSCP domains I think the text could benefit from pointing out that the subscriber actually needs to know what the … [Ballot comment] 1. Section 2.3: DSCP domains I think the text could benefit from pointing out that the subscriber actually needs to know what the DSCP values represents in the diffserv domain of the publisher. As these could be different, they also create an interesting problems for transports of how they establish a transport connection that uses a particular DSCP, as the receiver if initiating need to know the local DSCP value that corresponds to the behavior in the publisher's domain. 2. In general I think there are more than one description that are fuzzy about if it describes a publisher or receiver action/requirement. |
2019-05-02
|
25 | Magnus Westerlund | Ballot comment and discuss text updated for Magnus Westerlund |
2019-05-02
|
25 | Magnus Westerlund | [Ballot discuss] My focus when reviewing this document was from a perspective of how to handle overload. I have a hard time understanding how this … [Ballot discuss] My focus when reviewing this document was from a perspective of how to handle overload. I have a hard time understanding how this will actually work, especially in a fashion that preservers goodput and ensure what is considered the most important subscriptions are delivered. Not having good undertanding into netconf and restconf don't hesitate to call out likely missunderstanding by me and provide clarification and pointers. A) The QoS and priority sending mechanism discussed in 2.3 and furhter defined by the YANG model. I do want to raise the usage of the DSCP code point to a discuss. As the DSCP defines different PHB and relative priorities in the router queues a DSCP value does not provide the publisher any information about priority. I get the feeling from the text that this may be intended. If the only intention is to have the transport perform differential treatment in the network between the publisher and the receiver there are still more considerations are needed. First of all I think these sentence needs a total rewrite: If the publisher supports the "dscp" feature, then a subscription with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP marking being placed within the IP header of any resulting notification messages and subscription state change notifications. Where TCP is used, a publisher which supports the "dscp" feature SHOULD ensure that a subscription's notification messages are returned within a single TCP transport session where all traffic shares the subscription's "dscp" leaf value. I think one need to put a requriement on the transport to use a transport that utilize the DSCP marking on its traffic. Which for the current set of connection oriented transport protocols, TCP, SCTP, and QUIC all currently only support using a single DSCP per connection. Implying multiple transport protocol connections using a particular transport to enable this mapping. A.2 Queuing model of a publisher. With the DSCP and the Weight and dependency model I think it is important to clarify the model of the queueing in the publisher. So is the intention that several subscriptions with different weights and possibly dependencies have their individual queues that goes into a scheduler? To avoid complex queue interactions on this level I think there need to be seperate scheduler instances per DSCP. I would also note that Dependency mechanism can't ensure that a dependent stream arrive at receiver after the identified dependency if they are on different DSCP. In fact if one would have HTTP/3 (over QUIC) we may not even guarantee it within a single connection and same DSCP due to packet loss impact. To me this model and what relationship one need to consider here need to be clarified. I think RFC 7540 Section 5.3.1 is an excellent indication of just the importance of considering what is in the same dependency tree and what it means to have different weighting. B. The unpredictability of the circuit breaker overload mechanism. My description of the overload handling in this document is that it is a circuit breaker based mechanism that can blow a fuse on subscriptions that it fails to honor in overload situations. What worries me deply is the total unpredictability of this mechanism. First, is it the intention to derive what subscriptions are least important from the DSCP, weighting and Dependency parameters? If it is, I think that is a misstake as priority on what subscriptions are most important to retain are not necessarily reflected in their QoS parameters. Secondly, what are the values when a subscription are considered to be to heavy or not be handled accordingly. Are there any parameter sets that actually describe what SLA the subscriber expect that can be converted into timeout timers or buffer depth thresholds to indicate that publisher side isn't delivering these in time? Third, I hard time to understand if there are any additional back pressure mechanism between the receiver and the publisher than the transport protocols flow control? So a receiver that is not keeping up processing the data it process will not read out the data out of the flow controlled buffers in the receiver and thus prevent the publisher to write to the transport conncetion, thus causing the publisher to eventually trigger a suspension. Is it correct that this is the only mechanism present? To my understanding the current mechanism places all subscriptions on the same importance and with the same SLA. Thus likely causing short term overload situations to cause subscription suspensions in random subscriptions. Is the WG fine with this type of randomness occuring and expecting that normally there will be such amount of overprovisioning that being able to indicate priority and SLA are overkill? C. 2.4.5. Killing a Dynamic Subscription The "kill-subscription" operation permits an operator to end a dynamic subscription which is not associated with the transport session used for the RPC. A publisher MUST terminate any dynamic subscription identified by the "id" parameter in the RPC request, if such a subscription exists. Can someone please clarify the use case for this functionality. To my understanding it allows another receiver given authority to kill the subscription being delivered to another receiver. Based on the otherwise rather strict that all manipulations of dynamic subscriptions happens from the transport session context that established it I want to better understand the use case it appears out place. D. The Requirements on a transport supporting Configured Subscriptions Reading through Section 2.5 I arrived at a number of questions. I tried to understand what the requirements are for the |
2019-05-02
|
25 | Magnus Westerlund | [Ballot comment] 1. Section 2.3: DSCP domains I think the text could benefit from pointing out that the subscriber actually needs to know what the … [Ballot comment] 1. Section 2.3: DSCP domains I think the text could benefit from pointing out that the subscriber actually needs to know what the DSCP values represents in the diffserv domain of the publisher. As these could be different, they also create an interesting problems for transports of how they establish a transport connection that uses a particular DSCP, as the receiver if initiating need to know the local DSCP value that corresponds to the behavior in the publisher's domain. |
2019-05-02
|
25 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund |
2019-05-02
|
25 | Alexey Melnikov | [Ballot comment] I missed comment from the document shepherd about YANG validation, so I am clearing my DISCUSS. |
2019-05-02
|
25 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss |
2019-05-02
|
25 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-05-01
|
25 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-05-01
|
25 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-05-01
|
25 | Alvaro Retana | [Ballot comment] I support Roman's DISCUSS. |
2019-05-01
|
25 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-05-01
|
25 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-05-01
|
25 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-05-01
|
25 | Alissa Cooper | [Ballot comment] = Section 1.3 = "Also note that transport specific transport drafts based on this specification MUST detail the life cycle of dynamic … [Ballot comment] = Section 1.3 = "Also note that transport specific transport drafts based on this specification MUST detail the life cycle of dynamic subscriptions, as well as the lifecycle of configured subscriptions (if supported)." I think this would be clearer if it said "transport-specific documents." = Section 2.5 = Please expand VRF on first use. |
2019-05-01
|
25 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-05-01
|
25 | Alexey Melnikov | [Ballot discuss] YANG validator reports the following: yanglint 0.14.80: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib} {model} -i: err : The leafref leaf is … [Ballot discuss] YANG validator reports the following: yanglint 0.14.80: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib} {model} -i: err : The leafref leaf is config but refers to a non-config leaf. (/ietf-subscribed-notifications:subscriptions/subscription/target/stream/stream) err : The leafref leaf is config but refers to a non-config leaf. (/ietf-subscribed-notifications:subscriptions/subscription/target/stream/stream) err : Invalid value "subscription-policy" of "uses". (/ietf-subscribed-notifications:subscriptions/subscription/subscription-policy) err : Copying data from grouping failed. (/ietf-subscribed-notifications:subscriptions/subscription/subscription-policy) err : Module "ietf-subscribed-notifications" parsing failed. I would like to understand whether this is a problem with the document or a problem with the validating tool. |
2019-05-01
|
25 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov |
2019-05-01
|
25 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-05-01
|
25 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-25.txt |
2019-05-01
|
25 | (System) | New version approved |
2019-05-01
|
25 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto |
2019-05-01
|
25 | Eric Voit | Uploaded new revision |
2019-04-30
|
24 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-04-30
|
24 | Warren Kumari | [Ballot comment] I support Benjamin and Roman's DISCUSSes. Also, thanks to Benjamin and others for such detailed reviews, they saved my much typing :-) |
2019-04-30
|
24 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-04-30
|
24 | Benjamin Kaduk | [Ballot discuss] Thanks for this document; I just have a few minor "housekeeping" points that should get resolved before publication. (Please also note the substantive … [Ballot discuss] Thanks for this document; I just have a few minor "housekeeping" points that should get resolved before publication. (Please also note the substantive comments in the COMMENT section as well, particularly those relating to the transport requirements and security considerations.) I'm not sure that we state clearly enough what is required to have a specification for a transport for notifications. Specifically (see COMMENT), in the module we seem to say that the specification must indicate what the default encoding is to be used if not otherwise specified, but that's not enumerated as a requirement on such a specification anywhere I see. I also think that we could probably require (as opposed to "highly recommend" in the current security considerations) that the transport provide message confidentiality and integrity protection. I'm also unsure that I properly understand the use of the "reset" RPC -- if it has no effect when transit connectivity already exists, then what entity is going to call "reset" in the case of publisher timeout when trying to reach a receiver? Surely not the publisher itself, since that would just be publisher-internal functionality with no need for an external-facing RPC. I'm also a little unclear on the mechanics of the list of subscriptions described in Section 3.3. Does it provide a way for a low-privilege client (that can only access one or a handful of the subscriptions) to enumerate all subscriptions that exist, including subscriptions used by high-privilege clients? If so, we may want to think about some security considerations text to that effect; if not, we may want to say that the access-control will limit which leafs are visible to some clients. Finally, we have a few instances of "leaf filter-failure-hint" that's of type "string", providing "Information describing where and/or why a provided filter was unsupportable for a subscription."; I don't understand why it's a string as opposed to some form of machine-readable data. Is it supposed to be human-readable? Does that bring in any internationalization considerations? |
2019-04-30
|
24 | Benjamin Kaduk | [Ballot comment] Section 1.3 Also note that transport specific transport drafts based on this specification MUST detail the life cycle of dynamic subscriptions, … [Ballot comment] Section 1.3 Also note that transport specific transport drafts based on this specification MUST detail the life cycle of dynamic subscriptions, as well as the lifecycle of configured subscriptions (if supported). I'm not sure I understand what additional specification is needed for the lifecycle of configured subscriptions -- doesn't the previous text tightly tie their lifecycle to the presence of configuration in the configuration datastore? nit: please be consistent about "life cycle" vs. "lifecycle" throughout. Section 2.1 An event stream is a named entity on a publisher which exposes a continuously updating set of YANG encoded event records. [...] nit: I don't think "YANG encoded" is well-defined (here and below), in that YANG structures generate data models but can be encoded into various formats (like XML and JSON). Section 2.3 If the publisher supports the "dscp" feature, then a subscription with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP marking being placed within the IP header of any resulting notification messages and subscription state change notifications. Where TCP is used, a publisher which supports the "dscp" feature SHOULD ensure that a subscription's notification messages are returned within a single TCP transport session where all traffic shares the subscription's "dscp" leaf value. Where this cannot be guaranteed, any "establish subscription" RPC request SHOULD be rejected with a "dscp-unavailable" error I can't decide whether we need to be more explicit in the second and/or third sentences that this remains contingent on the subscription in question having a "dscp" leaf. nit: end sentence with a full stop I share the TSV-ART reviewer's confusion about how the weighting (as well as DSCP) functionality is intended to work. Section 2.4.2.1 Replay provides the ability to establish a subscription which is also capable of passing recently generated event records. In other words, nit/editorial: this language could probably be more clear about "recently generated" meaning "in the past", that is, records for events that have already happened when the subscription is established. Section 2.4.3 any number of times. Dynamic subscriptions can only be modified via this RPC using a transport session connecting to the subscriber. If nit(?): is this more readable as "connecting to" or "connecting from" the subscriber? (The same wording shows up throughout the document, but I'll try to just comment once.) Section 2.4.5 Is there any distinction between "killing a subscription" and "administratively deleting a subscription"? It's unclear to me that we need the extra connotations of the word "kill", here. Section 2.4.6 As a result of this mixture, how subscription errors are encoded nit: "mixture" doesn't seem like the right word to me; "variety" or "varied population" are the first alternatives that come to mind, though they are not perfect either. Is there some sort of "access denied" error that could result from kill-subscription RPCs? (The table/artwork only lists "no-such-subscription".) Section 2.5 It's interesting to see a slight dichotomy between dynamic and configured subscriptions, in that (IIUC) for dynamic subscriptions, a modification event un-suspends a subscription immediately, but for configured subscriptions the publisher seems to have some latitude to retain the subscription in the suspended state for some time before un-suspending it and sending the "subscription-modified" state change message. In this case, a separate dynamic subscription can be established to retransmit the missing event records. Do you want to put in a pointer to replay-start-time here? Section 2.5.1 Event records are only sent to active receivers. Receivers of a configured subscription remain active if both transport connectivity can be verified to the receiver, and event records are not being dropped due to a publisher buffer overflow. [...] nit: "buffer overflow" is a technical term in security circles indicating a potentially exploitable security flaw; would "publisher buffer capacity being reached" be an acceptable substitute (here and below)? Section 2.7.7 This notification indicates that all of the event records prior to the current time have been passed to a receiver. It is sent before any notification message containing an event record with a timestamp later than (1) the "stop-time" or (2) the subscription's start time. nit(?): this text seems to imply that a notification message with a timestamp later than the "stop-time" might actually be sent, which IIUC is not the case. Section 2.9 nit: the name "supports-vrf" for the feature doesn't really parallel the other feature names, that don't include a word like "support" and rather just describe the actual feature. Section 3.1 Is there any risk of collision in event stream names from vendor-specific streams? (We don't seem to create an IANA registry for them, for example.) Section 4 identity subscription-suspended-reason { description "Problem condition communicated to a receiver as part of a 'subscription-terminated' notification."; } identity subscription-terminated-reason { description "Problem condition communicated to a receiver as part of a 'subscription-terminated' notification."; } Are these descriptions supposed to be the same? identity configurable-encoding { description "If a transport identity derives from this identity, it means that it supports configurable encodings. An example of a [...] Is it intended that such future transports (or future encodings?) will derive from both this and the normal base identity (i.e., "transport")? I guess I'm asking why this identity does not derive from the corresponding base, but that's just a style question and not really a protocol matter, making this question a side note. leaf weighting { if-feature "qos"; type uint8 { range "0 .. 255"; } description "Relative weighting for a subscription. Allows an underlying transport layer perform informed load balance allocations between various subscriptions"; reference "RFC-7540, section 5.3.2"; Do we want to chase the reference for readers and say that larger weights get more resources? leaf encoding { when 'not(../transport) or derived-from(../transport, "sn:configurable-encoding")'; type encoding; description "The type of encoding for notification messages. For a dynamic subscription, if not included as part of an establish- subscription RPC, the encoding will be populated with the encoding used by that RPC. For a configured subscription, if not explicitly configured the encoding with be the default encoding for an underlying transport."; Where is the default encoding for an underlying transport specified? Section 5.3 does not seem to say that a transport specification must provide this information, nor does Section 1.3 (which mentions that transport specifications must detail the lifecycle of dynamic subscriptions), nor does Section 2.5.7 (that discusses the need for a separate model augmenting /subscriptions/subscription/receivers/receiver to provide transport details). choice notification-message-origin { if-feature "configured"; description "Identifies the egress interface on the publisher from which notification messages are to be sent."; nit: given the address-originated case, perhaps "the egress interface" is not quite correct anymore. enum connecting { value 3; if-feature "configured"; description "A subscription has been configured, but a 'subscription-started' subscription state change notification needs to be successfully received before notification messages are sent. nit: successful receipt happens on the receiver but sending happens on the publisher, so there's a bit of a mismatch in the sentence subject here. Perhaps we could talk about "successfully sent" state-changes to resolve things. config false; mandatory true; description "Specifies the state of a subscription from the perspective of a particular receiver. With this info it is possible to determine whether a subscriber is currently generating notification messages intended for that receiver."; nit: is it the subscriber that is generating messages or the publisher? Section 5.3 A secure transport is highly recommended and the publisher MUST ensure that the receiver has sufficient authorization to perform the function they are requesting against the specific subset of content involved. "secure transport" usually means that it provides message confidentiality, integrity protection, and source authenticity (akin to the mutual authentication). This is qualitatively different from implementing authorization checks, and it's surprising to see them squashed into the same sentence. Do we want to say anything about discovery for support of new transports, and what workflow would be used to negotiate the use of a new transport? Section 5.4 I can think of a couple other considerations to mention here: - Using DNS names for receiver "name" lookup can cause situations where the name resolves differently on the publisher and subscriber, so the recipient would be different than expected. - Using the publisher's boot time for deduplication protection on replayed messages introduces a dependency on accurate time. We don't have a great secure time story at present, so this is more of a "beware of risk" situation than something we can mitigate, but it does seem that an attacker that could (e.g.) spoof the NTP traffic to the publisher on boot could cause it to send duplicate notifications to recipients that requested historical data. Some other comments on what's already there (which is pretty good; thanks for it!) follow. Container: "/filters" o "stream-subtree-filter": updating a filter could increase the computational complexity of all referencing subscriptions. o "stream-xpath-filter": updating a filter could increase the computational complexity of all referencing subscriptions. Do we want to say anything about modifying either of these causing the set of notifications delivered to recipients to shrink (or become unmanageably large)? I guess it may not be necessary, since the recipient gets a notification about the modification that includes the details of the filter. Container: "/subscriptions" o "excluded-event-records": leaf can provide information about filtered event records. A network operator should have permissions to know about such filtering. To be clear, this is event records filtered either via explicit filter or via access control restrictions. Specifically, it can allow a receiver to learn that there exists access controls that deny it access to some data, in the case when they did not apply any filtering rules explicitly. This potential for information leakage (of the existence of ACLs) should be mentioned explicitly. Appendix A This example transport module does not specify the life cycle of dynamic subscriptions per Section 1.3, and a couple other things required from a transport module specification. Perhaps we are okay claiming that since this is just an example YANG model and not a full transport example, the omission is okay, but it may be worth mentioning the omission for clarity. |
2019-04-30
|
24 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to Discuss from No Record |
2019-04-30
|
24 | Roman Danyliw | [Ballot discuss] Sections 2.4.2.1 and 2.5.6 seems to describe a mechanism (replay) to access historical data that was potentially collected prior to a given subscriber … [Ballot discuss] Sections 2.4.2.1 and 2.5.6 seems to describe a mechanism (replay) to access historical data that was potentially collected prior to a given subscriber having access to it. This appears to be an explicitly designed feature. No push back on that. However, I believe that explicitly stating this arrangement is warranted. Perhaps something on the order of the following could be added to the Security Considerations -- “The replay mechanisms described in Sections 2.4.2.1 and 2.5.6 provides access to historical event records. By design, the access control model that protects these records could enable subscribers to view data to which they were not authorized at the time of collection.” |
2019-04-30
|
24 | Roman Danyliw | [Ballot comment] (1) Section 2.5.1. Per Figure 8, if a modify operation fails re-evaluation (the “no (2)” branch) wouldn’t it go directly to “invalid” (instead … [Ballot comment] (1) Section 2.5.1. Per Figure 8, if a modify operation fails re-evaluation (the “no (2)” branch) wouldn’t it go directly to “invalid” (instead of through “unsupportable->invalid”)? (2) Section 2.5.2, what are “transport specific call-home operations”? (3) Section 2.5.6. Typos s/timegap/time gap/ s/successfully/successfully/ |
2019-04-30
|
24 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2019-04-30
|
24 | Éric Vyncke | [Ballot comment] I appreciate the goal of this document to specify another telemetry streaming than gRPC. As the I-D has been reviewed by YANG-doctors, I … [Ballot comment] I appreciate the goal of this document to specify another telemetry streaming than gRPC. As the I-D has been reviewed by YANG-doctors, I did not look in the YANG module. Comments -------- C1) section 1.3, should the published check authorization before accepting an subscription? There is some text in section 3.1 is about authorization but I would prefer to have this authorization stated as early as possible C2) end of section 1.3, "transport drafts" shouldn't rather be "transport specifications" ? C3) end of section 1.3, upon termination decided by the publisher, is there a need for any explanation message sent to the subscriber? C4) is there any reason why the YANG module validation but the datatracker fails? Outdated/invalid PYANG ? C5) section 2.2 "all event records on an event stream are to be sent", should there be a mention of publisher being out of ressource ? C6) section 2.4.1 "insufficient CPU or bandwidth available" but there may be other reasons (e.g. memory), what about using "insufficient CPU, bandwidth unavailable or other lack of ressource" C7) for my curiosity, in section 2.4.2.1, how deep could realistically be a replay buffer? Minutes? C8) the term 'transport' is used quite often in the document but it seems to refer to NETCONF and not so much to my understanding of 'transport' in an IETF document (which is TCP, UDP, SCTP, ...). Is it obvious to the readers? If so, then I do not mind. Else, it may be useful to clarify in section 1.2 Nits ---- N1) is there any reason why not all Cisco authors are not grouped together? (even if another one has changed affiliation) N2) abstract s/information/data/ also applicable in other sections IMHO N3) section 1.3, expand RPC even if obvious N4) section 2.3, expand QoS even if obvious |
2019-04-30
|
24 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-04-29
|
24 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Record from Discuss |
2019-04-29
|
24 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-04-29
|
24 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-24.txt |
2019-04-29
|
24 | (System) | New version approved |
2019-04-29
|
24 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto |
2019-04-29
|
24 | Eric Voit | Uploaded new revision |
2019-04-29
|
23 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-04-29
|
23 | Benjamin Kaduk | [Ballot discuss] [putting this out early in the hopes it can be resolved quickly; I'm just starting to review the document.] This document started life … [Ballot discuss] [putting this out early in the hopes it can be resolved quickly; I'm just starting to review the document.] This document started life as a rfc5277bis, published in July 2008, before RFC 5378 (BCP 78) was published in November of 2008. If we are using any text from RFC 5277 and did not gain the additional rights declaration from the authors of that document, this document needs to use a different boilerplate text (the "pre-2008" text). I look at the sibling document draft-ietf-netfonf-yang-push of this document, which does use the pre-2008 boilerplate, and am having a hard time understanding why this document does not also have the pre-2008 boilerplate. |
2019-04-29
|
23 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-04-29
|
23 | Mirja Kühlewind | [Ballot comment] 1) Sec 2.3: “Where TCP is used, a publisher which supports the "dscp" feature SHOULD ensure that a subscription's notification messages … [Ballot comment] 1) Sec 2.3: “Where TCP is used, a publisher which supports the "dscp" feature SHOULD ensure that a subscription's notification messages are returned within a single TCP transport session where all traffic shares the subscription's "dscp" leaf value.“ This should probably be generalised to “If a connection-oriented protocol is used, …”, however, I’m not sure I understand the sentence correctly. It is no problem to have multiple TCP session using the same DSCP value, however, what should be avoided is using different DCSP values within the same TCP connection. Can you please clarify what this sentence is supposed to say? 2) Also sec 2.3: “For the "weighting" parameter, when concurrently dequeuing notification messages from multiple subscriptions to a receiver, the publisher MUST allocate bandwidth to each subscription proportionally to the weights assigned to those subscriptions.” I’m also wondering about this sentence. Should this really be a MUST? I can assume that there could also be cases where there is a local policy to prioritise some notification. And do you really mean bandwidth (which would mean taking the message size into account), or would it make sense to leave the details to the exact implementation of the publisher and maybe talk just about “resources” instead? 3) Sec 1.3 says “ the loss of the transport session will result in the immediate termination of any associated dynamic subscriptions.” However, there is the following text in section 2.4.5: “The "kill-subscription" operation permits an operator to end a dynamic subscription which is not associated with the transport session used for the RPC.” If the subscription is anyway immediately terminated when the transport session is lost, why is the kill-subscription operation still needed? 4) Sec 2.5: Please expand VRF. 5) Figure 8: I would recommend to call the second “evaluate” event “re-evaluate” instead. |
2019-04-29
|
23 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-04-17
|
23 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2019-04-16
|
23 | Ignas Bagdonas | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2019-04-16
|
23 | Amy Vezza | Placed on agenda for telechat - 2019-05-02 |
2019-04-16
|
23 | Ignas Bagdonas | IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup |
2019-04-16
|
23 | Ignas Bagdonas | Ballot has been issued |
2019-04-16
|
23 | Ignas Bagdonas | [Ballot Position Update] New position, Yes, has been recorded for Ignas Bagdonas |
2019-04-16
|
23 | Ignas Bagdonas | Created "Approve" ballot |
2019-04-16
|
23 | Ignas Bagdonas | Ballot writeup was changed |
2019-04-16
|
23 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Ravi Singh. |
2019-04-12
|
23 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-04-12
|
23 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-netconf-subscribed-notifications-23. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-netconf-subscribed-notifications-23. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the ns registry on the IETF XML Registry page located at: https://www.iana.org/assignments/xml-registry/ a single, new namespace will be registered as follows: ID: yang:ietf-subscribed-notifications URI: urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Second, in the YANG Module Names registry on the YANG Parameters registry page located at: https://www.iana.org/assignments/yang-parameters/ a single, new YANG module will be registered as follows: Name: ietf-subscribed-notifications File: [ TBD-at-Registration ] Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications Prefix: sn Module: Reference: [ RFC-to-be ] While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published. The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-04-12
|
23 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-04-05
|
23 | Carlos Pignataro | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Carlos Pignataro. Sent review to list. |
2019-04-04
|
23 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jari Arkko |
2019-04-04
|
23 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jari Arkko |
2019-04-03
|
23 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Pignataro |
2019-04-03
|
23 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Pignataro |
2019-04-02
|
23 | Wesley Eddy | Request for Last Call review by TSVART Completed: Almost Ready. Reviewer: Wesley Eddy. Sent review to list. |
2019-03-28
|
23 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Chris Lonvick. |
2019-03-25
|
23 | Min Ye | Request for Last Call review by RTGDIR is assigned to Ravi Singh |
2019-03-25
|
23 | Min Ye | Request for Last Call review by RTGDIR is assigned to Ravi Singh |
2019-03-24
|
23 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Wesley Eddy |
2019-03-24
|
23 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Wesley Eddy |
2019-03-22
|
23 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2019-03-22
|
23 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2019-03-22
|
23 | Alvaro Retana | Requested Last Call review by RTGDIR |
2019-03-22
|
23 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-03-22
|
23 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-04-12): From: The IESG To: IETF-Announce CC: ibagdona@gmail.com, draft-ietf-netconf-subscribed-notifications@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, kent+ietf@watsen.net … The following Last Call announcement was sent out (ends 2019-04-12): From: The IESG To: IETF-Announce CC: ibagdona@gmail.com, draft-ietf-netconf-subscribed-notifications@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, kent+ietf@watsen.net, Kent Watsen Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Subscription to YANG Event Notifications) to Proposed Standard The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'Subscription to YANG Event Notifications' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request for and receive a continuous, custom feed of publisher generated information. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-03-22
|
23 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-03-22
|
23 | Amy Vezza | Last call announcement was changed |
2019-03-22
|
23 | Alissa Cooper | Last call was requested |
2019-03-22
|
23 | Alissa Cooper | Last call announcement was generated |
2019-03-22
|
23 | Alissa Cooper | Ballot approval text was generated |
2019-03-22
|
23 | Alissa Cooper | Ballot writeup was generated |
2019-03-22
|
23 | Alissa Cooper | IESG state changed to Last Call Requested from Publication Requested |
2019-02-26
|
23 | Kent Watsen | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? [SHEPHERD] This document is a Proposed Standard document, and is indicated in the title page as a "Standards Track" document. This is the proper designation for this RFC by WG consensus. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. [SHEPHERD] From the Abstract: This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request for and receive a continuous, custom feed of publisher generated information. [SHEPHERD] From the Introduction: This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Effectively this enables a 'subscribe then publish' capability where the customized information needs and access permissions of each target receiver are understood by the publisher before subscribed event records are marshaled and pushed. The receiver then gets a continuous, custom feed of publisher generated information. While the functionality defined in this document is transport- agnostic, transports like NETCONF [RFC6241] or RESTCONF [RFC8040] can be used to configure or dynamically signal subscriptions, and there are bindings defined for subscribed event record delivery for NETCONF within [I-D.draft-ietf-netconf-netconf-event-notifications], and for RESTCONF within [I-D.draft-ietf-netconf-restconf-notif]. The YANG model in this document conforms to the Network Management Datastore Architecture defined in [RFC8342]. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? [SHEPHERD] Nothing in the process is worth noting. No decisions were particularly rough. There was a debate as to if this RFC should define support for *configured* subscriptions, in additional to dynamic subscriptions; in the end, the WG consensus was to define support for configured subscriptions in this draft, but to NOT define support for configured subscriptions in the two drafts that complete the model (draft-ietf-netconf-restconf-notif and draft-ietf-netconf-event-notifications). Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? [SHEPHERD] Apparently (not confirmed), this work has been implemented in the OpenDayLight SDN controller. This document just went through a post-LC YANG Doctor review (all issues raised were addressed): https://datatracker.ietf.org/doc/review-ietf-netconf-subscribed-notifications-21-yangdoctors-lc-bierman-2019-01-14/ Personnel Who is the Document Shepherd? Who is the Responsible Area Director? [SHEPHERD] The Document Shepherd is Kent Watsen. The Responsible Area Director is Ignas Bagdonas. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. [SHEPHERD] The shepherd has reviewed emails on the list, and tested against `idnits`, and validated the YANG modules using both `pyang` and `yanglint`. The shepherd is comfortable with forwarding the document to the IESG at this time. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? [SHEPHERD] The Shepherd has no concerns about the depth or breadth of the reviews that have been performed. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. [SHEPHERD] No review from a particular or from broader perspective is required. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. [SHEPHERD] There are no specific concerns or issues that the Responsible Area Director and/or the IESG should be aware of. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. [SHEPHERD] Each author has just confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Here is the thread: https://mailarchive.ietf.org/arch/msg/netconf/pMdfD8tKMoV42nuwl3nKTOCrRZk. Note: Alberto sent his response on on Feb 19, though it does not show up in the mail archive... (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. [SHEPHERD] No IPR disclosure been filed that references this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? [SHEPHERD] Generally solid, with many being interested in and reviewing this work. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) [SHEPHERD] No one has threatened an appeal or otherwise indicated extreme discontent. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. [SHEPHERD] - several "weird spacing" false-positive warnings - one "obsolete normative reference" error: RFC 5246 (Obsoleted by RFC 8446) [this will be fixed later] - one "possible downref" (XPATH), but it's okay (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. [SHEPHERD] The document was reviewed by the YANG doctor assigned to it. (13) Have all references within this document been identified as either normative or informative? [SHEPHERD] Yes, all references within this document been identified as either normative or informative. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? [SHEPHERD] as mentioned above, RFC5246 is obsoleted by RFC8446 needs to be replaced by RFC8446 in the normative references section. Otherwise, the only quazi-questionable normative reference is to draft-ietf-netconf-subscribed-notifications, which is being submitted to the IESG at the same time as this draft. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. [SHEPHERD] There are no downward normative references. IDNITS warns about a possible downref to non-RFC "XPATH", but it is okay. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. [SHEPHERD] The publication of this document will not change the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). [SHEPHERD] The shepherd has reviewed the IANA Considerations section. The document registers one URI and one YANG module. The registries for each of them have been identified in the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. [SHEPHERD] There are no new IANA registries that require Expert review for future allocations. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. [SHEPHERD] `pyang` and `yanglint` were used to validate the YANG module defined in this document. Note that Datatracker shows YANG validation errors, but the module validates fine on my machine (I'm using yanglint 0.16.110, whereas DataTracker is using yanglint 0.14.80). |
2019-02-26
|
23 | Kent Watsen | Responsible AD changed to Ignas Bagdonas |
2019-02-26
|
23 | Kent Watsen | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-02-26
|
23 | Kent Watsen | IESG state changed to Publication Requested from I-D Exists |
2019-02-26
|
23 | Kent Watsen | IESG process started in state Publication Requested |
2019-02-26
|
23 | Kent Watsen | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? [SHEPHERD] This document is a Proposed Standard document, and is indicated in the title page as a "Standards Track" document. This is the proper designation for this RFC by WG consensus. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. [SHEPHERD] From the Abstract: This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request for and receive a continuous, custom feed of publisher generated information. [SHEPHERD] From the Introduction: This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Effectively this enables a 'subscribe then publish' capability where the customized information needs and access permissions of each target receiver are understood by the publisher before subscribed event records are marshaled and pushed. The receiver then gets a continuous, custom feed of publisher generated information. While the functionality defined in this document is transport- agnostic, transports like NETCONF [RFC6241] or RESTCONF [RFC8040] can be used to configure or dynamically signal subscriptions, and there are bindings defined for subscribed event record delivery for NETCONF within [I-D.draft-ietf-netconf-netconf-event-notifications], and for RESTCONF within [I-D.draft-ietf-netconf-restconf-notif]. The YANG model in this document conforms to the Network Management Datastore Architecture defined in [RFC8342]. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? [SHEPHERD] Nothing in the process is worth noting. No decisions were particularly rough. There was a debate as to if this RFC should define support for *configured* subscriptions, in additional to dynamic subscriptions; in the end, the WG consensus was to define support for configured subscriptions in this draft, but to NOT define support for configured subscriptions in the two drafts that complete the model (draft-ietf-netconf-restconf-notif and draft-ietf-netconf-event-notifications). Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? [SHEPHERD] Apparently (not confirmed), this work has been implemented in the OpenDayLight SDN controller. This document just went through a post-LC YANG Doctor review (all issues raised were addressed): https://datatracker.ietf.org/doc/review-ietf-netconf-subscribed-notifications-21-yangdoctors-lc-bierman-2019-01-14/ Personnel Who is the Document Shepherd? Who is the Responsible Area Director? [SHEPHERD] The Document Shepherd is Kent Watsen. The Responsible Area Director is Ignas Bagdonas. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. [SHEPHERD] The shepherd has reviewed emails on the list, and tested against `idnits`, and validated the YANG modules using both `pyang` and `yanglint`. The shepherd is comfortable with forwarding the document to the IESG at this time. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? [SHEPHERD] The Shepherd has no concerns about the depth or breadth of the reviews that have been performed. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. [SHEPHERD] No review from a particular or from broader perspective is required. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. [SHEPHERD] There are no specific concerns or issues that the Responsible Area Director and/or the IESG should be aware of. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. [SHEPHERD] Each author has just confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Here is the thread: https://mailarchive.ietf.org/arch/msg/netconf/pMdfD8tKMoV42nuwl3nKTOCrRZk. Note: Alberto sent his response on on Feb 19, though it does not show up in the mail archive... (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. [SHEPHERD] No IPR disclosure been filed that references this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? [SHEPHERD] Generally solid, with many being interested in and reviewing this work. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) [SHEPHERD] No one has threatened an appeal or otherwise indicated extreme discontent. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. [SHEPHERD] - several "weird spacing" false-positive warnings - one "obsolete normative reference" error: RFC 5246 (Obsoleted by RFC 8446) [this will be fixed later] - one "possible downref" (XPATH), but it's okay (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. [SHEPHERD] The document was reviewed by the YANG doctor assigned to it. (13) Have all references within this document been identified as either normative or informative? [SHEPHERD] Yes, all references within this document been identified as either normative or informative. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? [SHEPHERD] as mentioned above, RFC5246 is obsoleted by RFC8446 needs to be replaced by RFC8446 in the normative references section. Otherwise, the only quazi-questionable normative reference is to draft-ietf-netconf-subscribed-notifications, which is being submitted to the IESG at the same time as this draft. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. [SHEPHERD] There are no downward normative references. IDNITS warns about a possible downref to non-RFC "XPATH", but it is okay. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. [SHEPHERD] The publication of this document will not change the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). [SHEPHERD] The shepherd has reviewed the IANA Considerations section. The document registers one URI and one YANG module. The registries for each of them have been identified in the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. [SHEPHERD] There are no new IANA registries that require Expert review for future allocations. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. [SHEPHERD] `pyang` and `yanglint` were used to validate the YANG module defined in this document. Note that Datatracker shows YANG validation errors, but the module validates fine on my machine (I'm using yanglint 0.16.110, whereas DataTracker is using yanglint 0.14.80). |
2019-02-15
|
23 | Kent Watsen | Notification list changed to Kent Watsen <kent+ietf@watsen.net> |
2019-02-15
|
23 | Kent Watsen | Document shepherd changed to Kent Watsen |
2019-02-13
|
23 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-23.txt |
2019-02-13
|
23 | (System) | New version approved |
2019-02-13
|
23 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto |
2019-02-13
|
23 | Eric Voit | Uploaded new revision |
2019-01-23
|
22 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-22.txt |
2019-01-23
|
22 | (System) | New version approved |
2019-01-23
|
22 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto |
2019-01-23
|
22 | Eric Voit | Uploaded new revision |
2019-01-14
|
21 | Andy Bierman | Request for Last Call review by YANGDOCTORS Completed: Ready with Issues. Reviewer: Andy Bierman. Sent review to list. |
2019-01-09
|
21 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-21.txt |
2019-01-09
|
21 | (System) | New version approved |
2019-01-09
|
21 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto |
2019-01-09
|
21 | Eric Voit | Uploaded new revision |
2018-12-19
|
20 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-20.txt |
2018-12-19
|
20 | (System) | New version approved |
2018-12-19
|
20 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto |
2018-12-19
|
20 | Eric Voit | Uploaded new revision |
2018-12-19
|
19 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Andy Bierman |
2018-12-19
|
19 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Andy Bierman |
2018-12-18
|
19 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-19.txt |
2018-12-18
|
19 | (System) | New version approved |
2018-12-18
|
19 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto |
2018-12-18
|
19 | Eric Voit | Uploaded new revision |
2018-12-18
|
18 | Kent Watsen | Requested Last Call review by YANGDOCTORS |
2018-10-26
|
18 | Kent Watsen | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2018-10-23
|
18 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-18.txt |
2018-10-23
|
18 | (System) | New version approved |
2018-10-23
|
18 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto |
2018-10-23
|
18 | Eric Voit | Uploaded new revision |
2018-09-28
|
17 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-17.txt |
2018-09-28
|
17 | (System) | New version approved |
2018-09-28
|
17 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto |
2018-09-28
|
17 | Eric Voit | Uploaded new revision |
2018-08-15
|
16 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-16.txt |
2018-08-15
|
16 | (System) | New version approved |
2018-08-15
|
16 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Einar Nilsen-Nygaard , Alberto Prieto |
2018-08-15
|
16 | Eric Voit | Uploaded new revision |
2018-08-03
|
15 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-15.txt |
2018-08-03
|
15 | (System) | New version approved |
2018-08-03
|
15 | (System) | Request for posting confirmation emailed to previous authors: netconf-chairs@ietf.org, Alexander Clemm , Alberto Prieto , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard |
2018-08-03
|
15 | Eric Voit | Uploaded new revision |
2018-07-02
|
14 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-14.txt |
2018-07-02
|
14 | (System) | New version approved |
2018-07-02
|
14 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard |
2018-07-02
|
14 | Eric Voit | Uploaded new revision |
2018-06-18
|
13 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-13.txt |
2018-06-18
|
13 | (System) | New version approved |
2018-06-18
|
13 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard |
2018-06-18
|
13 | Eric Voit | Uploaded new revision |
2018-04-16
|
12 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-12.txt |
2018-04-16
|
12 | (System) | New version approved |
2018-04-16
|
12 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard |
2018-04-16
|
12 | Eric Voit | Uploaded new revision |
2018-04-06
|
11 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-11.txt |
2018-04-06
|
11 | (System) | New version approved |
2018-04-06
|
11 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard |
2018-04-06
|
11 | Eric Voit | Uploaded new revision |
2018-03-15
|
10 | Andy Bierman | Request for Last Call review by YANGDOCTORS Completed: Almost Ready. Reviewer: Andy Bierman. Sent review to list. |
2018-03-08
|
10 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Andy Bierman |
2018-03-08
|
10 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Andy Bierman |
2018-03-07
|
10 | Kent Watsen | Requested Last Call review by YANGDOCTORS |
2018-03-07
|
10 | Kent Watsen | IETF WG state changed to In WG Last Call from WG Document |
2018-03-07
|
10 | Kent Watsen | Changed consensus to Yes from Unknown |
2018-03-07
|
10 | Kent Watsen | Intended Status changed to Proposed Standard from None |
2018-02-23
|
10 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-10.txt |
2018-02-23
|
10 | (System) | New version approved |
2018-02-23
|
10 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard |
2018-02-23
|
10 | Eric Voit | Uploaded new revision |
2018-01-25
|
09 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-09.txt |
2018-01-25
|
09 | (System) | New version approved |
2018-01-25
|
09 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard |
2018-01-25
|
09 | Eric Voit | Uploaded new revision |
2017-12-22
|
08 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-08.txt |
2017-12-22
|
08 | (System) | New version approved |
2017-12-22
|
08 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard |
2017-12-22
|
08 | Eric Voit | Uploaded new revision |
2017-10-30
|
07 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-07.txt |
2017-10-30
|
07 | (System) | New version approved |
2017-10-30
|
07 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard |
2017-10-30
|
07 | Eric Voit | Uploaded new revision |
2017-10-27
|
06 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-06.txt |
2017-10-27
|
06 | (System) | New version approved |
2017-10-27
|
06 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard |
2017-10-27
|
06 | Eric Voit | Uploaded new revision |
2017-10-03
|
05 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-05.txt |
2017-10-03
|
05 | (System) | New version approved |
2017-10-03
|
05 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard |
2017-10-03
|
05 | Eric Voit | Uploaded new revision |
2017-09-19
|
04 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-04.txt |
2017-09-19
|
04 | (System) | New version approved |
2017-09-19
|
04 | (System) | Request for posting confirmation emailed to previous authors: Ambika Tripathy , Eric Voit , Alexander Clemm , Alberto Prieto , Einar Nilsen-Nygaard |
2017-09-19
|
04 | Eric Voit | Uploaded new revision |
2017-07-02
|
03 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-03.txt |
2017-07-02
|
03 | (System) | New version approved |
2017-07-02
|
03 | (System) | Request for posting confirmation emailed to previous authors: Alberto Prieto , netconf-chairs@ietf.org, Alexander Clemm , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard |
2017-07-02
|
03 | Eric Voit | Uploaded new revision |
2017-04-20
|
02 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-02.txt |
2017-04-20
|
02 | (System) | New version approved |
2017-04-20
|
02 | (System) | Request for posting confirmation emailed to previous authors: Alberto Prieto , netconf-chairs@ietf.org, Alexander Clemm , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard |
2017-04-20
|
02 | Eric Voit | Uploaded new revision |
2017-04-14
|
01 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-01.txt |
2017-04-14
|
01 | (System) | New version approved |
2017-04-14
|
01 | (System) | Request for posting confirmation emailed to previous authors: Alberto Prieto , netconf-chairs@ietf.org, Alexander Clemm , Ambika Tripathy , Eric Voit , Einar Nilsen-Nygaard |
2017-04-14
|
01 | Eric Voit | Uploaded new revision |
2017-03-15
|
00 | Mahesh Jethanandani | Added to session: IETF-98: netconf Tue-1640 |
2017-02-23
|
00 | Mahesh Jethanandani | This document now replaces draft-ietf-netconf-rfc5277bis instead of None |
2017-02-23
|
00 | Eric Voit | New version available: draft-ietf-netconf-subscribed-notifications-00.txt |
2017-02-23
|
00 | (System) | WG -00 approved |
2017-02-23
|
00 | Eric Voit | Set submitter to "Eric Voit ", replaces to draft-ietf-netconf-rfc5277bis and sent approval email to group chairs: netconf-chairs@ietf.org |
2017-02-23
|
00 | Eric Voit | Uploaded new revision |