A YANG Data Model for Alarm Management
draft-ietf-ccamp-alarm-module-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-07-16
|
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-07-01
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-05-14
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-05-13
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-05-13
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-05-10
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-05-02
|
09 | (System) | RFC Editor state changed to EDIT |
2019-05-02
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-05-02
|
09 | (System) | Announcement was received by RFC Editor |
2019-05-02
|
09 | (System) | IANA Action state changed to In Progress |
2019-05-02
|
09 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-05-02
|
09 | Amy Vezza | IESG has approved the document |
2019-05-02
|
09 | Amy Vezza | Closed "Approve" ballot |
2019-05-02
|
09 | Amy Vezza | Ballot writeup was changed |
2019-05-02
|
09 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-05-02
|
09 | Deborah Brungard | Ballot approval text was changed |
2019-04-25
|
09 | Roman Danyliw | [Ballot comment] Thank you for iterating to resolve my DISCUSSes and address my comments |
2019-04-25
|
09 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2019-04-11
|
09 | Dan Romascanu | Request for Telechat review by GENART Completed: Ready. Reviewer: Dan Romascanu. Sent review to list. |
2019-04-11
|
09 | Benjamin Kaduk | [Ballot comment] Thank you for (finding the actual issue in and) resolving my DISCUSS point! |
2019-04-11
|
09 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-04-11
|
09 | Adam Roach | [Ballot comment] Thanks for addressing my DISCUSS. |
2019-04-11
|
09 | Adam Roach | [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss |
2019-04-11
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-04-11
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-04-11
|
09 | Martin Björklund | New version available: draft-ietf-ccamp-alarm-module-09.txt |
2019-04-11
|
09 | (System) | New version approved |
2019-04-11
|
09 | (System) | Request for posting confirmation emailed to previous authors: Martin Bjorklund , Stefan Vallin |
2019-04-11
|
09 | Martin Björklund | Uploaded new revision |
2019-04-11
|
08 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-04-11
|
08 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-04-11
|
08 | Magnus Westerlund | [Ballot comment] To me it appear that this document is a part in a system that lacks mechanisms for handling overload situations in a way … [Ballot comment] To me it appear that this document is a part in a system that lacks mechanisms for handling overload situations in a way that maintains goodput in the system. The system design appears to rest on that principle that there will allways be sufficient resources to process and handle the events and that misconfigurations or operator errors do not result in that the system exceeeds the considered load that it was deployed to handle. This alarm module is only a component that from my perspective do require some thought of how alarms that has interactions are reported and with which priority to minimize delay until they can be acted on. However, the general framework appears to lack the necessary hook for such thoughts to be meaningful. Therefore I abstain on this document. |
2019-04-11
|
08 | Magnus Westerlund | [Ballot Position Update] New position, Abstain, has been recorded for Magnus Westerlund |
2019-04-10
|
08 | Adam Roach | [Ballot discuss] §6: > If the type is given as an UUID or a string, it is interpreted > … [Ballot discuss] §6: > If the type is given as an UUID or a string, it is interpreted > as a W3C regular expression, which matches a resource of type > 'yang:uuid' or 'string' if the given regular expression > matches the resource string. This needs a citation for what is meant by "W3C regular expression." I'm making a wild guess that this refers to the regular expressions defined for use with XSD? If so, the reference is presumably this document: https://www.w3.org/TR/xmlschema11-2/ |
2019-04-10
|
08 | Adam Roach | [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach |
2019-04-10
|
08 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-04-10
|
08 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-04-08
|
08 | Barry Leiba | [Ballot comment] — Section 3.2 — A nit: For example, a system with digital inputs that allows users to connects detectors (e.g., smoke … [Ballot comment] — Section 3.2 — A nit: For example, a system with digital inputs that allows users to connects detectors (e.g., smoke detector) to the inputs. This is a sentence fragment ans also has a number error in “connects”. NEW An example is a system with digital inputs that allows users to connect detectors, such as smoke detectors, to the inputs. END |
2019-04-08
|
08 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-04-08
|
08 | Warren Kumari | [Ballot comment] I support Roman's DISCUSS, especially #2. Also, please see the OpsDir review here -- I believe that you have already discussed it with … [Ballot comment] I support Roman's DISCUSS, especially #2. Also, please see the OpsDir review here -- I believe that you have already discussed it with the reviewer (Thank you, Joe Clarke!), but wanted to make sure that you also catch the nits. Like Joe, and others, I find the term "Alarm Shelving" to be confusing - it may be a formal term of art, but I've working in / with many NOCs, and have never heard the term used; if anything the terminology I'm familiar with "Shut up stupid alarm! I'll suppress it for now....". Shelving evokes memories of https://pics.me.me/10-ill-just-put-this-over-here-with-the-rest-32772452.png I would suggest introducing the term earlier, and more fully describing it as a courtesy to other readers. "X.733 and especially 3GPP were not really clear on this point." - this sounds (unncessarily) rude - I would suggest perhaps "The X.733 and 3GPP Alarm IRP documents are not really clear ..." Nits: "For example, a system with digital inputs that allows users to connects detectors" s/connects/connect/ I would also think that a better term is "sensors" "A potential drawback of this is that there is a big risk that alarm operators will receive alarm types as a surprise, ..." "big" reads oddly - I would suggest "significant" instead. "Alarm deletion (using the action "purge-alarms"), can use this state as a criterion." - superfluous comma. |
2019-04-08
|
08 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-04-08
|
08 | Benjamin Kaduk | [Ballot discuss] I think we may need to double-check that the example in Appendix C is fully compliant with the main spec. In particular, are … [Ballot discuss] I think we may need to double-check that the example in Appendix C is fully compliant with the main spec. In particular, are the elments properly sorted? (I'm less sure whether the time needs to match a or whether the is good enough for that.) |
2019-04-08
|
08 | Benjamin Kaduk | [Ballot comment] Section 1.1 o Fault: A fault is the underlying cause of an undesired behaviour. There is no trivial one-to-one … [Ballot comment] Section 1.1 o Fault: A fault is the underlying cause of an undesired behaviour. There is no trivial one-to-one mapping between faults and alarms. One fault may result in several alarms in case the system lacks root-cause and correlation capabilities. An alarm might not have an underlying fault as a cause, imagine a bad MOS score alarm from a VOIP probe and the cause being non-optimal QoS configuration. nit: this is a comma splice o Alarm Type: An alarm type identifies a possible unique alarm state for a resource. Alarm types are names to identify the state like "link-alarm", "jitter-violation", "high-disk-utilization". Are these only intended for human consumption? o Cleared alarm: A cleared alarm is an alarm where the system/server considers the undesired state to be cleared. Operators can not clear alarms, clearance is managed by the system. A linkUp notification can be considered a clear condition for a linkDown state. nit: I'd suggest "For example, " before "a linkUp notification [...]" o Corrective Action: An action taken by an operator or automation routine in order to minimize the impact of the alarm or resolving the root cause. nit: "or resolve the root cause" Section 2 o Clear definition of "alarm" in order to exclude general events that should not be forwarded as alarm notifications. I'm not sure I am parsing this correctly. Is the objective to *provide* such a clear definition? (Similarly for the next item.) Part of my confusion probably stems from the dual use of the word "clear" as a verb and a noun in English. Section 3.2 In order to allow for dynamic addition of alarm types the alarm module allows for further qualification of the identity based alarm type using a string. A potential drawback of this is that there is a big risk that alarm operators will receive alarm types as a surprise, they do not know how to resolve the problem since a defined alarm procedure does not necessarily exist. [...] nit: this is a comma splice. Section 3.5.1 From a resource perspective, an alarm can for example have the following life-cycle: raise, change severity, change severity, clear, Is the duplicate "change severity" intentional? For the alarm history functionality, a given 'time' leaf is clearly the time that a change occurred, but are the sibling leafs the state before that change or after that change? (It looks like the actual YANG module descriptions (e.g., for 'status-change') indicate that this is the state after that change, but I don't know if it makes sense to also mention that here or not.) Section 3.7 (blocked/filtered). Shelved alarms appear in a dedicated shelved alarm list in order not to disturb the relevant alarms. Shelved nit: this sentence could probably be reworded for greater clarity (what does "disturb" mean, and perhaps what "relevant alarms" is may not be clear just from context). Section 4.1 The "/alarms/control/notify-status-changes" leaf controls if notifications are sent for all state changes, only raise and clear, or only notifications more severe than a configured level. This feature in combination with alarm shelving corresponds to the ITU Alarm Report Control functionality. Is there a specific section reference for the ITU functionality? (If not, it's probably fine to leave this as-is). Section 4.2 The system might not instrument all defined alarm type identities, and some alarm identities are abstract. I just wanted to double-check: the intent is indeed to use "instrument" here (as opposed to, say, "implement")? Section 4.7 /alarms/alarm-list/purge-alarms: Delete alarms from the "alarm-list" according to specific criteria, for example all cleared alarms older than a specific date. /alarms/alarm-list/compress-alarms: Compress the "status-change" list for the alarms. It's a bit confusing to me to have such different language for these two action nodes, since as far as I can tell the compress-alarms action also allows for specific criteria (e.g., resources) to be provided to limit the scope of the action. (Similarly for compress-shelved-alarms.) Section 6 feature service-impact-analysis { description "The system supports identifying candidate impacted resources for an alarm, for example a link being impacted by an interface alarm."; nit: it feels a bit odd to say that the link is "impacted by an alarm", since normally the causality flow would be the other way -- the link state changes, and then an alarm stat changes. I'm not sure I understand the distinction between 'warning' and 'minor' severities -- it seems that neither is supposed to be indicating a service-affecting fault. For the 'age-spec' choice, am I reading RFC 7950 correctly that I choose exactly one case of the choice, so I can't have both a "minute part" and an "hours part"? If so, then I would suggest using different description text for the choices, since the current text implies that you can combine parts with different units to assemble a compound timespec. list alarm { [...] Entries appear in the alarm list the first time an alarm becomes active for a given alarm-type and resource. Entries do not get deleted when the alarm is cleared, this is a boolean state in the alarm. nit: this is a comma splice. Section 10 It's a bit of a stretch as far as an attack, but an attacker that can temporarily reduce max-alarm-status-changes to a small value (e.g., one) could use that to hide their tracks to some extent if they can cause the alarm to clear after they've done what they intended to do. (They could then restore the max-alarm-status-changes value, too.) It seems that the list of alarms itself may be potentially sensitive, in that it potentially gives an attacker an authoritative picture of the (broken) state of the network. Appendix F.1 nit: We say that X.733 alarms "also use the basic criteria of deviation from normal condition", but it's not entirely clear whether the "also" indicates that they share this behavior with some external reference point or is a synonym for "additionally". nit: I think the semicolon in the ISA "comment" should be a regular colon. The paragraph at the end talks about "evolution" and "moves from" -- is the table sorted chronologically? Appendix G Are tables 4 and 5 talking about alarm rates or notification rates? |
2019-04-08
|
08 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-04-08
|
08 | Alissa Cooper | [Ballot comment] Thank you addressing the Gen-ART review. This sentence in Section 4 does not parse properly: The rest of the data model are made … [Ballot comment] Thank you addressing the Gen-ART review. This sentence in Section 4 does not parse properly: The rest of the data model are made conditional with YANG the features "operator-actions", "alarm-shelving", "alarm-history", "alarm-summary", "alarm-profile", and "severity-assignment". In 4.1: s/corresponds to the ITU Alarm Report Control functionality/corresponds to the ITU X.733 Alarm Report Control functionality |
2019-04-08
|
08 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-04-06
|
08 | Éric Vyncke | [Ballot comment] Easy to read and well-thought except for "shelving" alarms, it took me a while to understand that it was like "stashing" ;-) Section … [Ballot comment] Easy to read and well-thought except for "shelving" alarms, it took me a while to understand that it was like "stashing" ;-) Section 3.4, may I assume that the document fixes the problem "X.733 and especially 3GPP were not really clear on this point." ? Perhaps did I miss the part where the alarm system could also fails: what alarm? status? does it generate? Or is it out of scope? *minor NITS* Section 1 s/north-bound/northbound/ ? |
2019-04-06
|
08 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-04-05
|
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-04-05
|
08 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-04-04
|
08 | Roman Danyliw | [Ballot discuss] (1) Section 3.5, Alarm Life-Cycle. The text states that “A server SHOULD describe how long it retains cleared/closed alarms: until manually purged or … [Ballot discuss] (1) Section 3.5, Alarm Life-Cycle. The text states that “A server SHOULD describe how long it retains cleared/closed alarms: until manually purged or if it has an automatic removal policy.” How is this retention policy described? Is that in scope for this document? (2) Section 4.2, Alarm Inventory. The text states that “A server MUST implement the alarm inventory in order to enable controlled alarm procedures in the client.” What is the expected server behavior if a client sends an alarm type not in the inventory (and it isn’t part of the dynamic addition process)? (2) Section 10, Security Considerations. It seems like “/alarms/alarm-list/alarm/set-operator-state” should be listed as an operation in the YANG model that presents a security issues (just like “purge-alarms”). Consider if one altered the operator alert state causing the alarm management procedures to miss an alert (e.g., setting an alert to “closed” before any action is taken). (3) Section 10, Security Considerations. I don’t know must about the implementations, but wouldn’t compressing alerts (per compress-alarms and compress-shelved-alarms operations) remove them from consideration by alarm management procedures? If so, these would be a sensitive operation that would need to be listed as the concern equivalent to the current text for purge-alarms. |
2019-04-04
|
08 | Roman Danyliw | [Ballot comment] (1) Section 1.1, Terminology, “Fault”. Consider expanding the acronym “MOS” (Mean Option Score?) (2) Section 2, Objectives, Consider s/X.733/[X.733]/ (3) Section 3.2, Alarm … [Ballot comment] (1) Section 1.1, Terminology, “Fault”. Consider expanding the acronym “MOS” (Mean Option Score?) (2) Section 2, Objectives, Consider s/X.733/[X.733]/ (3) Section 3.2, Alarm Type, Consider s/identity based/identity-based/ (4) Section 3.2, Alarm Type, Typo, s/standard organization/standards organization/ (5) Section 3.4, Identifying Alarm Instances, Consider s/were not really clear/were not clear/ (6) Section 3.5.2, Operator Alarm Life-cycle, Consider s/can also act upon/act upon/ (7) Section 3.5.2, Operator Alarm Life-cycle, Consider s/A closed alarm is an alarm/For example, a closed alarm is an alarm/ (8) Section 3.6, Root Cause, Impacted Resources and Related Alarms, Consider s/Different systems have various various/Different systems have varying/ (9) Section 3.6, Root Cause, Impacted Resources and Related Alarms, Consider s/In some occasions/On some occasions/ (10) Section 3.6, Root Cause, Impacted Resources and Related Alarms, Consider s/needs to represent an alarm that indicates a situation that needs acting upon/raises an alarm to indicate a situation requiring attention/ (11) Section 4.1.1, Alarm Shelving, The text states “The instrumentation MUST move shelved alarms from the alarm list (/alarms/alarm-list) to the shelved alarm list (/alarms/shelved-alarms/).” It wasn’t clear when these shelved alarms must be moved given the text. (12) Section 4.4, The Alarm List, The sentence, “The alarm list (/alarms/alarm-list) is a function from (resource, alarm type, alarm type qualifier) to the current composite alarm state” is missing a word/phrase. Removing the parenthetical remarks it reads a “The alarm list is a function from to the current composite alarm state” is does not parse. (13) Consider s/Life-cycle/Lifecycle/g |
2019-04-04
|
08 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2019-04-04
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2019-04-04
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2019-04-04
|
08 | Mirja Kühlewind | [Ballot comment] Minor editorial comment: Appendix F.2.4.: "G.7710 is different than the previous referenced alarm standards. It does define a data-model for alarm reporting. … [Ballot comment] Minor editorial comment: Appendix F.2.4.: "G.7710 is different than the previous referenced alarm standards. It does define a data-model for alarm reporting. " Is this correct or is there a "not" missing? |
2019-04-04
|
08 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-04-01
|
08 | Amy Vezza | Placed on agenda for telechat - 2019-04-11 |
2019-04-01
|
08 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-04-01
|
08 | Deborah Brungard | Ballot has been issued |
2019-04-01
|
08 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2019-04-01
|
08 | Deborah Brungard | Created "Approve" ballot |
2019-04-01
|
08 | Deborah Brungard | Ballot writeup was changed |
2019-03-26
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2019-03-26
|
08 | Martin Björklund | New version available: draft-ietf-ccamp-alarm-module-08.txt |
2019-03-26
|
08 | (System) | New version approved |
2019-03-26
|
08 | (System) | Request for posting confirmation emailed to previous authors: Martin Bjorklund , Stefan Vallin |
2019-03-26
|
08 | Martin Björklund | Uploaded new revision |
2019-03-20
|
07 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-03-20
|
07 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-ccamp-alarm-module-07. 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-ccamp-alarm-module-07. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions 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: two, new namespaces will be registered as follows: ID: yang:ietf-alarms URI: urn:ietf:params:xml:ns:yang:ietf-alarms Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] ID: yang:ietf-alarms-x733 URI: urn:ietf:params:xml:ns:yang:ietf-alarms-x733 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/ two, new YANG modules will be registered as follows: Name: ietf-alarms File: [ TBD-at-Registration ] Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-alarms Prefix: al Module: Reference: [ RFC-to-be ] Name: ietf-alarms-x7333 File: [ TBD-at-Registration ] Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-alarms-x733 Prefix: x733 Module: Reference: [ RFC-to-be ] IANA Question --> Is the module name a typo? For instance, should it be ietf-alarms-x733 instead? While the YANG module names 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 Functions 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-03-20
|
07 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-03-18
|
07 | Dan Romascanu | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Dan Romascanu. Sent review to list. |
2019-03-18
|
07 | Joe Clarke | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Joe Clarke. Sent review to list. |
2019-03-14
|
07 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Shawn Emery. |
2019-03-11
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2019-03-11
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2019-03-07
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2019-03-07
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2019-03-07
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2019-03-07
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2019-03-06
|
07 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-03-06
|
07 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-03-20): From: The IESG To: IETF-Announce CC: Daniele Ceccarelli , ccamp-chairs@ietf.org, db3546@att.com, ccamp@ietf.org, … The following Last Call announcement was sent out (ends 2019-03-20): From: The IESG To: IETF-Announce CC: Daniele Ceccarelli , ccamp-chairs@ietf.org, db3546@att.com, ccamp@ietf.org, draft-ietf-ccamp-alarm-module@ietf.org, daniele.ceccarelli@ericsson.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (YANG Alarm Module) to Proposed Standard The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'YANG Alarm Module' 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-03-20. 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 module for alarm management. It includes functions for alarm list management, alarm shelving and notifications to inform management systems. There are also operations to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-03-06
|
07 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-03-06
|
07 | Deborah Brungard | Last call was requested |
2019-03-06
|
07 | Deborah Brungard | Ballot approval text was generated |
2019-03-06
|
07 | Deborah Brungard | Ballot writeup was generated |
2019-03-06
|
07 | Deborah Brungard | IESG state changed to Last Call Requested from Expert Review |
2019-03-06
|
07 | Deborah Brungard | Last call announcement was generated |
2019-01-28
|
07 | Martin Björklund | New version available: draft-ietf-ccamp-alarm-module-07.txt |
2019-01-28
|
07 | (System) | New version approved |
2019-01-28
|
07 | (System) | Request for posting confirmation emailed to previous authors: Martin Bjorklund , Stefan Vallin |
2019-01-28
|
07 | Martin Björklund | Uploaded new revision |
2019-01-11
|
06 | Deborah Brungard | Joel Halpern - RTG DIR review. |
2019-01-11
|
06 | Deborah Brungard | IESG state changed to Expert Review from Publication Requested |
2019-01-10
|
06 | Joel Halpern | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Joel Halpern. Sent review to list. |
2019-01-09
|
06 | Min Ye | Request for Last Call review by RTGDIR is assigned to Joel Halpern |
2019-01-09
|
06 | Min Ye | Request for Last Call review by RTGDIR is assigned to Joel Halpern |
2019-01-09
|
06 | Deborah Brungard | Requested Last Call review by RTGDIR |
2019-01-09
|
06 | Daniele Ceccarelli | 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? >Proposed standard. This is indicated in the title page header and approprited for the type of RFC. (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 This document defines a YANG module for alarm management. It includes functions for alarm list management, alarm shelving and notifications to inform management systems. There are also operations to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards. Working Group Summary The draft was first presented in Netmod working group as defining a genering alarm model, but then moved to CCAMP as the working group has the right competence to correctly progress this work. This was a successfull move as the draft was rapidly progressed with a very good support and also attracting new participants to the working group. Document Quality The draft has been discussed many times on the mailing list and been subject of many liaisons between the IETF and other SDOs. It is also supported by various telco vendors. The draft has already been reviewed by the YANG doctors with very positive feedbacks. Personnel Who is the Document Shepherd? Daniele Ceccarelli Who is the Responsible Area Director? Deborah Brunghard. (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. The draft is ready for publication. THis is the Shepherd opinion as well as the YANG doctors' one. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (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. YANG doctor review already carried out. (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. No concerns. (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. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure. (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? The WG as a whole understands and agrees with the document. The draft also brought new participants to the wg which are not interested in usual CCAMP work but particularly interested on the topic. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.) No. (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. Minor issues with references and spacing that can be solved during the next steps of reviews. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document passed the YANG doctor review. (13) Have all references within this document been identified as either normative or informative? Yes. Two normative references need to be updated. (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? None. (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. No. (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. No. (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). This document registers two URIs in the IETF XML registry and two YANG modules in the YANG Module Names registry. THis is properly identified in the IANA section. (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. (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. |
2019-01-09
|
06 | Daniele Ceccarelli | Responsible AD changed to Deborah Brungard |
2019-01-09
|
06 | Daniele Ceccarelli | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2019-01-09
|
06 | Daniele Ceccarelli | IESG state changed to Publication Requested from I-D Exists |
2019-01-09
|
06 | Daniele Ceccarelli | IESG process started in state Publication Requested |
2019-01-09
|
06 | Daniele Ceccarelli | Changed consensus to Yes from Unknown |
2019-01-09
|
06 | Daniele Ceccarelli | Intended Status changed to Proposed Standard from None |
2019-01-09
|
06 | Daniele Ceccarelli | 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? >Proposed standard. This is indicated in the title page header and approprited for the type of RFC. (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 This document defines a YANG module for alarm management. It includes functions for alarm list management, alarm shelving and notifications to inform management systems. There are also operations to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards. Working Group Summary The draft was first presented in Netmod working group as defining a genering alarm model, but then moved to CCAMP as the working group has the right competence to correctly progress this work. This was a successfull move as the draft was rapidly progressed with a very good support and also attracting new participants to the working group. Document Quality The draft has been discussed many times on the mailing list and been subject of many liaisons between the IETF and other SDOs. It is also supported by various telco vendors. The draft has already been reviewed by the YANG doctors with very positive feedbacks. Personnel Who is the Document Shepherd? Daniele Ceccarelli Who is the Responsible Area Director? Deborah Brunghard. (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. The draft is ready for publication. THis is the Shepherd opinion as well as the YANG doctors' one. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (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. YANG doctor review already carried out. (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. No concerns. (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. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure. (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? The WG as a whole understands and agrees with the document. The draft also brought new participants to the wg which are not interested in usual CCAMP work but particularly interested on the topic. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.) No. (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. Minor issues with references and spacing that can be solved during the next steps of reviews. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document passed the YANG doctor review. (13) Have all references within this document been identified as either normative or informative? Yes. Two normative references need to be updated. (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? None. (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. No. (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. No. (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). This document registers two URIs in the IETF XML registry and two YANG modules in the YANG Module Names registry. THis is properly identified in the IANA section. (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. (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. |
2019-01-09
|
06 | Daniele Ceccarelli | Notification list changed to Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> |
2019-01-09
|
06 | Daniele Ceccarelli | Document shepherd changed to Daniele Ceccarelli |
2018-12-19
|
06 | Carl Moberg | Request for Last Call review by YANGDOCTORS Completed: Ready. Reviewer: Carl Moberg. Sent review to list. |
2018-11-21
|
06 | Martin Björklund | New version available: draft-ietf-ccamp-alarm-module-06.txt |
2018-11-21
|
06 | (System) | New version approved |
2018-11-21
|
06 | (System) | Request for posting confirmation emailed to previous authors: Martin Bjorklund , Stefan Vallin |
2018-11-21
|
06 | Martin Björklund | Uploaded new revision |
2018-11-21
|
05 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Carl Moberg |
2018-11-21
|
05 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Carl Moberg |
2018-11-21
|
05 | Daniele Ceccarelli | Requested Last Call review by YANGDOCTORS |
2018-11-07
|
05 | Daniele Ceccarelli | IPR poll (Daniele) https://mailarchive.ietf.org/arch/msg/ccamp/A3h-JwwFQUR9QdXLkVM0z0b7Dgw AUTHORS Martin Bjorklund mbj@tail-f.com https://mailarchive.ietf.org/arch/msg/ccamp/3KNlZ1RI4xK62emwPCiYpWW6b38 Stefan Vallin stefan@wallan.se https://mailarchive.ietf.org/arch/msg/ccamp/xb3BA1MDU4VXo8qcLivkYHHv4Zg |
2018-11-07
|
05 | Daniele Ceccarelli | IETF WG state changed to In WG Last Call from WG Document |
2018-11-05
|
05 | Martin Björklund | New version available: draft-ietf-ccamp-alarm-module-05.txt |
2018-11-05
|
05 | (System) | New version approved |
2018-11-05
|
05 | (System) | Request for posting confirmation emailed to previous authors: Martin Bjorklund , Stefan Vallin |
2018-11-05
|
05 | Martin Björklund | Uploaded new revision |
2018-10-09
|
04 | Martin Björklund | New version available: draft-ietf-ccamp-alarm-module-04.txt |
2018-10-09
|
04 | (System) | New version approved |
2018-10-09
|
04 | (System) | Request for posting confirmation emailed to previous authors: Martin Bjorklund , Stefan Vallin |
2018-10-09
|
04 | Martin Björklund | Uploaded new revision |
2018-09-20
|
03 | Martin Björklund | New version available: draft-ietf-ccamp-alarm-module-03.txt |
2018-09-20
|
03 | (System) | New version approved |
2018-09-20
|
03 | (System) | Request for posting confirmation emailed to previous authors: Martin Bjorklund , Stefan Vallin |
2018-09-20
|
03 | Martin Björklund | Uploaded new revision |
2018-08-08
|
02 | Martin Björklund | New version available: draft-ietf-ccamp-alarm-module-02.txt |
2018-08-08
|
02 | (System) | New version approved |
2018-08-08
|
02 | (System) | Request for posting confirmation emailed to previous authors: Martin Bjorklund , Stefan Vallin |
2018-08-08
|
02 | Martin Björklund | Uploaded new revision |
2018-02-08
|
01 | Martin Björklund | New version available: draft-ietf-ccamp-alarm-module-01.txt |
2018-02-08
|
01 | (System) | New version approved |
2018-02-08
|
01 | (System) | Request for posting confirmation emailed to previous authors: Martin Bjorklund , Stefan Vallin |
2018-02-08
|
01 | Martin Björklund | Uploaded new revision |
2017-12-14
|
00 | Fatai Zhang | IPR Polling result: from Martin Bjorklund: https://mailarchive.ietf.org/arch/msg/ccamp/Ke7wj88A61FwBMpkQz9cdWmpekE from Stefan Vallin: https://mailarchive.ietf.org/arch/msg/ccamp/Yim3tWLEy8AwMC86w4LCEv7sk5s |
2017-12-14
|
00 | Daniele Ceccarelli | This document now replaces draft-vallin-ccamp-alarm-module instead of None |
2017-12-14
|
00 | Martin Björklund | New version available: draft-ietf-ccamp-alarm-module-00.txt |
2017-12-14
|
00 | (System) | WG -00 approved |
2017-12-14
|
00 | Martin Björklund | Set submitter to "Martin Bjorklund ", replaces to (none) and sent approval email to group chairs: ccamp-chairs@ietf.org |
2017-12-14
|
00 | Martin Björklund | Uploaded new revision |