Hi,
Here is the preliminary shperherding document for -sign-
It is complete through revision -19-, and -20- should become available
this week so I can finalize.
Comments welcome.
David Harrington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Shepherding document for syslog-sign
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?
David Harrington <[EMAIL PROTECTED]>
I believe that this version is ready for publication.
(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?
The document has been reviewed by the Working Group and by people outside
of the Working Group. There are no concerns about the reviews. The
recent reviews may be found in the mailing list archive:
http://www1.ietf.org/mail-archive/web/syslog/current/msg01209.html
http://www1.ietf.org/mail-archive/web/syslog/current/msg01190.html
http://www1.ietf.org/mail-archive/web/syslog/current/msg01227.html
(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML
No.
(1.d) Does the Document Shepherd have any specific concerns or
issues 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 those issues have been discussed in the WG and the
WG has indicated that it still wishes to advance the document,
detail those concerns here.
There are no specific concerns.
(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 Working Group as a whole understands the document and supports it
moving forward.
(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire will
be entered into the ID Tracker.)
No appeals have been threatened.
(1.g) Has the Document Shepherd verified that the document satisfies
all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough.
[todo] Yes. The document was generated using xml2rfc, has passed automated
checking using idnits 1.118 , and passed a manual check of idnits by the
shepherd.
(1.h) Has the document split its references into normative and
informative? 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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].
The references are split and all referenced documents are RFCs in good
standing.
This document has informative dependencies upon other draft-ietf-syslog-*
internet drafts. These documents are being submitted together.
(1.i) 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 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 draws upon the work defined in RFC xxxx, "The
syslog Protocol", however it may be used atop any message delivery
mechanism, even that defined in RFC 3164, "The BSD syslog Protocol",
or in the RAW mode of "RFC 3195, "The Reliable Delivery of syslog".
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?
This document has been ready for a very long time. The holdup has been
that the Working Group decided to revise draft-ietf-syslog-protocol. This
action has been completed.
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?
There are a number of implementations of syslog-sign available for different
operating systems.
===
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
