Chris, I mostly agree (but keep my posting on -04 in mind). Some issue below...
Rainer > -----Original Message----- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 22, 2006 3:03 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] Draft Shepherding document > fordraft-ietf-syslog-transport-tls-04.txt > > Hi, > > Below is the first draft for the shepherding document for > draft-ietf-syslog-transport-tls-04.txt. Please review and > send feedback > to the list. > > All of this is pending final reviews of the latest document submitted. > > === > Having passed a WG Last Call, > draft-ietf-syslog-transport-tls-04.txt is > ready for AD review. > > [Area] SECURITY > [WG] syslog > [I-D] draft-ietf-syslog-transport-tls-04.txt > [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt > [Shep] Chris Lonvick <[EMAIL PROTECTED]> > > === > (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? > Chris Lonvick <[EMAIL PROTECTED]> > Yes; I believe that the document 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? > > Adequate review has occurred from WG members, and it has been reviewed > by others. The reviews of the WG Last Call for this document (-03 > version) may be found here: > > Bert Wijnen's review (not a member of the WG mailing list) > http://www1.ietf.org/mail-archive/web/syslog/current/msg01244.html > > John Calcote's review > http://www1.ietf.org/mail-archive/web/syslog/current/msg01199.html > > Other reviews of particular sections and concepts fill the WG mailing > list. Of note is Eric Rescorla's review (of -02) > http://www1.ietf.org/mail-archive/web/syslog/current/msg01100.html > > The issues raised in these reviews have been discussed on the mailing > list and I am satisfied about the level of review. > === > (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? > > I have no concerns. > === > (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 the WG has discussed those issues and > has indicated > that it still wishes to advance the document, detail those > concerns here. > > There are no concerns about the technical merit of the document. > === > (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 messages to the Responsible Area > Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) > > No appeals have been threatened. > === > (1.g) Has the Document Shepherd personally 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. Has > the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? > > XXX - Let's see what --04 looks like - XXX > === > (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 into normative and informational references. > The document is dependant upon draft-ietf-syslog-transport-udp-08.txt > and draft-ietf-syslog-protocol-18.txt which are being submitted > along with this document. It is not dependent on draft-ietf-syslog-transport-udp-08.txt. I suggest you remove that dependency. -protocol is dependent on both tranports, but the transport so far only depend on -protocol. > === > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent > with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly > identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggested a > reasonable name for the new registry? See > [I-D.narten-iana-considerations-rfc2434bis]. If > the document > describes an Expert Review process has Shepherd > conferred with > the Responsible Area Director so that the IESG can > appoint the > needed Expert during the IESG Evaluation? > > The document IANA section is complete and the requested registries are > clearly marked. The registry name as required by I-D.narten-iana-considerations-rfc2434bis is not yet present. > === > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate > correctly in > an automated checker? > > The ABNF in the document has been verified through > http://www.apps.ietf.org/abnf.html > === > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Writeup? 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 the use of Transport Layer > Security (TLS) to > provide a secure connection for the transport of syslog messages. > This document describes the security threats to Syslog and how TLS > can be used to counter such threats. > > 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? > > There was controversy around the IPR statement from Huawei from this > document. The Working Group examined the issue and came to > consensus that > the statement would be accepted. > > There was controversy around the use of a version number within the > payload. Since this implementation is close to the > fire&forget model of > traditional syslog/udp, no signalling of errors from the > receiver will > occur. There was a concern on the mailing list that if the method of > inserting the payload into the transport were to change in > the future, the > recipient may not be able to parse the information. Hence > the WG decided > upon a version number at the start of the payload. The WG > consensus at > this time is to have a version number as a field in the payload. I did have the impression that removal of the version number was consensus. Today, I learnt we didn't actaully discuss this. I can life with and without version number. I'd happily accept a chair decision. However, if we stick with the version number, I think we must look into the mechanism on what to do when the receiver does not accept it (see my review from earlier today). > > There was some controversy around the use of a special > character to denote > the end of the payload, or a counter at the start of the payload to > indicate the length of the payload. The Working Group has > consent that a > counter is the best mechanism. > > > 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 protocol has very similar characteristics to implementations of > syslog over ssl that are available at this time. The author of that > implementation has indicated that he will make changes to > conform to this > specification. I am not sure if we can really say this. True, both use syslog over ssl and the overall idea is exactly the same. The details, however, differ greatly. Currently existing syslog/ssl uses octet-stuffing for framing (LF inserted as end of record marker) while -transport-tls utilizes octet-counting. While this is a small difference in design, it will make existing implementations and -transport-tls implementations non-interoperable. On the other hand, it should be extremely easy to adopt existing code to the new way of doing things (even concurrently to existing practice). Maybe this is worth noting. > No vendors have announced that they will utilize this protocol. Some > vendors have indicated interest in supporting this document. > The above named reviewers did an outstanding and thorough job. > > > Personnel > Who is the Document Shepherd for this document? > Who is the > Responsible Area Director? > [Area] SECURITY > [WG] syslog > [I-D] draft-ietf-syslog-transport-tls-04v.txt > [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt > [Shep] Chris Lonvick <[EMAIL PROTECTED]> > [AD] Sam Hartman <[EMAIL PROTECTED]> > === > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
