Hi Sam,
We are submitting a shepherding document for advancemnet of
syslog-sign to PS.
We are submitting a shepherding document for advancement of
syslog-tc-mib to PS.
David Harrington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
shepherding submission for syslog-sign
Having passed a WG Last Call, and been updated to meet the comments
from the WGLC, draft-ietf-syslog-sign-23.txt is ready for AD review.
[Area] SECURITY
[AD] Sam Hartman
[WG] syslog
[I-D] draft-ietf-syslog-sign-23.txt
[Qver] draft-ietf-proto-wgchair-doc-shepherding-07.txt
[Shep] David Harrington <[EMAIL PROTECTED]>
The WG last call turned up no major comments or discussion.
1.a) Have the chairs personally reviewed this version of
the Internet Draft (ID), and in particular, do they believe this
ID is ready to forward to the IESG for publication?
Yes.
1.b) Has the document had adequate review from both key WG
members and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?
Adequate review has occurred from WG members, and it has been
reviewed by others. I am satisfied about the level of review.
1.c) Do you have concerns that the document needs more
review from a particular (broader) perspective (e.g., security,
operational complexity, someone familiar with AAA, etc.)?
No.
1.d) Do you have any specific concerns/issues with this
document that you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for it.
In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.
No.
1.e) 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?
There is strong consensus to publish this document.
1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director.
No.
1.g) Have the chairs verified that the document adheres
to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Yes.
1.h) Is the document split into normative and informative
references? Are there normative references to IDs, where the IDs are
not also ready for advancement or are otherwise in an unclear state?
(note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until all
such IDs are also ready for publication as RFCs.)
The references are split into normative and informational
references.
The document has normative dependencies on draft-ietf-syslog-protocol-23.txt
and draft-ietf-syslog-transport-udp-12.txt, which have been approved, and on
draft-ietf-syslog-transport-tls-10.txt which has not yet been approved.
1.ijk) Write-up section:
* Technical Summary
This document describes a mechanism to add origin authentication,
message integrity, replay resistance, message sequencing, and
detection of missing messages to the transmitted syslog messages.
This specification is intended to be used in conjunction with the
work defined in RFC xxxx, "The syslog Protocol".
* Working Group Summary
The consensus of the working group was to publish this as a
standards-track document.
* Protocol Quality
It is possible that there are implementations of this document in
various stages of completion at this time. Some equipment
vendors have indicated interest in supporting this document, and some
non-commercial implementations are also expected.
shepherding submission for syslog-tc-mib
draft-ietf-syslog-tc-mib-04.txt is ready for AD review.
[Area] SECURITY
[AD] Sam Hartman
[WG] syslog
[I-D] draft-ietf-syslog-tc-mib-04.txt
[Qver] draft-ietf-proto-wgchair-doc-shepherding-07.txt
[Shep] David Harrington <[EMAIL PROTECTED]>
1.a) Have the chairs personally reviewed this version of
the Internet Draft (ID), and in particular, do they believe this
ID is ready to forward to the IESG for publication?
Yes.
1.b) Has the document had adequate review from both key WG
members and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?
Adequate review has occurred from WG members, and it has been
reviewed by others. I am satisfied about the level of review.
It passes IDnits.
The document meets the guidelines of RFC4181 for MIB documents.
It passes libsmi MIB validation.
The security considerations is appropriate to documents containing only TCs.
1.c) Do you have concerns that the document needs more
review from a particular (broader) perspective (e.g., security,
operational complexity, someone familiar with AAA, etc.)?
No. Dan Romascanu has agreed to perform a MIB Doctor review.
1.d) Do you have any specific concerns/issues with this
document that you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for it.
In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.
No.
The ADs should be aware that syslog is a defacto standard widely used in the
industry, and supported by standard POSIX APIs. The syslog WG discussed whether
to standardize the use of the labels in the facilities TC. WG consensus is that
the labels are normative, but irrelevant.
The chairs are comfortable with this decision.
The following text is included in the document, with references, and the MIB
module itself, without references, to explain what this means.
" For interoperability and backwards compatibility reasons, the mapping
specified in this document between a label which represents a
Facility or a Severity, and the value which represents the
corresponding code, is normative. So the mapping from a label
configured by operators in syslog.conf or equivalent will
consistently map to the same Facility code regardless of
implementation, but the label itself is often semantically
meaningless, because it is impractical to attempt to enumerate all
possible facilities, and the mapping (label and corresponding value)
that is used for an actual facility is, and has historically been,
implementation-dependent.
For example, the foobar application might log messages as having come
from local7, even though there is no "local" process on the device,
and the operator can configure syslog.conf to have local7.critical
messages be relayed, even though there might be multiple facilities
using Facility local7. This is typical current practice, and
originators, relays and collectors know how to handle this situation.
For improved accuracy, the foobar application can also include an
APPNAME Structured Data Element [RFCPROT]."
1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?
The WG cares little about having MIB support. There is strong consensus to
publish this document from those WG members who want MIB support, from the MIB
Doctors, and from other WGs who are developing syslog-related MIB modules, so
there will be consistency in the definition of MIB objects representing
Facility and Severity.
1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director.
No.
1.g) Have the chairs verified that the document adheres
to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Yes.
1.h) Is the document split into normative and informative
references? Are there normative references to IDs, where the IDs are
not also ready for advancement or are otherwise in an unclear state?
(note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until all
such IDs are also ready for publication as RFCs.)
Yes, it is split.
draft-ietf-syslog-protocol has already been approved for advancement.
1.ijk) Write-up section:
* Technical Summary
This document contains a MIB module that defines textual conventions to
represent facility and severity information commonly used in syslog messages.
The intent is that these textual conventions will be imported and used in MIB
modules that would otherwise define their own representations.
* Working Group Summary
The consensus of the working group was to publish this as a
standards-track document.
* Protocol Quality
These textual conventions standardize MIB representation of facility and
severity, concepts which are widely used in existing implementations of syslog.
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
