Hi Darren,
On Sat, 22 Oct 2005, Darren Reed wrote:
Hi Darren,
It's not syslog/udp/ssh nor syslog/tcp/ssh, it's going to be
syslog/ssh/tcp/ip. syslog will be a defined subsystem for SSH much like
sftp and netconf.
Oh! Hmmm.
Do you have any links to critiques about sftp ?
The secsh wg
Hi Rainer,
On Fri, 21 Oct 2005, Rainer Gerhards wrote:
Chris,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick
Are you volunteering to write? :)
I think we are not yet in a position we have something to write. I know
that you
Hi Folks,
I'll be asking this in Vancouver but would like to get some input from the
mailing list.
Our charter says that we will develop a secure method to transport syslog
messages. We have BEEP (RFC 3195) but it has a low implementation record.
Other groups have specified BEEP as well
Hi All,
I am finding that the people contributing to the mailing list are making
progress in defining a useful protocol. I also see that they are
discussing implementation details. Both of these tell me that we're on
the right track.
What we found in Vancouver is that we were on the wrong
]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick
(clonvick)
Sent: Tuesday, November 29, 2005 10:22 AM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] #5 - character encoding (was: Consensus?)
Hi Rainer,
Why don't we look at it from the other direction? We could state that
any
Hi Rainer,
I believe that we are saying the same thing. :)
If there is no indicator of encoding or language then a reciever will not
know what it is receiving - just like receivers don't know what they are
receiving today. They MAY make an assumption that it is something in
US-ASCII (but
Hi,
Let's keep in mind that syslog-sign will transport binary signatures. In
that, the authors are proposing to use base-64 encoding. I agree with
Rainer that we've provided enough means in syslog-protocol so that may be
accomplished.
As Rainer says, let's focus on getting syslog-protocol
David's text be suitable? I think it is very clear and precise.
With it, probably the whole issue hadn't started. I know this WG likes
it very brief, but isn't it worth the extra lines?
Rainer
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick
Sent
the
threads but I believe that we have rough consensus on all of the other
issues so that Rainer can re-work syslog-protocol.
Thanks,
Chris
PAF's comments below
-- Forwarded message --
Date: Wed, 7 Dec 2005 17:23:24 +0100
From: [ISO-8859-1] Patrik F?ltstr?m
To: Chris Lonvick [EMAIL
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick
Sent: Wednesday, December 07, 2005 8:11 PM
To: [EMAIL PROTECTED]
Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd)
Hi Folks,
I asked Patrik Faltstrom to review this proposal. He has
some comments
below
and
termination..
Anyone else agree or disagree?
Tom Petch
- Original Message -
From: Chris Lonvick [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, December 07, 2005 8:10 PM
Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd)
Hi Folks,
I asked Patrik Faltstrom
Hi All,
Sam has asked that we nail down one topic in our re-chartering effort:
backwards compatibility. I'll propose the following modification to our
Charter and I've also put in some Milestone dates below.
===
Syslog is a de-facto standard for logging system events. However, the
Hi All,
The WG does need Me too. comments to show consensus. If I don't see
those on the list then the issue will be dropped.
We do not have the time for lengthy discussions on any topic dealing with
syslog-protocol and syslog-transport-udp. If anyone brings up a topic,
they really need
Hi Sam,
On Thu, 5 Jan 2006, Sam Hartman wrote:
Hi. The IESg reviewed the proposed syslog charter at today's telechat
and decided that it requires revision. The main concern seems to be
the lack of a mandatory to implement security mechanism. I indicated
this might be the case in the
Hi Folks,
This is it. We need people to review this and get back to the WG.
When you reivew it, either send in notes about issues, or respond by
saying that you have reviewed it. (We DO need me too's.)
Thanks,
Chris
-- Forwarded message --
Date: Tue, 03 Jan 2006 15:50:02
Hi Working Group,
I'll pass this along to those people who have already implemented
syslog/TLS(SSL). Please be specific about why you did this.
Thanks,
Chris
On Tue, 10 Jan 2006, Sam Hartman wrote:
Hi.
Can you explain what actions on a part of an attacker are prevented in
terms of
Hi,
I was thinking that if we have to do authentication then we could try to
get consensus on a simple authentication mechanism - a shared secret.
Essentially, each sender would have to be configured with a shared secret
before it could use TLS. The receivers and relays would also have that
Hi,
I forgot to address the use of SSH for authentication. The isms WG is
trying to use SSH to provide security for SNMPv3. This can be done by
having the devices authenticate by having a username and credential
(password, public key, etc.). Again, this sounds to me like it's getting
Hi Sam,
I also have a concern that we may try to craft an answer that provides
good security but that won't actually be deployed. As an analogy, snmp
has similar characteristics to syslog. usm has good security properties
but has not been widely deployed. isms is trying to redress that and
Hi Rainer,
I'm still not seeing too many responses about how TLS is authenticated.
Only Baszi has said that full X.509 certificates should be used - similar
to how they are used in stunnel. Is this acceptable to the WG? Should
the WG also consider using PSKs as proposed in RFC 4279?
Hi Folks,
We need to back up a moment and formalize our thoughts on the threats that we
are going to address to secure syslog messages. We need to have this
discussion to ensure that any mechanism we decide to provide will address the
threats. The summary of our discussion will likely be
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Chris Lonvick
Sent: Tuesday, February 07, 2006 10:10 PM
To: [EMAIL PROTECTED]
Subject: [Syslog] Coming to consensus on syslog threats
Hi,
In reviewing the messages around the threats
Hi Tom,
You are correct.
I'll change that to:
Nov 2006 Submit a secure syslog transport mapping document to the
IESG for consideration as a PROPOSED STANDARD.
Thanks,
Chris
On Thu, 9 Feb 2006, Tom Petch wrote:
Chris
I notice that the body of the proposal takes a neutral
Hi,
Just FYI - The article is about the US NIST's effort to standardize event
message formats. The link to the NIST workshop is:
http://csrc.nist.gov/CLIX/
Thanks,
Chris
-- Forwarded message --
Date: Wed, 15 Mar 2006 10:40:37 -0800
From: Jian Zhen [EMAIL PROTECTED]
To:
Hi Folks,
I think that this resolves the netconf discussion.
Thanks,
Chris
-- Forwarded message --
Date: Wed, 29 Mar 2006 14:53:20 -0800
From: Andy Bierman [EMAIL PROTECTED]
To: Sharon Chisholm [EMAIL PROTECTED]
Cc: Netconf (E-mail) netconf@ops.ietf.org
Subject: Re: Why are we
Hi Darren,
David has recused himself from this discussion because of any possible
conflict of interest. As you note, the claim statement does not
accurately reflect the sections of the ID, but rather the sections of the
claim statement itself. I am working on getting more information about
Hi Sam,
Please keep this between us for the moment.
On Thu, 8 Jun 2006, Sam Hartman wrote:
First, have you looked at the updated IPR disclosure?
Yes. The Cisco lawyer who deals with IPR says that he is confused by it.
He suggests that I ask for a clarification of what is based on
Hi,
OK - I blew it.
My apologies to the Working Group and to David for my obvious problem. I
had meant that to be an update to Sam only.
With sincere apologies,
Chris
On Fri, 9 Jun 2006, Chris Lonvick wrote:
Hi Sam,
Please keep this between us for the moment
Hi Folks,
I do want to be clear on this subject. Hauwei is well within their rights
to discover something while writing a Working Group document, and then to
claim IPR on that discovery. This has happened in the past which was why
the IETF started writing BCP 79 - currently RFC 3979. The
Hi Rainer,
On Sat, 10 Jun 2006, Rainer Gerhards wrote:
Chris,
ok, you have pointed to the IPR IETF list, anyhow, one comment on this
list is due:
I do want to be clear on this subject. Hauwei is well within
their rights
to discover something while writing a Working Group document,
and
Hi,
I've seen a lot of discussion about payload format on the list lately. I
think that everyone already knows the charter of the WG but I want to be
clear about this; we're not going to address that issue within our WG.
I'm OK with having some discussion around this as it makes us think
Hi Folks,
Please continue to send in your opinion on this. I'll determine consensus
next Thursday and outline our steps to go forward.
Thanks,
Chris
On Wed, 5 Jul 2006, Chris Lonvick wrote:
Hi Folks,
Everyone has now had a week to think about the IETF process on IPR claims.
The first
Hi Folks,
The consensus reached is that:
The WG SHOULD proceed with draft-ietf-syslog-transport-tls as a Working
Group document.
There were numerous votes cast for this option. Most were public and are
in the archive and I recieved two additional private responses for this.
I saw very few
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
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
Hi,
On Thu, 17 Aug 2006, Balazs Scheidler wrote:
On Wed, 2006-08-16 at 12:32 -0700, Carson Gaspar wrote:
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
Hi,
I agree; we don't want a vote here. We want strong technical reasons for
making a decision.
Thanks,
Chris
On Wed, 16 Aug 2006, David Harrington wrote:
Hi Rainer,
The IETF doesn't vote.
The chairs will determine consensus on or after the Aug 18 deadline
for this decision.
David
Hi,
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:
PRI... 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.
We need this
Hi Bazsi,
On Thu, 7 Sep 2006, Balazs Scheidler wrote:
On Thu, 2006-09-07 at 17:17 +0800, Miao Fuyou wrote:
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
Hi Folks,
We need some more reviews of our documents. There has been some
discussion that the documents havn't changed much since the last time we
went through a WGLC. I've made some diffs of -protocol and of
-transport-udp so you can see what changes have been made.
Diff from protocol-14
Hi Bert,
We appreciate your review of the document.
As for syslog-over-ssh: We had been incontact with the ISMS and Netconf
WGs and we did see that they had chosen SSH as a secure transport. We did
discuss this within our own Working Group. The consensus was:
- there are current
with the same
transport version. Does it work?
My preference is 4 1 2 3.
Miao
-Original Message-
From: Chris Lonvick [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 21, 2006 2:55 AM
To: Miao Fuyou
Cc: 'David Harrington'; [EMAIL PROTECTED]
Subject: RE: syslog/tls - how to abort because
Hi All,
I've been reviewing the use of enc (for defining the encapsulation
type). This discussion has been going on for some time.
http://www.mail-archive.com/syslog@lists.ietf.org/msg00241.html
http://www.mail-archive.com/syslog@lists.ietf.org/msg00252.html
Hi,
In David Harrington's review of syslog-protocol-17
http://www1.ietf.org/mail-archive/web/syslog/current/msg01145.html
he asked about the Alarm MIB - Section 6.2.1.1 (from RFC3877). We
discussed this a while ago and it doesn't seem that there is a good fit
between the historical syslog
-authored RFC 3877). It provides the mapping between severities in
alarms sent via SNMP and those logged in syslog. Removing it means that
implementations will all have different mappings.
Sharon
-Original Message-
From: Chris Lonvick [mailto:[EMAIL PROTECTED]
Sent: Friday, November 03, 2006 12:34
://www.ietf.org/rfc/rfc4268.txt?number=4268
Sharon
-Original Message-
From: Chris Lonvick [mailto:[EMAIL PROTECTED]
Sent: Friday, November 03, 2006 1:26 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] Alarm MIB in syslog-protocol
Hi Sharon,
It's an important
is
ready for AD review.
[Area] SECURITY
[WG] syslog
[I-D] draft-ietf-syslog-transport-tls-04.txt
[Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt
[Shep] Chris Lonvick [EMAIL PROTECTED]
===
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd
Hi Rainer,
inline
On Wed, 22 Nov 2006, Rainer Gerhards wrote:
Chris,
I mostly agree (but keep my posting on -04 in mind). Some issue below...
Rainer
-Original Message-
From: Chris Lonvick [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 22, 2006 3:03 PM
To: [EMAIL PROTECTED
Hi Miao,
On Mon, 27 Nov 2006, Miao Fuyou wrote:
Hi,
Unfortunately (or fortunately), there are several issues raised after the
chair start shepherding process. As the editor, I would like close the
issues as soon as possible, and get the doucment updated.
1, Version. The wg seems have
Hi Everyone,
Cisco asked Huawei to make this change. Essentially the prior statement
appeared to be similar to the IPR statements made by Cisco and other
companies but it had differences that were not acceptable to the Cisco
legal team. Hence, Cisco would not have been willing to implement
-syslog-transport-tls-05.txt is
ready for AD review.
[Area] SECURITY
[WG] syslog
[I-D] draft-ietf-syslog-transport-tls-05.txt
[Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt
[Shep] Chris Lonvick clonvick at cisco.com
===
(1.a) Who is the Document Shepherd for this document? Has
] SECURITY
[WG] syslog
[I-D] draft-ietf-syslog-protocol-19.txt
[Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt
[Shep] Chris Lonvick clonvick at cisco.com
===
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version
port
should be requested and that there should be no indication of version with the
consequence that any future change to the protocol might require a different
port number.
Tom Petch
- Original Message -
From: Chris Lonvick [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November
document for -05 as well.
Thanks,
Chris
On Thu, 30 Nov 2006, tom.petch wrote:
Chris
I agreed (mostly) with the actions in your e-mail but do not see them all
reflected in -05. See inline
Tom Petch
- Original Message -
From: Chris Lonvick [EMAIL PROTECTED]
To: Miao Fuyou [EMAIL
Hi All,
Cisco legal counsel has reviewed this and found it to be acceptable and
written consistent with most other IPR statements.
Again, Cisco thanks Huawei for addressing this issue.
Thanks,
Chris
On Mon, 27 Nov 2006, Chris Lonvick wrote:
Hi Everyone,
Cisco asked Huawei to make
Hi Folks,
David and I are pleased to announce that the shepherding documents for the
following IDs have been submitted to the IESG.
- draft-ietf-syslog-protocol-19.txt
- draft-ietf-syslog-transport-tls-06.txt
- draft-ietf-syslog-transport-udp-08.txt
Our thanks go to the authors and the
Hi Folks,
There have been many changes made to the syslog-sign ID during the last
WGLC. As David announced, we are going to do another WGLC for this ID.
To help you in your reviews, I have created some diffs.
The differences between -18 and -19
Hi,
Rainer has it right. I agree that a simple note as Rainer suggests will
do it.
Thanks,
Chris
On Fri, 15 Dec 2006, Rainer Gerhards wrote:
David,
I went through my notes. Retaining PRI as is is actually a charter item:
---
Reviews have shown that there are very few similarities
Hi,
In the following,
[14] is syslog-protocol
[15] is syslog-transport-udp
[16] is syslog-transport-tls
===
Last paragraph in the Introduction
This specification is independent of the actual transport protocol
selected. The mechanism is especially suitable for use with the
Hi Rainer,
On Mon, 18 Dec 2006, Rainer Gerhards wrote:
Hi,
So far, I have not been able to do a full review. But this triggers my
attention immediately...
Perhaps restructure that as:
A Signature Block message that is compliant with RFC
[14] MUST
contain valid APP-NAME,
,
-Original Message-
From: Chris Lonvick [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 19, 2006 10:18 PM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] clonvick WGLC Review of
draft-ietf-syslog-sign-20.txt
Hi Rainer,
On Mon, 18 Dec 2006, Rainer Gerhards wrote:
Hi,
So
--
Date: Wed, 20 Dec 2006 15:51:25 +0100
From: Rainer Gerhards [EMAIL PROTECTED]
To: Chris Lonvick [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: APP-NAME,
PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of
draft-ietf-syslog-sign-20.txt
Chris
Hi,
Overwhelming consensus is that references to 3164 will be removed from
syslog-sign.
Alex, Please start working on this but don't submit any changes until
after WGLC is complete on 28 Dec.
All: Please continue to review the document and let's get this out the
door.
Thanks,
Chris
Hi,
The Chairs have spoken to the author of RFC 3164. The author agrees that
it should be OBSOLETED. ;-)
I did discuss this with someone who has been trying to de-cruft a lot of
ancient RFCs. It is not usual to OBSOLETE an INFORMATIONAL RFC but
there's nothing that says that we can't do
Hi,
I'm OK removing references to RFC 3195 from syslog-sign for the points you
mention. I'd welcome other opinions.
I agree that RFC 3195 is due for an update but I disagree with most of
your other points. A major vendor has found customers requesting it and
has implemented it.
Hi Folks,
New ID:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-07.txt
Miao has submitted a revised -transport-tls document. This came about
after Sam performed a review and found some items that needed to be
addressed.
From Sam:
===vvv===
First, I think the idea
Hi Folks,
I know that the mailing list has been quiet for a while. This doesn't
mean that we're not working. :-)
We have taken the IETF Last Call comments and asked Rainer to integrate
them into -protocol. As we've discussed, the definitions in -protocol
needed to be slightly reworked so
Hi,
On Tue, 24 Apr 2007, Eliot Lear wrote:
Miao,
TLS is still duplex even if syslog is simplex. In the same time,
authenticaiton happens in the handshaking phase of TLS when syslog message
transfering does not begin . So, simplex or duplex does not matter for
authentication.
I
Hi,
I'm OK with this proposal with two minor changes.
- rather than (see below) it should have (see next paragraph)
- remove parenthasis from (with a bad certificate error) as that text is
normative.
vv
If the hostname does not match the identity in the certificate,
clients SHOULD log the
Hi,
David is correct in this. No matter how strongly we feel that defining
SDEs for other applications is good work, it will not be done in this WG.
For documents that describe new SDEs, the alternatives to forming a new WG
are:
- have SDEs defined in a WG that is already dealing with that
awaiting a further -tls for review before the three of
them go to the rfc-editor.
Tom Petch
- Original Message -
From: tom.petch [EMAIL PROTECTED]
To: Chris Lonvick [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, May 04, 2007 4:37 PM
Subject: Re: [Syslog] FINAL review of draft-ietf-syslog
Hi All,
What I'm seeing is that our effort to add granularity for mib accounting
has made the document less clear. My apologies for that.
Does the following make more sense:
+-++-+
| content|| content|
? or do you parse the message and expect there to
be helpful data in the SDE?
This is all getting complicated and I am unclear about the benefits of going
down this road.
Tom Petch
- Original Message -
From: Chris Lonvick [EMAIL PROTECTED]
To: tom.petch [EMAIL PROTECTED]
Cc: David Harrington
Hi Folks,
I'm going to ask that people review the new -protocol document.
http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-21.txt
I'd like to get that back to Sam by the 25th. I'm not sure that this will
need another IETF Last Call but I'll discuss that with Sam.
I want to
Hi Folks,
The discussion came up about the use of the Facilities in the
-syslog-tc-mib document; are they normative or non-normative. David and I
discussed this and have concluded that they are normative to the version
of the protocol that we are now discussing. That may be changed in the
Hi Folks,
This note from Sam to [EMAIL PROTECTED] for those of you who don't subscribe.
Thanks,
Chris
-- Forwarded message --
Date: Fri, 15 Jun 2007 19:48:25 -0400 (EDT)
From: Sam Hartman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [Syslog]
Discuss - Congestion Control
Magnus: But what I think is needed here is some clear and normative
requirement on how to avoid and limit congestion. First of all I would
like to see a restriction on the applicability of this transport to within
a controlled environment unless the rate is
Discuss - UDP Length
Lars:
draft-ietf-syslog-transport-udp-09, Section 65535, paragraph 0:
This transport mapping supports transmission of syslog messages up to
65535 octets in size. This limit stems from the maximum supported
UDP payload of 65535 octets specified in the RFC 768
Hi Folks,
David and I have been trying to address the open DISCUSSes on
-syslog-protocol and -syslog-transport-udp.
https://datatracker.ietf.org/idtracker/ballot/1800/
As an aside: Sam has reviewed -syslog-transport-tls and has asked for some
modifications. Miao and Yuzhi are working on
Discuss - Source Address
Lars:
draft-ietf-syslog-protocol-21, Section 5., paragraph 2:
If a syslog application is running on a machine
that has both statically and dynamically assigned addresses, then
that value SHOULD be from the statically assigned addresses. As an
alternative,
Discuss - UDP Checksum
===
Magnus:
Discuss [2007-06-19]:
UDP transport:
Section 3.6:
It is RECOMMENDED that syslog senders use valid UDP checksums when
sending messages over IPv4 and IPv6.
It is RECOMMENDED that syslog receivers check the checksums whenever
they are present (i.e.
Hi Juergen,
Good question. ..and not something that we'll be able to answer in our
WG. I'll bring it up in the [EMAIL PROTECTED] list.
Thanks,
Chris
On Thu, 5 Jul 2007, Juergen Schoenwaelder wrote:
On Thu, Jul 05, 2007 at 07:56:39AM -0700, Chris Lonvick wrote:
We used to recommend
NOT depend on the UDP checksum being a zero value.
===
I'd like to hear from people who have current syslog/udp code. What works
for you?
Thanks,
Chris
On Thu, 5 Jul 2007, Chris Lonvick wrote:
Hi Juergen,
Good question. ..and not something that we'll be able to answer in our WG.
I'll bring
be lost forever and it is better to receive it in
some degraded state. At least this is what my *actual* users are
requesting.
Rainer
-Original Message-
From: Juergen Schoenwaelder
[mailto:[EMAIL PROTECTED]
Sent: Thursday, July 05, 2007 9:24 PM
To: Chris Lonvick
Cc: [EMAIL PROTECTED]
Subject
, it would directly
contradict IPv6 RFC, which says:
IPv6 receivers must discard UDP packets containing a zero checksum, and
should log the error.
Anton.
-Original Message-
From: Juergen Schoenwaelder
[mailto:[EMAIL PROTECTED]
Sent: Thursday, July 05, 2007 4:16 PM
To: Chris Lonvick
-- Forwarded message --
Date: Fri, 06 Jul 2007 18:08:12 +0200
From: Magnus Westerlund [EMAIL PROTECTED]
To: David Harrington [EMAIL PROTECTED]
Cc: Chris Lonvick [EMAIL PROTECTED], Lars Eggert [EMAIL PROTECTED]
Subject: Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd)
Hi David
Hi Sam,
I'm going to wait a day or so for any input from the WG. However, the
proposed text seems to be acceptable. Do you want a new ID, or is this
something that we can change in AUTH24?
Thanks,
Chris
On Fri, 7 Sep 2007, Sam Hartman wrote:
Hi, folks.
I think the WG made a mistake
Hi Sam,
I've heard no objection from the WG on your proposed wording. Please go
with that.
Thanks,
Chris
On Mon, 10 Sep 2007, Sam Hartman wrote:
If the WG is OK with my proposed text, I'll handle it in an rfc editor note
___
Syslog mailing
Hi Folks,
This is adding to the note that David sent out about syslog-tc-mib-02 and
a discussion we've had about the Facilities. David and I have reviewed
the mailing list discussion and have concluded that the labels are
normative, but irrelevant.
For interoperability and backwards
Hi Folks,
I have not seen any further discussion on this but we still have some open
issues.
I like the idea of describing the cases for the clients and servers to
have (or not have) certificates. For high deployability, I believe that
the client would not need one at all. At the other
Hi,
It made it into the repository today. Please review and comment.
Thanks,
Chris
On Mon, 19 Nov 2007, Rainer Gerhards wrote:
David,
it may be just my problem, but... I have not seen any updated doc. Did I
miss something?
Rainer
-Original Message-
From: David Harrington
Hi WG,
Things are changing in the IETF around documenting the management and
operations of protocols. The OPS Area WG has been documenting a change of
approach, in which SNMP and MIBs are not the only way to configure,
manage and operate a protocol, and existing practices are taken into
application. IMO, we should let the specific application designers do
that.
Regards,
Anton.
-Original Message-
From: Chris Lonvick (clonvick)
Sent: Wednesday, January 16, 2008 5:32 AM
To: [EMAIL PROTECTED]
Subject: [Syslog] Documenting the configuration of syslog
Hi WG,
Things are changing
93 matches
Mail list logo
