[Syslog] survey
Hi, The survey was summarized at IETF 60 in the following presentation: http://www3.ietf.org/proceedings/04aug/slides/isms-1.pdf Dave Harrington [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] FW: Real Notification Requirements for Netconf
Hi, There is a discussion about netconf notification messages going on in the netconf WG. Part of the discussion is about carrying syslog content in netconf notifications. It might be useful to have some syslog experts monitor and contribute to the discussion. David Harrington [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juergen Schoenwaelder Sent: Tuesday, March 28, 2006 9:18 AM To: Shane Kerr Cc: Andy Bierman; Netconf (E-mail) Subject: Re: Real Notification Requirements On Tue, Mar 28, 2006 at 05:02:25PM +0200, Shane Kerr wrote: > Perhaps it would be better to focus on adding a subscription mechanism > to SYSLOG? Certainly an option. Having a subcription mechanism is actually for me an important feature. Some 12 years ago, we hacked our central syslog daemon to actually ship syslog messages once you connected to it and it was a lovely hack which we used a lot (since it makes access to syslog message real simply for programs). On the classification question: I think you can put anything into syslog, so the distinction between syslog messages, configuration change notifications, or SNMP notifications is kind of artificial. In fact, it seems popular in many operational environments to have SNMP notification receivers which simply write to syslog, probably because there are also pretty nice syslog readers that can trigger all sorts of actions when they discover certain input patterns. If we do an interim, it would be valuable to get some syslog experts there as well so that we can evaluate whether structured syslog and syslog enhancements will actually solve the problem. /js -- Juergen Schoenwaelder International University Bremen <http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/> ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] RE: draft-ietf-syslog-sign-18.txt
sed Reference: [3] is defined on line 1110, but not referenced ' [3] American National Standards Institute, "USA Code for' 6) The contact information in the "authors and working group chair" section recognizes only Chris since he was chair during the work on that document. I should probably be added in case the rfc-ditor needs to contact me, such as for AUTH48. My contact information is David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] Huawei Technologies (USA) 1700 Alma Drive, Suite 100 Plano, TX 75075 +1-603-436-8634 7) The authors' address information should be filled in more throughly to improve the rfc-editor's chance of finding all of us for AUTH48, and to imporve chances of readers with questions being able to reach us. Does J.Kelsey have an affiliation? If so, it should be reflected on the first page. 8) Please add the following to the top of the "authors and working group chair" section. "Comments are solicited and should be addressed to the working group's mailing list and/or the author(s)." Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: Alexander Clemm (alex) [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 25, 2006 8:55 PM > To: David Harrington > Subject: FW: draft-ietf-syslog-sign-18.txt > > > Hello David, > > sorry, I forgot to courtesy copy you but just realized my mistake. > > Best regards > --- Alex > > -Original Message- > From: Alexander Clemm (alex) > Sent: Thursday, May 25, 2006 5:48 PM > To: [EMAIL PROTECTED] > Cc: Chris Lonvick (clonvick); Jon Callas; Alexander Clemm (alex) > Subject: RE: draft-ietf-syslog-sign-18.txt > > Hello, > > please find enclosed the submission draft-ietf-syslog-sign-18.txt > (Signed syslog Messages), of the syslog Working Group, to > replace draft > 17. > > I am also enclosing the XML file that was used to generate > the .txt file > using the tool provided on http://xml.resource.org/. > > Please let me know if there are any questions. > > Thank you, and kind regards > --- Alexander Clemm > > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt
Hi, Three things: 1) Whether the patent would survive a check into prior art is not something the IETF takes a position on: Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at [EMAIL PROTECTED] 2) The company has filed a disclosure. You should read the disclosure before losing your cool. The disclosure says (roughly) it will license the technology royalty-free for standards use. The disclosure can be found at https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=717. 3) Since I work for the company filing the disclosure, I will recuse myself from chairing this discussion. I have asked Chris to chair the discussion. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt
Hi,
I am staying out of the debate, but I can answer Balzs's question
based on my experiences.
In the US patent system, it takes on the order of three to five years
for a patent to be granted.
I believe the applicant is permitted to not disclose the claims for
eighteen months.
But I am not a lawyer, so your mileage may vary.
dbh
> -Original Message-
> From: Balazs Scheidler [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 08, 2006 8:39 AM
> To: Rainer Gerhards
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt
>
> On Thu, 2006-06-08 at 09:38 +0200, Rainer Gerhards wrote:
> > Hi all,
> >
> > I agree with Anton on all important issues. I've read the
> IPR claim and
> > what disturbs me the most is "unpublished pending patent
> application".
> > This sounds like someone took what we have been discussing (and is
> > widely deployed), brought it to a lawyer and is now trying
> to make some
> > patent out of it. This smells very bad.
> >
> > Without knowing what exactly is claimed to be invented by
> the claimer, I
> > can not judge the effect it will have on my work. Anyhow, I do not
> > intend to invest any of my time into something that
> somebody else claims
> > exclusive rights too. If I did, I'd end up with the need to "pay"
> > (money-wise or other) for the right to use my own work.
> Would I be smart
> > if I did that? ;)
> >
> > The licensing terms themselves sound fair (but are vague
> enough to do
> > so...). My root concern is that there is nothing that has
> been invented
> > by that party. I am still waiting for someone to patent the
> use of the
> > letter "a" ("@" has been tried AFIK)...
> >
> > I think using a patented technology inside a standard will
> definitely
> > hinder the acceptance of that standard. Especially if it is
> something as
> > trivial as syslog over tls. So my vote is to put this work
> on hold until
> > further clarification can be obtained. If that means we'll have no
> > syslog RFC, so be it. That would probably be the better choice...
>
> My feelings are about the same. I don't really know the US
> patent system
> specifics, how long does it take to have something concrete about
the
> patent?
>
> --
> Bazsi
>
>
> ___
> 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
RE: [Syslog] IESG secure transport requirement can be quicklysolved...
Hi, As a co-chair looking for a way forward, I was considering asking for volunteers to write a syslog-over-SSH draft as the likely alternative to TLS as a security solution. I welcome the discussion of a 3195bis alternative rorposal as a way to move forward. Thanks Rainer. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 20, 2006 10:05 AM > To: Rainer Gerhards > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] IESG secure transport requirement can > be quicklysolved... > > Hi Everyone, > > > On Tue, 20 Jun 2006, Rainer Gerhards wrote: > > > > I would appreciate if the chairs could try to reach consensus on my > > proposal. > > > > Comments are appreciated. > > Thanks, > > Rainer > > I'll apologize up front for not paricipating in some recent > dicussions. > I'm on a business trip and rather busy with the day job right now. > > I am willing to listen to a discussion of this proposal. As > Rainer says, > please provide some input and comments. > > 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
[Syslog] stream transport
Hi, [Posting as a contributor] Let me tell you that in ISMS we have written an equivalent abstraction layer. ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-isms-tmsm -02.txt discusses how to handle generic session-based security rather than datagram-based security, transport connection reuse, and other issues that came up because we now use a streaming protocol. Then we wrote a protocol-specific proposal in ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-isms-secs hell-03.txt. This separation into an abstract and protocol-specific layers has been a large task, partly because it is difficult to eliminate unnecessary repetition between documents, it is difficult to keep the two documents in sync on terminology, and so on (and I'm the author for both drafts). Having also authored RFC3411 which defines an abstracted modular architecture for SNMP frameworks, I can also tell you that going in that direction can end up constraining future development a great deal. The SMIng WG and the EOS WG suffered a great deal from having to try to remain compatible with the RFC3411 abstractions. I am a believer in specifying architectures or frameworks to guide modular development, but they also need to be taken with a grain of salt. That is much easier to do in a product development environment than it is in a standards development environment, so caveat emptor (and whatever latin phrase suits this best). I worked for years at Cabletron helping to develop internal standards for software OS-portability. There was a wonderful quote from somebody who led the industry effort to standardize some portion of X-Windows or Xmake. I don't remember the quote, the technology, or who said it, but I remember the gist of it - Do not try to abstract the concepts from one instance or implementation of a technology; there should always be at least two to draw from, and preferably more. I think that trying to develop an abstraction layer at this point would be a distraction. I think that this WG has a history of being easily distracted. As a contributor, I think we should not deal with an abstraction layer at this time. If the goal is to make it easy to develop an alternative proposal to TLS, I suggest that using cut-and-paste techniques to take text from the current syslog/tls draft (for the threat model discussions) and the current netconf/ssh draft (for layering over ssh) would be far more efficient than starting a new document and abstracting the concepts. My $.02 as a contributor, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 20, 2006 6:48 AM > To: Miao Fuyou; Tom Petch > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] stream > transportwasdraft-ietf-syslog-transport-tls-01.txt > > Miao, > > the idea of describing syslog over tcp is not to use this as an actual > transport, but to provide this as an interim for other stream > transport, > e.g. for use by ssh. The more I think about it, the more logical it > sounds to define how syslog framing works over a stream (not > necessarily > tcp). Then, other transports can build on this. As a software > engineer, > this is also like I would use layers in my application. So it sounds > quite natural and extensibel. > > A current practical good reason for this is the patent claim. An > interim-layer enables us to drop TLS with relative ease if we > decide to > do so. > > I've begun to put together some thoughts on stream framing. > > Rainer > > > -Original Message- > > From: Miao Fuyou [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 20, 2006 4:23 AM > > To: 'Tom Petch' > > Cc: [EMAIL PROTECTED] > > Subject: RE: [Syslog] stream > > transportwasdraft-ietf-syslog-transport-tls-01.txt > > > > > Yes, maybe it is favorable to have Syslog over TCP and Syslog > > over DTLS for > > Syslog working group. But, there will be several transport > > documents for the > > working group: > > 1, Syslog over UDP, already there and favorable for implementers > > 2, Syslog over TCP, what is the benefit? > > 3, Syslog over TLS > > 4, Syslog over DTLS, I reckon implementer would like it, > but does IESG > > satisfy to this transport? > > With so many transport, implementer will be puzzled. Which is > > recommended by > > the working group? The current ones are option 1 and 3. > > > > > > > -Original Message- > > > From: Tom Petch [mailto:[EMAIL PROTECTED] > > > Sent: Friday, June 16, 2006 4:13 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [Syslog] stream transport > > > wasdraft-ietf-syslog-transport-t
RE: [Syslog] IESG secure transport requirement can be quicklysolved...
Hi, [speaking as co-chair] I also am willing to listen to discussion of alternative proposals. As mentioned in my contributor posting, I can see a number of alternatives to syslog/TLS that I think might be viable. It is important that we make progress and not just discuss the alternatives, ad infinitum, however. We need volunteers who are willing to put in the work to write viable internet-drafts and drive them to completion, or the discussions are largely useless. So, I will make these requests to help focus the discussions: 1) please indicate which secure transports you consider to be feasible, 2) please indicate which secure transports address which syslog threats (they're listed in syslog/tls), 3) please indicate which secure transport you volunteer to write a draft for, and 4) please indicate which secure transport you would commit to implement in your products (and do you have the decision-making authority to commit what gets implemented in shipping products?). Disclaimer: products do not need to be commercial products; they can be freely available implementations, such as open source libraries. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG > -Original Message- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 20, 2006 10:05 AM > To: Rainer Gerhards > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] IESG secure transport requirement can > be quicklysolved... > > Hi Everyone, > > > On Tue, 20 Jun 2006, Rainer Gerhards wrote: > > > > I would appreciate if the chairs could try to reach consensus on my > > proposal. > > > > Comments are appreciated. > > Thanks, > > Rainer > > I'll apologize up front for not paricipating in some recent > dicussions. > I'm on a business trip and rather busy with the day job right now. > > I am willing to listen to a discussion of this proposal. As > Rainer says, > please provide some input and comments. > > 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
[Syslog] Secure transport alternatives
Hi, [Posting as a contributor] I am involved in a number of NM and Security WGs, and I can make these observations: Running an NM protocol over SSH has been done in both netconf and ISMS. I suspect it would be fairly easy to adapt the netconf-over-SSH draft to work for syslog-over-SSH. I suspect it would take a week or so to write a syslog-over-SSH draft since most could be cut-and-paste from the netconf-over-SSH draft. I am the author of the ISMS drafts, and I adapted the netconf/SSH draft for ISMS purposes. Syslog and netconf seem to be closer in their requirements than syslog and ISMS. ISMS has this whole model of access control to deal with that is not part of the threat model for syslog or for netconf at this time. There is a parallel discussion of running syslog messages over netconf. As Rainer has pointed out to Phil, having a consistent terminology would be very helpful. I think having a consistent security solution would probably be helpful in that situation as well. I have concerns about 3195bis as the only alternative we consider, because I have not seen much interest in RFC3195 yet, nor has there been much expresseed interest in netconf over BEEP. Since there may be delay involved in this WG no matter what, would somebody be willing to volunteer to write a syslog-over-SSH draft, so the WG can compare the three approaches? There are other possibilities as well (and I am being serious here, not "let's make this absurd by proposing a whole slew of alteratives documents"). 1) Tom mentioned DTLS, which might be a viable alternative given syslog's UDP roots. Tom would you, or somebody else, be willing to write a proposal for syslog/DTLS? 2) Andy Bierman observed that if syslog messages are going to be transported over netconf, then why not simply use syslog/netconf and let netconf deal with the security issues. That could be an alternative proposal. Is anybody willing to write a draft proposing that as a syslog secure transport solution? My $.02 as a contributor, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 20, 2006 9:44 AM > To: [EMAIL PROTECTED] > Subject: [Syslog] IESG secure transport requirement can be > quickly solved... > > Hi all, > > I propose to update RFC 3195 in the spirit of syslog-protocol > to satisfy > the IESG secure transport requirement (I will call this > derivative work > RFC3195bis below). I sincerely believe that this option would > enable us > to submit syslog-protocol, -transport-UDP and RFC3195bis within a few > weeks. > > My reasoning for this proposal is as follows: > > We all know that 3195 has limited acceptance in the community and very > few implementations. However, it satisfies all IESG criteria > we have in > our charter. Also, it *is* something that can be used in practice and > implementing it becomes easier as support libraries become visible. I > know it is not an optimal choice. On the other hand, we have > syslog-transport-tls, which has been encrumbered by a patent claim. As > it looks, this will need months to solve. RFC3195bis can not be taken > hostage by any patent claims, because there is well-defined > prior art in > RFC 3195. Focussing on RFC 3195bis would enable us to complete our > mission and finsh work that is in the queue for many years > now. I think > this is urgently needed. We might even put the netconf WG with their > syslog gateway on hold (because syslog-protocol can not be published > without resolving the secure transport). Or netconf might > choose to drop > syslog-protocol in order to publish. > > And the good news is that 3195bis can definitely very quickly > be done. I > am saying this on the assumption that we do not revisit the basics of > 3195 but just adopt it to syslog-protocol. I've gone through > 3195 today > and the changes are absolutely minimal: > > Section 2: > Most of it simply needs to be removed because the entity roles are > defined in syslog-protocol. > > Section 3: > - the message samples must be upgraded to -protocol-format > - syslog-framing in section 3.3 must be changed (could be > octet-counting > or disallow of multiple messages per ANS, what I recommend) > > Section 4: > 4.4.2 > - needs to be updated with the new HEADER fields and STRUCTURED-DATA > - some work on "deviceFQDN" and "deviceIP" needed > - some transformation rules (page 15) need to be removed > - handling of invalid message formatting must be removed (no longer a > concern) > - samples must be adjusted > > 4.4.3 > - sample on page 24 (top) must be checked and/or adjusted > > Section 7: > - DTD needs to be adjusted > >
RE: [Syslog] Secure transport alternatives
Hi Darren, I don't know them well enough to comment. Are you willing to write one or two drafts proposing these as possible solutions so the WG can evaluate them as alternatives? David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 22, 2006 6:14 AM > To: Miao Fuyou > Cc: 'David Harrington'; 'Rainer Gerhards'; [EMAIL PROTECTED] > Subject: Re: [Syslog] Secure transport alternatives > > Miao Fuyou wrote: > > real "general" security mechanisms(except IPsec, but it is not > > application-friendly). So, IMHO the primary criteria for > selection is: is it > > convenient for the application to invoke the security > service provided by > > the security protocol? > > That to me sounds like GSSAPI or SASL. > > Any reason these aren't being considered ? > > -- > Darren J Moffat > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] IESG secure transport requirement can be quicklysolved...
Hi Rainer, The deadline for a -00- draft has just passed, so you won't be able to publish officially until after Montreal. I recommend posting the draft to the mailing list for discussion, as a non-WG draft. By the time the I-D publication process re-opens after montreal, the WG can decide whether to have you publish as an individual or WG draft. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 22, 2006 11:09 AM > To: David Harrington; Chris Lonvick > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] IESG secure transport requirement can > be quicklysolved... > > David, WG, > > > -----Original Message- > > From: David Harrington [mailto:[EMAIL PROTECTED] > > [snip] > > > It is important that we make progress and not just discuss the > > alternatives, ad infinitum, however. We need volunteers who are > > willing to put in the work to write viable internet-drafts and drive > > them to completion, or the discussions are largely useless. > > > > So, I will make these requests to help focus the discussions: > > 1) please indicate which secure transports you consider to be > > feasible, > > -transport-ssh, rfc3195bis, [-transport-tls] > > > 2) please indicate which secure transports address which syslog > > threats (they're listed in syslog/tls), > > section 2 of -transport-tls, IMHO, applies to all three > > > 3) please indicate which secure transport you volunteer to write a > > draft for, and > > I have acutally "written" (copy&paste plus a few sentences) something > that could be a starting point for -transport-ssh: > > http://www.syslog.cc/ietf/drafts/draft-ietf-syslog-transport-s sh-00pre.t > xt > > If it is WG consensus, I can submit this as an WG document. > The current > version describes the overall picture plus a weak idea of framing and > transmission (sections 4, 5, and 6). This idea was taken from the > current discussion on -transport-tls. However, I consider it > to be very > insufficient and have made no attempt to specify it in depth. If we > adopt this document, I would further investigate how a proper framing > would look like. I have on my mind to borrough some ideas > from netconf, > but use them in the simple spirit of syslog (e.g. we might > use the same > opening with a syslog-reserved URI, if the netconf-WG does not object > against this, but it is too early to discuss such issues). > > I would also volunteer to update 3195 to 3195bis, if their original > authors are not available for that. I expect to need some help on the > XML schema when doing so. As I have already written, I expect > this to be > an extremely easy and quick task. My summary in the other mail was > concluding. There is no need for any additional edits. > > > 4) please indicate which secure transport you would commit to > > implement in your products (and do you have the decision-making > > authority to commit what gets implemented in shipping products?). > > With a very high probability, we would implement > -transport-ssh and with > a somewhat lower probability we would change our rfc 3195 > implementation > to support 3195bis. I would expect this to happen in our products as > well as in liblogging/rsyslog (open source projects). I have sufficent > decision-making authority to make this commitment (not thinking about > major market or overall company policy changes). > > I would deeply appreciate feedback if I should submit the > -transport-ssh > draft as a WG document. > > Rainer > > > > > Disclaimer: products do not need to be commercial products; they can > > be freely available implementations, such as open source libraries. > > > > Thanks, > > David Harrington > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > co-chair, Syslog WG > > > > > > > -Original Message- > > > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, June 20, 2006 10:05 AM > > > To: Rainer Gerhards > > > Cc: [EMAIL PROTECTED] > > > Subject: Re: [Syslog] IESG secure transport requirement can > > > be quicklysolved... > > > > > > Hi Everyone, > > > > > > > > > On Tue, 20 Jun 2006, Rainer Gerhards wrote: > > > > > > > > I would appreciate if the chairs could try to reach consensus on > > my > > > > proposal. > > > > > > > >
RE: [Syslog] Secure transport alternatives
Hi Darren, [posting as a contributor] I don't know GSSAPI or SASL well enough to evaluate their approriateness for securing syslog. Are you willing to write one or two drafts proposing these as possible solutions so the WG can evaluate them as alternatives? [posting as a contributor] David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 22, 2006 6:14 AM > To: Miao Fuyou > Cc: 'David Harrington'; 'Rainer Gerhards'; [EMAIL PROTECTED] > Subject: Re: [Syslog] Secure transport alternatives > > Miao Fuyou wrote: > > real "general" security mechanisms(except IPsec, but it is not > > application-friendly). So, IMHO the primary criteria for > selection is: is it > > convenient for the application to invoke the security > service provided by > > the security protocol? > > That to me sounds like GSSAPI or SASL. > > Any reason these aren't being considered ? > > -- > Darren J Moffat > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Decisions to make about the Huawei IPR claim
Hi Rainer, [speaking as a contributor] This WG needs to deliver documents soon or the WG could be closed. We need to deliver a secure transport solution. If the WG decides to do a 3195bis as the secure transport solution, I recommend the short-term deliverable be "good enough" to work with syslog-protocol. That way we can get 3195bis AND the other documents (-protocol- and -udp-) published and onto the standards track, so the industry can begin to implement, and the WG can stay open to do additional work. Then we can address whether the 3195 design should be modified in other ways. There have been suggestions to modify 3195 to "harmonize" with the work of other Standards Development Organizations such as OASIS and W3C. Doing that work would likely not be quick or easy. I fear it would be a real rathole that would prevent us getting 3195bis published at all, and if 3195bis is the WG's choice as the secure transport protocol, then that rathole would also prevent the publication of -protocol- and -udp- on a timely basis. As a 14-year veteran of IETF WG efforts, I think it would be a bad WG decision to put 3195bis on the critical path and to open it up to a rathole discussion. If 3195bis is on the critical path, we need to avoid the rathole discussion for now; it can be considered for a future "release". If the WG feels the rathole discussion is really necessary, and 3195bis should not be done without having had such a possible-rathole discussion, then 3195bis should not be put on the critical path. My $.02 David Harrington [EMAIL PROTECTED] > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 29, 2006 5:11 AM > To: Chris Lonvick; [EMAIL PROTECTED] > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > Besides the somewhat political issue, I think there is also technical > issue that affects the question. I think we should consider that > question in parallel to the IPR question. > > This question is if this WG intends to do a revision of 3195. And, if > so, I think the very close next question is if we "just" update it to > support syslog-protocol or if we intend to make any > substantial changes. > > I see a relationship between the IPR and the 3195bis issue because > 3195bis modifies the "cost" of finding alternate solutions. Coming to > this point, it would probably be helpful if we could actually > weigh cost > vs. utlity of the different approaches. IPR, IMHO, is just a cost, > obviously one whose weight we need to decide on. But I think it is not > the only cost. If the WG finds such a "cost vs. utility" discussion > useful, I could document my point of view as a starting point. I > volunteer to create a summary document (a public web page, not a I-D) > where I track all contributions to this discussion (for an example of > what I have in mind see Juergen Schoenwaelder's page on netconf > notification requirements: > http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications). > > I would find such a page very helpful. It documents the > decision process > and the decision criteria. In doing that, it helps us come to a better > decison because we than have all facts at a single place. > Thus, it also > provides good argument when dealing with the IESG (in the case we need > to justify the decision). > > Thanks, > Rainer > > > -Original Message- > > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, June 28, 2006 7:56 PM > > To: [EMAIL PROTECTED] > > Subject: [Syslog] Decisions to make about the Huawei IPR claim > > > > Hi Folks, > > > > It's looking like we have a primary decision to make about > > the IPR claim > > that Huawei has made on syslog-transport-tls. First and > > foremost, I want > > everyone to be informed of the IETF stand on IPR claims and > > on the IETF > > process that we will follow. > > > > This is the position of the IETF on IPR claims: > > -- > > --- > > Intellectual Property > > > > The IETF takes no position regarding the validity or > scope of any > > Intellectual Property Rights or other rights that might > > be claimed to > > pertain to the implementation or use of the technology > > described in > > this document or the extent to which any license under > such rights > > might or might not be available; nor does it represent > that it has > > made any independent effort to identify any such rights. > > Information > > on the procedures with respect to rights in R
RE: [Syslog] Decisions to make about the Huawei IPR claim
Hi, [posting as a contributor] I recommend this WG make a clear separation (as much as is possible) between issues of security and issues of network management. Issues such as harmonization with the work of other SDOs, integration with netconf, message formatting, content standardization, and so on, are about syslog as a network management protocol. I strongly beleve this work should **not** be done by the syslog-sec WG, but in a WG chartered in the OPS area or the Application area, not the Security area. There are many contributors who have worked on, and are currently working on, other network management protocols and have addressed issues similar to those facing syslog. In addition, there is an effort by the new OPS Management AD to address the current isolated decision making (silos) that is occurring regarding the management plane throughout the IETF. The contributors to this WG should be involved in that discussion, which is likely to be centered in the OPS area. This WG is about security for syslog, and we should focus our efforts on solving the security problems, whether with tls or ssh or beep, and publish. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Friday, June 30, 2006 6:11 AM > To: David Harrington; Chris Lonvick; [EMAIL PROTECTED] > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > David, > > I fully agree with your thought. I, too, think we must put emphasis on > the delivery of documents. In my personal opinion, this > leaves only two > realistic options: > > a) rfc 3195bis as you have described it (without the "rathole > discussion") > b) -transport-tls more or less as it is now > > I think there are enough comments on a) already in the list archive. I > will not repeat them. > > Comments on b) currently tend to focus on the IPR issue. Let's ignore > that for a moment and look at other arguments. We have > intially opted in > favor of -transport-tls because it already is in widespread > use. What is > done currently can not be standardized literally, but we can > standardize > something that is quite close to it. It was our opinion that > -transport-tls should by fairly easy to implement, thus bringing some > immediate value to the community. > > Now some technical issues have come up on the list, things like > app-layer ACKs, opening and closeing conversations. I have brought up > some of them. I am also of the view that we could craft a better > framing, probably borrowing from NETCONF (and thus easing conversion - > the "big picture"). This is still sufficiently easy, but it is a big > departure from the "let's standardize what is used in practice" > approach. I fear that discussing a better framing/session management > again takes up a lot of time and includes a high risk of missing our > milestones again. BTW: we are scheduled to deliver by > November 2006, and > I do not expect that we will be granted an extension this time again. > November will be very soon, especially looking at the summer break. > > So I propose that we do NOT enter any new discussion. We > should deliver > either a) or b) (above), without introducing any new features > or ideas. > That means that the result will be sub-optimal. But > delivering something > usable is much better than aiming for the perfect one that will never > appear. > > Once we have delivered, we should discuss what to do next (but only > AFTER delivery). I have to admit that I now see some good points in a > -transport-ssh and consider it implementable with reasonable effort. > However, -transport-ssh should be done after we have reconsidered the > framing. Given the track record of this WG, I would suspect > this can not > be done in less than 12 to 24 month. There are also the issues that > Anton brought up and the general question on configuration and event > data models for syslog. A lot of useful work lying ahead (but > depending > on our ability to finish the base stuff first). > > I think this work can never be done if this WG fails. So I am > desperately trying to get us to publish. I think what we have > is useful > and well-enough. If we do not publish soon, we will never be able to > publish at all. IMHO, we have already received our third chance and > there will be no fourth... > > Rainer > > > -Original Message- > > From: David Harrington [mailto:[EMAIL PROTECTED] > > Sent: Thursday, June 29, 2006 8:32 PM > > To: Rainer Gerhards; 'Chris Lonvick'; [EMAIL PROTECTED] > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > > >
RE: [Syslog] Decisions to make about the Huawei IPR claim
Hi Anton, I am not proposing to drop anything that has been developed by this WG so far; I am proposing that we focus our current and future discussions on what we are suppposed to be delivering. I have concerns that there are numerous discussions that deal with issues other than security-related issues, and I think those discussions belong in the OPS area rather than the Security area. dbh > -Original Message- > From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] > Sent: Friday, June 30, 2006 3:43 PM > To: David Harrington; Rainer Gerhards; Chris Lonvick > (clonvick); [EMAIL PROTECTED] > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > David: > > Please clarify... > > Are you suggesting we drop syslog-protocol, which actually > defines message format, and just do a generic secure > transport for events? Something that just does framing, > app-level ack and had generic payload? > > And then we continue to live without syslog standard, waiting > for others to standardize payload? > > Anton. > > > -Original Message- > > From: David Harrington [mailto:[EMAIL PROTECTED] > > Sent: Friday, June 30, 2006 11:58 AM > > To: 'Rainer Gerhards'; Chris Lonvick (clonvick); [EMAIL PROTECTED] > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > > > Hi, > > > > [posting as a contributor] > > > > I recommend this WG make a clear separation (as much as is possible) > > between issues of security and issues of network management. > > > > Issues such as harmonization with the work of other SDOs, > integration > > with netconf, message formatting, content standardization, > and so on, > > are about syslog as a network management protocol. I strongly beleve > > this work should **not** be done by the syslog-sec WG, but in a WG > > chartered in the OPS area or the Application area, not the Security > > area. There are many contributors who have worked on, and are > > currently working on, other network management protocols and have > > addressed issues similar to those facing syslog. > > > > In addition, there is an effort by the new OPS Management AD to > > address the current isolated decision making (silos) that > is occurring > > regarding the management plane throughout the IETF. The contributors > > to this WG should be involved in that discussion, which is likely to > > be centered in the OPS area. > > > > This WG is about security for syslog, and we should focus > our efforts > > on solving the security problems, whether with tls or ssh > or beep, and > > publish. > > > > David Harrington > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > > > > -Original Message- > > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > > Sent: Friday, June 30, 2006 6:11 AM > > > To: David Harrington; Chris Lonvick; [EMAIL PROTECTED] > > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > > > > > David, > > > > > > I fully agree with your thought. I, too, think we must > put emphasis > > on > > > the delivery of documents. In my personal opinion, this > > > leaves only two > > > realistic options: > > > > > > a) rfc 3195bis as you have described it (without the "rathole > > > discussion") > > > b) -transport-tls more or less as it is now > > > > > > I think there are enough comments on a) already in the > list archive. > > I > > > will not repeat them. > > > > > > Comments on b) currently tend to focus on the IPR issue. Let's > > ignore > > > that for a moment and look at other arguments. We have > > > intially opted in > > > favor of -transport-tls because it already is in widespread > > > use. What is > > > done currently can not be standardized literally, but we can > > > standardize > > > something that is quite close to it. It was our opinion that > > > -transport-tls should by fairly easy to implement, thus bringing > > some > > > immediate value to the community. > > > > > > Now some technical issues have come up on the list, things like > > > app-layer ACKs, opening and closeing conversations. I have brought > > up > > > some of them. I am also of the view that we could craft a better > > > framing, probably borrowing from NETCONF (and thus easing > conversion > > - > &
[Syslog] FW: Initial Logging capabiltiies document
FYI. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of patrick cain Sent: Wednesday, July 05, 2006 10:33 AM To: [EMAIL PROTECTED] Subject: Initial Logging capabiltiies document Hi, I promised to get out a version of the logging capabiltiies document. Since I missed the initial draft cutoff date, I spent some extra time flushing it out. And it is attached. It will go to the IETF repository as soon as it re-opens. Please advise me of correction, complaints, and aditions, and feel free to spam it others you may know who are into logging. I asked for agenda time at the Montreal OPSEC meeting, but I don't think this one needs much presenting. Pat Cain OPSECP. Cain Internet-Draft The Cooper-Cain Group, Inc. Expires: December 28, 2006 June 26, 2006 Logging Capabilities for IP Network Infrastructure draft-cain-logging-caps-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document lists logging capabilities needed to support the current practices described in Operational Security Current Practices [CURPRAC] and logical enhancements to those practices if the capability existed. Logging is defined as the delivery to another entity or system of messages about the device, the data passing through the device, or the device's interaction with another device. Capabilities are defined without reference to specific technologies. This is done to leave room for deployment of new technologies that CainExpires December 28, 2006 [Page 1] Internet-DraftLogging Capabilities June 2006 implement the capability. Each capability cites the practices it supports. Current implementations that support the capability are cited. Special considerations are discussed as appropriate listing operational and resource constraints, limitations of current implementations, trade offs, etc. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Capabilities or Requirements ? . . . . . . . . . . . . . . 3 1.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 2. Functional Capabilities of Log Generating Systems . . . . . . 5 2.1. Logging Facility Uses Protocols Subject To Open Review . . 5 2.2. Logs Sent To Remote Servers . . . . . . . . . . . . . . . 6 2.3. Ability to Select Reliable Delivery . . . . . . . . . . . 6 2.4. Ability to Remotely Log Securely . . . . . . . . . . . . . 7 2.5. Ability to Log Locally . . . . . . . . . . . . . . . . . . 8 2.6. Ability to Log Different Severities to Different Destinations . . . . . . . . . . . . . . . . . . . . . . . 9 2.7. Ability to Log to Multiple Destinations . . . . . . . . . 10 2.8. Ability to Maintain Accurate System Time . . . . . . . . . 11 2.9. Display Timezone And UTC Offset . . . . . . . . . . . . . 12 2.10. Default Timezone Should Be UTC . . . . . . . . . . . . . . 13 2.11. Log Entries Must Be Timestamped . . . . . . . . . . . . . 13 2.12. Log on Exception or Identifed Event . . . . . . . . . . . 14 2.13. Logs Contain Untranslated IP Addresses . . . . . . . . . . 15 2.14. Logs Contain Records Of Security Events . . . . . . . . . 16 2.15. Logs Do Not Contain Passwords . . . . . . . . . . . . . . 17 2.16. Devices Should Log Every Message . . . . . . . . . . . . . 18 2.17. Syslog-specific Capabilties . . . . . . . . . . . . . . . 19 2.17.1. Configurable Facility Values .
RE: [Syslog] Decisions to make about the Huawei IPR claim
Hi Tom, The editors' responsibility is to make the document reflect WG consensus, as best they can. The co-chairs and the AD are responsible for ensuring that the editors represented the WG consensus in the document, and to determine WG consensus if it is not clear to the editors. Please propose text worded as you wish to see it, and ask for WG comments. If Chris feels there is WG consensus on the wording, then that wording would go into the document, without being slightly modified. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: Tom Petch [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 06, 2006 3:56 AM > To: Chris Lonvick > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim > > > Tom Petch > > - Original Message - > From: "Chris Lonvick" <[EMAIL PROTECTED]> > To: "Darren Reed" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Wednesday, July 05, 2006 6:25 PM > Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim > > > > Hi Darren, > > > > There is no need for Bazsi to write a different i-d. > > draft-ietf-syslog-transport-tls is a Working Group document and the > > final revision must reflect WG consensus. > > > > I think that draft-ietf-syslog-transport-tls is seriously > flawed and I have > already made some comments on this, have others pending. But > I am now reluctant > to make any constructive suggestions lest my text be slightly > modified, > incorporated into this I-D and then made subject to an IPR claim. > > I believe we need a new document, or at least a new editor > who is prepared to > rewrite everything. I am not saying it should be that of > Bazsi, just anyone who > does not have H*** in their e-mail address. > > Tom Petch > > > If Bazsi (or anybody else) can propose changes to > > draft-ietf-syslog-transport-tls and the WG reaches consensus on the > > proposed changes, then the document will be revised to reflect that. > > > > Please check me if I'm wrong on this, but I think that the > only changes > > between syslog-ng and what's in syslog-transport-tls are > > - framing, > > - changes to address the threat model (listed in our Charter). > > > > 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
[Syslog] Internet-draft sources
Hi, As WG co-chair, I like to have a copy of the sources for all the WG's documents, just in case we lose contact with the author/editor. Can the primary editor for each document please send me a copy of the sources for either the last published revision, or your latest current sources, or both? If you are using nroff macros, makefiles, xml2rfc external entities, etc., please send me and/or Chris the files needed to reproduce the WG internet-drafts. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Syslog MIB document
Hi, The syslog MIB document has now been declared "dead" and is no longer available from the i-d repository. This is rather unfortunate since it is a milestone in our charter to deliver this. Can we get a new revision posted please so everybody can access it? The WG needs to make a decision about whether the syslog MIB document is what the WG wants. I have seen some feedback that the mib does not provide the management desired. At this point, we need to decide if this document represents WG consensus or not, and, if not, then we need to plan to work on it. Chris is unavailable this week. I believe that Chris required a stuckee for reviews for each document in the new charter. Who was the stuckee for the MIB document review? Can we please get a review of the document? Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] FW: Posting of draft-ietf-syslog-device-mib-08.txt
Hi, I had draft-ietf-syslog-device-mib-08.txt resurrected. Please review this document to determine if it needs additional work or not, so we can plan to get the work completed by the November deadline. Thanks, David Harrington [EMAIL PROTECTED] co-chair, Syslog WG -Original Message- From: IETF Secretariat [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 25, 2006 3:50 PM To: Glenn M. Keeni Cc: David Harrington; Chris Lonvick; Sam Hartman; Steven Bellovin Subject: Posting of draft-ietf-syslog-device-mib-08.txt As you requested, draft-ietf-syslog-device-mib-08.txt, an updated version of an expired Internet-Drafts, has been posted. The draft will expire on January 26, 2007 unless it is replaced by an updated version, or the Secretariat has been notified that the document is under official review by the IESG or has been passed to the RFC Editor for review and/or publication as an RFC. The IETF Secretariat. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] FW: Posting of draft-ietf-syslog-device-mib-08.txt
Whoops. I apparently did not get the draft resurrected; Glenn posted a new revision. Thanks Glenn. Please review this document to determine if it needs additional work or not, so we can plan to get the work completed by the November deadline. dbh > -Original Message- > From: David Harrington [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 25, 2006 5:08 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] FW: Posting of draft-ietf-syslog-device-mib-08.txt > > Hi, > > I had draft-ietf-syslog-device-mib-08.txt resurrected. > > Please review this document to determine if it needs additional work > or not, so we can plan to get the work completed by the November > deadline. > > Thanks, > David Harrington > [EMAIL PROTECTED] > co-chair, Syslog WG > > -Original Message- > From: IETF Secretariat [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 25, 2006 3:50 PM > To: Glenn M. Keeni > Cc: David Harrington; Chris Lonvick; Sam Hartman; Steven Bellovin > Subject: Posting of draft-ietf-syslog-device-mib-08.txt > > As you requested, draft-ietf-syslog-device-mib-08.txt, an updated > version of an > expired Internet-Drafts, has been posted. The draft will expire on > January 26, > 2007 unless it is replaced by an updated version, or the Secretariat > has been > notified that the document is under official review by the IESG or has > been > passed to the RFC Editor for review and/or publication as an RFC. > > The IETF Secretariat. > > > ___ > 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
RE: [Syslog] delineated datagrams
Hi, As you probably know by now, I like to see design reuse across IETF NM solutions, especially across SNMP, syslog, ipfix, and netconf where feasible. As all the IETF NM protocols move toward similar secure transport solutions, including moving from datagrams to streams, it would be a good thing to use consistent aproaches to framing. Here is what is happening in the other IETF NM protocols: SNMPv1/v2c/v3 uses octet-counting within its BER encoded messages. For SNMP over TCP (RFC3430): It is possible that the underlying TCP implementation delivers byte sequences that do not align with SNMP message boundaries. A receiving SNMP engine MUST therefore use the length field in the BER-encoded SNMP message to separate multiple requests sent over a single TCP connection (framing). An SNMP engine which looses framing (for example due to ASN.1 parse errors) SHOULD close the TCP connection. SNMP over SSH (ISMS) does not specify how to delineate datagrams, beyond the BER octet-counting. (As editor of the SNMP/SSH draft, I will probably copy the text from RFC3430.) IPFIX uses octet-counting. See http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-22.txt section 3.1. The NETCONF protocol uses an RPC-based communication model. From http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-12.txt: NETCONF peers use and elements to provide transport protocol-independent framing of NETCONF requests and responses. There is ongoing discussion about the framing in the netconf notification protocol, and the possibility of interleaving notifications and request/responses within a session or channel. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Friday, August 04, 2006 10:14 AM > To: Miao Fuyou > Cc: [EMAIL PROTECTED]; 'Tom Petch' > Subject: RE: [Syslog] delineated datagrams > > Hi, > > I'd like to get this resolved and put into the next version > of the draft. > > Many protocols use byte-counting for framing. > Many protocols use a specific character as a delimiter. > Do we need both? > > I think that I've seen notes from Rainer, Tom Petch, and Andrew Ross > saying that we should only use a special character for both > simplicity of > design and for interoperability with current syslog/tls > implementations. > > Are there other opinions on this? Please speak up now. > > Thanks, > Chris > > > On Mon, 24 Jul 2006, Miao Fuyou wrote: > > > > > Hi, Rainer, > > > > Interop is a compelling reason for protocol design, so I > tend to agree with > > you that it is a feature nice to have. I am wondering > whether we should > > define procedures for frame delineating processing in > syslog-tls draft > > because we have both octect-counter and LF in a record. > > > > Miao > > > >> -Original Message- > >> From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > >> Sent: Friday, July 21, 2006 6:16 PM > >> To: Miao Fuyou; Tom Petch; [EMAIL PROTECTED] > >> Subject: RE: [Syslog] delineated > >> datagramswasdraft-ietf-syslog-transport-tls-01.txt > >> > >> Miao, > >> > >> I agree with your comments. However, using the LF as a record > >> delimited would still allow us to interop with existing > >> syslog/tls implementations. This is my major point. I think > >> it is worth it. > >> > >> Rainer > >> > >>> -Original Message- > >>> From: Miao Fuyou [mailto:[EMAIL PROTECTED] > >>> Sent: Friday, July 21, 2006 12:00 PM > >>> To: 'Tom Petch'; [EMAIL PROTECTED] > >>> Subject: RE: [Syslog] delineated > >>> datagramswasdraft-ietf-syslog-transport-tls-01.txt > >>> > >>> > >>> TLS uses SHA-1 or MD5 in ciphersuite for message integrity > >>> verification. If bytes lost happens during transferring, > >> the message > >>> will be dropped by TLS. > >>> That is also the cause that we need a security mechanism > >> for Syslog. > >>> > >>> As for error of encoding/decoding, I believe if an > application does > >>> encoding/decoding in a wrong way, you must not expect it do > >> it right > >>> with other mechanism, such as LF. > >>> > >>> Redundancy to improve robustness is good idea, but I don't > >> think it > >>> applies to this case. > >>> > >>>> -Original Message- > >>>> From: Tom Petch [mailto:[EMAIL PROTECTED] > >
[Syslog] timeline
Hi, Chris and I are working on a schedule to help the WG meet its deliverables. We have not yet agreed on all the specific dates because Chris is on (another) vacation, but should have a schedule posted within a few days. Here are two things we need to resolve soon. 1) whether draft-ietf-syslog-transport-tls should use byte-counting, special character, or both, including which special character. We want to finalize this WG decision by August 18. 2) whether draft-ietf-syslog-device-mib represents WG consensus on what needs to be managed in the protocol, udp, tls, and sign documents, and if not, what needs to be changed to represent WG consensus. We want to finalize this WG decision by August 18 as well. The chairs will be starting WGLCs on each document so we can submit them to the IESG by the November deadlines. The first two WGLCs will be for draft-ietf-syslog-protocol and draft-ietf-syslog-transport-udp, so you can get started ahead of time to do these reviews if you want. WGLCs will probably start Monday Aug 14. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] delineated datagrams
Hi Tom, You're right; I didn't go far enough. I was looking for a framing defined by the netconf protocol, not the separator of messages within a transport. Unfortunately, Netconf uses a number of transport-dependent schemes within the multiple transports it supports, including both octet-counting approaches and terminating character approaches. Sigh. The "]]>]]>" sequence only works in the SSH transport mapping, not the BEEP or SOAP mappings. So much for trying to find consistency. Note that Netconf is considering a design that allows multiple syslog messages to be sent in a netconf notification session. If we used "]]>]]>" as a syslog message delimiter, we would prevent netconf from transporting multiple syslog messages, since netconf can only transport valid XML, and the "]]>]]>" in a syslog message would indicate the end of an , causing netconf to lose synchronization? See the Montreal Netconf Interim minutes currently available on the netconf mailing list for more details. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: Tom Petch [mailto:[EMAIL PROTECTED] > Sent: Monday, August 14, 2006 6:36 AM > To: David Harrington; 'Chris Lonvick'; 'Miao Fuyou' > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] delineated datagrams > > - Original Message - > From: "David Harrington" <[EMAIL PROTECTED]> > To: "'Chris Lonvick'" <[EMAIL PROTECTED]>; "'Miao Fuyou'" > <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; "'Tom Petch'" <[EMAIL PROTECTED]> > Sent: Friday, August 04, 2006 7:59 PM > Subject: RE: [Syslog] delineated datagrams > > > > > > As you probably know by now, I like to see design reuse > across IETF NM > > solutions, especially across SNMP, syslog, ipfix, and netconf where > > feasible. > > > > As all the IETF NM protocols move toward similar secure transport > > solutions, including moving from datagrams to streams, it would be a > > good thing to use consistent aproaches to framing. > > > > Here is what is happening in the other IETF NM protocols: > > > > > > > The NETCONF protocol uses an RPC-based communication model. > > From > > http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-12.txt: > >NETCONF peers use and elements to provide > > transport > >protocol-independent framing of NETCONF requests and responses. > > Ok as far as it goes but incomplete. As the ssh mapping says, > > " As the previous example illustrates, a special character sequence, > ]]>]]>, MUST be sent by both the client and the server > after each XML > document in the NETCONF exchange. This character sequence cannot > legally appear in an XML document, so it can be > unambigiously used to > indentify the end of the current document in the event of an XML > syntax or parsing error, allowing resynchronization of the NETCONF > exchange." > . > Wishing to promote design reuse across IETF NM solutions, > especially across the > character-based ones, I did propose the same separator for > syslog over tls and > still see it as the technically best solution (even though > our message content > can be anything and so, unlike NETCONF, we cannot rely 100% > on that not > appearing in our message content). > > > > > David Harrington > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] syslog WG Timeline
Hi, This message officially starts the Syslog Working Group Last Call for the following two documents: draft-ietf-syslog-protocol: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt draft-ietf-syslog-transport-udp: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 .txt The Working Group Last Call for these documents will end August 28. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, it if does not look acceptable please identify your ibjections, preferably with suggested text that would make it acceptable. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG > -Original Message- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Friday, August 11, 2006 3:17 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] syslog WG Timeline > > Hi Folks, > > David and I have agreed upon a timeline for the completion of our > milestones. Please review this. We will be asking for > people to provide > review comments on each of the documents while they are in > Working Group > Last Call (WGLC). If you know that you're going to be > unavailable (summer > vacation) for some of these WGLCs, please submit comments to the WG > beforehand, at least to let us know that you've read it. > > Thanks, > Chris and David > > > ===start=== > > Aug 11 - Drive discussion on whether draft-ietf-syslog-device-mib > represents WG consensus on what needs to be managed in > -protocol-, -udp-, -tls-, and -sign-. > Aug 11 - Drive discussion on whether draft-ietf-syslog-transport-tls > should use byte-counting, special character, or > both, including > which special character. > > Aug 14 - Begin WG Last Call for draft-ietf-syslog-protocol (45 pages) > Aug 14 - Begin WG Last Call for draft-ietf-syslog-transport-udp (10 > pages) > > Aug 18 - Decide what needs to be changed in > draft-ietf-syslog-transport-tls to represent the final WG > consensus on byte-counting, special character, or > both, including > which special character. > Aug 18 - Decide what needs to be changed in the general design of > draft-ietf-syslog-device-mib to represent the WG consensus. > > Aug 28 - Close WG Last Call for draft-ietf-syslog-protocol > Aug 28 - Close WG Last Call for draft-ietf-syslog-transport-udp > > Aug 28 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > > Sep 1 - updated revision of draft-ietf-syslog-transport-tls, > representing WG consensus. > Sep 1 - updated revision of draft-ietf-syslog-device-mib, representing > WG consensus. > > Aug 28 - Begin WG Last Call for draft-ietf-syslog-sign (33 pages) > Aug 28 - Begin WG Last Call for draft-ietf-syslog-transport-tls (11 >pages) > > > Sep 11 - Close WG Last Call for draft-ietf-syslog-sign. > Sep 11 - Close WG Last Call for draft-ietf-syslog-transport-tls. > > Sep 11 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-sign > > Sep 11 - Begin WG Last Call for draft-ietf-syslog-device-mib (33 >pages) > > Sep 25 - Close WG Last Call for draft-ietf-syslog-device-mib. > Sep 25 - Chairs start working on Shepherding documents for >- draft-ietf-syslog-device-mib > > Oct 16 - Chairs produce Shepherding Documents for > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-device-mib > - draft-ietf-syslog-sign > > Oct 23 - Final review of Spepherding Documents by the WG > > Nov 1 - Submit the following to the IESG >- draft-ietf-syslog-protocol >- draft-ietf-syslog-transport-udp >- draft-ietf-syslog-transport-tls >- draft-ietf-syslog-device-mib >- draft-ietf-syslog-sign > > ===end=== > > ___ > 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
RE: [Syslog] Syslog-sign & -protocol
Hi, When can we get an updated revision of syslog-sign? Our current timeline calls for starting WGLC Aug 28. The changes sound sufficiently large that we should definitely try to review the changes before we start a last call on the document. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG > -Original Message- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Monday, August 14, 2006 10:33 AM > To: Rainer Gerhards > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] Syslog-sign & -protocol > > Hi All, > > On Sun, 13 Aug 2006, Rainer Gerhards wrote: > > > Hi, > > > > A general comment: syslog-sign is still based on rfc 3164 > and has ist own format definitions. It needs to be edited to > utilize the new work in syslog-protocol. It should now use > structured data for ist signature blocks. > > Alex has moved much of it to be conformant with > syslog-protocol. The work > that needs to be addressed (as I see it :) > > For the Signature Block, should the payload of signatures be > part of the > "ssign" SD-ID, or should it be the payload (behind the BOM)? > Right now, > it is part of the SD-ID. > > Similarly, about the "ssign-cert" and it's payload. I think > it likely > that the Payload Block can be placed within a single > Certificate Block > based upon our discussions of the max length. > > The document needs to define how to use "@enterpriseID" in some cases. > > Section 8.2 - the length is no longer limited to 1024B. > > Section 9 - "Cookie Fields" are no longer used. > > The IANA section also needs to specify which SD-IDs and > SD-Params should > be registered. > > Should other SD-IDs be included with "ssign" and "ssign-cert" > SD-IDs? (I > think so as that's how we include information about time > accuracy, etc.) > > 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
[Syslog] byte-counting vs special character
t;new style" > syslogd. Having the octet count in front of the message removes that > ability, as the old syslogd will no longer see the at > the start of > the message. > > I agree that it is trivial to modify code to take care for the octet > counter. But this is not my concern. My concern is that I > would like to > achive as good as possible compatibility with existing deployed (aka > "unmodified") technology. I should have been more specific on that. > Sorry for the omission... > > I am also unaware of any implementation that mandates CR LF over just > LF. Could you let me know which ones are these? > > Rainer > > > -Original Message- > > From: Miao Fuyou [mailto:[EMAIL PROTECTED] > > Sent: Monday, August 14, 2006 7:07 PM > > To: Rainer Gerhards > > Cc: [EMAIL PROTECTED] > > Subject: RE: [Syslog] timeline > > > > > > Hi, Rainer, > > > > A new implementation could rely on byte-counting only and > > then delete LF > > from the frame(appplication knows exactly where the LF is), > > it may not force > > us to use escapes. For LF, I think it is difficult to get > > 100% compatibility > > for a legacy implementation to comply TLS-transport without > > any change to > > the code. At least, some imlementation may need to change > CR LF to LF > > because some implementations use CR LF rather than LF. So, it > > may be ok to > > add several LOC to delete FRAME-LEN SP from the frame. > > > > I still prefer byte-counting only to byte-counting+LF even > if it is a > > feasible tradeoff. > > > > Miao > > > > > -Original Message- > > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > > Sent: Monday, August 14, 2006 10:18 PM > > > To: Miao Fuyou > > > Subject: RE: [Syslog] timeline > > > > > > We should not go byte-counting + LF. This is the worst choice: it > > > > > > A) breaks compatibility > > > B) Forces us to use escapes > > > > > > So we get the bad of both worlds, without any benefits. > > > > > > Rainer > > > > > > > -Original Message- > > > > From: Miao Fuyou [mailto:[EMAIL PROTECTED] > > > > Sent: Monday, August 14, 2006 12:58 AM > > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington'; > > > [EMAIL PROTECTED] > > > > Subject: RE: [Syslog] timeline > > > > > > > > > > > > My vote: byte-counting only > byte-counting + LF > LF > > > > > > > > > > > > > > ___ > 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
[Syslog] Working Group Last Call: protocol and udp documents
Hi, I am resending this message with a new subject line, in case anybody is watching for the words "working group last call" in the subject line. It's also easier for me for bookkeeping reasons ;-) David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG -Original Message----- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 7:33 PM To: 'Chris Lonvick'; [EMAIL PROTECTED] Subject: RE: [Syslog] syslog WG Timeline Hi, This message officially starts the Syslog Working Group Last Call for the following two documents: draft-ietf-syslog-protocol: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt draft-ietf-syslog-transport-udp: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 .txt The Working Group Last Call for these documents will end August 28. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, it if does not look acceptable please identify your ibjections, preferably with suggested text that would make it acceptable. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG > -Original Message- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Friday, August 11, 2006 3:17 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] syslog WG Timeline > > Hi Folks, > > David and I have agreed upon a timeline for the completion of our > milestones. Please review this. We will be asking for > people to provide > review comments on each of the documents while they are in > Working Group > Last Call (WGLC). If you know that you're going to be > unavailable (summer > vacation) for some of these WGLCs, please submit comments to the WG > beforehand, at least to let us know that you've read it. > > Thanks, > Chris and David > > > ===start=== > > Aug 11 - Drive discussion on whether draft-ietf-syslog-device-mib > represents WG consensus on what needs to be managed in > -protocol-, -udp-, -tls-, and -sign-. > Aug 11 - Drive discussion on whether draft-ietf-syslog-transport-tls > should use byte-counting, special character, or > both, including > which special character. > > Aug 14 - Begin WG Last Call for draft-ietf-syslog-protocol (45 pages) > Aug 14 - Begin WG Last Call for draft-ietf-syslog-transport-udp (10 > pages) > > Aug 18 - Decide what needs to be changed in > draft-ietf-syslog-transport-tls to represent the final WG > consensus on byte-counting, special character, or > both, including > which special character. > Aug 18 - Decide what needs to be changed in the general design of > draft-ietf-syslog-device-mib to represent the WG consensus. > > Aug 28 - Close WG Last Call for draft-ietf-syslog-protocol > Aug 28 - Close WG Last Call for draft-ietf-syslog-transport-udp > > Aug 28 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > > Sep 1 - updated revision of draft-ietf-syslog-transport-tls, > representing WG consensus. > Sep 1 - updated revision of draft-ietf-syslog-device-mib, representing > WG consensus. > > Aug 28 - Begin WG Last Call for draft-ietf-syslog-sign (33 pages) > Aug 28 - Begin WG Last Call for draft-ietf-syslog-transport-tls (11 >pages) > > > Sep 11 - Close WG Last Call for draft-ietf-syslog-sign. > Sep 11 - Close WG Last Call for draft-ietf-syslog-transport-tls. > > Sep 11 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-sign > > Sep 11 - Begin WG Last Call for draft-ietf-syslog-device-mib (33 >pages) > > Sep 25 - Close WG Last Call for draft-ietf-syslog-device-mib. > Sep 25 - Chairs start working on Shepherding documents for >- draft-ietf-syslog-device-mib > > Oct 16 - Chairs produce Shepherding Documents for > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-device-mib > - draft-ietf-syslog-sign > > Oct 23 - Final review of Spe
[Syslog] WGLC: protocol
is the addition of a new OPTIONAL PARAM-NAME to an existing SD-ID, what MAY be done." This strikes me as incorrect English grammar; I recommend rewording it. Here is some suggested text: "OPTIONAL PARAM-NAMEs MAY be added to an existing SD-ID." 7.2.1 Can it list an ip address in the "ip" parameter AND provide a list of multiple "ip" parameters in an "origin" element? If not, why not? Wouldn't it be useful to provide the "origin" list, but also to identify its "preferred" address for syslog purposes in "ip"? 7.2.3 "It always contains the name of the generating software," - should this one be MUST? "whereas APP-NAME can contain anything else, including an operator-configured value." Section 6.2.5 should mention that APP-NAME is an operator-configured value. If the software parameter contains UTF-8, then it is important to specify the maximum length of strings in octets rather than characters, since characters can be multi-byte. 7.2.4 If the swVersion parameter contains UTF-8, then it is important to specify the maximum length of strings in octets rather than characters, since characters can be multi-byte. -- spelling -- /parsable/parseable/g neither MS-Word nor Merriam-Webster recognizes either spelling. Wikipedia supports parseable under parsing. computing-dictionary.thefreedictionary.com supports parseable. Apparently the Oxford dictionary supports parseable, based on a discussion at apache.org, but I don't have a subscription to check it. /trucation/truncation /conceptionally/conceptually/ /mimimize/minimize/ /timezone/time zone/g according to MS-Word and Mirriam-Webster online /implementor/implementer/g for consistency with rfc-editor boilerplate text. /any-enterprise assigned/any enterprise-assigned/ enterpriseId or enterpriseID - inconsistent usage. 6.2.4 "described in RFC 3513" should this be ", as described in RFC 3513"? 7.2.2 "Only that number and any-enterprise assigned ID below it MUST be specified in the "enterpriseId" parameter." seems awkward. Would this be better as "An enterprise is only authorized to assign values within the iso.org.dod.internet.private.enterprise. subtree assigned by IANA to that enterprise. The enterpriseId MUST contain only a value from the iso.org.dod.internet.private.enterprise. subtree." 7.3.2 /integer/INTEGER/ Note that the semantics in RFC3418 are "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." This of course relates to the SNMP-related management portion of the system, which MAY be different than the syslog-related management portion of the system. -- security considerations Good job describing the potential configuration issues. Since the transport documents will describe the threat models, it is probably acceptable that the threat model is not covered here in the terminology recommended by rfc3552. -- IANA considerations -- Good. -- Authors -- We now have a [EMAIL PROTECTED] mailing list adddress. That should be used rather than the employees.org address. You should identify that I work for Huawei Technologies USA. -- Acknowledgment -- The funding acknowledgment for the RFC Editor function is out of date, but the latest xml2rfc tool corrects it to acknowledge the IASA rather than the Internet Society. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] RE: byte-counting vs special character
Hi Rainer, The IETF doesn't vote. The chairs will determine consensus on or after the Aug 18 deadline for this decision. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 16, 2006 8:08 PM > To: Carson Gaspar > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] RE: byte-counting vs special character > > Carson, > > Legacy code does not contain LF in messages. It is advised that > new-style syslog also does not contain control characters > (though it now > is allowed). > > Thus the argument is valid. Again, I do not object octet-couting (I > actually introduced the idea ;)) but find it the second best-solution. > Maybe we should do a simple poll - some have already voiced their > choices... > > Rainer > > > -Original Message- > > From: Carson Gaspar [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, August 16, 2006 1:33 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [Syslog] RE: byte-counting vs special character > > > > Escaping precludes no-configuration backwards compatibility, > > as no legacy > > syslog-over-tcp code does escaping. So if you want to > > interoperate with > > existing code, you must have a "don't escape or expect > > escapes" switch in > > your code. If you're going to do that, just have a "LF mode > > vs byte-count > > mode" switch. This whole backwards compat argument is bogus, > > iff we decide > > to escape embedded LF instead of forbidding it. And I have > yet to see > > anyone argue for LF on any grounds except backwards compatibility. > > > > -- > > Carson > > > > ___ > > 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 > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] byte-counting vs special character
Hi Tom, [speaking as a contributor] Rainer asserted that using LF would not break existing implementations. It does not appear to me that we have reached consensus that this assertion is true. I personally have concerns because this WG has already found that many syslog implementations are not compatible, especially on the point of having reserved/escaped control characters for special use. I asked if Rainer could provide any empirical support for his assertion, or whether his assertion was theoretical. I have not asserted that a message containing an octet count would work with existing implementations; only syslog implementations that were updated to support the not-yet-defined standard would use octet counting. Legacy messages without an octet-count would continue to be sent to the legacy syslog port, presumably one by one or delineated using whatever mechanism the legacy implementation currently supports. As I see it, a syslog/tls implementation would prepend an octet-count field to each syslog message, concatenate the messages into a stream, and send the concatenated messages to the new port. An implementation that supports the syslog/tls standard would strip off the prepending octet-count and extract each counted syslog message from the stream. Each extracted message could then be processed using the exact same parser code as would be used for messages received at the legacy syslog port. Using an octet-count encapsulation technique like this means the existing syslog message is not touched in any way, and the presence of an octet-counted stream delivered to a special port expecting the octet-counted stream, cannot interfere with any existing assumptions about the message format or content. Note that the syslog messages encapsulated by the octet-count might be able to be of any syslog format. The legacy parser implementation (whichever of the many incompatible variations) would not be changed. If the ability to carry different formats of syslog messages is desired, an additional field should probably be prepended to each syslog message in the stream that identified which syslog parser should be used to parse it. I am not a supporter of this approach because I would rather see implementations move to the syslog-protocol standard, but for those who value backwards compatibility above all else, this might be an interesting property. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: tom.petch [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 16, 2006 1:08 PM > To: David Harrington > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] byte-counting vs special character > > - Original Message - > From: "David Harrington" <[EMAIL PROTECTED]> > To: "'Rainer Gerhards'" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Tuesday, August 15, 2006 7:24 PM > Subject: [Syslog] byte-counting vs special character > > > > Hi Rainer, > >> > > [speaking as contributor] > > I like the argument that the LF solution will not break existing > > implementations, but I would like to know this is actually > true. Have > > you actually tested this against multiple implementations, > or is it a > > theoretical argument? > > > Turning the argument around, how many implementations have > you got and have > tested for interoperability that use byte counting for syslog? > > As Rainer's posts and earlier work as documented on his web > site show, there is > an awful lot of syslog out there, more pre-existing, interoperable > implementation than in any other activity of the IETF I have > been involved with. > For me, this overcomes any technical, architectural considerations of > 'betterness' and says we must go with our best understanding > of the existing > marketplace (I thought differently when I started:-( > > Other participants on this list may only represent a little > of the implemented > code but it is still an awful lot of pre-existing implementation. > > Tom Petch > > > > > I know you have tested a number of other proposed ways of > doing things > > against multiple implementations to try to verify backwards > > compatibility. Have you actually tested multiple existing > > implementations with the LF and found that they do continue to work > > without significant problems? Can you tell the WG which > ones you have > > tested? Are there implementations that break when using > this solution? > > > > > > dbh > > > >/syslog > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] MIB document decision
Hi, I agree the terminology in the MIB document differs from that in -protocol- and should be updated to match the WG consensus on terminology. Here are a few things I spotted that should be fixed or checked: The references in the MIB are to RFC3164, not the current -protocol- document produced by the WG. Since -protocol- will be a standard while RFC3164 is informational, we should reference the standard documents. (If it is useful to compare the RFC3164 attributes to the -protocol- attributes, I recommend a section that shows how they map/compare. There are DEFVAL default values; are these connsistent with the new document? Use existing textual-conventions (such as transportDomain) rather than SyslogTransport ? Is syslDevCCtlConfFileName implementation-neutral? MOs should be spelled out as managed objects. syslDevOpsLastError - could this contain sen sitive information, such as passwords or user names? Has the MIB been checked against RFC4181? MIB Doctors will expect a section entitled "Relationship to other MIB Modules". See ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-harrington-tex t-mib-doc-template-00.txt for further advice about what should be in the document. The documents that contain the IMPORTS must be cited in text outside the MIB module. The document does not pass the id-nits check by http://tools.ietf.org/tools/idnits/idnits.pyht It would be good to make this RFC4181-compliant and idnits-compliant before we start the WGLC. The document should also be compared to the functionality described in -protocol-, -udp-, and -tls- documents to make sure the defaults are consistent, and the management functionality adequate. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Legitimate \n or byte-counting
Hi, [speaking as co-chair] I believe it is inaccurate to say there has been a WG decision to maximize backwards compatibility. The charter says "The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard." There is a big difference between "maximizing for backwards compatibility" and "considering the ease of migration between and the co-existence of existing versions and the standard." This difference was discussed during the charter discussions. We need to balance backwards compatibility with improved interoperability and good technical design. We need to focus on **forward** compatibility - defining a standard that implementors can move forward toward so there is increased commonality, vendor neutrality, and interoperability. If we keep trying for backwards compatibility to a wide range of incompatible implementations, then we might as well go home now. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG > -Original Message- > From: Carson Gaspar [mailto:[EMAIL PROTECTED] > Sent: Friday, August 18, 2006 4:19 PM > To: [EMAIL PROTECTED] > Subject: Re: [Syslog] Legitimate \n or byte-counting > > --On Friday, August 18, 2006 7:35 AM -0700 Chris Lonvick > <[EMAIL PROTECTED]> wrote: > > > If we use LF-escaping in syslog messages, what's going to > happen if a > > legitimate "\n" is sent by a sender? An example would be: > > > > ... BOM The offending characters are \n > > > > Will a receiver convert that into LF? If that's the case > then we should > > not be using LF-escaping. > > I raised the same issue. The answer is the receiver will examine the > protocol version and will not un-escape unless the sender is > a new-style > sender. I'm still not convinced that the installed base of TCP syslog > deployments is large enough to care about, but, given the decision to > maximize backwards comparability, this is "good enough" to make > implementation possible. > > -- > Carson > > ___ > 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
[Syslog] Consensus: octet-counting
Hi, [speaking as co-chair] Chris and I have reviewed the discussions and have reached the conclusion that the WG consensus is to use octet-counting rather a special character for delineating messages in a TLS transport. Miao and Yuzhi, please update the syslog-tls draft accordingly. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
FW: [Syslog] Working Group Last Call: protocol and udp documents
Hi, I haven't seen many reviews for the WGLC. Come on people, we're trying to finally get this work finished. Please put away your apathy and do some reviews. Dbh co-chair, Syslog WG -Original Message----- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 15, 2006 2:42 PM To: [EMAIL PROTECTED] Subject: [Syslog] Working Group Last Call: protocol and udp documents Hi, I am resending this message with a new subject line, in case anybody is watching for the words "working group last call" in the subject line. It's also easier for me for bookkeeping reasons ;-) David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG -Original Message----- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 7:33 PM To: 'Chris Lonvick'; [EMAIL PROTECTED] Subject: RE: [Syslog] syslog WG Timeline Hi, This message officially starts the Syslog Working Group Last Call for the following two documents: draft-ietf-syslog-protocol: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt draft-ietf-syslog-transport-udp: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 .txt The Working Group Last Call for these documents will end August 28. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, it if does not look acceptable please identify your ibjections, preferably with suggested text that would make it acceptable. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG > -Original Message- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Friday, August 11, 2006 3:17 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] syslog WG Timeline > > Hi Folks, > > David and I have agreed upon a timeline for the completion of our > milestones. Please review this. We will be asking for > people to provide > review comments on each of the documents while they are in > Working Group > Last Call (WGLC). If you know that you're going to be > unavailable (summer > vacation) for some of these WGLCs, please submit comments to the WG > beforehand, at least to let us know that you've read it. > > Thanks, > Chris and David > > > ===start=== > > Aug 11 - Drive discussion on whether draft-ietf-syslog-device-mib > represents WG consensus on what needs to be managed in > -protocol-, -udp-, -tls-, and -sign-. > Aug 11 - Drive discussion on whether draft-ietf-syslog-transport-tls > should use byte-counting, special character, or > both, including > which special character. > > Aug 14 - Begin WG Last Call for draft-ietf-syslog-protocol (45 pages) > Aug 14 - Begin WG Last Call for draft-ietf-syslog-transport-udp (10 > pages) > > Aug 18 - Decide what needs to be changed in > draft-ietf-syslog-transport-tls to represent the final WG > consensus on byte-counting, special character, or > both, including > which special character. > Aug 18 - Decide what needs to be changed in the general design of > draft-ietf-syslog-device-mib to represent the WG consensus. > > Aug 28 - Close WG Last Call for draft-ietf-syslog-protocol > Aug 28 - Close WG Last Call for draft-ietf-syslog-transport-udp > > Aug 28 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > > Sep 1 - updated revision of draft-ietf-syslog-transport-tls, > representing WG consensus. > Sep 1 - updated revision of draft-ietf-syslog-device-mib, representing > WG consensus. > > Aug 28 - Begin WG Last Call for draft-ietf-syslog-sign (33 pages) > Aug 28 - Begin WG Last Call for draft-ietf-syslog-transport-tls (11 >pages) > > > Sep 11 - Close WG Last Call for draft-ietf-syslog-sign. > Sep 11 - Close WG Last Call for draft-ietf-syslog-transport-tls. > > Sep 11 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-sign > > Sep 11 - Begin WG Last Call for draft-ietf-syslog-device-mib (33 >pages) > > Sep 25 - Close WG Last Call for draft-ietf-syslog-device-mib. > Sep 25 - Chairs start working on Shepherding documents for &g
[Syslog] Working Group Last Calls
Hi, The WGLC for -protocol-17 and -udp-07 documents will end later today. Please review and comment on these documents today. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Working Group Last Call: syslog-sign document
Hi, This message officially starts the Syslog Working Group Last Call for the following document: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt The Working Group Last Call for this document will end September 11. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, if it does not look acceptable please identify your objections, preferably with suggested text that would make it acceptable. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] WGLC: udp-07
parently refers to UDP. It woul dbe less ambiguous if each usage of "this ... Protocol" was replaced by "the UDP protocol" or "the syslog/udp transport mapping". "a well-known port 514" s/b "the well-known port 514" --- RFC2119 terminology --- Some of the keywrods are used in both lowercase and uppercase; I believe the preferred approach is to use uppercase consistently. Some authors use lowercase when th eterm is not used as an rfc2119 keyword, but uppercase when referring to an rfc2119 keyword. I recommend always using uppercase and avoiding the keywords when they are not meant to be used as an rfc2119 keyword to avoid ambiguity. The word "can" is used where MAY might be more appropriate. The document says that "this transport protocol" is required for interoperability. However, two transport protocols are referred to, and they are not necessarily interoperable. For a system that only supports IPv4, then the UDP/IPv4 protocol should be required for interoperability. For a system that only supports IPv6, then UDP/IPv6 should be supported for interoperability in an IPv6 environment. For a system that supports both IPv4 and IPv6, what is required - UDP/IPv4, UDP/IPv6, or both, for interoperability? If both, then by default, should operators have syslog messages sent over both (i.e. duplicate the messages) so they can be transmitted over IPv4 and IPv6 networks? In SNMPv3, we chose UDP/IPv4 as the required even if both IPv4 and IPv6 are available, and for IPv6-only devices, we require UDP/IPv6. --- general review --- "This limit stems from the maximum supported UDP payload of 65535 octets specified in the RFC 768 [1]." - I couldn't find such a limit specified in rfc768. In fact, rfc768 **assumes** this will run over the IP protocol. IP might define some limits that would lead to this syslog limit. If UDP had a limit, then saying UDP supported "payloads" of 65535 would probably be incorrect, since part of the 65535 limit would be used up by header fields, thus lessening the "payload" limit. "It is RECOMMENDED that application developers restrict message sizes" - shouldn't this be "It is RECOMMENDED that syslog senders restrict message sizes"? The receivers are also applications and we don't really want the receivers to restrict message sizes. I am a bit concerned that we are violating layer separation when we get too specific about the structure and checksums of the transport protocol; lower-layer details like checksums should not necessarily be made accessible to the syslog protocol, which operates at a higher layer. We should trust theunderlying transport to do its job correctly, and operators to configure their devices correctly, so requiring syslog receivers to examine the UDP checksums seems wrong. In section 4.1, we go even further - "This protocol specifies use of UDPchecksums to enable corruption detection in addition to checksums used in IP and Layer 2 protocols." We have no business looking at layer 3 and layer 2 checksums. If a checksum is neede to validate the syslog mesdsage, then we should have a syslog checksum. Doesn't the last sentence of 5.1 mean basically the same thing as what is discussed in 5.2? Section 5.6 says "they will not get a higher priority". The standard will not mandate prioritization because that is an implementation decision and would not affect interoperability on-the-wire, but a sending implementation might provide such prioritization, so the document should not say they will not get a higher priority. It might even be a good idea to suggest that implementers of sending applications and relays consider support for prioritization based on the label. Section 5.7 discusses DoS attacks. Should the MIB include the ability to restrict the nuber of messages sent per minute? David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] WGLC: protocol, part 2
nformational document. So sentences like "RFC 3164 specifies relay behavior" should be changed to "RFC 3164 describes observed relay behavior." "RFC 3164 mandates UDP as transport protocol for syslog." should be changed to "Most existing implementations support UDP as the transport protocol for syslog. This specification REQUIRES UDP support in compliant implementations, and allows additional transport protocols to be used." Section A.2 "To further strengthen this point, it has also been observed that some UDP implementations generally do not support message sizes of more then 480 octets." Is this accurate? Is it the UDP implementations that do not support more than 480 bytes, or is it the syslog/udp implementations? I am not sure I agree that the IPv6 MTU must be noted in this document. It is more approrpiately mentioned in a transport mapping that addresses transport over IPv6. I prefer to eliminate it here. A.6 and A.8 are related; it would be good to have them next to each other. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Working Group Last Call: syslog-tls document
Hi, This message officially starts the Syslog Working Group Last Call for the following document: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 .txt The Working Group Last Call for this document will end September 12. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, if it does not look acceptable please identify your objections, preferably with suggested text that would make it acceptable. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG ___ 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
[Syslog] WG timeline update - again
Hi, In the original timeline, we planned to start the WGLC for syslog-tls on Aug 28, but we didn't have an updated document to work with. Now a revision has been published, so we'll start the WGLC now. Here is another update to the timeline Aug 28 Close WGLC on protocol and udp Aug 28 start WGLC on syslog-sign Aug 29 tls drafts published with requested changes (before WGLC) Aug 29 start WGLC on syslog-tls Sep 1 mib draftspublished with requested changes (before WGLC) Sep 4 start WGLC on mib draft Sep 11 Close WGLC on syslog-sign Sep 11 revisions of protocol and udp drafts (after WGLC) Sep 12 Close WGLC on syslog-tls document Sep 18 Close WGLC for mib Sep 25 revisions of sign, tls, mib Sep 25 start final WGLC on all modified documents if needed. Oct 9end final WGLCs Oct 20 submit all final-WGLC-modified drafts to internet-drafts Oct 23 publication cut-off preceding IETF67 Nov 1submit documents to the IESG. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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
[Syslog] WGLC closeed for protocol and udp
Hi, The WGLC was scheduled to end yesterday. We allowed the complete day to get responses in. The WGLC is now closed for draft-ietf-syslog-protocol: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt draft-ietf-syslog-transport-udp: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 .txt The editors are requested to modify the documents and post new revisions. If the editors have any questions, they should initiate a discussion on the mailing list. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] WGLC: sysog-sign, part 1
T NOT", "REQUIRED", "SHALL", "SHALL NOT", ^ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that appear in this document are to be interpreted as described in RFC 2119 [13].") (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). Experimental warnings: - Unused Reference: '3' is defined on line , but not referenced '[3] American National Standards Institute, "USA Code for Informat...' - Unused Reference: '4' is defined on line 1114, but not referenced '[4] Menezes, A., van Oorschot, P., and S. Vanstone, ""Handbook of...' - Unused Reference: '6' is defined on line 1120, but not referenced '[6] Mockapetris, P., "Domain names - concepts and facilities", ST...' - Unused Reference: '7' is defined on line 1123, but not referenced '[7] Mockapetris, P., "Domain names - implementation and specifica...' - Unused Reference: '9' is defined on line 1129, but not referenced '[9] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996...' - Unused Reference: '10' is defined on line 1131, but not referenced '[10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Exte...' - Unused Reference: '11' is defined on line 1135, but not referenced '[11] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with Rep...' - Unused Reference: '12' is defined on line 1138, but not referenced '[12] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashi...' - Unused Reference: '14' is defined on line 1144, but not referenced '[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", R...' - Unused Reference: '15' is defined on line 1147, but not referenced '[15] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifi...' - Unused Reference: '16' is defined on line 1150, but not referenced '[16] Hinden, R. and S. Deering, "IP Version 6 Addressing Architect...' - Unused Reference: '22' is defined on line 1169, but not referenced '[22] Klyne, G. and C. Newman, "Date and Time on the Internet: Time...' - Unused Reference: '25' is defined on line 1179, but not referenced '[25] Schneier, B., "Applied Cryptography Second Edition: protocols...' spelling "Predistributed" is not an English word. This could be difficult for those who rely on translators. "distributed" should be adequate for the usage. Otherwise, please use "pre-distributed" "SD ELEMENTS(SDEs)" add a space after ELEMENTS For consistency among all our documents, please use implementers rather than implementors. Correspondsss /permissable/permissible/ Can you spell out the meaning of O(N lg N) at its first usage? "collusionist" does not appear to be an English word. Would "attacker" do? In section 9.3 "Section Section" Abstract: /"The syslog Protocol", however it may be used atop any message delivery mechanism, even that/"The syslog Protocol" However it may be used atop any message delivery mechanism, including that/ and change the following "or" to "and" Introduction: /the type of key material which may be/the type of key material, which may be/ -- added a comma /In the cases of certificates being sent, the certificates may have/Ceetificates may have/ /actual transport protocol/transport protocol/ /defined in the informational RFC 3164/described in the informational RFC 3164/ There are lots of "it" references in the document, and in many cases it would be better if it was spelled out to be unambiguous. "The MSG part of the syslog message as defined in RFC [23] will simply be empty - it is not intended for interpretation by humans" What isn't intended for human consumption, the MSG? this specification? The signature block? Syslog-sign messages? /Having said that, as stated above,// /independent of the SD-ID definitions and/independent of the SD-ID definitions, and/ /The SD-ID must have the value of "ssign"./The SD-ID MUST have the value of "ssign"./ --- general review snmpEngineBoots has a range of 1..2147483647 and records the reboot of the SNMP engine. The Reboot Session ID has a range of 1..99 and records the reboot of the device. "is rendered useless." - does this mean an attacker culd deliberately create a denial fo service so that they could then attack the system with less chance of detection? I found section 3 a bit har
[Syslog] RE: I-D submission draft-ietf-syslog-device-mib-09.txt
Hi Glenn, I have not yet seen revision -09- announced, and it is not yet available from the I-D repository. Can you check on the progress of this please? I seem to have some problems getting email to you using the [EMAIL PROTECTED]; if there is another address I can use to contact you, please send it to me privately. An idnits-tool review of the copy of the -09- document you posted to the group complains of pages being too long. My copy of the -09- shows lots of white space between the footer and the next page header; are you adding extra lines by mistake, causing the pages to be too long? http://tools.ietf.org/tools/idnits/idnits.pyht also complains that the document is missing a Security Considerations section, which it obviously does have, so a bug must have been introduced into the idnits tool recently. dbh > -Original Message- > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 05, 2006 11:16 AM > To: Internet Draft Submission Manager; Chris Lonvick; > [EMAIL PROTECTED] > Subject: I-D submission draft-ietf-syslog-device-mib-09.txt > > Hi, > Attached, please find the revised I-D > draft-ietf-syslog-device-mib-09.txt. > Please post this document to the archives. > > Thanks and cheers > > Glenn > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] WGLC and document advancement
Hi, There are good things and bad things that come with having a new WG co-chair. I think I have helped the WG by driving the completion of milestones. That's the good part. The bad part is I bring my own opinions of what adequate review means. The IETF has started using a new process, called document shepherding, for the advancement of documents to the standards-track. The chairs are given much more responsibility and authority to decide whether documents are ready for advancement. They are expected to write up their analyses of WG issues, consensus, and degree of review of the documents being submitted, and these analyses will be reviewed at every step of the process after this point, as the members of the IESG try to determine whether the document really is ready for advancment to standards-track. You can see the details they expect us to provide by reading draft-ietf-proto-wgchair-doc-shepherding-07 (which has been expanded quite a bit from the -05- draft used during your earlier WGLCs). I have shepherded a number of documents through the process, and I know how difficult it can be to get documents through the process, and how much the documents can be delayed during the standards-approval process if they are not really ready for submission to that process. I am concerned that the documents have not gotten adequate review during WGLC. There have been very few comments made, and I would like to see more reviews done by the members of the WG for each of these documents. If you have problems with the documents, speak up now, so the chairs can be sure your concerns are recognized and have been addressed. If you have read the document, and found no important problems and have no significant objections to the document, and belive it is ready to be submitted to the advancement process, please send a note to the WG saying so. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] WGLC and document advancement
Hi, I realize the WG is tired of reviewing these documents. But the documents have been changed since the last WGLC, and it is the responsibility of the WG to review the documents for THIS WGLC. I wasn't co-chair at the time of the last WGLC. The last WGLC occurred more than a year ago. The documents have changed since protocol-14 and udp-05. I personally do not have copies of protocol-14 and udp-05 to do the diffs for you. Since that time, we have had a new charter, and debated issues such as: max message size, structured data, NUL octets, binary data, octet counts, field order, character encoding, MSGID, PROCID, APP-NAME, and VERSION in the header the standardization of message drops truncation I do not believe reviewing just the diffs will be adequate given the number and scope of changes. So, WG members should do a complete review again, as boring as such reviews will be. Hopefully, this WILL be the last one. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG > -Original Message- > From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] > Sent: Friday, September 08, 2006 2:39 PM > To: David Harrington; [EMAIL PROTECTED] > Subject: RE: [Syslog] WGLC and document advancement > > David: > > Part of it is that we reviewed a lot of the syslog-protocol before the > last WGLC, and it did not change much since. I think we just added the > header, right? > > So, I have not given this version a close review because I > reviewed much > of the same content for 2 years up to the last WGLC. > > If there were significant other changes since the last WGLC, > I'd like to > know. If there were a lot of minor changes, I'd appreciate a document > with tracked changes since last WGLC. Word Compare feature may help > with that. > > Thanks, > Anton. > > > -Original Message- > > From: David Harrington [mailto:[EMAIL PROTECTED] > > Sent: Friday, September 08, 2006 1:23 PM > > To: [EMAIL PROTECTED] > > Subject: [Syslog] WGLC and document advancement > > > > Hi, > > > > There are good things and bad things that come with having a > > new WG co-chair. > > I think I have helped the WG by driving the completion of > milestones. > > That's the good part. > > The bad part is I bring my own opinions of what adequate > review means. > > > > The IETF has started using a new process, called document > > shepherding, for the advancement of documents to the > > standards-track. The chairs are given much more > > responsibility and authority to decide whether documents are > > ready for advancement. They are expected to write up their > > analyses of WG issues, consensus, and degree of review of the > > documents being submitted, and these analyses will be > > reviewed at every step of the process after this point, as > > the members of the IESG try to determine whether the document > > really is ready for advancment to standards-track. You can > > see the details they expect us to provide by reading > > draft-ietf-proto-wgchair-doc-shepherding-07 (which has been > > expanded quite a bit from the -05- draft used during your > > earlier WGLCs). > > > > I have shepherded a number of documents through the process, > > and I know how difficult it can be to get documents through > > the process, and how much the documents can be delayed during > > the standards-approval process if they are not really ready > > for submission to that process. > > > > I am concerned that the documents have not gotten adequate > > review during WGLC. There have been very few comments made, > > and I would like to see more reviews done by the members of > > the WG for each of these documents. > > > > If you have problems with the documents, speak up now, so the > > chairs can be sure your concerns are recognized and have been > > addressed. > > > > If you have read the document, and found no important > > problems and have no significant objections to the document, > > and belive it is ready to be submitted to the advancement > > process, please send a note to the WG saying so. > > > > David Harrington > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > > > ___ > > 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
RE: version field in syslog-tls - was: RE: [Syslog] WorkingGroupLastCall: syslog-tls document
Hi Tom, Welcome back. I agree that section 5.3.2 should describe the behavior of the receiver if a message with a protocol version that is not supported is received, and it should recognize that future version #s are possible in this position. Could you suggest text for this? Can you identify which applications find it useful to have a string at the front, and what was found useful about it? Would the string be required, and the text be standard? I would be interested in seeing others' comments on this suggestion. Personally, I think using an assigned port serves the purpose of differentiating syslog from syslog/tls for receiving applications and for applications such as firewalls; use of a reserved port number alleviates the need for the string and is consistent with other Internet standards. Other protocols retrofitted to run over secure protocols have been assigned separate ports to differentiate the secure and non-secure versions of the protocol. Presumably there have been good justifications for the IESG to approve such port assignments. BCP 72, RFC 3552 section 4.5.2 supports the practice. I will note that so many applications are retrofitting to TLS that maybe IANA should consider port assignment ranges for udp, tcp, and tls/ssl ;-) David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: tom.petch [mailto:[EMAIL PROTECTED] > Sent: Monday, September 18, 2006 3:23 AM > To: Miao Fuyou; 'Balazs Scheidler'; 'Chris Lonvick' > Cc: [EMAIL PROTECTED] > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > WorkingGroupLastCall: syslog-tls document > > Apologies for my absence last week. Comments below > > Tom Petch > - Original Message - > From: "Miao Fuyou" <[EMAIL PROTECTED]> > To: "'tom.petch'" <[EMAIL PROTECTED]>; "'Balazs Scheidler'" > <[EMAIL PROTECTED]>; "'Chris Lonvick'" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Thursday, September 07, 2006 11:17 AM > Subject: RE: version field in syslog-tls - was: RE: [Syslog] Working > GroupLastCall: syslog-tls document > > > > > > Starting from TCP and then upgrading to tls is quite > different to current > > tls transport mapping document. If we decide to do > UPGRADING, we may first > > need a TCP transport mapping for Syslog, and then define a > specific string > > to indicate the other side to upgrade to TLS. > > I am NOT suggesting that we have a TCP transport which can be switched > dynamically to be or not be TLS; that was not my intended > meaning of the words I > used.. > > Rather I was saying that other applications, forget how they > got there, found it > useful to have a string at the front stating their > intentions, eg to use TLS. > Of course, no matter how simple, like a single digit for a > version number, this > is in some sense an application protocol. What does the > recipient do if it > agrees, what if it disagrees? Terminating the connection may > cause the > transmitter to try again and then what? All soluble problems. > > I also think that hard coding this 'information' into a well > known port is > wrong. Ports may or may not be in short supply but the > management associated > with them by anyone with firewall or gateway, ie many if not > most enterprises. > is a pain so I am very much of the view to keep the number of > ports few in > number, and reuse them by changing the initial string. > > > > > > > We currently assume Syslog has > > a IANA allocated port for tls transport mapping, we may not > need such > > complexity on upgrading. > > > > FYI, HTTP has two tls mechansims: RFC2818(standards track) > is similiar to > > this draft, RFC2817(Informational) is on upgrading. > > > > > -Original Message- > > > From: tom.petch [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, September 06, 2006 2:51 AM > > > To: Balazs Scheidler; Chris Lonvick > > > Cc: [EMAIL PROTECTED] > > > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > > > Working GroupLastCall: syslog-tls document > > > > > > - Original Message - > > > From: "Balazs Scheidler" <[EMAIL PROTECTED]> > > > To: "Chris Lonvick" <[EMAIL PROTECTED]> > > > Cc: <[EMAIL PROTECTED]> > > > Sent: Tuesday, September 05, 2006 9:18 AM > > > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > > > Working GroupLast > > > Call: syslog-tls document > > > &
RE: [Syslog] WGLC and document advancement
Hi Rainer, Welcome back. I hope the vacation with family was relaxing and fun. I understand your frustration. Let me be clear however, that requiring reviews during WGLC is certainly not a new requirement; reviews during WGLC have ALWAYS been a requirement of work being submitted to the IESG for advancement. Working group chairs got lax for a while, and submitted documents that were obviously not ready for advancement. The IESG now requires better reviews by the WG before accepting documents for advancement. If the WG provides the reviews, I believe we stand a very good chance of finally getting these through the process to RFCs. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Monday, September 18, 2006 3:10 AM > To: David Harrington; [EMAIL PROTECTED] > Subject: RE: [Syslog] WGLC and document advancement > > WG, > > still no WGLC comments or any further responses... > > Let me share my deep frustration with you. I have cautioned > against low > participation levels last year when the question was if the > WG should be > concluded or continue to work. Then, the overall opinion was > that there > were sufficient interest in the topic. With that on my mind, I put > another round of effort into syslog-protocol. I am now working on this > for several years. I spent considerable work on it. Each time when it > looked close to finish, either some radical new thoughts came > in (which > is fine), an old issue was re-itereated (which I do not consider to be > OK) or some other unexpected show-stopper showed up. This time, it is > the insufficient review. I am thoroughly disappointed and now need to > think that all the time I put into this effort is wasted. > This is quite > regrettable. > > However, I do not intend to spent any more time on it without the > *solid* indication that the work can be completed and published. As > such, I will NOT make any further edits at this time and I will also > hold my planned review of other WG documents. I will also refrain from > commenting on any technical issues. Probably the best option at this > stage would be to recommend to the IESG to finally conclude the WG. > > Thanks, > Rainer > > > -Original Message- > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > Sent: Saturday, September 09, 2006 2:34 AM > > To: David Harrington; [EMAIL PROTECTED] > > Subject: RE: [Syslog] WGLC and document advancement > > > > David, > > > > Thanks for the reminder. > > > > I have read -transport-tls several times, only been unable to have a > > close look at the latest increment. To my understanding, > > there were only > > minor changes to the document, so I am still happy with it. > > > > I am concerned about the lack of feedback to my response to your > > concerns on the "enc" SD-ID and transparency of MSG and > > STRUCTURED-DATA > > in -protocol. I am hesitant to do any edits until there has been any > > final discussion of these issues (reminder: I am most > probably able to > > edit starting September, 18th). > > > > I have roughly reviewed -transport-tls (due to my time > > constraints). All > > in all, it looks good enough to me. My main concerns have > already been > > addressed by adding the version number. I think, however, this point > > needs some more discussion. > > > > There are many other points in -tls that could be discussed. > > HOWEVER, I > > think discussing any of them now would make us miss our > > milestone. What > > is there is well enough. It could be better. Let's do that at later > > stage (version field permits this). > > > > We have been discussing syslog-protocol and -tls (and the > work leading > > to it) for 3 or 4 years now, often going in circles. Participation > > levels have varied greatly. My personal opinion is that > many folks are > > finally bored with going ever and ever over the same > arguments. But I > > may be wrong. Getting some work done would definitely help us. > > > > We should not aim for the perfect. In an ideal world, we > > would have only > > ideal solutions. But we do not life in an ideal world. If NASA feels > > strong enough to launch a shuttle with an imperfect fuel > > cell, we should > > probably feel strong enough in putting some non-ideal but obviously > > useful work to completion. So please comment on the drafts and open > > issues. > > > > Rainer > > > -Original Message- > > > From: David
[Syslog] WGLC closed for tls, sign, mib
Hi, This message officially closes the WG Last Calls for http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 .txt, started 8/29/2006 http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt, started 8/28/2006 http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx t, started 9/11/2006 The WG Last Calls for these documents had already been closed. http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 .txt The chairs will collect and review the comments, and work with the editors to ensure the comments are addressed appropriately, prepare a report for the working group, have new documents published, and prepare the documents for submission to the IESG for approval. Thank you for your hard work. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] WGLC results
Hi, Will the editors of the WGLC'd documents please collect the comments made for each of your documents into a single document, preferably text, and indicate what was done in the document to address the issue raised. Send the summary document to the chairs, with a copy of your current in-process document containing the fixes thus far, so the chairs can review your fixes. Once we have reviewed the fixes, we may ask for some changes. Then we will have you publish a new I-D, which we will send to the WG. It would be good to separate the issues document into three sections: 1) purely editorial issues (spelling, grammar, etc.) 2) Closed issues Technical issues where consensus was obvious. For each issue, please describe who raised the issue, and how the document was changed to address the issue. The chairs will review the changes to make sure they represent what the chairs consider to be WG consensus. 3) Open issues Technical issues where the resolution is unclear. Please identify who raised the issue. If you have a proposed fix, please describe it. The chairs will review the issues and determine whether it is an issue that needs resolution, whether your proposal is acceptable and in keeping with WG consensus, or whether it needs to be discussed further by the WG. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] WG timeline
Hi, The two co-chairs have really dropped the ball on meeting the WG scheduled dates. We need to review the comments and request revisions changes. We apparently will not get that done in time for editors to publish by the deadline. So this is the new schedule. Sep 29 Close all WGLCs - done Oct 16-Nov12 Chairs review comments and determine what changes are needed. (Hopefully, we'll get this done much sooner than these dates) Nov 13 publish revisions of sign, tls, mib, protocol, udp if needed Nov 13 start final WGLC on all modified documents if needed. Nov 27 end final WGLCs Nov 27 submit all final-WGLC-modified drafts to internet-drafts Nov 30 submit documents to the IESG. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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
[Syslog] Dbh Review of -mib-09, part 1
allowed specifications" defined? We don't want a value that can be interpreted differently by different entities, because then the values canot be compared across systems, or have consistent baselines for comparison across products, etc. Objects shoud be defined to be interoperable and unambiguous. 24) syslEntOpsLastMsgDeliveredTime - the system does not know when the message was delivered, only when it was transmitted or received. 25) syslEntOpsLastError talks about "this process". Is this the syslog entity? This needs to be clear and unambiguous, and consistent with the terminology in the other WG documents. 26) syslEntOpsLastError talks about the last error this process "encountered". The definition of encountered needs to be made unclear and unambiguous. 27) what is the persistence of the syslEntOpsReference across reboots of the OS? Across reboots of the SNMP system? If it is not persistent, but the table is, what should the SNMP agent do - delete the references? Change the references to match the new SWRunIndex? David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Mib-09- review, part 2
Continued ... 1) syslEntCtlTable should describe what type of information is stored in the table, and the description should be more than "static info". 2) syslEntCtlEnty - what type of parameters? What process? 3) syslEntCtlBindAddress - does this field contain an address or a hostname? What does the seond sentence mean? 4) syslEntCtlTransport - why is this "default" transport instead of just transport? 5) is there a mismatch between transportaddresstype and syslEntCtlService? Is there a transportAddressType for this type of "address"? 6) syslEntCtlConfFileName - using lots of abbreviations in the name makes it hard for people to remember how the words were abbreviated. It would be better to use something like syslogEntCtlFilename. Why do we need Ent in the name? we never deal with anything other than entities, do we? syslogControlFile would be much easier to remember than syslEntCtlConfFileName. 7) syslEntCtlConfFileName refers to syslogCtlSelectionTable and syslogCtlActionTable - where are these defined? 8) syslEntCtlStatus - again, what process? 9) syslEntCtlStorageType - is this definition exactly the same as the StorageType T-C? 10) ...RowStatus - spelling "iff" 11) syslEntStarted and syslEntStopped - spell out MO. I don't understand the second sentence; how does the manager know what syslEntOpsIndex is used? 12) It would be much better to use consistent naming between the objects/tables and the conformance clauses. The table refers to syslEnt, but conformance is for syslogDev; the objects are syslogDefault but the conformance is syslogSystem. Let'e make it easy to work with by being more consistent. 13) why are notifications not mandatory for compliance? 14) The MIB module exposes some info from syslog, such as last error. The security considerations talk about securing snmp, but that does not make sense if you do not also secure the syslog transport. The security considerations should recommend securing syslog to match the snmp security. 15) iana considerations talks about a base arc; this would be better reworded. 16) I thik rfc3164 is informative, no tnormative. 17) I suspect you are not usinng xml2rfc. If not, you need to make sure all the boilerplates are up-to-date. Please check the funding statement and the intellectual property clauses. 18) the change log is most effective if you track the chnages from published version to published version, not by MIB revision dates. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] -mib-, part 3
Hi, The transport area directors have been requiring protocol specs to describe how to avoid congestion. This is especially problematic when we use UDP. I suggest adding a writable variable to the MIB module to enable rate limiting (messages per second) at the sender. This might be a transport-specific setting (since some transports already have congestion avoidance), or a system-wide setting. I think the WG should discuss how they want to handle this. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] WGLC: syslog-sign
Hi Alex, I have quickly checked sign-19. It appears to me that you did not resolve many of the editorial problems identified in the Liaison from the OIF posted by Chris on 9-13. The review can be found at https://datatracker.ietf.org/public/liaisons.cgi Please review their comments and address them as appropriate. Most are simple editorial fixes. If there are any questions, then please contact the chairs. I also note that -19 does not remove the unused references. You can get the list by running the document through the validator at http://tools.ietf.org/tools/idnits/idnits.pyht Since -19 was published we also had a discussion of APP-NAME, et al. so that needs to be addressed in -20. And there are a few editorial fixes I mentioned. Can you publish a sign-20 soon? There have been quite a few changes since -18-, so I think we'll need to do another WGLC. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Review of Mib-10, part 1
Hi Glenn, -10- looks better than -09-. Thanks for getting this out. I sent some comments, and I think some still need to be addressed. Have you finished addressing all Bert's comments? Here are a couple things I spotted in -10- 1) syslEntCtlEntry should be changed to match the other prefixes (syslogEntityControlEntry) 2) the same for syslEntOpsEntry, syslEntStarted, syslEntStopped, etc. 3) I recommend chaging "operations related information" to "operations information" 4) I recommend changing syslogSystemGroup to syslogDefaultGroup if that's the prefix you keep on all the "Default" variables. 5) I recommend changing syslDevOpsGroup to syslogEntityOpsGroup, and syslDevCtlGroup to syslogEntityControlGroup. Why do we need two groups? Can you implement Ops without the Control table, now that one augments the other? 6) /implememt/implement/ 7) Is it possible to support notifications only, since the notifications contain data from the tables not implemented? Where do the values come from? 8) did you run the document through the idnits checker at http://tools.ietf.org/tools/idnits/? It still reports this problem: The page length should not exceed 58 lines per page, but there was 38 longer pages, the longest (page 2) being 60 lines 9) did you run the MIB module through the smilint utility? Instructions can be found at http://www.ibr.cs.tu-bs.de/projects/libsmi/mailrobot.html?lang=de 10) Can you add "Intended status: Standards Track" to the header (see syslog-sign for an example). David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] All editors
Hi, Please make sure your documents contain "Intended Status: Standards Track" in the header. Note that if you use xml2rfc, this defaults to Informational, which can cause problems when it gets to the RFC editor. You need to fix the attribute or the category field in XXE. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Mib -10-, part 2
Hi Glenn, I want to remind you of some outstanding issues to resolve: >From tom petch, 8-16: "I still have trouble with the mib document, not for any mibby reason but simply because, as I commented on the previous version, it seems to be written in a different language to the other I-D and, insofar as I understand that language, seems to be describing a different set of concepts to the other documents." And 9-28: "I have looked at this I-D and appreciate the increased explanation at the beginning. It leaves me clearer, but still thinking that this document steers a different course to the other syslog ones, in its focus on a group of syslog entities. It's not that there cannot be more than one syslog entity running in a given host, just that bundling them together into a table seems an artificial complication; other syslog MIB modules I see are scalar in approach." I am less concerned about the table of entities versus modeling a single entity. Having this in a table makes it easier than forcing the use of contexts to get at multiple instances of the MIB module on a host, and is consistent with the hrSwRunTable of the Host Resources MIB. Unless the WG raises objections, I believe the table approach is acceptable. Consistent concepts and terminology is important. WG consensus is that all the documents should be consistent. The other document editors aligned their terminology, and you must do so for this document as well. It is especially important that terminology used in the management interface be consistent with the technology being managed. Please plan on submitting another official revision before Nov 12, with all outstanding change requests addressed, so we can finish another 2-week WGLC and still meet our November deadline. If you question some of the change requests, please consult the chairs and we will make a determination. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Updated IPR disclosure
Hi, The syslog WG co-chairs were notified that a request was being made to Huawei by a company experienced in IETF IPR disclosures, that Huawei modify their terms related to the TLS transport document. Huawei has chosen to change their terms as requested. The new terms can be seen at https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=763 The new disclosure is relevant to tls-03. We have requested Huawei to also post an update relevant to tls-04, which was just published. The changes apparently are meant to tighten the language a bit, and to make Huawei terms more consistent with those of other companies filing disclosures within the IETF. The co-chairs are not lawyers, and cannot provide legal advice about the changes. The WG needs to consider whether the modified terms are acceptable for this document to be advanced to the standards-track. Please send your comments to the co-chairs as soon as possible. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Updated Syslog-tls Document
> -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 23, 2006 2:48 AM > To: Miao Fuyou; [EMAIL PROTECTED] > Subject: RE: [Syslog] Updated Syslog-tls Document > > > - > > > 5.1 > > > > > > == > > >When confidentiality is a concern, a sender/relay MUST > > authenticate > > >the receiver to make sure it is talking to the right peer. > > > == > > > > > > I do not find the MUST is appropriate here: "when > > > confidentiality is a concern" is not a hard fact. What does > > > it mean? When MUST I implement authentication. Is my > > > Implementation not compliant to this doc if I have the wrong > > > understanding of "when confidentiality is a concern". Or MUST > > > I always implement it, because confidentiality is probably > > > very often a concern? > > > > > > I think this is a operator-issue not to be dealt with in the > > > protocol. I suggest dropping this sentence or at last spell > > > MUST in lower case. > > > > > > > Probably lower case. The point is confidentility is > > meaningless without > > authenticaion. > > Well... maybe it is just a wording issue. Are we actually REQUIREING a > sender to authenticate the receiver in all cases? If so, we > should state > that. My impression so far is that this is something that is optional > and at the discretion of the sender or the operator configuring it. If > so, we should state that clearly too. As an implementor, I am unsure > what to do if I use the above text as a guideline. > Standards do not typically require an operator to use the technology in a specific manner; Standards do typically require implementers to implement in a way so that operators CAN configure the technology in the preferred (interoperable) manner. MUST is used when the on-the-wire format/information/etc. must be interoperable for the protocol to work properly. I do not like seeing "must" in a document; either it deserves to be a MUST, i.e. it impacts on-the-wire interoperability, or it is an implementation/usage decision and we should not mandate it. If you use a lower case "must", then you'll need to convince me as co-chair that the usage is justifed before I send it to the IESG. Dbh ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Proposed schedule
Hi, Chris and I have discussed the last calls and the status of the documents. We believe the -protocol-, -udp-, and -tls- documents have received adequate review, and are (almost) ready for submission to the IESG. If the WG reaches consensus on the remaining issues, and revisions are published reflecting the consensus, then we plan to submit them for advancement by the end of this week. We believe there have been enough changes to the text of -sign- and -mib- to require an additional last call for these documents. There are a number of reviews that have been performed on these documents, and a number of issues discussed and resolved. Not all requested changes (that the chairs approve as consensus) are reflected in the latest official revisions. We are in discussions with the editors about getting the documents updated so we can take them to WGLC again. We expect -sign- will be republished within the next week or so, and then we will start a WGLC. Assuming no major problems develop, we hope to have a syslog-sign document submitted to the IESG by mid-December. The -mib- document had a number of significant changes, and a number of detailed changes requested, and the chairs have not finished reviewing the document changes versus the requested changes yet. Once we are satisfied the current list of comments has been addressed properly, we will ask Glen to publish a new revision and we will start a WGLC. If all goes well, we may have this done by mid-December, but we accept that it may take as long as late January to complete the document, run another WG last call (in non-holiday weeks), and make adjustments to be ready for submission to the IESG. Good work everybody, and thanks for staying involved to get these documents to completion. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] bcc: the area directors ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Shepherding document for udp-08
Hi, Yes, I/we should correct this. Do we have any information about vendors that have implemented the current UDP specification? dbh > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 22, 2006 6:29 AM > To: David Harrington; [EMAIL PROTECTED] > Subject: RE: [Syslog] Shepherding document for udp-08 > > David, > > there is one minor thing in the shepherding document I do not concur > with: > > -- > This document describes the traditional udp transport for syslog. > draft-ietf-syslog-protocol makes changes to the syntax of the syslog > fields but this is just the udp transport. It could be said that > all existing implementations of syslog use this specification. > -- > > There are some changes in -transport-udp compared to the traditional > transport. I think it is somewhat dangerous to draw the conclusion > drawn. > > But as I said - this is a minor comment and probably depend's on ones > point of view... > > Rainer > > > -Original Message- > > From: David Harrington [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 22, 2006 12:41 AM > > To: [EMAIL PROTECTED] > > Subject: [Syslog] Shepherding document for udp-08 > > > > Hi, > > > > I have reviewed a pre-publication copy of -08- and am satisifed it > > represents WG consensus and is of a quality sufficient for > advancement > > to Proposed Standard. > > > > Barring serious objection from the WG, revision -08- will > be submitted > > to the IESG for advancement, accompanied by the attached > shepherding > > document. > > > > David Harrington > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > co-chair, Syslog WG > > > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Updated Syslog-tls Document
That wording satisfies me. dbh > -Original Message- > From: Miao Fuyou [mailto:[EMAIL PROTECTED] > Sent: Monday, November 27, 2006 9:07 PM > To: 'David Harrington'; 'Rainer Gerhards'; [EMAIL PROTECTED] > Subject: RE: [Syslog] Updated Syslog-tls Document > > > I am changing the sentence to: > > "For the deployment where confidentiality is a concern, receiver > authentication is required for sender/relay to make sure it > is talking to > the right peer. It is up to the operator to decide whether > confidentiality > is a concern for a specific deployment. " > > This sentence serves as a tip for deployer rather than something about > on-the-wire protocol. > > Thanks, > Miao > > > -Original Message- > > From: David Harrington [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, November 28, 2006 8:27 AM > > To: 'Rainer Gerhards'; 'Miao Fuyou'; [EMAIL PROTECTED] > > Subject: RE: [Syslog] Updated Syslog-tls Document > > > > > > > > > -Original Message- > > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, November 23, 2006 2:48 AM > > > To: Miao Fuyou; [EMAIL PROTECTED] > > > Subject: RE: [Syslog] Updated Syslog-tls Document > > > > > - > > > > > 5.1 > > > > > > > > > > == > > > > >When confidentiality is a concern, a sender/relay MUST > > > > authenticate > > > > >the receiver to make sure it is talking to the right peer. > > > > > == > > > > > > > > > > I do not find the MUST is appropriate here: "when > > confidentiality > > > > > is a concern" is not a hard fact. What does it mean? > > When MUST I > > > > > implement authentication. Is my Implementation not > compliant to > > > > > this doc if I have the wrong understanding of "when > > > > > confidentiality is a concern". Or MUST I always implement it, > > > > > because confidentiality is probably very often a concern? > > > > > > > > > > I think this is a operator-issue not to be dealt with in the > > > > > protocol. I suggest dropping this sentence or at last > > spell MUST > > > > > in lower case. > > > > > > > > > > > > > Probably lower case. The point is confidentility is meaningless > > > > without authenticaion. > > > > > > Well... maybe it is just a wording issue. Are we actually > REQUIREING > > a > > > sender to authenticate the receiver in all cases? If so, > we should > > > state that. My impression so far is that this is something that is > > optional > > > and at the discretion of the sender or the operator > configuring it. > > If > > > so, we should state that clearly too. As an implementor, I > > am unsure > > > what to do if I use the above text as a guideline. > > > > > > > Standards do not typically require an operator to use the > > technology in a specific manner; Standards do typically > > require implementers to implement in a way so that operators > > CAN configure the technology in the preferred > (interoperable) manner. > > > > MUST is used when the on-the-wire format/information/etc. > > must be interoperable for the protocol to work properly. > > > > I do not like seeing "must" in a document; either it deserves > > to be a MUST, i.e. it impacts on-the-wire interoperability, > > or it is an implementation/usage decision and we should not > > mandate it. If you use a lower case "must", then you'll need > > to convince me as co-chair that the usage is justifed before > > I send it to the IESG. > > > > Dbh > > > > > > > > > > > > > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Udp shepreherding document.
Hi, Here is the revised shepherding document for -udp-08 I modified the section. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Shepherding document for syslog-transport-udp-08 (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/msg01242.html http://www1.ietf.org/mail-archive/web/syslog/current/msg01246.html In particular, since UDP lacks congestion control, we consulted TSVWG, and have followed the recommendations concerning provisioning to account for the syslog traffic. (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. We have sought reviews from a number of experts and are satisfied this document has received adequate expert review. (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. UDP is widely supported as a transport for syslog. (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. 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 is co-dependent upon draft-ietf-syslog-protocol. 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 the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered archi
[Syslog] Shepherding document for draft-ietf-syslog-transport-udp-08
Hi Sam, Please publish draft-ietf-syslog-transport-udp-08 as a Proposed Standard RFC. Attached is the shepherding document for draft-ietf-syslog-transport-udp-08, including the Document Announcement Write-Up and contact information. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG Shepherding document for draft-ietf-syslog-transport-udp-08 [Area] SECURITY [WG] syslog [I-D] draft-ietf-syslog-transport-udp-08.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt [Shep] David Harrington <[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? 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/msg01242.html http://www1.ietf.org/mail-archive/web/syslog/current/msg01246.html In particular, since UDP lacks congestion control, we consulted TSVWG, and have followed the recommendations concerning provisioning to account for the syslog traffic. (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. We have sought reviews from a number of experts and are satisfied this document has received adequate expert review. (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. UDP is widely supported as a transport for syslog. (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. 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 is co-dependent upon draft-ietf-syslog-protocol. 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
[Syslog] Shepherding document for -sign-
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 , "T
[Syslog] IESG approval process
Hi, It is important for the WG to understand the process that we are entering, and the sequence of events. Here is a rough description of the process (you can read the relevant RFCs and internet-drafts to get the exact process.) 1) we submit the documents to the AD/IESG. Change control now rests with the IESG; we are not permitted to modify the document except as requested by the AD/IESG. 2) The AD will review the documents to determine if they are ready for general IETF review and for IESG review. The AD has the responsibility of "selling it" to the rest of the IESG. 3) The AD/IESG may ask experts to review the documents, for such things as security, congestion control, MIB review, etc. 4) The AD/IESG will ask the general IETF to review the documents. This is called IETF Last Call. Any issues raised will be recorded, and the IESG, in cosultation with the chairs, will need to determine whether changes should be made to address the issues. In general, this filters out all the issues for which we have already reached consensus. The chairs (document shepherds) decide whether the requested changes require consultation with the WG. 5) Once any raised issues are addressed to the IESG's satisfaction, the IESG should approve the documents. 6) The documents go to the RFC editor to be published as RFCs. The rfc editor will make minor changes to correct spelling and grammar, change boilerplates to the RFC boilerplates (if they differ from internet-draft boilerplates), etc. 7) AUTH48 is the final review by authors to correct spelling and grammar and contact addresses, and to make sure the editing done by the rfc-editor does not change any semantics inadvertently. The WG does NOT get a chance to review these changes, so the changes should only be editorial in nature. Once the document is published as an RFC, it is never changed, so AUTH48 is that final sanity check before we cast it in stone. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] revisions going forward
Hi, So that you know how we will handle issues that are raised for duments that have been submitted to the AD. Once we submit the document it goes it into the ID tracker, and under IESG control. We are not allowed to revise the document unless instructed to do so by the area director. People will continue to find new small problems in the drafts that need correcting. This is going to happen. It is very common. Here is how we handle those issues. You can raise the issue on the WG list, or simply raise it with the chairs. The chairs will decide whether it is in scope. Spelling and grammar are in scope. Technical clarifications are in scope. New technical matter is generally out of scope, unless the protocol is broken without the fix (and the WG agrees). The chairs will need to be convinced a technical change is really required and not just an extension. Since editorial changes make it more difficult to see the requested changes, even editorial changes will be subject to chair/shepherd approval; if it isn't broken, we may decide to not fix it. We definitely do NOT want the editors to decide they could rewrite whole sections of text to be more elegant. We do not want changes at this point if we can help it. For editorial changes (spelling, grammar, contact info, etc.) the changes will be kept by the editors in a working draft, but not published. Remember, we are not allowed to publish revisions once it has been submitted, except by request of the AD. As new issues arise, we can address them in the working draft, but not publish. There will be a delay before the AD finishes his review and brings it to the rest of the IESG for review. At some point he will almost certainly ask us for a new document to address issues to that point, before he asks the rest of the IESG to perform their reviews. That is the point at which we can publish a revision. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Dbh re-Review of -mib-11, part 1
aming guidelines. Fixed. > > 19) syslEntCtlTable contains static info; does that imply that > syslEntOpsTable contains dynamci info? Or is syslEntOpsTable about the > operational environment, and syslEntCtlTable about control info? The > descritions should kae the purpose of the table unambiguous. Fixed. > > 20) In the SNMPv2 effort, we found that using integer indices made > using the tabels more difficut for human readers. It would be much > easier for a human to interpret the statistics here is it is easy to > tell what the systlog entity is. So I recommend using an > SnmpAdminString as the index. For systems that cannot, for whatever > reason, determine a human-readable identifier for the index, the > SnmpAdminString can always be "1", "2", etc. Not fixed. > > 21) what is the persistence of the index? If syslog entities happen to > start in a different order, will the index# refer to the same entity > after a reboot? If the MIB says they must be persistent across > reboots, how difficult will that be for the OS that starts the > applications? What value will the system keep to match up to the > integer indicies to make sure they remain the same? Partially fixed. Is it important for interoperability to be able to correlate messages from before a system reboot and after a system reboot? If so, what object can be used to do this correlation since integer index can change across reboots? I suspect the ControlDescr object might be able to be used, but the description for ControlDescr does not specify the persistence of that object. All objects in the syslogEntityControlTable should probably persist across reboots if you want the syslog entity to be configured the same way across reboots. You have a problem, however. You are using an integer index that does not persist across reboots. How does the SNMP agent correlate the persistent configuration parameters with the appropriate application index after a reboot? How does a remote manager read this table and understand which row of configuration and monitoring info (like statistics) refers to which application? > > 22) syslEntOpsMsgsDropped counts messages that could not be relayed. > What about messages that cannot be queued for transmission for an > original sender? Fixed. > > 23) syslEntOpsMsgsIgnored - where are the "allowed specifications" > defined? We don't want a value that can be interpreted differently by > different entities, because then the values canot be compared across > systems, or have consistent baselines for comparison across products, > etc. Objects shoud be defined to be interoperable and unambiguous. Partially fixed. This is still ambiguous, and could be interpreted in different ways by different implemnenters resulting in non-interoperability. This needs to be unambiguous as to what gets counted. This object counts things outside the "allowed specifications" - again I ask where are the allowed specfications defined so an implementer knows what they are? > > 24) syslEntOpsLastMsgDeliveredTime - the system does not know when the > message was delivered, only when it was transmitted or received. Fixed. > > 25) syslEntOpsLastError talks about "this process". Is this the syslog > entity? This needs to be clear and unambiguous, and consistent with > the terminology in the other WG documents. I'm confused. Is an entity an application, such as login, or is the entity the thing that sends syslog messages, such as a syslog daemon, that sends messages for multiple applications? Does the last error refer to the last error seen by the login process, or by the syslog sender process (e.g. daemon)? Since entity refers to all the different roles - senders, receivers, relays, and collectors, does that mean we are keeping "last error" info at the receiver as well as at the sender, and at the relays as well? > > 26) syslEntOpsLastError talks about the last error this process > "encountered". The definition of encountered needs to be made unclear > and unambiguous. Not fixed. What does "encountered" mean? Sent/received/relayed/collected? While we're at it, what exactly does error mean? How do I know when I am encountering an error? Can I encounter other things, like warnings? I see that Error is a type of severity. Is that what we ar ecounting? Do we also want to count criticals, and alerts, and emergencies, etc. Or is that not what you mean by "encounter an error". > > 27) what is the persistence of the syslEntOpsReference across reboots > of the OS? Across reboots of the SNMP system? If it is not persistent, > but the table is, what should the SNMP agent do - delete the > references? Change the references to match the new SWRunIndex? > > > David Harrington > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > > ___ > 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
[Syslog] Review of mib-11, part 3
Hi, 1) The idnits checker reports the use of the old copyright and disclaimer boilerplates rather than the new copyright and disclaimer boilerplates. These need to be updated. 2) syslogEntityOperationsReference uses a lower case "should". Is it nto important for interoperability that this be done? If so, then this should be a "SHOULD". If not for interoperability, why are we saying it "should" be done? 3) I still have difficulty understanding why default parameters are listed in the MIB module. What is the use case that requires these objects in the MIB module? Who decides what the default values should be? Since they are read-write objects, I assume the purpose is to allow an NMS to set the default values they want the sender to use. What happens if there are multiple NMSs talking to the same sender? Then who decides? If each NMS gets to decide, than you need a table in which each row is "owned" by a particular NMS. I still don't see why this would be needed however. If the sender decides, and the objects exist only so the receivers can check and see what the sender will use for defaults, then why are the objects read-write? Once an NMS checks the defaults, what are they supposed to do with this information? I question whether this deserves to be in the MIB module at all, but if it kept, then at least the MIB module should include a description of why it is there and how it should be used. 4) RFCPROT is a reference in syslogDefaultTransportDomain; it probably shoul dbe shown as [RFCPROT] or the RFC editor may overlook it. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Working Group Last Call: syslog-sign-20
Hi, This message officially starts the Syslog Working Group Last Call for the following document: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-20.txt The Working Group Last Call for this document will end December 28. The previous WGLC for this document was revision http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt It is recommended that reviewers especially consider the changes made between the two revisions, although the complete document should also be reviewed. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] WGLC sign-20 comments, part 1
Hi, I started doing a quick review of sign-20. There have been quite a few changes in the text, including some that will have impact on the technical specification, so if you haven't reviewed the latest revision, you probably should to make sure the new text is acceptable. 1) the document passes idnits 1.122 2) I have some concerns about the RFC2119 keyword usages. There are quite a few lowercase "must" and "may" and other RFC2119 keywords throughout the document. This can cause quite a lot of delay during advancement since every IESG member is likely to question whether they are required for interoperability and should be capitalized keywords. 3) /A device needs to hence support persisting previous reboot session ID across reboots./The reboot session ID must be persistent across reboots./ More later. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Syslog-mib-11
Hi, In my latest review of syslog-mib-11, I have started to believe that Tom was right when he questioned the MIB module design, which models multiple syslog entities in a table, so one SNMP engine deals with multiple syslog senders, relays, and/or recievers on the same host. This adds complexity in the MIB design that I am not convinced is necessary. As the terminology in the MIB document has gotten closer to other WG documents, this has become somewhat clearer to me. Tom recommended that the MIB module only model a single syslog entity. Different instantations of the MIB module can be represented as existing in different contexts (e.g. in different communities), so one SNMP engine can still deal with multiple syslog senders, relays, and/or receivers on the same host, but the MIB module itself becomes simpler. We should be sure the MIB module reflects real world requirements. I do not have much operational experience, so I need your input. In real deployments, is it **typical** to have multiple syslog stacks running on the same host, each with a different bind address and port number and config file? or is it more common for most applications to share one syslog process (e.g., daemon) that operates via one address/port? David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Notification compliance
Hi, Dbh> If the intention is to leave out the notification, I would like to know why this is desirable. Glenn> The reason is to retain the possibility of a compliant implementation that does not support notifications. This still does not explain why this is desirable. Who wants this feature? It may be desirable to implementers who have not chosen to implement notifications, so they can market their products as being IETF-compliant, but we are NOT here to help marketing departments claim compliance for their implementations by lowering the standards to match their implementations. The majority of snmp agents are based on either the commerical toolkit from SNMP research (or other commercial snmp toolkits), or the NET-SNMP (nee CMU-SNMP) toolkit. These already support notifications, and the objects carried in the notification are required for compliance, so I think it should be pretty simple to support the one notification. So I don't see a strong benefit for an implementer to not support the notification. I especially do not see the benefit of making this optional in the standard. Keep in mind that our job here is NOT to define a specification that allows as many incompatible implementations to claim compliance as possible. Our job here is to set some standards - a minimum level of support for a common set of features to provide multi-vendor and vendor-neutral interoperability. Having some implementations support notfications and others not support notifications negatively impacts interoperability. Non-interoperability is NOT a desirable feature. So I STRONGLY question the need for a compliance level to allow the lack of support for the notification. -- Let me approach the question from a different angle. Does the WG believe that this notification is so useless that most implementers will not implement it? Is this a nice-to-have but not really necessary feature in the standard? If so, then we should simply remove it from the standard. My personal opinion is that this would be a useful feature, and should not be optional. It should be part of the mandatory compliance, and an implementation without it should NOT be allowed to claim compliance to the standard. dbh > -Original Message- > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 13, 2006 6:45 AM > To: [EMAIL PROTECTED] > Subject: Re: [Syslog] Dbh re-Review of -mib-11, part 1,2,3 > > Hi, >I have pruned the list of comments and renumbered them. >The following starts the discussion on the points raised > in Dbh re-Review of -mib-11, part 2. > >Cheers > >Glenn > > +---+ > 2.1 > > 5) is there a mismatch between transportaddresstype and > > > syslEntCtlService? Is there a transportAddressType for this > > > type of > > > "address"? > Not fixed. > I think you are using an enumeration to identify the > format of the > value in the next object, and then using a format in the > next object > that does not match any of the enumerated choices. This > is obviously > wrong. > > Response: > That is not what we are doing. > > syslogEntityControlTransportDomain maps onto a transport domain. >e.g. transportDomainUdpIpv4 > syslogEntityControlService maps onto a port number >e.g. 512 > > Let me know if I got this wrong. > > > 2.2 > > 6) syslEntCtlConfFileName - using lots of abbreviations in > > > the name > > > makes it hard for people to remember how the words were > > > abbreviated. > > > It would be better to use something like > syslogEntCtlFilename. > > > Why do > > > we need Ent in the name? we never deal with anything > other than > > > entities, do we? syslogControlFile would be much easier to > > > remember > > > than syslEntCtlConfFileName. > Fixed (mostly). > > Response: > What is the remaining problem? > > 2.3 > > 9) syslEntCtlStorageType - is this definition exactly the > > >same as the > > > StorageType T-C? > I am not sure this is the same semantics as StorageType T-C. > Your text is somewhat unclear when it says "backed up by > non-volatile (permanent)" > > Response: > Will the following help: >syslogEntityControlStorageType OBJECT-TYPE >SYNTAX StorageType >MAX-ACCESS read-create >STATUS current >DESCRIPTION >"This object defines whether the parameters defined in > this row are kept in volatile storage and lost upon > reboot or are backed up by non-volatile or permanent > storage. > Conceptual rows having the value 'permanent' need not > allow write-access to any columnar objects in the row. >" > > That mimics the DESCRIPTION used in DISMAN-MIB e.g. >
[Syslog] severity
Hi, I don't think -protocol- spelled out the restriction clearly that severity could only be 0-7. The document states that the 0-7 severities listed were not normative. Now that Rainer pointed this out, I do realize that an implementer of the PRI calculation code might recognize that the PRI calculation implies such a restriction. But syslog is often implemented as a system of independently-implemented pieces (daemon vs application, for example), and not all of them will need to implement the PRI calculation code, so it may not be obvious (just as it was not obvious to Gleen who has been working with this WG for a long time). Before we publish the spec as an RFC, is the WG satisfied with this restriction of severity to 0-7, and is the WG satisfied that this is clear and unambiguous in our spec? If the WG believes the 0-7 restriction is unacceotable, we will need to pull the draft back from the IESG and make changes to PRI. If the WG accepts the 0-7, but thinks the draft is not clear and unambiguous, then we could provide clarifying text as part of WGLC without pulling the draft back from the IESG. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 14, 2006 9:26 AM > To: Glenn M. Keeni; [EMAIL PROTECTED] > Subject: RE: [Syslog] Dbh re-Review of -mib-11, part 1 > > So far, just one comment... > > > 1.6 > > 11) in SyslogSeverity, I recommend removing the > > second sentnece > > > > in the > > > > description "The syslog protocol uses the values 0 > > (emergency) > > > > to 7 (debug)." since this is already spelled out in > > the SYNTAX > > > > clause,andshows that 99 (other) is also used. Why do we > > > > need 99? Are other > > > > values valid? > > Partially fixed. When is "other" used? > > > > Response. > > "other" will be used to count messages that do not have > > severity in > > the range 0-7. The syslog protocol specs (-19.txt) does > > not disallow > > such messages. > > Actually, -syslog-protocol disallows this by the way the PRI value is > specified (this was different in previous versions of the I-D). In > short: PRI MOD 8 is severity. So if a severity greater than 7 would be > given, it would actually modify the facility. See 6.2.1: > > -- > The Priority value is calculated by first multiplying the Facility > number by 8 and then adding the numerical value of the Severity. > -- > > Rainer > > ___ > 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
[Syslog] Mib terminology and MIB design
Hi, [speaking as coc-ahir] We need WG input on this. Please look at mib-11 and decide whether "entity" is appropriate. Glenn has changed the terminology in many places to be more consistent than previous revisions. In the TLS document, Miao and Yuzhi tried to use a generic term for any role and WG consensus was to change the document to use the sender/receiever/relay/collector terminology. Does the same thing need to be done here? [co-chair end] [speaking as contributor (and MIB Doctor)] I have mixed feelings on this issue. I personally think not having a generic term makes it harder to write documents and design mib modules that can be applied to any of the roles. In SNMPv3, we deliberately moved away from different processing for different roles and toward a common "entity" that could act in different roles. When designing a MIB module to encompass multiple roles as one entity, it is very important to review the design from the perspective of each of the roles. For example, it may make sense to count messagesSent if you are implementing a sender or relay, but not if you are implementing a reciever or collector. It will be a poor MIB module design if it makes a great deal of sense for implementers to only implement some of the objects in a table that is mandatory-to-implement for compliance. Having objects that only make sense for certain roles and not others in one common table will encourage non-compliant implementations. On the other hand, defining the MIB module to contain four tables to model the sender configuration, and the receiver configuration, and the relay configuration, and the collector configuration, even though all four tables would contain identical information is simply ridiculous design. I do not like having one set of terminology in the protocol specifications, and a different set of terminology in the management interface, because it makes it harder for operators to interpret the data in the MIB module. The WG needs to review the MIB module design and determine what makes protocol sense. [contributor end] David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > +---+ > 1.1 > > 3) the terminology is not consistent with the > other WG documents. > Not fixed. Still a problem. The WG consensus was > to use sender, > receiver, relay, and collector. Other document were > required to change > to match this terminology. The MIB document uses entity, > which is a term not found in the protocol draft. > > I find this change in terminology makes it difficult > to interpret some objects in the mib module. > > Response: > We have a single MIB module for all the roles of a syslog > "entity" - sender, receiver, relay and collector. > I do not see any problem with this generic nature of the > MIB, as yet. > > Let me know about the specific objects that are difficult > to interpret. We may try the following: > Use the generic "syslog entity" when the discussion > applies to all the roles > Use the role(s) explicitly "syslog sender", "syslog > receiver", etc. when the discussion does not apply to > all the roles. > Add a statement to that effect in the early part of > the text. > > Any other suggestions? > > 1.2 > > 4) "roles a syslog entity maybe in" would be better > as "roles of a > > > syslog entity" (although then entity should be > changed according to > > > #3. > See #3. > Response: > See #1. > 1.3 > > 5) I concur with Bert that the citations in section 2 seem > > > inappropriate. > I suggest rewriting the introduction to use the same > terminology as > the protocol draft. See #3. > Response: > See #1. > > 1.4 > > 6) I find the references to SA-Li, RA-Rj confusing > since these are > not > > > used in the diagram. > Fixed, but replaced by "entity" which is a problem. See #3. > Response: > See #1. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Syslog-mib-11
Hi, [speaking as a contributor] Thank you Rainer for such a clear response. I recommend that text similar to Rainer's response be included in the DESCRIPTION clause for the syslogEntityControlTable, to explain why multiple syslog entities are modeled in the MIB module. I recommend capturing the discussion within the MIB module definition rather than in the document introductory sections, because MIB modules are often distributed already-extracted from the surrounding document, and NMS help screens are often fashioned from the DESCRIPTION clauses. So putting this info in the table description clause will get the explanation to the users. I would not object to **also** having it discussed in the introductory text sections. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 14, 2006 9:52 AM > To: David Harrington > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] Syslog-mib-11 > > David, > > Sorry for the late reply. > > In my experience: it depends... > > Under Linux/Unix, it is most common to have a single instance of the > syslog process running. All other processes communicate with that > process via local IPC, but the ultimate sender is the single > instance of > syslogd running. I have seen some deployments where multiple syslogd's > run on a single machine. This is rare and, if so, almost > always because > of different security domains (e.g. have a different process listen to > locally generated messages vs. Network received messages). > > From a design perspective, it might be a choice to have multiple > processes make up for the syslog subsystem. A real-world > example is SDSC > syslogd, which runs different stacks in different processes. Rsyslog > also has the RFC 3195 receiver separated. AFAIK these processes do not > share internal information. It is questionable if such can always be > assumed. > > Under Windows, it is common to have different syslog sender processes, > but typically only one receiver is running. This stems back > to the fact > that there is no syslog subsystem is available on Windows so every > vendor brings in its own. The key difference to *nix is that here each > program is itself a syslog sender, while under *nix each > program formats > the MSG part of the message, passes that to an API and the > syslogd picks > and sends it from there (effectively relaying the message). > > I hope this information is useful. > > Rainer > > > -Original Message- > > From: David Harrington [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, December 12, 2006 9:36 PM > > To: [EMAIL PROTECTED] > > Subject: [Syslog] Syslog-mib-11 > > > > Hi, > > > > In my latest review of syslog-mib-11, I have started to believe that > > Tom was right when he questioned the MIB module design, which models > > multiple syslog entities in a table, so one SNMP engine deals with > > multiple syslog senders, relays, and/or recievers on the same host. > > > > This adds complexity in the MIB design that I am not convinced is > > necessary. As the terminology in the MIB document has > gotten closer to > > other WG documents, this has become somewhat clearer to me. > > > > Tom recommended that the MIB module only model a single > syslog entity. > > Different instantations of the MIB module can be represented as > > existing in different contexts (e.g. in different > communities), so one > > SNMP engine can still deal with multiple syslog senders, relays, > > and/or receivers on the same host, but the MIB module itself becomes > > simpler. > > > > We should be sure the MIB module reflects real world requirements. I > > do not have much operational experience, so I need your input. > > > > In real deployments, is it **typical** to have multiple > syslog stacks > > running on the same host, each with a different bind > address and port > > number and config file? or is it more common for most > applications to > > share one syslog process (e.g., daemon) that operates via one > > address/port? > > > > David Harrington > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > > > > > ___ > > 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
[Syslog] transportDomain and transportAddress
Hi Glenn,
Maybe I misunderstand how transportDomain and transportAddress are
supposed to work. I have consulted one of the authors of RFC3419 to
make sure my understanding is correct.
As I read RFC3419, it seems to me that transportDomain and
transportAddress form a discriminated union; they form a corresponding
pair. So your response to my concern did not answer the question.
> -Original Message-
> From: Glenn M. Keeni [mailto:[EMAIL PROTECTED]
>
> Response.
> The syslogEntityControlTransportDomain specifies the
> transport e.g.
> transportDomainUdpIpv4.
>From RFC3419:
transportDomainUdpIpv4 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4 for
global IPv4 addresses."
::= { transportDomains 1 }
TransportAddressIPv4 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d:2d"
STATUS current
DESCRIPTION
"Represents a transport address consisting of an IPv4
address and a port number (as used for example by UDP,
TCP and SCTP):
octets contents encoding
1-4 IPv4 address network-byte order
5-6 port number network-byte order
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific
format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair."
SYNTAX OCTET STRING (SIZE (6))
When syslogEntityControlTransportDomain contains the value
transportDomainUdpIpv4, into which object in the syslog mib does one
put the corresponding transport address of type TransportAddressIPv4?
David Harrington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] TLS TransportDomain
Hi Glenn, How will the syslog/TLS transport address be specified in this object? Response. A syslog TLS transport domain will be defined. E.g. something like SyslogTLSTransportDomain. We will specify that as the syslogEntityControlTransportDomain. Thus, we will have something like: syslogEntityControlTransportDomain : SyslogTLSTransportDomain syslogEntityControlService: SyslogTLSPort Where and when will SyslogTLSTransportDomain be defined? Would it not make sense to define it in this mib module? I notice that RFC3419 uses the naming convention "transportDomain" So wouldn't it make sense to use transportDomainTLSIPv4? RFC3419 is meant to make transportDomains more generic than RFC3417, which is used to define snmp-specific transportDomains. I don't think we need to design syslog-specific transportDomains, but if so, then the naming convention from RFC3417 is Domain, such as snmpUDPDomain. With our byte-count header for syslog/TLS, a syslogTLSDomain might alert an application that there will be byte-counts in the stream. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] SyslogService
Hi Glenn, > -Original Message- > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > > 1.7 > > 12) SyslogService - can we make this just a service name. The > > > port semantics are really ambiguous. How do distinguish a UDP > > >port# from a TCP port#? > Not fixed. > > Response. > The syslogEntityControlTransportDomain specifies the > transport e.g. > transportDomainUdpIpv4. > I am looking for an unambiguous format for the value of this field. SyslogService ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The service name or port number that will be used to send and/or receive messages. The service name must resolve to a port number on the local host. " SYNTAX OCTET STRING (SIZE (0..255)) A service name is presumably a string; a port number is a decimal value. When put into this object, MUST the port number be represented as an ASCII string? If so, the description does not say so. If a service name is specified, is this done as an ASCII string or a UTF-8 string? The description doesn't say. If it is not UTF-8, why not? If the service name must resolve to a port number on the local host, how will a remote NMS get that resolution from the local host? Wouldn't it be simpler to put only a port number in the managed object? If you restricted it to a port number, then implementers only need to provide memory for an unsigned32 value (4 octets) rather than 255 octets. dbh ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] allowed
Hi Glenn, > -Original Message- > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > > 1.11> > 23) syslEntOpsMsgsIgnored - where are the "allowed > > > specifications" > > > defined? We don't want a value that can be interpreted > > > differently by > > > different entities, because then the values canot be compared > > > across > > > systems, or have consistent baselines for comparison across > > > products, > > > etc. Objects shoud be defined to be interoperable and > > > unambiguous. > Partially fixed. This is still ambiguous, and could be > interpreted > in different ways by different implemnenters resulting in > non-interoperability. This needs to be unambiguous as to > what gets > counted. > This object counts things outside the "allowed specifications" - > again > I ask where are the allowed specfications defined so an > implementer > knows what they are? > > Response. > The allowed specifications are in the protocol document. > There are > several MUST clauses. Some clauses explicitly mention that if the > MUST condition is not met the message MAY be discarded, > some don't. > E.g. Sec. 6.1 Message length, Sec. 6.2 HEADER. > We want to ensure consistency in what is counted; Will you please enumerate which conditions should be counted in this object. List which MUST clauses are relevant to this object, and which are not, and make it clear that ONLY these conditions should be counted. We should consider counting these conditions separately rather than counting them in an aggregated count. That way, a remote system could tell what the problem is, whereas "outside the allowed specifications" only says "there are one or more problems being encountered; we'll tell you how many problems have been encountered, but not which problems have been encountered." David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] syslEntCtlConfFileName
> -Original Message- > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 13, 2006 6:45 AM > To: [EMAIL PROTECTED] > Subject: Re: [Syslog] Dbh re-Review of -mib-11, part 1,2,3 > > > 2.2 > > 6) syslEntCtlConfFileName - using lots of abbreviations in > > > the name > > > makes it hard for people to remember how the words were > > > abbreviated. > > > It would be better to use something like > syslogEntCtlFilename. > > > Why do > > > we need Ent in the name? we never deal with anything > other than > > > entities, do we? syslogControlFile would be much easier to > > > remember > > > than syslEntCtlConfFileName. > Fixed (mostly). > > Response: > What is the remaining problem? syslogEntityControlConfFileName uses an abbreviation for Configuration. The abbreviation could have been Conf or Config or Cfg. This makes it harder to remember. I can live with this. You can mark it as fixed. dbh ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Dbh re-Review of -mib-11, part 1,2,3
> -Original Message- > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 13, 2006 6:45 AM > To: [EMAIL PROTECTED] > Subject: Re: [Syslog] Dbh re-Review of -mib-11, part 1,2,3 > > Hi, >I have pruned the list of comments and renumbered them. >The following starts the discussion on the points raised > in Dbh re-Review of -mib-11, part 2. > >Cheers > >Glenn > > > 2.3 > > 9) syslEntCtlStorageType - is this definition exactly the > > >same as the > > > StorageType T-C? > I am not sure this is the same semantics as StorageType T-C. > Your text is somewhat unclear when it says "backed up by > non-volatile (permanent)" > > Response: > Will the following help: >syslogEntityControlStorageType OBJECT-TYPE >SYNTAX StorageType >MAX-ACCESS read-create >STATUS current >DESCRIPTION >"This object defines whether the parameters defined in > this row are kept in volatile storage and lost upon > reboot or are backed up by non-volatile or permanent > storage. > Conceptual rows having the value 'permanent' need not > allow write-access to any columnar objects in the row. >" > > That mimics the DESCRIPTION used in DISMAN-MIB e.g. > smLaunchStorageType > That will do, yes. > > 2.4 > > 11) syslEntStarted and syslEntStopped - spell out MO. I don't > > > understand the second sentence; how does the manager > know what > > > syslEntOpsIndex is used? > Partially fixed. I still do not understand the second > sentence. Can > you reword this sentence? > > Response: > When a trap is received, the NMS/Operator needs to > figure out which > syslog "entity" the trap is about. This is done by using the > syslogEntityOperationsIndex instance identifier of the objects in > the notification. > > Will the following help? > >"The syslog entity corresponding to the notification will be > identified by the syslogEntityOperationsIndex > instance identifier > of the objects in the notification." Yes. Thanks. > 2.6 > > 14) The MIB module exposes some info from syslog, such as > > > last error. > > > The security considerations talk about securing snmp, but > > > that does > > > not make sense if you do not also secure the syslog > transport. > > > The > > > security considerations should recommend securing syslog to > > > match the > > > snmp security. > Not fixed. > > Response: > To me that appeared to be out of scope. That seems to be a matter > for the "security considerations" for syslog transport. No? > > Will something like the following suffice: > >"Under some circumstances securing SNMP will not make sense if > the syslog transport is not secured. It is > recommended that the > syslog transport be secured to match the security > level of SNMP." Let me just withdraw my comment. If the IESG wants something here, they can request it. > > 2.7 > > 17) I suspect you are not usinng xml2rfc. If not, you need to > > > make > > > sure all the boilerplates are up-to-date. Please check the > > > funding > > > statement and the intellectual property clauses. > Partially fixed. Needs updated boilerplates. > > Response: > Updated the boilerplate for the Copyright notice. > http://tools.ietf.org/tools/idnits/ > shows zero errors now. > Good. > > > > > Glenn M. Keeni wrote: > > Dave, > > Thanks for the detailed review. I count a total of > > 13 + 7 + 4 = 24 issues raised in the three mails. Let > > me go through these and try to figure out how to address > > the issues, hopefully by 18/12/2006. > > > > Cheers > > > > Glenn > > > > > > ___ > > 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 > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Mib terminology and MIB design
| | | | || | Subsystem | | || | | | ++ ++ +---+| | | +-+ | | | | +-+ | | | Application(s) | | | | | | | | +-+ +--+ +--+| | | | | Syslog | | Syslog | | Syslog || | | | | Sender | | Receiver | | Relay|| | | | +-+ +--+ +--+| | | | | | | +-+ | | | +---+ I think with the addition of entity and engine to the terminology, this picture does a good job of describing the syslog architecture, and would make it clearer what the "things" are that are modeled in the syslog mib module. It would however, only be clearer to a degree. The table in the mib document would likely model one or more *engines* (daemons that serve multiple applications) in a *NIX environment, but would model multiple *entities* in a Windows environment. And sometimes, the table would include multiple engines and multiple entities. We need to model the real world. As Tom points out, one way to avoid this is to develop a scalar mib module. Such a mib module would only model one engine at a time. It might be immaterial whether that engine services one or more applications. It could however be important to know that, so we might need to model the engine as a scalar, and supplement that with a table of applications (facilities?) serviced by the one engine, and statistics related to that usage. If a system had more than one syslog engine operating, a single SNMP engine could service them all, using different SNMP contexts to model them. But this brings us back to where we are now, with the reality that some engines are contained in complete entities, and some engines are not. I have a bias toward an approach using RFC3411. Not only am I one of the authors of RFC3411, I am trying to migrate SNMP, syslog, ipfix, and netconf to all use a common terminology, where possible, to describe their concepts and functionalities, so it is easier to compare, and possibly reuse, some design decisions. It might also be possible to reuse some specifications. All of these protocols are looking to utilize secure transports (e.g., SSH and TLS). It would be a good thing if they all used similar approaches, so operators only had to configure one secure transport protocol (e.g. TLS) in one consistent manner to secure all four NM protocols. All four protocols need data modleing capabilities, to different degrees, and if the IETF NM community could agree to all use, say XML for encoding, and XSD for modeling, it would be easier to reuse and/or correlate the data. Netconf is looking at a notification design that can carry syslog info and snmp info; if the syslog SDEs can be translated into XML, and MIB data can be translated into XML, and ipfix data can be transalted into XML, (e.g., via XSLT transform tools), then it might be much easier for operators to correlate the data of the four NM protocols. I am only suggesting here that we use a diagram and entity/engine terminology similar to RFC3411 terminology to make the MIB module easier to understand. Doing so would place no constraints on syslog designers, implementers, or users (except of course, the designers of this mib module). David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: tom.petch [mailto:[EMAIL PROTECTED] > Sent: Friday, December 15, 2006 9:18 AM > To: David Harrington; 'Glenn M. Keeni'; [EMAIL PROTECTED] > Subject: Re: [Syslog] Mib terminology and MIB design > > This is also tied up with the scalar/table question. If we > had a scalar MIB > module, then much of my difficulty would vanish. > > If we keep the table, then it should not be of entities. As > you point out, > SNMPv3 has given the word 'entity' a specific meaning and I > think it wrong to > re-use the word to mean something different in a MIB module > (it would be ok if > this were SMTP or BGP); I find the use of 'managed entity' in > DESCRIPTION > clauses especially confusing. I like 'daemon' (not seeing > that as being in any > way limited to a particular role) or 'device', which is > already in use in other > syslog documents. > > Tom Petch > > > - Original Message - > From: "David Harrington" <[EMAIL PROTECTED]> > To: "'Glenn M. Keeni
[Syslog] Mib-12
Hi Glenn, Once you finish updating the document with the issues we agree on, can you publish a mib-12 so we narrow the discussion to the few remaining issues? Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Dbh re-Review of -mib-11, part 3
acility that doesn't provide the facility and severity (e.g. refusing the request or substituting default values) is an implementation detail, not a standard detail. Note that I don't think there really is a non-standards-compliant application here, because we don't standardize implementation interfaces between an application and its sender/engine, but it seems pretty certain that if a sender needs to calculate a PRI, then it will need a facility and severity, and any application working with a standards-compliant sender would be expected to provide that info, so an application that doesn't provide them might be called non-standards-compliant, but that would really be stretching. It would probbaly b emore accurate to call the application non-standards-supporting. I do not understand the purpose of these defaults; I do not understand who uses them for what, and without understanding what the use case is, I **CANNOT** understand the implications of their designs, and why an implemneter is required to support them, or how an implementer is expected to utilize them. How can we possibly declare these to be part of an industry-wide standard? David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] RE: Framing...
Hi, The chairs believe there is consensus, and will ask Miao to change the -tls- document to say that FRAME-LEN is the count of the octets of the SYSLOG-MSG. dbh > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Monday, December 18, 2006 9:55 AM > To: Chris Lonvick; David Harrington; Miao Fuyou > Subject: Framing... > > Hi all, > > I just wonder if we have reached consensus to change the octet counter > to just cover the SYSLOG-MSG len. I have to admit that I am > hesitant to > release the open source software with the "wrong" framing. I know that > it is not appropriate to claim anything of an implementation > of a draft, > but as it looks we have consensus, I'd like to release what will most > probable become reality. Of course, I'll include big > disclaimers on that > functionality. But on the other hand, I would really like to get some > feedback from practice. I am also preparing a document that describes > why I have implemented the framing and why it is a big advantage over > traditional syslog/tcp. > > If we have a consensus, could we declare it? > > Rainer > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] RFC 3164
If members of the syslog community want to provide updated information about observed on-the-wire syslog messages, they should feel free to write such an informational document and have it published by the IETF. However, that is not part of the charter of our work, and should not be a WG item, but an individual draft. There is some question of whether providing such an update might conflict with the IETF efforts to standardize syslog, so the IESG may choose to prevent the publication of such a document within the IETF. Declaring RFC3164 obsolete (or historic) is within the scope of what we are authorized to do as a WG, and that step can be fully independent of an effort to provide updated information about historic/obsolete implementations. dbh > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Friday, December 22, 2006 2:39 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] RFC 3164 > > Andrew, Anton, > > I am using Andrew's message to reply to both. I concur with Andrew, > please see below... > > > -Original Message- > > From: Andrew Ross [mailto:[EMAIL PROTECTED] > > Sent: Thursday, December 21, 2006 10:53 PM > > To: Rainer Gerhards > > Subject: RE: [Syslog] RFC 3164 > > > > > > Hi Rainer, > > > > Merry Christmas! > > > > Sorry I've been out of the discussion loop for so long, things have > > been > > pretty hectic over here. I know that the new protocols are in good > > hands > > though. > > > > With regard to 3164. I would prefer to obsolete 3164 with a document > > that > > details what is actually seen in real life on the wire. This would > just > > mean > > adding some extra text to the 3164 document and adding in some > examples > > of > > what is seen by different OS senders. Pretty much the research you > > presented > > to the list a while ago. This new document would then obsolete 3164. > > That would actually be my prefferred way to handle things. Other than > Andrew, I think we should remove/change most of the text, as > indeed only > PRI is available on an universal basis. Samples of different message > formats can be used to convey that information. > > > We get asked so often by customers if we are 3164 compliant. We used > to > > explain that 3164 is not really valid, but that didn't satisfy them, > so > > we > > just said "yes, we are compliant" to keep them happy. > > Now to the question "why do that?". Andrew has a very valid > point here. > We experience the same quite often. We even added an option "use RFC > 3164 compatible format" to our product and guess what - it is > turned off > most of the time because RFC 3164 does not describe what receivers and > senders typically do ;). Even if we obsolete 3164 with > -protocol, I know > a lot of folks will come and ask "Hey, do you support the old standard > that most of my other devices use?". They simply will not > care about it > being obsoleted by something different. However, if we go ahead and > crate 3164bis (another informational document), the situation > will IMHO > change. Now there is a newer "standard" (as people perceive > it) for the > "old" syslog. And if that says "You can not trust anything but PRI" I > can "sell" that. Plus, I have a very good point in argumenting why > syslog-protocol is superior. > > I know I am not talking hard technical facts here. I am talking real > life. Most people do not care if a RFC is informational or standards > track. If it is a RFC, it must be something products comply > too. I agree > that implementors should understand the difference. They > (hopefully/probably) do. But do implementors actually decide what to > implement? No - not in my experience. The marketing department tells > them what to do. And customers tell the marketing department. > And guess > what? These customers are the informed masses that do *not* know the > inner workings of the IETF (aka "a RFC is a RFC is a RFC..."). > > Even in a technical context like the IETF I think a little bit of > real-world politics can be considered. It is the key to acceptance of > new standards. > > Rainer > > > > Cheers > > > > Andrew > > > > > > > > > > -Original Message- > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > Sent: Thursday, 21 December 2006 8:13 p.m. > > To: [EMAIL PROTECTED] > > Subject: [Syslog] RFC 3164 > > > > > > Hi all, > > > > I just realized that the future of RFC 3164 is not yet publically > > discussed. > > > > RFC 3164 is a well-done work, but we have made much progress in the > > past > > 5 years since it was written. Most importantly, we discovered that > > actual syslog software uses a much different set of formats than > > expected by 3164. This was the source of much discussion > inside the WG > > and we did a lot of testing to confirm the findings. The bottom line > is > > that we now know that 3164 does *not* acurately describe what is > > observed in the wild. Nobody is to blame here -
[Syslog] RE: TransportDomain
Hi Tom,
Juergen's explanation has nothing to do with RFC3411. The fact that
syslog can be 3164 or -protocol or signed is really immaterial to this
discussion, since these happen above the addressing level.
This discussion has to do with choosing from three standard mechanisms
for representing addresses in SMIv2 MIB modules. There are advantages
and disadvantages to each of the three standard approaches to
representing address formats, and these should be understood to make
the proper choice. (Juergen is well versed in the intracacies of the
advantages and disadvantages, and is trying to provide some advice).
The three standards are:
1) TDomain (RFC3417) - which defines a mechanism to represent
snmp-specific addresses (at layer7). This was defined explicitly for
use in the MIB modules that are part of SNMPv3, and are designed only
for managing SNMP, and the addresses defined (e.g.
SnmpUDPDomain/SnmpUDPAddress) can not be easily reused to represent
addresses used by other protocols.
snmpUDPDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over UDP over IPv4 transport domain.
The corresponding transport address is of type
SnmpUDPAddress."
::= { snmpDomains 1 }
SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current
DESCRIPTION
"Represents a UDP over IPv4 address:
octets contentsencoding
1-4 IP-address network-byte order
5-6 UDP-portnetwork-byte order
"
SYNTAX OCTET STRING (SIZE (6))
Tdomain includes definitions for snmp-specific addresses. For
syslog to use TDomain will require us to develop hardcoded OID
assignments for a syslogUDPDomain and syslogUDPAddress,
syslogTCPDomain, syslogTCPAddress, syslogTLSDomain, syslogTLSAddress,
and so on. Those hardcoded values can then be used in TDomain/TAddress
fields in MIB modules.
To provide an SSH transport extension would require publishing
a new MIB module to define the new hardcoded values syslogSSHDomain,
syslogSSHAddress.
The SNMP community realized it is really undesirable to have
to write a whole new MIB module just to say what the address domain
would be and what the address would look like.
The suggestion that a syslog address is always
syslog/tls/tcp/IANAport might lead one to select the TDomain approach,
but this is not really required. One ting to point out is that IANA
assigns a requested "default" port, but operators can often change
what port is actually used.
2) TransportDomain - which defines a mechanism that represents
(layer4) transport addresses, independent of the application. This
better permitted showing the transport addresses of non-snmp-things in
MIB modules.
transportDomainUdpIpv4 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4 for
global IPv4 addresses."
::= { transportDomains 1 }
TransportAddressIPv4 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d:2d"
STATUS current
DESCRIPTION
"Represents a transport address consisting of an IPv4
address and a port number (as used for example by UDP,
TCP and SCTP):
octets contents encoding
1-4 IPv4 address network-byte order
5-6 port number network-byte order
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific
format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair."
SYNTAX OCTET STRING (SIZE (6))
To use this in a MIB module, you define a pair of fields: a
transportDomain field identifies the type of address being used, and a
corresponding field of transportAddress with the actual address value.
The corresponding address value MUST be of the type defined in
TransportDomain.
Syslog could use this approach, BUT - there are no existing
definitions for a TLS/TCP transport address, so if we want to use
this, we need to define such a transportDomain and corresponding
transportAddress. The current syslog mib document does not provide
such an update.
There is an additional complication. RFC3419 provides an enumeration
to select a transportDomain; this is done so a transportDomain can be
used as a field in an index without having the whole OID of a
transportDomain be part of the INDEX; you can use an integer
identifier.
In order to add a new transportDomain therefore requires updating
RFC3419 to keep the enumeration in sync with the possible values of
transportDomain.
So while using trasportDomain would require us to make fewer hardcoded
definti
[Syslog] Syslog-mib-12
Hi, [speaking as co-chair] I think these comments from Tom have not been addressed in mib-12. Does the WG agree that Figure 1 and discussion of facilities and hosts and so on should be removed in mib-xx? Does the WG agree that Diagram 1 from protocol-19 should be duplicated in mib-xx, as a way to bring the language used in the mib module closer to the "standard terminology" proposed by this WG? Does the WG agree that Diagram 1 represents all likely deployment scenarios (most notably those encountered on dumb-device, *NIX and Windows environments)? Would it be adequate to simply **reference** Diagram 1 in [RFCPROT], and the Terminology of Section 3 of [RFCPROT], and then explain how the terminology in the mib module relates to the [RFCPROT] terminology and diagram? David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG > -Original Message- > From: tom.petch [mailto:[EMAIL PROTECTED] > Sent: Friday, December 15, 2006 9:35 AM > To: David Harrington; 'Rainer Gerhards' > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] Syslog-mib-11 > > mm > > Rainer's explanation shows me why I have not encountered > this; it is only > present in Windows servers and then only, if I read it > aright, because Windows > has not done a satisfactory implementation yet. The question > then is, how much > do we adapt to this behaviour of Windows? > > I find your remedy insufficient. Look at the diagram at the > start of -mib and > compare it with the diagram at the start of -protocol. > Seeing those two > diagrams convinced me that the two I-Ds came from different > planets and that, > until that was resolved - and only now, months later, do I > begin to see a > resolution - it was not worth expending much effort on -mib. > > I think this will be the reaction of others and that we MUST > include the diagram > in -mib that appears in all the others and then -mib must > explain how the terms > it chooses relates to those in the diagram and why. > Simplying saying this I-D > is different because we are on planet Microsoft is not > sufficient for me. > > I agree that there must also be a brief explanation in the > DESCRIPTION clause. > > Another problem I have with -mib is the statement that > "The syslog entities may be on the same host or on different hosts." > If on different hosts, what is the protocol used to > communicate between the two > hosts? If this is syslog, then how is the MIB information > communicated from > syslog sender to the entity with the SNMP agent? This is not a new > question:-(. > > > Tom Petch > > > - Original Message - > From: "David Harrington" <[EMAIL PROTECTED]> > To: "'Rainer Gerhards'" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Thursday, December 14, 2006 11:23 PM > Subject: RE: [Syslog] Syslog-mib-11 > > > > Hi, > > > > [speaking as a contributor] > > > > Thank you Rainer for such a clear response. > > > > I recommend that text similar to Rainer's response be > included in the > > DESCRIPTION clause for the syslogEntityControlTable, to explain why > > multiple syslog entities are modeled in the MIB module. > > > > I recommend capturing the discussion within the MIB module > definition > > rather than in the document introductory sections, because > MIB modules > > are often distributed already-extracted from the > surrounding document, > > and NMS help screens are often fashioned from the > DESCRIPTION clauses. > > So putting this info in the table description clause will get the > > explanation to the users. I would not object to **also** having it > > discussed in the introductory text sections. > > > > David Harrington > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > https://www1.ietf.org/mailman/listinfo/syslog > > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Rfc3164 and mib
Hi, The consensus of the WG is to obsolete rfc3164. Therefore, it should not be referenced in the MIB document. The MIB document only references it in the introduction, so this has no effect. Glenn, please remove all reference to RFC3164 from the mib document. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] TransportDomain issue
Hi
[speaking as co-chair]
As this discussion continues, and based on the updated description
clauses, it appears more and more obvious that some objects are only
important for receivers or for senders or for relays:
syslogEntityControlBindAddrType = receiver
syslogEntityControlBindAddr = receiver
syslogEntityControlBind(Port) = receiver
syslogEntityControlService = receiver
syslogEntityControlMaxMessageSize = receiver
syslogEntityOperationsMsgsIgnored = receiver (exceeds max message
size)
syslogEntityOperationsMsgsReceived = reciever
syslogEntityOperationsMsgsIllFormed = receiver
syslogEntityOperationsLastMsgRecdTime = receiver (or for internal
debugging?)
syslogEntityControlEncapsulation = sender
syslogEntityOperationsMsgsDropped = sender (internal debugging
information?)
syslogEntityOperationsLastMsgRecdTime = sender (internal debugging?)
syslogEntityOperationsLastMsgTransmittedTime = sender, relay
syslogDefaultFacility = relay
syslogDefaultSeverity = relay
syslogEntityOperationsMsgsRelayed = relay
syslogEntityOperationsLastMsgTransmittedTime = sender, relay
syslogEntityControlConfFileName = entity
So let's take the tables, break them out according to role and
document what is needed for each role. After that exercise, we may
reach the conclusion that much of the info could be modeled for a
generic syslog entity, but at this point I am far from convinced that
is true.
So far, the members of this WG have stayed out of the mib discussions,
so the overall design (scalar versus tabular) comes down to Tom versus
Glenn, and that does not denote consensus. We have seen one approach,
but not the other, so let's design an alternate mib that has the
information broken out by sender/receiver/relay, and is scalar with
different instances represented in different SNMP contexts. This may
simplify the design considerably and help us to understand what needs
to be in the official mib module.
Who wants to design an alternate mib module for the WG? It doesn't
have to be perfect from a MIB standpoint; it needs to do a reasonably
good job of showing what needs to be modeled for 1) a syslog receiver,
2) a syslog sender, and 3) a syslog relay. Glenn? Tom? Others?
David Harrington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
co-chair, Syslog WG
> -Original Message-
> From: Juergen Schoenwaelder [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 28, 2006 3:30 PM
> To: Glenn M. Keeni
> Cc: Wijnen, Bert (Bert); [EMAIL PROTECTED]
> Subject: Re: [Syslog] TransportDomain issue
>
> On Fri, Dec 29, 2006 at 03:51:14AM +0900, Glenn M. Keeni wrote:
>
> > After some discussion on the list and explanations
> > from Juergen I porpose the following MIB description
> > of the syslog transport. Let me have your comments.
> >
> > Cheers
> >
> > Glenn
> >
> > +---+
> >
> > SyslogEncapsulation ::= TEXTUAL-CONVENTION
> > STATUS current
> > DESCRIPTION
> > "This textual convention enumerates the encapsulations
> > of the syslog message that is used between syslog
> > application endpoints.
> > "
> > REFERENCE
> > "TBD.
> > "
> > SYNTAX INTEGER
> > {
> >other (0),
> >none(1), -- RFCUDPX (no encapsulation)
> >tls (2), -- RFCTLS
> >beep(3), -- RFCBEEP
> >sign(4) -- RFCSIGN
> > }
>
> My understanding is that signed syslog messages can be shipped over
> different transports. The signed syslog ID says:
>
>This specification is independent of the actual transport
protocol
>selected. The mechanism is especially suitable for use with the
>syslog protocol as defined in RFC [14] because it utilizes
the
>STRUCTURED-DATA elements defined in that document. It may also
be
>used with syslog packets over traditional UDP [4] as
> described in RFC
>3164 [10]. It may also be used with the Reliable Delivery
> of syslog
>as described in RFC 3195 [11], and it may be used with
> other message
>delivery mechanisms. Designers of other efforts to define event
>notification mechanisms are encouraged to consider this
> specification
>in their design.
>
> In other words, I think sign(4) does not make sense as an
> encapsulation mechanism.
>
> > syslogDefaultEncapsulation OBJECT-TYPE
> > SYNTAX SyslogEncapsulation
> > MAX-ACCESS read-write
> > STATUS current
> > DESCRIPTION
> > "The default encapsulation that the syslog
> > entity
[Syslog] Conclusion of Working Group Last Call: syslog-sign-20
Hi, This message officially concludes the Syslog Working Group Last Call for the following document: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-20.txt The chairs and the editor will review the comments and determine which actions should be taken. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Syslog Protocol doubts
Or we could simply reiterate Postel's law: "In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior. That is, it must be careful to send well-formed datagrams, but must accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear)." [STD5] dbh > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Friday, January 05, 2007 8:47 AM > To: Glenn M. Keeni; [EMAIL PROTECTED] > Subject: RE: [Syslog] Syslog Protocol doubts > > Hi Glen, > > thanks for the message. Let me start on an overview level: if you look > at the evolution of the draft, you will see that earlier versions were > quite specific on what to do if the message was malformed. However, > based on dicussion, one after another of these rules were deleted. The > reason was always that MUSTs here are not actually needed to ensure > interoperability. > > You can get a glimpse of this discussion by looking at > > http://www.syslog.cc/ietf/why-indepth.html > > This is a very old page. For more recent samples, you should > consult the > mailing list archives. There are (too) plenty samples of this being > discussed to point to anything specific. > > The bottom line behind the current draft is that we do not necessarily > specify what happens if the message is malformed. This is not > vital for > interoperability. Also, implementors will provide different solutions > (most probably operator-configurable) to address real-world needs. For > example, we could specify that a message with leap seconds in > it MUST be > discarded - but if the operator insists that he needs such a > message, an > implementor will always create a way to process it. > > We are specific on invalid UTF-8 sequences. This must not be > interpreted, because this is a big security issue. However, > even than it > might be OK for an implementation to store the invalid UTF-8 sequence. > > If that is consensus, we can add the statement "the handling of > non-compliant messages will be implementation dependent" which very > precisely describes the list consensus. > > Rainer > > > -Original Message- > > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > > Sent: Friday, January 05, 2007 12:32 PM > > To: [EMAIL PROTECTED] > > Subject: [Syslog] Syslog Protocol doubts > > > > Hi, > >I have been trying to figure out the error conditions > > that a syslog receiver will need to anticipate and the > > corresponding actions that it is expected to take. I do > > not see this clearly spelt out in the protocol document. > > There are several MUST clauses, I understand that a > > compliant syslog sender WILL always send messages that > > meet the MUST clauses. But the document does not spell > > out clearly what a compliant syslog receiver will do > > when it gets a non-compliant message. Possible actions > > could be: > > a. discard whole message > > b. discard non-compliant part ( assuming the non- > >compliant part can be isolated) > > c. rectify the non-compliance e.g. > > - truncate message: [this is mentioned in 6.1] > > - truncate the long-fields (software, > > swVersion etc.) > > d. implementation dependent > > > > Is this a problem ? I have listed the MUST conditions > > in the attached document. My take is that we may have to > > address each one of these. Or we can include a sweeping > > statement like " non-compliant messages will be discarded" > > or "the handling of non-compliant messages will be > > implementation dependent". > > > >Glenn > > > > > > > ___ > 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
RE: [Syslog] Syslog Protocol doubts
Hi,
[speaking as co-chair]
Let's make this more concrete. What specific changes to which specific
documents are you requesting?
David Harrington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
> -Original Message-
> From: tom.petch [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 06, 2007 2:04 PM
> To: Rainer Gerhards; Glenn M. Keeni; [EMAIL PROTECTED]
> Subject: Re: [Syslog] Syslog Protocol doubts
>
>
> Tom Petch
>
> - Original Message -
> From: "Rainer Gerhards" <[EMAIL PROTECTED]>
> To: "tom.petch" <[EMAIL PROTECTED]>; "Glenn M. Keeni"
> <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Friday, January 05, 2007 9:12 PM
> Subject: RE: [Syslog] Syslog Protocol doubts
>
>
> Hi Tom,
>
> I think this is an extreme position. The reason is that if I take
this
> to its ultimate end, we would probably end up without any MUST in
the
> draft. For example, should we just say the date SHOULD be given in
RFC
> 3339 format ... But leave it open to any implementor what he
> intends to
> do? I think a MUST is justified here. But on the other hand, I can
NOT
> force ("MUST") an implementation to discard an otherwise
> useful message
> just because the date is in the wrong format. From the protocol
> perspective, this might be the right thing to do (in trying to
punish
> the incompliant implementation), but from a usabulity point
> of view, the
> administrator needs to have this capability. In a closed-source
> environment, that means marketing will force an implementor to
support
> it. In open-source, the administrator will simply modify the
> implementation himself. In either way, the "MUST discard" will not
> survive. So is it really smart to mandate something in a standard
that
> we can foresee to be ignored (and that for good reason)? However, we
> need to set same baseline and these are the format-MUSTs. If we
change
> them all to SHOULD (to cover a myriad of real-world cases), we do
not
> have a standard...
>
> Rainer
>
>
> I disagree:-)
>
> I am not suggesting we add or change anything in -protocol.
> I think MUST is
> well defined in RFC2119 and that the consequences are clear.
> If the sender
> demonstrably does not conform to -protocol in some regard (to
> a MUST), then what
> confidence can you have that they will conform in other
> regards where that may
> not be immediately apparent from the message itself?
>
> syslog may have more MUSTs than most but I think that what
> makes syslog unusual
> is that it is simplex; in other protocols, the receiver can
> say 'what on earth
> is this?'; here it cannot and so I am content that the
> specification should be
> stricter.
>
> Tom Petch
>
> > -Original Message-
> > From: tom.petch [mailto:[EMAIL PROTECTED]
> > Sent: Friday, January 05, 2007 6:47 PM
> > To: Rainer Gerhards; Glenn M. Keeni; [EMAIL PROTECTED]
> > Subject: Re: [Syslog] Syslog Protocol doubts
> >
> >
> > Tom Petch
> >
> > - Original Message -
> > From: "Rainer Gerhards" <[EMAIL PROTECTED]>
> > To: "Glenn M. Keeni" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > Sent: Friday, January 05, 2007 2:46 PM
> > Subject: RE: [Syslog] Syslog Protocol doubts
> >
> >
> > Hi Glen,
> >
> > thanks for the message. Let me start on an overview level:
> if you look
> > at the evolution of the draft, you will see that earlier
> versions were
> > quite specific on what to do if the message was malformed.
However,
> > based on dicussion, one after another of these rules were
> deleted. The
> > reason was always that MUSTs here are not actually needed to
ensure
> > interoperability.
> >
> >
> >
> > I take a somewhat different view. To quote RFC2119,
> >
> > "Imperatives of the type defined in this memo must be used with
care
> >and sparingly. In particular, they MUST only be used where it
is
> >actually required for interoperation or to limit
> behavior which has
> >potential for causing harm (e.g., limiting retransmisssions)."
> >
> > So if you receive a packet that breaks a MUST, you MUST discard
it.
> >
> > If it breaks a SHOULD, then you MAY accept it, in fact I
> > would say you ought to
> > on the principle of being liberal in what you accept.
> >
> >
> >
> >
> >
> > You can get a glimpse of this discussion by looking at
> >
> > http://www.syslog.cc/ietf/why-indepth.html
> >
> >
>
>
> ___
> 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
[Syslog] MIB Issue #1 - one or multiple? Seeking consensus
Hi, [speaking as co-chair] Finally, we are getting discussion of the issues of what needs to be modeled by more than two people with opposing ideas. I would like to reach consensus on this question: Is it acceptable practice to have more than one syslog application (sender, receiver, relay) running on a server/host/system simultaneously? At this point, based on Glenn's suggestion of having an experimental and a production syslogd running at the same time, and Rainer's description of syslog in a Windows environment, I think that having more than one active syslog application (sender/receiver/rerlay) is a reasonably common scenario in some environments and not in others. The current MIB interface is designed to support multiple syslog sender or receivers on the same server/host. I believe this is a valid requirement. If you agree with this, please say so. If you disagree with this, please say so. The chairs will make a determination of consensus, and this issue will be closed. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG > -Original Message- > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > Sent: Friday, January 12, 2007 3:30 AM > To: [EMAIL PROTECTED] > Subject: [Syslog] The SIMPLE SyslogMIB > > Hi, >I will try to address David's concern about the complexity > and utility of the MIB. >The basic design principle has been to keep the MIB simple. > It has gone through several iterations, each one making it > simpler than the earlier version :-) >At present the MIB basically allows the NMS to manage the > syslog entity (sender, receiver, relay) by looking at its > (a) status ( up/down/suspended/unknown) > (b) configuration > (c) macro statistics >total number of messages (sent, received, relayed) >total number of exceptions > ( drops, discards, malforms) >The notifications will tell the NMS about change in the > syslog entity's status. > That in a nutshell is what one will want to or need to do > for basic monitoring/management. > > The MIB can provide information on multiple syslog entities. > [Scenario: two syslogd's are running on a syslog server - one > for experiments one for regular operations.] > > So if we want we may get a table like the following from the MIB. > > Syslog Status and Statistics Summary > > > +-+-+--+--+-+-+-+ > |Index|Type | Description |Status| Messages| > | |rsR* | | |Sent | Recd| Dropped | > +-+-+--+--+-+-+-+ > | 1 |r-- | SecuritySys | Up | - | 120| - | > | 2 |r-- | Operations | Up | - | 1234| - | > | 3 |r-- | Experiment-1 | Up | - | 9890| - | > | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > +-+-+--+--+-+-+-+ > * r: Receiver , s: Sender, R: relay > > Note that this is a sample. Several other columns are possible. > In a similar manner the address and port of the syslog receiver, > the number of malformed messages received etc. can be obtained. > > In more advanced usage, a syslog entity can be started [on a > specific address and port, if it is receiver] or an existing > syslog entity can be stopped or suspended. [I will not try to > explain how that can be done.] > > I think that is simple as it can be. Let me know if > a. it can be made simpler. > b. it is too simple and more detailed information is necessary. > e.g. facility wise statistics as follows. > > Facility-wise Syslog Statistics Summary > === > +-++-+--+--+-+-+-+ > |Index|Facility|Type | Description |Status| Messages| > | ||rsR* | | |Sent | Recd| malformd| > +-++-+--+--+-+-+-+ > | 1 |51 |r-- | SecuritySys | Up | - | 123| - | > | 1 |52 |r-- | SecuritySys | Up | - | 45|45 | > | 1 |53 |r-- | SecuritySys | Up | - |6| - | > | 2 |51 |r-- | Operations | Up | - | 789| - | > | 2 |52 |r-- | Operations | Up | - | 10|10 | > +-++-+--+--+-+-+-+ > > * r: Receiver , s: Sender, R: relay > > I will not recommend tables for > - facility-wise and severity-wise statistics > - facility-wise, severity-wise and host-wise statistics.
RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
Nothing we do here should prevent you from using multiple snmp agents running on different ports if desired. dbh > -Original Message- > From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] > Sent: Friday, January 12, 2007 1:53 PM > To: David Harrington; [EMAIL PROTECTED] > Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking > consensus > > > > > -Original Message- > > From: David Harrington [mailto:[EMAIL PROTECTED] > > Sent: Friday, January 12, 2007 10:31 AM > > To: [EMAIL PROTECTED] > > Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > > > > Hi, > > > > [speaking as co-chair] > > > > Finally, we are getting discussion of the issues of what > > needs to be modeled by more than two people with opposing ideas. > > > > I would like to reach consensus on this question: > > > > Is it acceptable practice to have more than one syslog > > application (sender, receiver, relay) running on a > > server/host/system simultaneously? > > Absolutely. Especially, sender. > > > At this point, based on Glenn's suggestion of having an > > experimental and a production syslogd running at the same > > time, and Rainer's description of syslog in a Windows > > environment, I think that having more than one active syslog > > application (sender/receiver/rerlay) is a reasonably common > > scenario in some environments and not in others. > > > > The current MIB interface is designed to support multiple > > syslog sender or receivers on the same server/host. I believe > > this is a valid requirement. > > > > If you agree with this, please say so. > > If you disagree with this, please say so. > > Agree. > > However, I am not clear it must be covered by a single SNMP agent with > single MIB. It should probably be possible to manage multiple syslog > instance with single SNMP agent per host, but we are not > excluding each > instance having it own SNMP agent on different port, right? > > I don't know if this violates anything in SNMP, but it may be easier > implementation-wise no to have to integrate my syslog component with > system SNMP agent. > > Thanks, > Anton. > > > > > The chairs will make a determination of consensus, and this > > issue will be closed. > > > > David Harrington > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > co-chair, Syslog WG > > > > > > > -Original Message- > > > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > > > Sent: Friday, January 12, 2007 3:30 AM > > > To: [EMAIL PROTECTED] > > > Subject: [Syslog] The SIMPLE SyslogMIB > > > > > > Hi, > > >I will try to address David's concern about the complexity > > > and utility of the MIB. > > >The basic design principle has been to keep the MIB simple. > > > It has gone through several iterations, each one making it > > > simpler than the earlier version :-) > > >At present the MIB basically allows the NMS to manage the > > > syslog entity (sender, receiver, relay) by looking at its > > > (a) status ( up/down/suspended/unknown) > > > (b) configuration > > > (c) macro statistics > > >total number of messages (sent, received, relayed) > > >total number of exceptions > > > ( drops, discards, malforms) > > >The notifications will tell the NMS about change in the > > > syslog entity's status. > > > That in a nutshell is what one will want to or need to do > > > for basic monitoring/management. > > > > > > The MIB can provide information on multiple syslog entities. > > > [Scenario: two syslogd's are running on a syslog server - one > > > for experiments one for regular operations.] > > > > > > So if we want we may get a table like the following from the MIB. > > > > > > Syslog Status and Statistics Summary > > > > > > > > > +-+-+--+--+-+-+-+ > > > |Index|Type | Description |Status| Messages| > > > | |rsR* | | |Sent | Recd| Dropped | > > > +-+-+--+--+-+-+-+ > > > | 1 |r-- | SecuritySys | Up | - | 120| - | > > > | 2 |r-- | Operations | Up | - | 1234
[Syslog] MIB Issue #2: document terminology.
Hi, [speaking as co-chair] For issue#2, you do not need to worry about the MIB module itself, so a lack of SNMP expertise is not important to resolving this issue. I have a copy of an unofficial -02- revision of the syslog-device-mib that was edited by Bruno Pape, dated August 2002. The current mib draft inherited its terminology and architecture diagrams and support for multiple entities from the WG drafts edited by Bruno. So the current terminology and architecture and table structure was decided by the WG, in the adoption and subsequent development of the mib document. As WG editor, it is Glenn's responsibility to represent in the document the consensus of the WG; if only one WG member argues for substantial changes to an existing WG document, then there is no clear WG consensus to make such changes. We need multiple WG members to review the current MIB document for the chairs to determine that the terminology used in the text sections represents what the WG wants to see, and that WG agrees the text section adequately describes what information is needed to manage a syslog sender, receiver, relay, and/or collector. Again, you do not need to be SNMP-literate to do such a review; We need a review of the surrounding text. Please make suggestions for replacement text when you think the current text is not appropriate. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Syslog WG co-chair ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
Hi, [speaking as co-chair] MIB Issue#1 is not about whether Windows is a real operating system. If you want to have that discussion feel free, but please do it elsewhere - it is inappropriate for the syslog WG, and it is certainly off-topic for MIB Issue#1. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG > -Original Message- > From: tom.petch [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 16, 2007 8:40 AM > To: Rainer Gerhards; [EMAIL PROTECTED] > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking > consensus > > Rainer > > Using this as a convenient peg on which to hang an answer. > > You asked about software architecture. I think that for all > its commercial > success, Windows is not, in some key respects, an operating > system in that it > does not provide the infrastructure that applications > deserve. You point out > that it does not have an SNMP engine or a syslog engine. > Other operating > systems do, so that an application wishing to use those > services can invoke them > (API, inter-process call, 127.0.0.n via a socket ) at a > level that is > suitable for the application. > > Windows does have a number of excellent third-party SNMP > engines, so I expect to > see one of those installed - but only one - with a load of > fourth party > applications hooking into the services that the snmp-engine provides. > > For the other software you mention, I do not see them as > providing a service for > multiple other software to use ie I only have the one web > browser, e-mail > server/client etc and often that limitaton is hard-coded into > proper operating > systems as well (Windows purports to support multiple web > browsers - 'do you > want this to be your default?' - but my attempts to run them > have been a > disaster). > > You comment that Windows has no syslog engine to serve > multiple applications, so > each application does it itself, with the consequences we are > now discussing. > > As to how much gets modelled in a MIB module, there is a > standards based Host > Resources MIB module (RFC2790) which models processes and > expects all of them to > have certain common attributes - I have used this on Linux > but have not seen it > on Windows. > > On the other hand, most operating system vendors do have > large quantities of > proprietary MIB modules that do model the software > architecture of their > particular operating system so my bias is towards, if > Microsoft want to model > this, let them do it themselves:-) > > Tom Petch > > - Original Message - > From: "Rainer Gerhards" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, January 16, 2007 12:30 PM > Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking > consensus > > > Being not MIB-literate, I tend to agree that it does not add much > complexity if there is a table which most often includes just a single > element. > > What is used in practice. It depends on your point of view. > If you look > at deployments, a single engine is the vast majority. If you look at > number of different implementations, I am not so sure. In any case, I > would vote for extensibility IF that does NOT add considerable > complexity. I can not make an informed judgement on the later. > > Rainer > > > -Original Message- > > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, January 16, 2007 12:21 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking > consensus > > > > Tom, > > > Which technique is best depends on whether the occurrence of > > > multiple instances is the norm, which should be modelled and > > > supported. I think that this is not the case for syslog and > > > so the additional complexity is not justified. I imagine you > > > think otherwise. > > The syslogMIB leaves it to the users to choose how they want to > > manage their syslog entities. I do not see the problem with that. > > About complexity- there is hardly any added complexity worth > > mention in the MIB design, implementation, and corresponding NMS > > development. > > > > Glenn > > > > > tom.petch wrote: > > > - Original Message - > > > From: "Glenn M. Keeni" <[EMAIL PROTECTED]> > > > To: "tom.petch" <[EMAIL PROTECTED]> > > > Cc: "David Harrington" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > > Sent: Sunday, January 14, 2007 5
RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
Hi, [speaking as a contributor, and a MIB Doctor] > -Original Message- > From: tom.petch [mailto:[EMAIL PROTECTED] > > > Using Tables is the standard SNMP technique for managing multiple > > instances. That is exactly what is done in the current MIB. > > > > > Well, no. As a MIB Doctor, I generally support Glenn's statement, and not Tom's. Using tables is **one** of the standard SNMP techniques for managing multiple instances. I would say it is the most commonly used standard SNMP technique for managing instances. There are multiple ways to model instances in SMIv2, each with advantages and disadvantages. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] IETF MIB Doctor ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
