[Syslog] RE: MIB Doctor review of draft-ietf-syslog-tc-mib-04.txt

Hi, > Romascanu, Dan (Dan) wrote: > > > > 1. I do not believe that it is necessary to carry all the duplicated > > text in the MIB module as commented text, as it does not provide any > > significant implementation information. > I will agree with this. > Are there any other opinions / suggestio

[Syslog] RE: syslog-tc-mib-02

Hi, In rereading this message, I realize that "may also use" could be misinterpreted as meaning "may use SDEs instead of". So the wording might be better as "may use supplementary" dbh > -Original Message- > From: David Harrington [mailto:[EMAIL PROTECTED] > Sent: Monday, September 24

[Syslog] Syslog-tls-09 draft - suggested change

Hi, The -09- revision copied text directly from rfc2818 without modifying it to match the simplex operating environment of syslog, as compared to the duplex operating environment of HTTP. I think this makes the text confusing since it is unclear what a "user-oriented" syslog would be. HTTP is o

RE: [Syslog] Doubts on definitions

y? dbh > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 10, 2007 4:17 PM > To: David B Harrington; [EMAIL PROTECTED] > Subject: RE: [Syslog] Doubts on definitions > > David, > > > -Original Message- &

[Syslog] Doubts on definitions

Hi, As we have this discussion, I find that the terminology (and the architecture it describes) in the protocol document is very ambiguous. For example, > > > The following definitions are used in this document: > > > o An application that can generate a syslog message is called a > > >

[Syslog] Dbh re-review of Mib-11-, part 2

Hi this is a review of the requested changes from part 2 of my earlier review. > -Original Message- > From: David Harrington [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 25, 2006 4:25 AM > To: [EMAIL PROTECTED] > Subject: Mib-09- review, part 2 > > Continued ... > > 1) syslEntCt

[Syslog] syslog-tls version number

-Original Message- From: Juergen Schoenwaelder [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 14, 2006 11:17 AM > > After taking another look at the syslog over TLS mapping, I am > > wondering why you have a version number in the transport mapping at > > all. Do you really think th

[Syslog] Working Group Last Call: syslog-mib 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-device-mib-09.tx t The Working Group Last Call for this document will end September 25. To help get these document reviewed throughly, we are

[Syslog] WG timeline update

Hi, We didn't include revisions and subsequent WGLCs in our timeline. Here is an update to the timeline Aug 28 Close WGLC on protocol and udp Aug 28 start WGLC on syslog-sign Sep 1 tls and mib drafts published with requested changes (before WGLC) Sep 4 start WGLC on tls and mib drafts Sep 11 C

[Syslog] MIB document decision needed

Hi, Tomorrow is the deadline for establishing consensus on 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. Tom has pointed out that the terminolo

[Syslog] draft-ietf-ipcdn-pktc-eventmess-07.txt

FYI. This document defines a MIB that, as part of its definition, manages syslog servers. I am the MIB Doctor for this document and would be interested in your comments. http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-07 .txt David Harrington [EMAIL PROTECTED] [EMAIL PROTECTE

[Syslog] RE: Call for David Harrington to resign from syslog as co-chair

] [EMAIL PROTECTED] [EMAIL PROTECTED] > -Original Message- > From: Darren Reed [mailto:[EMAIL PROTECTED] > Sent: Friday, June 09, 2006 1:23 PM > To: David B Harrington > Cc: [EMAIL PROTECTED] > Subject: Call for David Harrington to resign from syslog as co-chair > &

[Syslog] Draft-ietf-syslog-transport-tls-01.txt

Hi, As co-chair it is my responsibility to make the WG aware that there has been a disclosure that an unpublished pending patent application might be infringed by the implementation of the specifications in draft-ietf-syslog-transport-tls-01.txt. The disclosure can be found at https://datatracker

[Syslog] Tls-01

Hi, The definition of sender in syslog-tls-01 differs from that in syslog-protocol. In -protocol, the "sender" is the message generator. In -tls, the sender is the message sender, whether that entity generated the message or not, and "originator" is the generator of the message. The distinction is

[Syslog] draft-ietf-syslog-transport-tls-01.txt

Hi, A new revision of the syslog/TLS draft is available. http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 .txt We need reviewers. Can we get 1) a person to check the grammar? 2) a person to check the syslog technical parts? 3) a person to check compatibility with the other

RE: [Syslog] Summary of the syslog/tls issues resolving

Hi, I also have concerns about depending on DNS. I want to be sure I understand what you are suggesting as an alternative. Is the mapping from IP to hostname operator-defined in a static way? What happens, network-management-wise, when an IP address changes for a given host, or more importantly,

RE: [Syslog] WG Review: Recharter of Security Issues in Network EventLogging (syslog)

At Huawei, we plan to develop a prototype of syslog/TLS. David Harrington [EMAIL PROTECTED] > -Original Message- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Friday, March 10, 2006 1:59 AM > To: iesg@ietf.org > Cc: [EMAIL PROTECTED] > Subject: FW: [Syslog] WG Review: Rechar

RE: [Syslog] Coming to consensus on syslog threats

Hi Miao and Yuhzi, It would be easier if you used a consistent numbering/lettering scheme in your outline, so a reviewer can refer to your #2, and be unambiguous. I recommend adding the following as you expand the outline: 1) The Problem Description - what security threats need to be addressed f

RE: [Syslog] implementing -protocol and -transport-udp

Hi, Just a point. -transport-udp and -transport-tls should be independent of each other, since one is based on udp and the other on tcp. I just want to be sure that is understood. -transport-udp and transport-tls should have a comparable interface to the rest of the syslog documents. Do we agree

RE: [Syslog] Threat model requirements discussion

Hi, Comments inline David Harrington [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Balazs Scheidler > Sent: Monday, January 30, 2006 6:15 AM > To: HarringtonDavid 73653 > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] Threat mod

RE: SSH - RE: [Syslog] Re: Threat model and charter

Hi, Note that ISMS has a user-authenticatioin requirement for mapping to data access controls, while I do not believe that to be a requirement of syslog. David Harrington [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lo

RE: [Syslog] #7, field order

plementors point of > view, I think > it is pretty easy to parse everything and then compare it to > a sole "-". > But that's not the point of this question. The question is if > there is a > way to make the *parser* do the differentiation. > > I'

[Syslog] #7 field order

Hi, Better yet, **I'll** change the subject to #7 field order. Thanks, dbh > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Darren Reed > Sent: Wednesday, December 14, 2005 3:43 PM > To: Darren Reed > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog]

RE: [Syslog] RE: syslog-protocol draft

Can we change the subject line to #7 field order, please? Thanks, David Harrington [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Darren Reed > Sent: Wednesday, December 14, 2005 3:43 PM > To: Darren Reed > Cc: [EMAIL PROTECTED]

[Syslog] Please use issue #s in subject lines

Darren, and others, Could you please use the issue # in the subject line, preferably one issue per message, so it is easier to find all of a conversation related to a specific issue? Darren, I tried to find the comments you made while the group was trying to establish consensus on various items,

RE: [Syslog] #2, max message size - Need to resolve this

Hi Chris, You have framed the question incorrectly. This discussion is about the "minimum maximum message length", not the "maximum message length". This is about "at least this big" and not about "no bigger than". All receivers MUST be able to handle the minimum maximum message size X, and it i

RE: [Syslog] #5 - character encoding (was: Consensus?)

I suggest including wording to the effect "if no SD-ID encoding element is specified, then the encoding of the content is implementation specific and it is RECOMMENDED that no assumption be made about the encoding of the content." dbh > -Original Message- > From: [EMAIL PROTECTED] > [m

RE: [Syslog] #7 field order

Hi, Can you please ask those who are sending you private messages to make their points on the mailing list, as is appropriate for IETF WG discussions? dbh > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > Sent: Wednesday, November

RE: [Syslog] Consensus on Charter?

Hi Darren, I suggest you work with some other implementors of TCP-based syslog to write a TCP transport mapping I-D that can be considered as the starting point for future WG work, if the current work ever gets completed. At a minimum, the document could probably be published as Informational. d

[Syslog] Forward compatibility

Rainer wrote: I am an IETF freshman. Anyhow, I often read that the IETF was driven by "rough consensus and running code". I say "was", because my impression is that this is no longer the case. I would prefer it were... While the IETF has increased its theoretical discussions, I think a major part

RE: [Syslog] New direction and proposed charter

Hi, I recommend we stop talking about RFC3164-compliant, since RFC3164 is only an Informational document and not standards-track. dbh > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > Sent: Thursday, November 24, 2005 8:01 AM > To

RE: [Syslog] Revised proposed charter

Hi, I will observe that the syslog MIB has been declared "dead" in the ID-tracker, and it has expired in the I-D repository. Is this deliberate, and if so, why? No explanation is given in the ID-tracker. dbh. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On

RE: [Syslog] Revised proposed charter

Hi, It would be a good thing to enumerate in the charter the select set of mechanisms to be standardized and included in the charter deliverables by the charter deadlines. That would severely limit any possibility of mission creep, something this group needs to constrain. I am concerned about the

RE: [Syslog] Message format

Hi, The IETF focuses on on-the-wire formats; we don't typically mandate how one stores data after it is received. David Harrington [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Ross > Sent: Tuesday, November 22, 2005 10

RE: [Syslog] New direction and proposed charter

Hi, I am concerned about the emphasis on backwards compatibility. The reason people want a standard is that existing server implementations have made different design decisions, and device and application vendors are forced to either interoperate with one vendor-specific server implementation, or

[Syslog] FW: Agenda for the Ops & Mgmt Open Area Meeting IETF64

Hi, I requested that the netconf/isms discussion be moved to the first half of the OPS open meeting so syslog personnel could attend. I will be presenting a slide show that includes discussion of syslog/netconf/snmp commonalities. dbh -Original Message- From: [EMAIL PROTECTED] [mailto:[

RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14

> see note above. Do you recommend we should actually make > English an requirement? I think that would be a mistake. For a vendor, e.g. a Chinese vendor, who produces switches that are sold only to the Chinese market, whose customers speak primarily Chinese and have limited English skills,

Re: [Syslog] Secure substrate - need your input

Hi, As this WG struggles with the question of which secure transport to use, I recommend reading RFC3535 - "Overview of the 2002 IAB Network Management Workshop". This workshop, a "world tour" of ISP organizations, and the survey of which Tom speaks were part of an effort by the IAB and the O&M A

RE: [Syslog] Secure substrate - need your input

> I see that there is a lot of work around SSH connection > protocol and its potential use in new protocols. I have not > followed these developments. There must have been a good > reason for it. I would like to understand why people object > to SSL, which is a well established technology. A

RE: [Syslog] TCP and SSH Discussion

ymmetry of authentication). David Harrington [EMAIL PROTECTED] > -Original Message- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Friday, October 21, 2005 8:48 AM > To: David B Harrington > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] TCP and SSH Discussion > >

RE: [Syslog] TCP and SSH Discussion

Hi, Comments inline > > If the WG feels that an SSH transport will accomplish this > goal, and it > > will be used, then I'm open to having that discussion. I > don't feel that > > documenting current tcp transports works towards that goal. > > The only concern I'd have would be syslog bei

RE: [Syslog] TCP and SSH Discussion

Hi, For a discussion of syslog over SSH, I recommend people read the documents for other IETF network management protocols that plan to run over SSH: http://www.ietf.org/internet-drafts/draft-ietf-netconf-ssh-05.txt and http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-00.txt http://

RE: [Syslog] plain tcp syslog

Hi, Comments inline > -Original Message- > From: Darren Reed [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 18, 2005 11:01 AM > To: [EMAIL PROTECTED] > Cc: 'Albert Mietus'; 'Rainer Gerhards'; [EMAIL PROTECTED] > Subject: Re: [Syslog] plain tcp syslog > > .. > > This discussion is l

RE: [Syslog] plain tcp syslog

Hi, There will be much discussion of "call-home" functionality, something akin to the reverese buffered approach described here, at the upcoming Vancouver meeting. It may be a BOF, or it may be a discussion in the O&M open area meeting. See https://www1.ietf.org/mailman/listinfo/call-home for info

RE: [Syslog] RE: [Syslog-sec] AD Review fordraft-ietf-syslog-protocol-14

re are no objections to this > approach, I > will create some text. > > Rainer > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Alexander Clemm (alex) > > Sent: Tuesday, October 04, 2005 9:10 P