A YANG Data Model for Syslog Configuration
draft-ietf-netmod-syslog-model-33
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2025-02-04
|
33 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2024-10-02
|
33 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2024-10-02
|
33 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2024-10-02
|
33 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2024-09-27
|
33 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2024-09-25
|
33 | Cindy Morgan | Manually changing the state to "RFC Editor Queue" because the automation that would normally handle that didn't work as expected because this doc had previously … Manually changing the state to "RFC Editor Queue" because the automation that would normally handle that didn't work as expected because this doc had previously been added to (and then removed from) the RFC Editor Queue. |
2024-09-25
|
33 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2024-09-23
|
33 | (System) | RFC Editor state changed to EDIT |
2024-09-20
|
33 | (System) | IANA Action state changed to In Progress from RFC-Ed-Ack |
2024-09-20
|
33 | (System) | Removed all action holders (IESG state changed) |
2024-09-20
|
33 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup |
2024-09-20
|
33 | Cindy Morgan | IESG has approved the document |
2024-09-20
|
33 | Cindy Morgan | Closed "Approve" ballot |
2024-09-20
|
33 | Cindy Morgan | Ballot approval text was generated |
2024-09-19
|
33 | Jenny Bui | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation |
2024-09-18
|
33 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2024-09-18
|
33 | Paul Wouters | [Ballot comment] Thanks for addressing my concerns and undoing my suggestion that didn't take the Historic nature of RFC6587 into account :) |
2024-09-18
|
33 | Paul Wouters | [Ballot Position Update] Position for Paul Wouters has been changed to Yes from Discuss |
2024-09-18
|
33 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2024-09-18
|
33 | Mahesh Jethanandani | New version available: draft-ietf-netmod-syslog-model-33.txt |
2024-09-18
|
33 | Mahesh Jethanandani | New version accepted (logged-in submitter: Mahesh Jethanandani) |
2024-09-18
|
33 | Mahesh Jethanandani | Uploaded new revision |
2024-09-18
|
32 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2024-09-18
|
32 | Zaheduzzaman Sarker | [Ballot comment] Thanks for working on this specificatoin. No object from transport protocol aspects. (no syslog protocol over QUIC yet ?? :-)) |
2024-09-18
|
32 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2024-09-17
|
33 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2024-09-17
|
32 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2024-09-16
|
32 | Roman Danyliw | [Ballot comment] Thank you to Francis Dupont for the GENART review. ** Section 10 says “ There are no RPC operations defined in this YANG … [Ballot comment] Thank you to Francis Dupont for the GENART review. ** Section 10 says “ There are no RPC operations defined in this YANG module.” However, in Figure 1 there is: | | +---x generate-csr {csr-generation}? Which appears to be generate-csr-grouping from draft-ietf-netconf-crypto-types. Should the Security Considerations of draft-ietf-netconf-crypto-types be mentioned? Is this Section 10 language of “no RPC operations defined”accurate – is it because the thinking is that this functionality is imported (via ct:asymmetric-key-pair-with-cert-grouping)? |
2024-09-16
|
32 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2024-09-16
|
32 | Orie Steele | [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele |
2024-09-15
|
32 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2024-09-13
|
32 | Gunter Van de Velde | [Ballot comment] # Gunter Van de Velde, RTG AD, comments for draft-ietf-netmod-syslog-model-32 # Many thanks for writing this document and for resolving the raised discuss … [Ballot comment] # Gunter Van de Velde, RTG AD, comments for draft-ietf-netmod-syslog-model-32 # Many thanks for writing this document and for resolving the raised discuss by providing more accurate text. #DISCUSS (resolved) ======================= ## (resolved (2024 Sept 13)) I am raising a DISCUSS. The inclusion of vendor-specific details in the main body of a standards-track document is unexpected (see line 165). If the Working Group wishes to document vendor-specific properties, it should be considered informational and explicitly placed in an appendix for clarity. Upon reviewing the YANG module, I note that the vendor-specific augmentations are already documented in the appendix. It may be beneficial for clarity to add a note at line 165 indicating that the referenced vendor-specific augmentations are detailed in Appendix A.1 and A.2. #GENERIC COMMENTS #================ ## The yang module has a significant amount of feature statement defines an optional capability that may or may not be supported by an implementation of the YANG module. Some of these at first glance look rather feasible for being supported by default. Has the list of optional capabilities been verified with existing syslog implementations? ## Some lines in the pyang tree output are wrapped, which affects the overall presentation. While this is not ideal, I do not have a better suggestion at this time. In my view, using abbreviations for leaf names would be less desirable from a modeling perspective than allowing wrapped lines within an IETF YANG standards document. #DETAILED COMMENTS #================= ##classified as [minor] and [major] 117 2. Terminology 118 119 The term "originator" is defined in [RFC5424] : an "originator" 120 generates syslog content to be carried in a message. 121 122 The term "relay" is defined in [RFC5424] : a "relay" forwards 123 messages, accepting messages from originators or other relays and 124 sending them to collectors or other relays 125 126 The term "collectors" is defined in [RFC5424] : a "collector" gathers 127 syslog content for further analysis. 128 129 The term "action" refers to the processing that takes place for each 130 syslog message received. [minor] rewrite suggestion for making the Terminology section more structured: " The following terms are used throughout this document: Originator: As defined in [RFC5424], an "originator" refers to an entity that generates syslog content to be included in a message. Relay: As defined in [RFC5424], a "relay" is an entity that forwards syslog messages. It accepts messages from originators or other relays and sends them to collectors or other relays. Collector: As defined in [RFC5424], a "collector" refers to an entity that gathers syslog messages for further analysis. Action: Refers to the processing applied to each syslog message received. " 160 This document addresses the common leafs between implementations and 161 creates a common model, which can be augmented with proprietary 162 features, if necessary. This model is designed to be very simple for 163 maximum flexibility. [minor] rewrite proposal: " This document identifies common elements across implementations and defines a shared model, which can be augmented with proprietary features as needed. The model is intentionally designed to be simple, ensuring maximum flexibility. " |
2024-09-13
|
32 | Gunter Van de Velde | [Ballot Position Update] Position for Gunter Van de Velde has been changed to No Objection from Discuss |
2024-09-10
|
32 | Gunter Van de Velde | [Ballot discuss] # Gunter Van de Velde, RTG AD, comments for draft-ietf-netmod-syslog-model-32 # Many thanks for writing this document. It contains one blocking DISCUSS, which … [Ballot discuss] # Gunter Van de Velde, RTG AD, comments for draft-ietf-netmod-syslog-model-32 # Many thanks for writing this document. It contains one blocking DISCUSS, which will likely be straightforward to resolve and some non-blocking comments and observations. #DISCUSS ======== ## I am raising a DISCUSS. The inclusion of vendor-specific details in the main body of a standards-track document is unexpected (see line 165). If the Working Group wishes to document vendor-specific properties, it should be considered informational and explicitly placed in an appendix for clarity. Upon reviewing the YANG module, I note that the vendor-specific augmentations are already documented in the appendix. It may be beneficial for clarity to add a note at line 165 indicating that the referenced vendor-specific augmentations are detailed in Appendix A.1 and A.2. |
2024-09-10
|
32 | Gunter Van de Velde | [Ballot comment] #GENERIC COMMENTS #================ ## The yang module has a significant amount of feature statement defines an optional capability that may or may not … [Ballot comment] #GENERIC COMMENTS #================ ## The yang module has a significant amount of feature statement defines an optional capability that may or may not be supported by an implementation of the YANG module. Some of these at first glance look rather feasible for being supported by default. Has the list of optional capabilities been verified with existing syslog implementations? ## Some lines in the pyang tree output are wrapped, which affects the overall presentation. While this is not ideal, I do not have a better suggestion at this time. In my view, using abbreviations for leaf names would be less desirable from a modeling perspective than allowing wrapped lines within an IETF YANG standards document. #DETAILED COMMENTS #================= ##classified as [minor] and [major] 117 2. Terminology 118 119 The term "originator" is defined in [RFC5424] : an "originator" 120 generates syslog content to be carried in a message. 121 122 The term "relay" is defined in [RFC5424] : a "relay" forwards 123 messages, accepting messages from originators or other relays and 124 sending them to collectors or other relays 125 126 The term "collectors" is defined in [RFC5424] : a "collector" gathers 127 syslog content for further analysis. 128 129 The term "action" refers to the processing that takes place for each 130 syslog message received. [minor] rewrite suggestion for making the Terminology section more structured: " The following terms are used throughout this document: Originator: As defined in [RFC5424], an "originator" refers to an entity that generates syslog content to be included in a message. Relay: As defined in [RFC5424], a "relay" is an entity that forwards syslog messages. It accepts messages from originators or other relays and sends them to collectors or other relays. Collector: As defined in [RFC5424], a "collector" refers to an entity that gathers syslog messages for further analysis. Action: Refers to the processing applied to each syslog message received. " 160 This document addresses the common leafs between implementations and 161 creates a common model, which can be augmented with proprietary 162 features, if necessary. This model is designed to be very simple for 163 maximum flexibility. [minor] rewrite proposal: " This document identifies common elements across implementations and defines a shared model, which can be augmented with proprietary features as needed. The model is intentionally designed to be simple, ensuring maximum flexibility. " |
2024-09-10
|
32 | Gunter Van de Velde | [Ballot Position Update] New position, Discuss, has been recorded for Gunter Van de Velde |
2024-09-09
|
32 | Paul Wouters | [Ballot discuss] Thanks for this document. I have a few points to discuss that hopefully are minor and a result from my misunderstanding. The layout … [Ballot discuss] Thanks for this document. I have a few points to discuss that hopefully are minor and a result from my misunderstanding. The layout is completely broken / wrapped, making the document fairly unreadable. Can this be fixed somehow ? I don't see a method for syslog using TCP without TLS ? In fact, I am using that on my personal home router to my collection server, without TLS. Could the document not simply use: +--rw (transport) | +--:(udp) | | +--rw udp | | +--rw address? inet:host | | +--rw port? inet:port-number | | +--rw tcp | | +--rw address? inet:host | | +--rw port? inet:port-number | +--:(tls) Also, how do ports and addresses combine. Can I specify "1.2.3.4:80 and 5.6.7.8:443" ? It looks like that is not the case here? I don't see an option for configuring ratelimits, which are commonly available as options for syslog services? Could the TLS configuration parameters not use another model (one the IESG reviewed a little while ago?). It seems odd to define these within the syslog module. It would be nice if any kind of certificate options with TLS could be included from another module so if there are no TLS options, this module/RFC does not require updating? Maybe the same applies for the "signers" section but perhaps that is differently formatted data signed and unrelated to the TLS layer ? |
2024-09-09
|
32 | Paul Wouters | [Ballot comment] Related question: Is it one certificate+key that used for the TLS connection as well as to sign data within the payload of packets? … [Ballot comment] Related question: Is it one certificate+key that used for the TLS connection as well as to sign data within the payload of packets? facility-filter seems badly named as it also filters for severity ? Maybe syslof-filter ? |
2024-09-09
|
32 | Paul Wouters | [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters |
2024-09-04
|
32 | Éric Vyncke | [Ballot comment] Thanks for the work done in this document, I have nevertheless some non-blocking comments (see below) and I am also curious why this … [Ballot comment] Thanks for the work done in this document, I have nevertheless some non-blocking comments (see below) and I am also curious why this document was done in NETMOD rather than OPSAWG (as it seems that many YANG models are authored in OPSAWG even if NETMOD charter would allow it). # Meta data Should Mahesh's new affiliation be specified ? # Abstract and title It is unclear that the YANG model is only for the collector part of syslog. # Section 1 What is the `target system` ? At first reading, it seems to be the collector system, if so, should the I-D be consistent in vocabulary ? # Section 5.1 While I am not a YANG expert, isn't it weird to replicate the facility-filter under console, remote, and file ? Or is it just a caveat of the tree diagram when it expands the facility-filter grouping several times ? Would it be possible to import TLS and authentication from other YANG models ? |
2024-09-04
|
32 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2024-09-03
|
32 | Mahesh Jethanandani | [Ballot comment] As an author of the draft, I am recusing myself. |
2024-09-03
|
32 | Mahesh Jethanandani | [Ballot Position Update] New position, Recuse, has been recorded for Mahesh Jethanandani |
2024-09-03
|
32 | Cindy Morgan | Telechat date has been changed to 2024-09-19 from 2018-03-08 |
2024-09-03
|
32 | Warren Kumari | Ballot has been issued |
2024-09-03
|
32 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2024-09-03
|
32 | Warren Kumari | Created "Approve" ballot |
2024-09-03
|
32 | Warren Kumari | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2024-09-03
|
32 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2024-08-30
|
32 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2024-08-30
|
32 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-netmod-syslog-model-32. If any part of this review is inaccurate, please let us know. IANA … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-netmod-syslog-model-32. If any part of this review is inaccurate, please let us know. IANA understands that, upon approval of this document, there are two actions which we must complete. First, in the ns registry in the IETF XML Registry group located at: https://www.iana.org/assignments/xml-registry/ a single new namespace will be registered as follows: ID: yang:ietf-syslog URI: urn:ietf:params:xml:ns:yang:ietf-syslog Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request. Second, in the YANG Module Names registry on the YANG Parameters registry group located at: https://www.iana.org/assignments/yang-parameters/ a single new YANG module will be registered as follows: Name: ietf-syslog File: [ TBD-at-Registration ] Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-syslog Prefix: syslog 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. We understand 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. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2024-08-20
|
32 | David Dong | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2024-08-20
|
32 | David Dong | IANA Experts State changed to Reviews assigned |
2024-08-20
|
32 | Jenny Bui | The following Last Call announcement was sent out (ends 2024-09-03): From: The IESG To: IETF-Announce CC: Kent Watsen , Lou Berger , draft-ietf-netmod-syslog-model@ietf.org, kwatsen@juniper.net … The following Last Call announcement was sent out (ends 2024-09-03): From: The IESG To: IETF-Announce CC: Kent Watsen , Lou Berger , draft-ietf-netmod-syslog-model@ietf.org, kwatsen@juniper.net, netmod-chairs@ietf.org, netmod@ietf.org, warren@kumari.net Reply-To: last-call@ietf.org Sender: Subject: Last Call: (A YANG Data Model for Syslog Configuration) to Proposed Standard The IESG has received a request from the Network Modeling WG (netmod) to consider the following document: - 'A YANG Data Model for Syslog Configuration' 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 last-call@ietf.org mailing lists by 2024-09-03. 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 for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ No IPR declarations have been submitted directly on this I-D. |
2024-08-20
|
32 | Jenny Bui | IESG state changed to In Last Call from Last Call Requested |
2024-08-20
|
32 | Jenny Bui | Last call announcement was generated |
2024-08-20
|
32 | Warren Kumari | Last call was requested |
2024-08-20
|
32 | Warren Kumari | IESG state changed to Last Call Requested from AD Evaluation |
2024-08-20
|
32 | (System) | Changed action holders to Warren Kumari (IESG state changed) |
2024-08-20
|
32 | Warren Kumari | IESG state changed to AD Evaluation from Publication Requested |
2024-08-20
|
32 | Warren Kumari | Changed action holders to Mahesh Jethanandani, Warren Kumari |
2024-08-20
|
32 | Warren Kumari | Ballot writeup was changed |
2024-08-15
|
32 | Mahesh Jethanandani | Shepherding AD changed to Warren "Ace" Kumari |
2024-08-14
|
32 | Mahesh Jethanandani | Shepherding AD changed to Mahesh Jethanandani |
2024-08-14
|
32 | Mahesh Jethanandani | Changed action holders to Mahesh Jethanandani (Change of leadership) |
2024-08-14
|
32 | 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? A Proposed Standard is being requested. A proposed standard is needed to ensure interoperability. The title page header indicates that it is a Standards Track document. (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. This document defines a YANG data model for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. 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? Yes, the model initially had defined support for configuring Syslog over TPC (RFC 6587). However, after reviewing the reasoning for why RFC 6587 was made HISTORIC, as decided to remove the support. Some stated that their companies support Syslog over TCP and now they would have to augment this model with a vendor-specific extension. There may be a subtle distinction between IETF defining an insecure protocol versus defining a data model to configure, amongst other things, an insecure protocol. We believe we did the right thing, from an IETF perspective, but please double-check this. 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? This draft defines a data model (not a protocol). So far, two vendors have indicated that they're interested in implementing this data model. There was a YANG Doctor review on the -17 that was successful: https://datatracker.ietf.org/doc/review-ietf-netmod-syslog-model-17-yangdoctors-lc-watsen-2017-09-12/ Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The Shepherd is Kent Watsen. The AD is Benoit Claise. (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 Document Shepherd went through the checklist posted here: http://trac.tools.ietf.org/group/iesg/trac/wiki/DraftShepherdWriteupWgAlternate One noteworthy point here. Regarding the checklist item "Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?", it is worth noting that this draft references both draft-ietf-netconf-keystore and draft-ietf-netconf-tls-client-server. While these two drafts are both fairly mature, they are not in a clear state. For example, the most recent update to the keystore module removed the storage of keys from it, and thus now the working group is ascertaining if the module should be renamed, which would have a ripple-effect on this draft. One idea was to remove the TLS-support from this document (leaving only the UDP transport), but it was decided to instead keep the references, which guarantees a MISREF, and then, once those other drafts are resolved, this draft may need some final fit-and-finish so it's aligned. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns (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. No portions of the document have been flagged as needing to be reviewed from a particular or broader perspective. (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. The Document Shepherd has no specific concerns or issues with this document beyond the afore-mentioned dependency on the YANG modules within the "keystore" and "tls-client-server" drafts. (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. This verification occurred at the time of the WG Last Call. (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 has been filed. (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? Strong concurrence of a few individuals, with others being silent. (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.) No one has threatened an appeal 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. Idnits finds only two issues: == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line 1340, but no explicit reference was found in the text '[I-D.ietf-netconf-keystore] Watsen, K., "YANG Data Model for a "Keys...' This is a bug in idnits, whereby a reference that splits two lines is not found. == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-05 This is not an issue. The tree-diagrams draft is almost an RFC now and already there should an RFC Editor note requesting the I-D be replaced with the final RFC number assignment. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. This document has been reviewed by a member of the YANG Doctors group. (13) Have all references within this document been identified as either normative or informative? Yes, all references have been partitioned into these two groupings. The partitioning seems okay except: * the tree-diagrams reference is Normative, whereas it should be Informative (mentioned to the author on Jan 17). Also, missing is an RFC Editor note requesting that the I-D reference to be updated to reflect the assigned RFC number. (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? There are two normative references to works in progress: draft-ietf-netconf-keystore and draft-ietf-netconf-tls-client-server. While both these drafts are fairly mature, they will take time to complete. Given the Editor of those drafts is busy, the chairs have looked for others that would be willing to take over the Editor role. Unfortunately, there were no takers. At this time, we have assurances from the Editor that those drafts will get moved back to the "front burner" in 2-3 weeks. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (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. 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). The draft does not define any new registries. It does insert one new element into two existing registries. It does this using the standard registration technique found in many YANG model drafts. (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. This document does not define any new IANA 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. The shepherd validated both the primary and example yang modules using both the `pyang` and `yanglint` tools. The shepherd also validated the two XML examples in Section 5 of the document using the `yanglint` tool |
2024-08-14
|
32 | Kent Watsen | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2024-08-14
|
32 | Kent Watsen | IESG state changed to Publication Requested from Dead |
2024-08-14
|
32 | (System) | Changed action holders to Robert Wilton (IESG state changed) |
2024-03-20
|
32 | Joe Clarke | New version available: draft-ietf-netmod-syslog-model-32.txt |
2024-03-20
|
32 | Joe Clarke | New version accepted (logged-in submitter: Joe Clarke) |
2024-03-20
|
32 | Joe Clarke | Uploaded new revision |
2024-03-19
|
31 | Joe Clarke | New version available: draft-ietf-netmod-syslog-model-31.txt |
2024-03-19
|
31 | Joe Clarke | New version accepted (logged-in submitter: Joe Clarke) |
2024-03-19
|
31 | Joe Clarke | Uploaded new revision |
2023-09-07
|
30 | (System) | Document has expired |
2023-09-07
|
30 | (System) | Removed all action holders (IESG state changed) |
2023-09-07
|
30 | (System) | IESG state changed to Dead from I-D Exists |
2023-04-28
|
30 | Kent Watsen | Notification list changed to "Lou Berger" <lberger@labn.net>, "Kent Watsen" <kent+ietf@watsen.net> from "Lou Berger" <lberger@labn.net>, "Kent Watsen" <kwatsen@juniper.net> |
2023-04-28
|
30 | Kent Watsen | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2023-03-06
|
30 | Joe Clarke | New version available: draft-ietf-netmod-syslog-model-30.txt |
2023-03-06
|
30 | Joe Clarke | New version accepted (logged-in submitter: Joe Clarke) |
2023-03-06
|
30 | Joe Clarke | Uploaded new revision |
2023-02-28
|
29 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2023-02-28
|
29 | Joe Clarke | New version available: draft-ietf-netmod-syslog-model-29.txt |
2023-02-28
|
29 | Joe Clarke | New version accepted (logged-in submitter: Joe Clarke) |
2023-02-28
|
29 | Joe Clarke | Uploaded new revision |
2023-01-13
|
28 | Kent Watsen | IETF WG state changed to In WG Last Call from WG Document |
2022-10-14
|
28 | (System) | Changed action holders to Robert Wilton (IESG state changed) |
2022-10-14
|
28 | Robert Wilton | IESG state changed to I-D Exists from Dead |
2022-10-11
|
28 | Joe Clarke | New version available: draft-ietf-netmod-syslog-model-28.txt |
2022-10-11
|
28 | Joe Clarke | New version accepted (logged-in submitter: Joe Clarke) |
2022-10-11
|
28 | Joe Clarke | Uploaded new revision |
2022-10-08
|
27 | (System) | Document has expired |
2022-07-24
|
27 | Lou Berger | Added to session: IETF-114: netmod Wed-1500 |
2022-04-06
|
27 | Joe Clarke | New version available: draft-ietf-netmod-syslog-model-27.txt |
2022-04-06
|
27 | (System) | New version approved |
2022-04-05
|
27 | (System) | Request for posting confirmation emailed to previous authors: Clyde Wildes , Kiran Koushik , netmod-chairs@ietf.org |
2022-04-05
|
27 | Joe Clarke | Uploaded new revision |
2021-06-14
|
26 | Kent Watsen | This document was in MISREF state for a long time. The document that it was waiting on is nearing completion and it is clear that … This document was in MISREF state for a long time. The document that it was waiting on is nearing completion and it is clear that this document needs to now be updated to reflect the YANG module in the current version of that document. |
2021-06-14
|
26 | Kent Watsen | Tag Holding for references cleared. |
2021-06-14
|
26 | Kent Watsen | IETF WG state changed to WG Document from Submitted to IESG for Publication |
2021-06-09
|
26 | (System) | Document has expired |
2021-06-09
|
26 | (System) | Removed all action holders (IESG state changed) |
2021-06-09
|
26 | (System) | IESG state changed to Dead from I-D Exists |
2021-06-09
|
26 | Robert Wilton | This document has been stuck in MISREF for a long time and now it is appropriate to update it vis the WG before publishing. |
2021-06-09
|
26 | (System) | Changed action holders to Robert Wilton (IESG state changed) |
2021-06-09
|
26 | Robert Wilton | IESG state changed to I-D Exists from RFC Ed Queue |
2021-06-08
|
26 | Robert Wilton | Shepherding AD changed to Robert Wilton |
2021-06-07
|
26 | Kent Watsen | Two action requests: - reassign back to the NETMOD WG - assign 'Rob Wilton' as AD Kent |
2018-04-26
|
26 | 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? A Proposed Standard is being requested. A proposed standard is needed to ensure interoperability. The title page header indicates that it is a Standards Track document. (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. This document defines a YANG data model for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. 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? Yes, the model initially had defined support for configuring Syslog over TPC (RFC 6587). However, after reviewing the reasoning for why RFC 6587 was made HISTORIC, as decided to remove the support. Some stated that their companies support Syslog over TCP and now they would have to augment this model with a vendor-specific extension. There may be a subtle distinction between IETF defining an insecure protocol versus defining a data model to configure, amongst other things, an insecure protocol. We believe we did the right thing, from an IETF perspective, but please double-check this. 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? This draft defines a data model (not a protocol). So far, two vendors have indicated that they're interested in implementing this data model. There was a YANG Doctor review on the -17 that was successful: https://datatracker.ietf.org/doc/review-ietf-netmod-syslog-model-17-yangdoctors-lc-watsen-2017-09-12/ Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The Shepherd is Kent Watsen. The AD is Benoit Claise. (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 Document Shepherd went through the checklist posted here: http://trac.tools.ietf.org/group/iesg/trac/wiki/DraftShepherdWriteupWgAlternate One noteworthy point here. Regarding the checklist item "Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?", it is worth noting that this draft references both draft-ietf-netconf-keystore and draft-ietf-netconf-tls-client-server. While these two drafts are both fairly mature, they are not in a clear state. For example, the most recent update to the keystore module removed the storage of keys from it, and thus now the working group is ascertaining if the module should be renamed, which would have a ripple-effect on this draft. One idea was to remove the TLS-support from this document (leaving only the UDP transport), but it was decided to instead keep the references, which guarantees a MISREF, and then, once those other drafts are resolved, this draft may need some final fit-and-finish so it's aligned. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns (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. No portions of the document have been flagged as needing to be reviewed from a particular or broader perspective. (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. The Document Shepherd has no specific concerns or issues with this document beyond the afore-mentioned dependency on the YANG modules within the "keystore" and "tls-client-server" drafts. (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. This verification occurred at the time of the WG Last Call. (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 has been filed. (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? Strong concurrence of a few individuals, with others being silent. (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.) No one has threatened an appeal 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. Idnits finds only two issues: == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line 1340, but no explicit reference was found in the text '[I-D.ietf-netconf-keystore] Watsen, K., "YANG Data Model for a "Keys...' This is a bug in idnits, whereby a reference that splits two lines is not found. == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-05 This is not an issue. The tree-diagrams draft is almost an RFC now and already there should an RFC Editor note requesting the I-D be replaced with the final RFC number assignment. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. This document has been reviewed by a member of the YANG Doctors group. (13) Have all references within this document been identified as either normative or informative? Yes, all references have been partitioned into these two groupings. The partitioning seems okay except: * the tree-diagrams reference is Normative, whereas it should be Informative (mentioned to the author on Jan 17). Also, missing is an RFC Editor note requesting that the I-D reference to be updated to reflect the assigned RFC number. (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? There are two normative references to works in progress: draft-ietf-netconf-keystore and draft-ietf-netconf-tls-client-server. While both these drafts are fairly mature, they will take time to complete. Given the Editor of those drafts is busy, the chairs have looked for others that would be willing to take over the Editor role. Unfortunately, there were no takers. At this time, we have assurances from the Editor that those drafts will get moved back to the "front burner" in 2-3 weeks. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (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. 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). The draft does not define any new registries. It does insert one new element into two existing registries. It does this using the standard registration technique found in many YANG model drafts. (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. This document does not define any new IANA 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. The shepherd validated both the primary and example yang modules using both the `pyang` and `yanglint` tools. The shepherd also validated the two XML examples in Section 5 of the document using the `yanglint` tool |
2018-04-26
|
26 | Kent Watsen | [Hi Ignas. There are some minor updates needed, per https://mailarchive.ietf.org/arch/msg/netmod/tzZEsmGJBIcU7EP0pF8wvMjA9wI. You can go ahead are start processing this document now (if so inclined) with … [Hi Ignas. There are some minor updates needed, per https://mailarchive.ietf.org/arch/msg/netmod/tzZEsmGJBIcU7EP0pF8wvMjA9wI. You can go ahead are start processing this document now (if so inclined) with the assumption that an updated draft will be posted to address said issues, and that I'll come back and edit this shepherd writeup to remove this note and some of the comments below. I imagine all this happening before you put this document up on the Tele-Chat. Kent] 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? A Proposed Standard is being requested. A proposed standard is needed to ensure interoperability. The title page header indicates that it is a Standards Track document. (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. This document defines a YANG data model for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. 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? Yes, the model initially had defined support for configuring Syslog over TPC (RFC 6587). However, after reviewing the reasoning for why RFC 6587 was made HISTORIC, as decided to remove the support. Some stated that their companies support Syslog over TCP and now they would have to augment this model with a vendor-specific extension. There may be a subtle distinction between IETF defining an insecure protocol versus defining a data model to configure, amongst other things, an insecure protocol. We believe we did the right thing, from an IETF perspective, but please double-check this. 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? This draft defines a data model (not a protocol). So far, two vendors have indicated that they're interested in implementing this data model. There was a YANG Doctor review on the -17 that was successful: https://datatracker.ietf.org/doc/review-ietf-netmod-syslog-model-17-yangdoctors-lc-watsen-2017-09-12/ Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The Shepherd is Kent Watsen. The AD is Benoit Claise. (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 Document Shepherd went through the checklist posted here: http://trac.tools.ietf.org/group/iesg/trac/wiki/DraftShepherdWriteupWgAlternate One noteworthy point here. Regarding the checklist item "Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?", it is worth noting that this draft references both draft-ietf-netconf-keystore and draft-ietf-netconf-tls-client-server. While these two drafts are both fairly mature, they are not in a clear state. For example, the most recent update to the keystore module removed the storage of keys from it, and thus now the working group is ascertaining if the module should be renamed, which would have a ripple-effect on this draft. One idea was to remove the TLS-support from this document (leaving only the UDP transport), but it was decided to instead keep the references, which guarantees a MISREF, and then, once those other drafts are resolved, this draft may need some final fit-and-finish so it's aligned. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns (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. No portions of the document have been flagged as needing to be reviewed from a particular or broader perspective. (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. The Document Shepherd has no specific concerns or issues with this document beyond the afore-mentioned dependency on the YANG modules within the "keystore" and "tls-client-server" drafts. (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. This verification occurred at the time of the WG Last Call. (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 has been filed. (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? Strong concurrence of a few individuals, with others being silent. (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.) No one has threatened an appeal 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. Idnits finds only two issues: == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line 1340, but no explicit reference was found in the text '[I-D.ietf-netconf-keystore] Watsen, K., "YANG Data Model for a "Keys...' This is a bug in idnits, whereby a reference that splits two lines is not found. == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-05 This is not an issue. The tree-diagrams draft is almost an RFC now and already there should an RFC Editor note requesting the I-D be replaced with the final RFC number assignment. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. This document has been reviewed by a member of the YANG Doctors group. (13) Have all references within this document been identified as either normative or informative? Yes, all references have been partitioned into these two groupings. The partitioning seems okay except: * the tree-diagrams reference is Normative, whereas it should be Informative (mentioned to the author on Jan 17). Also, missing is an RFC Editor note requesting that the I-D reference to be updated to reflect the assigned RFC number. (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? There are two normative references to works in progress: draft-ietf-netconf-keystore and draft-ietf-netconf-tls-client-server. While both these drafts are fairly mature, they will take time to complete. Given the Editor of those drafts is busy, the chairs have looked for others that would be willing to take over the Editor role. Unfortunately, there were no takers. At this time, we have assurances from the Editor that those drafts will get moved back to the "front burner" in 2-3 weeks. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (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. 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). The draft does not define any new registries. It does insert one new element into two existing registries. It does this using the standard registration technique found in many YANG model drafts. (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. This document does not define any new IANA 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. The shepherd validated both the primary and example yang modules using both the `pyang` and `yanglint` tools. The shepherd also validated the two XML examples in Section 5 of the document using the `yanglint` tool |
2018-03-26
|
26 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Ron Bonica. |
2018-03-20
|
26 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-03-20
|
26 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-03-19
|
26 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-03-16
|
26 | (System) | IANA Action state changed to In Progress |
2018-03-16
|
26 | (System) | RFC Editor state changed to MISSREF |
2018-03-16
|
26 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-03-16
|
26 | (System) | Announcement was received by RFC Editor |
2018-03-16
|
26 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2018-03-16
|
26 | Amy Vezza | IESG has approved the document |
2018-03-16
|
26 | Amy Vezza | Closed "Approve" ballot |
2018-03-16
|
26 | Amy Vezza | Ballot approval text was generated |
2018-03-16
|
26 | Amy Vezza | Ballot writeup was changed |
2018-03-16
|
26 | Cindy Morgan | New version available: draft-ietf-netmod-syslog-model-26.txt |
2018-03-16
|
26 | (System) | Secretariat manually posting. Approvals already received |
2018-03-16
|
26 | Cindy Morgan | Uploaded new revision |
2018-03-14
|
25 | Cindy Morgan | New version available: draft-ietf-netmod-syslog-model-25.txt |
2018-03-14
|
25 | (System) | Secretariat manually posting. Approvals already received |
2018-03-14
|
25 | Cindy Morgan | Uploaded new revision |
2018-03-08
|
24 | Cindy Morgan | New version available: draft-ietf-netmod-syslog-model-24.txt |
2018-03-08
|
24 | (System) | Secretariat manually posting. Approvals already received |
2018-03-08
|
24 | Cindy Morgan | Uploaded new revision |
2018-03-08
|
23 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from Waiting for Writeup |
2018-03-08
|
23 | Adam Roach | [Ballot comment] One quick comment on the model for the console: +--rw console! {console-action}? … [Ballot comment] One quick comment on the model for the console: +--rw console! {console-action}? | +--rw facility-filter | | +--rw facility-list* [facility severity] | | +--rw facility union | | +--rw severity union | | +--rw advanced-compare {select-adv-compare}? | | +--rw compare? enumeration | | +--rw action? enumeration | +--rw pattern-match? string {select-match}? Syslog can be (and frequently is) configured to log to "console" on a non-default tty. It's not clear from this model how this would be configured or indicated. Is the assumption here that all non-default-console tty logging would be handled by the "file" portion of the tree? If so, it would be worth indicating so explicitly, and noting that such an approach is limited to those systems that present ttys as a part of the filesystem. Alternately, it might make sense to add a tty field to the "console" subtree to report/configure this value. |
2018-03-08
|
23 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-03-07
|
23 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-03-07
|
23 | Eric Rescorla | [Ballot comment] https://mozphab-ietf.devsvcdev.mozaws.net/D4614 It's not a problem with this document, but I took a quick look at draft-ietf-netconf-tls-client-server and I've got some concerns. Here are … [Ballot comment] https://mozphab-ietf.devsvcdev.mozaws.net/D4614 It's not a problem with this document, but I took a quick look at draft-ietf-netconf-tls-client-server and I've got some concerns. Here are a few examples: - You can set the cipher suite but not key sizes and groups You can - say sort of incoherent things in TLS like "I support TLS 1.0 and TLS 1.2 but not TLS 1.1" (there is no way to negotiate this in TLS 1.2) I'll try to get a chance to give this a real review, but I wanted to mention it before I forgot. We are using definitions of syslog protocol from [RFC5424] in this RFC. Not a big deal, but this introduction feels like it ought to say what the document is about, not just about syslog. The severity is one of type syslog-severity, all severities, or none. None is a special case that can be used to disable a filter. When filtering severity, the default comparison is that messages of the This seems to be the first use of the term filter to mean this entity subtree, implementations MUST NOT specify a private key that is used for any other purpose. It seems like the data that syslog writes is sensitive, so the ability to write a destination reflects a high degree of risk. |
2018-03-07
|
23 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-03-07
|
23 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-03-07
|
23 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-03-06
|
23 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-03-06
|
23 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2018-03-06
|
23 | Alexey Melnikov | [Ballot comment] Thank you for this document. I agree with Kathleen that risks of disabling syslog logging in order to hide system compromise needs to … [Ballot comment] Thank you for this document. I agree with Kathleen that risks of disabling syslog logging in order to hide system compromise needs to be discussed. I also prefer for TCP to be documented, if used in real world. Some minor comments: 1) Please add a Normative Reference for the file: URI RFC (RFC 8089) when you mention it for the first time. 2) On page 19: Example: compare->equals and action->no-match means messages that have a severity that is not equal to the specified severity will be logged."; Do you mean "action->block" instead of "action->no-match"? 3) When logging to file: how is the file name constructed from the name file: URI if multiple files are preserved by the system? E.g. if the log file is rotated daily and 5 last files are preserved, how does each individual filename look? If I understood how this is used, this needs more clarification. 4) Nit: on page 18, typo in "spectify" |
2018-03-06
|
23 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2018-03-06
|
23 | Alexey Melnikov | [Ballot comment] Thank you for this document. I also prefer for TCP to be documented, if used in real world. Some minor comments: 1) Please … [Ballot comment] Thank you for this document. I also prefer for TCP to be documented, if used in real world. Some minor comments: 1) Please add a Normative Reference for the file: URI RFC (RFC 8089) when you mention it for the first time. 2) On page 19: Example: compare->equals and action->no-match means messages that have a severity that is not equal to the specified severity will be logged."; Do you mean "action->block" instead of "action->no-match"? 3) When logging to file: how is the file name constructed from the name file: URI if multiple files are preserved by the system? E.g. if the log file is rotated daily and 5 last files are preserved, how does each individual filename look? If I understood how this is used, this needs more clarification. 4) Nit: on page 18, typo in "spectify" |
2018-03-06
|
23 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-03-06
|
23 | Warren Kumari | [Ballot comment] On the specific question in the Shepherd writeup: --- Was there anything in WG process that is worth noting? For example, was … [Ballot comment] On the specific question in the Shepherd writeup: --- 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? Yes, the model initially had defined support for configuring Syslog over TPC (RFC 6587). However, after reviewing the reasoning for why RFC 6587 was made HISTORIC, as decided to remove the support. Some stated that their companies support Syslog over TCP and now they would have to augment this model with a vendor-specific extension. There may be a subtle distinction between IETF defining an insecure protocol versus defining a data model to configure, amongst other things, an insecure protocol. We believe we did the right thing, from an IETF perspective, but please double-check this. --- I *personally* would have preferred that Syslog over TCP be included, as it is something which is in use by people, and having a single standard (with notes on why you might not want to use this) is better than an augmented one -- but, if the WG discussed this, then process was followed, and my preference is in the rough... |
2018-03-06
|
23 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-03-05
|
23 | Francis Dupont | Request for Last Call review by GENART Completed: Ready. Reviewer: Francis Dupont. |
2018-03-05
|
23 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-03-05
|
23 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-03-04
|
23 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-03-02
|
23 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-03-02
|
23 | Kathleen Moriarty | [Ballot comment] I agree with the SecDir review and thanks for responding to the review. I have one additional suggestion to make sure the points … [Ballot comment] I agree with the SecDir review and thanks for responding to the review. I have one additional suggestion to make sure the points made from this review are clear to the reader. Thanks in advance! SecDir Review text & response: Security Comments * I think almost all writable data nodes here are sensitive, because a network attacker's first move is to block any logging on the host, and many of the data nodes here can be used for this purpose. [clw1] I will reword the security section to include all writeable nodes as sensitive. [KMM] Thank you, I think it would be helpful to also note the reason is this case with an extra sentence or two. Something to the effect of: Logging in particular is used to assess the state of systems and can be used to indicate a network compromise. If logging were to be disabled through malicious means, attacks may not be readily detectable. * Re: readable data nodes, I'm not sure which are sensitive, and the document should give an example or two rather than just say "some". Otherwise the security advice is not actionable. One example: "remote" sections leak information about other hosts in the network. [clw1] This text was lifted from another model. I will review the readable nodes and update. [KMM] Thanks * Write operations... can have a negative effect on network operations. - I would add "and on network security", because logs are often used to detect security breaches. [clw1] I will add this phrase. [KMM] I see this was added, thanks. Please consider the above 2 sentences. * Also add an advice, similar to the one on "pattern match", that the private key used for signing log messages MUST NOT be used for any other purpose, and that the implementation of this data node must ensure this property (I'm not sure how). The rationale: if the TLS private key is used, for example, this could result in a signing oracle for TLS and eventually a MITM attack. [clw1] I will add this advice. [KMM] Thanks for adding this advice. |
2018-03-02
|
23 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2018-03-02
|
23 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-03-01
|
23 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2018-03-01
|
23 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-23.txt |
2018-03-01
|
23 | (System) | New version approved |
2018-03-01
|
23 | (System) | Request for posting confirmation emailed to previous authors: Kiran Koushik , Clyde Wildes |
2018-03-01
|
23 | Clyde Wildes | Uploaded new revision |
2018-02-28
|
22 | Benoît Claise | Ballot has been issued |
2018-02-28
|
22 | Benoît Claise | [Ballot Position Update] New position, Yes, has been recorded for Benoit Claise |
2018-02-28
|
22 | Benoît Claise | Created "Approve" ballot |
2018-02-28
|
22 | Benoît Claise | Ballot writeup was changed |
2018-02-28
|
22 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-02-22
|
22 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2018-02-22
|
22 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-netmod-syslog-model-20. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-netmod-syslog-model-20. If any part of this review is inaccurate, please let us know. We understand that upon approval of this document, we need to complete two registry actions. First, the following entry should be added to the IETF XML ns registry at https://www.iana.org/assignments/xml-registry: ID: yang:ietf-syslog URI: urn:ietf:params:xml:ns:yang:ietf-syslog Template: [as provided in document] Reference: [this document] This request has been reviewed and approved by the IESG-designated registry expert. Second, the following entry should be added to the YANG Module Names registry at https://www.iana.org/assignments/yang-parameters: Name: ietf-syslog Maintained by IANA?: N Namespace: urn:ietf:params:xml:ns:yang:ietf-syslog Prefix: ietf-syslog Reference: [This document] Note: Our understanding is that while the module file will be posted in the registry after the RFC is published, the module will not be maintained by IANA. If this is incorrect, and IANA will be maintaining the module, please let us know as soon as possible. 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, Amanda Baber IANA Services Specialist |
2018-02-21
|
22 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-22.txt |
2018-02-21
|
22 | (System) | New version approved |
2018-02-21
|
22 | (System) | Request for posting confirmation emailed to previous authors: Kiran Koushik , Clyde Wildes |
2018-02-21
|
22 | Clyde Wildes | Uploaded new revision |
2018-02-18
|
21 | Yaron Sheffer | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Yaron Sheffer. Sent review to list. |
2018-02-16
|
21 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Ron Bonica |
2018-02-16
|
21 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Ron Bonica |
2018-02-16
|
21 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2018-02-16
|
21 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2018-02-15
|
21 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2018-02-15
|
21 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2018-02-14
|
21 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-21.txt |
2018-02-14
|
21 | (System) | New version approved |
2018-02-14
|
21 | (System) | Request for posting confirmation emailed to previous authors: Kiran Koushik , Clyde Wildes |
2018-02-14
|
21 | Clyde Wildes | Uploaded new revision |
2018-02-14
|
20 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-02-14
|
20 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-02-28): From: The IESG To: IETF-Announce CC: netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org, Kent Watsen , … The following Last Call announcement was sent out (ends 2018-02-28): From: The IESG To: IETF-Announce CC: netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org, Kent Watsen , draft-ietf-netmod-syslog-model@ietf.org, Lou Berger , bclaise@cisco.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (A YANG Data Model for Syslog Configuration) to Proposed Standard The IESG has received a request from the Network Modeling WG (netmod) to consider the following document: - 'A YANG Data Model for Syslog Configuration' 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 2018-02-28. 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 for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "I-D.ietf-netconf-keystore" --> the assigned RFC value for draft- ietf-netconf-keystore o "I-D.ietf-netconf-tls-client-server" --> the assigned RFC value for draft-ietf-netconf-tls-client-server o "zzzz" --> the assigned RFC value for this draft The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-netconf-tls-client-server: YANG Groupings for TLS Clients and TLS Servers (None - IETF stream) draft-ietf-netconf-keystore: YANG Data Model for a "Keystore" Mechanism (None - IETF stream) |
2018-02-14
|
20 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-02-14
|
20 | Benoît Claise | Placed on agenda for telechat - 2018-03-08 |
2018-02-14
|
20 | Benoît Claise | Last call was requested |
2018-02-14
|
20 | Benoît Claise | Last call announcement was generated |
2018-02-14
|
20 | Benoît Claise | Ballot approval text was generated |
2018-02-14
|
20 | Benoît Claise | Ballot writeup was generated |
2018-02-14
|
20 | Benoît Claise | IESG state changed to Last Call Requested from AD Evaluation |
2018-02-13
|
20 | Benoît Claise | IESG state changed to AD Evaluation from Publication Requested |
2018-02-12
|
20 | 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? A Proposed Standard is being requested. A proposed standard is needed to ensure interoperability. The title page header indicates that it is a Standards Track document. (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. This document defines a YANG data model for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. 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? Yes, the model initially had defined support for configuring Syslog over TPC (RFC 6587). However, after reviewing the reasoning for why RFC 6587 was made HISTORIC, as decided to remove the support. Some stated that their companies support Syslog over TCP and now they would have to augment this model with a vendor-specific extension. There may be a subtle distinction between IETF defining an insecure protocol versus defining a data model to configure, amongst other things, an insecure protocol. We believe we did the right thing, from an IETF perspective, but please double-check this. 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? This draft defines a data model (not a protocol). So far, two vendors have indicated that they're interested in implementing this data model. There was a YANG Doctor review on the -17 that was successful: https://datatracker.ietf.org/doc/review-ietf-netmod-syslog-model-17-yangdoctors-lc-watsen-2017-09-12/ Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The Shepherd is Kent Watsen. The AD is Benoit Claise. (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 Document Shepherd went through the checklist posted here: http://trac.tools.ietf.org/group/iesg/trac/wiki/DraftShepherdWriteupWgAlternate One noteworthy point here. Regarding the checklist item "Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?", it is worth noting that this draft references both draft-ietf-netconf-keystore and draft-ietf-netconf-tls-client-server. While these two drafts are both fairly mature, they are not in a clear state. For example, the most recent update to the keystore module removed the storage of keys from it, and thus now the working group is ascertaining if the module should be renamed, which would have a ripple-effect on this draft. One idea was to remove the TLS-support from this document (leaving only the UDP transport), but it was decided to instead keep the references, which guarantees a MISREF, and then, once those other drafts are resolved, this draft may need some final fit-and-finish so it's aligned. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns (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. No portions of the document have been flagged as needing to be reviewed from a particular or broader perspective. (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. The Document Shepherd has no specific concerns or issues with this document beyond the afore-mentioned dependency on the YANG modules within the "keystore" and "tls-client-server" drafts. (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. This verification occurred at the time of the WG Last Call. (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 has been filed. (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? Strong concurrence of a few individuals, with others being silent. (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.) No one has threatened an appeal 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. Idnits finds only two issues: == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line 1340, but no explicit reference was found in the text '[I-D.ietf-netconf-keystore] Watsen, K., "YANG Data Model for a "Keys...' This is a bug in idnits, whereby a reference that splits two lines is not found. == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-05 This is not an issue. The tree-diagrams draft is almost an RFC now and already there should an RFC Editor note requesting the I-D be replaced with the final RFC number assignment. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. This document has been reviewed by a member of the YANG Doctors group. (13) Have all references within this document been identified as either normative or informative? Yes, all references have been partitioned into these two groupings. The partitioning seems okay except: * the tree-diagrams reference is Normative, whereas it should be Informative (mentioned to the author on Jan 17). Also, missing is an RFC Editor note requesting that the I-D reference to be updated to reflect the assigned RFC number. (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? There are two normative references to works in progress: draft-ietf-netconf-keystore and draft-ietf-netconf-tls-client-server. While both these drafts are fairly mature, they will take time to complete. Given the Editor of those drafts is busy, the chairs have looked for others that would be willing to take over the Editor role. Unfortunately, there were no takers. At this time, we have assurances from the Editor that those drafts will get moved back to the "front burner" in 2-3 weeks. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (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. 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). The draft does not define any new registries. It does insert one new element into two existing registries. It does this using the standard registration technique found in many YANG model drafts. (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. This document does not define any new IANA 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. The shepherd validated both the primary and example yang modules using both the `pyang` and `yanglint` tools. The shepherd also validated the two XML examples in Section 5 of the document using the `yanglint` tool |
2018-02-12
|
20 | Kent Watsen | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-02-12
|
20 | Kent Watsen | IESG state changed to Publication Requested |
2018-02-12
|
20 | Kent Watsen | IESG process started in state Publication Requested |
2018-02-12
|
20 | Kent Watsen | Tag Doc Shepherd Follow-up Underway cleared. |
2018-02-12
|
20 | Kent Watsen | Changed document writeup |
2018-02-09
|
20 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-20.txt |
2018-02-09
|
20 | (System) | New version approved |
2018-02-09
|
20 | (System) | Request for posting confirmation emailed to previous authors: Kiran Koushik , Clyde Wildes |
2018-02-09
|
20 | Clyde Wildes | Uploaded new revision |
2018-01-12
|
19 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-19.txt |
2018-01-12
|
19 | (System) | New version approved |
2018-01-12
|
19 | (System) | Request for posting confirmation emailed to previous authors: Kiran Koushik , Clyde Wildes |
2018-01-12
|
19 | Clyde Wildes | Uploaded new revision |
2017-12-12
|
18 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-18.txt |
2017-12-12
|
18 | (System) | New version approved |
2017-12-12
|
18 | (System) | Request for posting confirmation emailed to previous authors: Kiran Koushik , Clyde Wildes |
2017-12-12
|
18 | Clyde Wildes | Uploaded new revision |
2017-09-12
|
17 | Kent Watsen | Tag Doc Shepherd Follow-up Underway set. |
2017-09-12
|
17 | Kent Watsen | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2017-09-12
|
17 | Kent Watsen | Intended Status changed to Proposed Standard from None |
2017-09-12
|
17 | Kent Watsen | Request for Last Call review by YANGDOCTORS Completed: Ready with Issues. Reviewer: Kent Watsen. Sent review to list. |
2017-09-12
|
17 | Benoît Claise | Changed consensus to Yes from Unknown |
2017-09-08
|
17 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-17.txt |
2017-09-08
|
17 | (System) | New version approved |
2017-09-08
|
17 | (System) | Request for posting confirmation emailed to previous authors: Kiran Koushik , Clyde Wildes |
2017-09-08
|
17 | Clyde Wildes | Uploaded new revision |
2017-08-11
|
16 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-16.txt |
2017-08-11
|
16 | (System) | New version approved |
2017-08-11
|
16 | (System) | Request for posting confirmation emailed to previous authors: Kiran Koushik , Clyde Wildes |
2017-08-11
|
16 | Clyde Wildes | Uploaded new revision |
2017-06-07
|
15 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-15.txt |
2017-06-07
|
15 | (System) | New version approved |
2017-06-07
|
15 | (System) | Request for posting confirmation emailed to previous authors: Kiran Koushik , Clyde Wildes |
2017-06-07
|
15 | Clyde Wildes | Uploaded new revision |
2017-03-27
|
14 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-14.txt |
2017-03-27
|
14 | (System) | New version approved |
2017-03-27
|
14 | (System) | Request for posting confirmation emailed to previous authors: Kiran Koushik , Clyde Wildes |
2017-03-27
|
14 | Clyde Wildes | Uploaded new revision |
2017-03-23
|
13 | Zitao Wang | Added to session: IETF-98: netmod Tue-0900 |
2017-03-13
|
13 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-13.txt |
2017-03-13
|
13 | (System) | New version approved |
2017-03-13
|
13 | (System) | Request for posting confirmation emailed to previous authors: netmod-chairs@ietf.org, Clyde Wildes , Kiran Koushik |
2017-03-13
|
13 | Clyde Wildes | Uploaded new revision |
2017-02-18
|
12 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Kent Watsen |
2017-02-18
|
12 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Kent Watsen |
2017-02-18
|
12 | Mehmet Ersue | Requested Last Call review by YANGDOCTORS |
2017-02-14
|
12 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-12.txt |
2017-02-14
|
12 | (System) | New version approved |
2017-02-14
|
12 | (System) | Request for posting confirmation emailed to previous authors: "Clyde Wildes" , "Kiran Koushik" |
2017-02-14
|
12 | Clyde Wildes | Uploaded new revision |
2016-11-13
|
11 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-11.txt |
2016-11-13
|
11 | (System) | New version approved |
2016-11-13
|
11 | (System) | Request for posting confirmation emailed to previous authors: "Clyde Wildes" , "Kiran Koushik" |
2016-11-13
|
11 | Clyde Wildes | Uploaded new revision |
2016-10-31
|
10 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-10.txt |
2016-10-31
|
10 | (System) | New version approved |
2016-10-31
|
09 | (System) | Request for posting confirmation emailed to previous authors: "Clyde Wildes" , "Kiran Koushik" |
2016-10-31
|
09 | Clyde Wildes | Uploaded new revision |
2016-07-08
|
09 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-09.txt |
2016-06-27
|
08 | Lou Berger | Notification list changed to "Lou Berger" <lberger@labn.net>, "Kent Watsen" <kwatsen@juniper.net> from "Lou Berger" <lberger@labn.net> |
2016-06-27
|
08 | Lou Berger | Document shepherd changed to Kent Watsen |
2016-05-10
|
08 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-08.txt |
2016-03-20
|
07 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-07.txt |
2016-02-29
|
06 | Lou Berger | IPR responses received: https://www.ietf.org/mail-archive/web/netmod/current/msg15400.html https://www.ietf.org/mail-archive/web/netmod/current/msg15401.html |
2016-02-22
|
06 | Benoît Claise | Shepherding AD changed to Benoit Claise |
2016-02-22
|
06 | Lou Berger | IP poll opened https://www.ietf.org/mail-archive/web/netmod/current/msg15310.html |
2016-02-22
|
06 | Lou Berger | Notification list changed to "Lou Berger" <lberger@labn.net> |
2016-02-22
|
06 | Lou Berger | Document shepherd changed to Lou Berger |
2015-12-22
|
06 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-06.txt |
2015-10-16
|
05 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-05.txt |
2015-10-14
|
04 | (System) | Notify list changed from "Thomas Nadeau" , "Thomas Nadeau" to (None) |
2015-07-06
|
04 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-04.txt |
2015-05-22
|
03 | Jürgen Schönwälder | Notification list changed to "Thomas Nadeau" <tnadeau@juniper.net>, "Thomas Nadeau" <tnadeau@lucidvision.com> from "Thomas Nadeau" <tnadeau@juniper.net> |
2015-05-22
|
03 | Jürgen Schönwälder | Document shepherd changed to Thomas Nadeau |
2015-05-22
|
03 | Jürgen Schönwälder | Notification list changed to "Thomas Nadeau" <tnadeau@juniper.net> |
2015-05-22
|
03 | Jürgen Schönwälder | Document shepherd changed to Thomas Nadeau |
2015-03-09
|
03 | Kiran Sreenivasa | New version available: draft-ietf-netmod-syslog-model-03.txt |
2015-03-06
|
02 | Kiran Sreenivasa | New version available: draft-ietf-netmod-syslog-model-02.txt |
2015-02-24
|
01 | Kiran Sreenivasa | New version available: draft-ietf-netmod-syslog-model-01.txt |
2015-02-06
|
00 | Thomas Nadeau | draft-wildes-netmod-syslog-model-02 |
2015-02-06
|
00 | Thomas Nadeau | This document now replaces draft-wildes-netmod-syslog-model instead of None |
2014-11-10
|
00 | Clyde Wildes | New version available: draft-ietf-netmod-syslog-model-00.txt |