A YANG Data Model for Syslog Configuration
draft-ietf-netmod-syslog-model-32

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.

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

[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

[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.

[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.

[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"

[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"

[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...

[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.

(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

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)

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