because it requires us to define the specific
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 th
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
greate
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 [mailto:
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 ext
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 compati
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 li
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 tryin
nks,
Chris
-- 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-p
AY accept
syslog message with invalid or zero checksums", 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 PROTEC
tal message might 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
ted as a zero value, and
o receivers MUST 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
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
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 capped
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.
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 [1].
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, t
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 thos
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] draft-iet
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
f
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 be
ssing? 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&
Hi,
On Tue, 22 May 2007, Sam Hartman wrote:
"Chris" == Chris Lonvick <[EMAIL PROTECTED]> writes:
Your layer diagram makes sense.
Chris> For discrepancies (if any) between the IP address of the
Chris> "originator" and the "transport sender", th
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|
|-
Hi,
On Fri, 11 May 2007, David Harrington wrote:
Hi,
I think Chris meant to say "draft-ietf-syslog-protocol and
draft-ietf-transport-udp are back in Sam's hands.
draft-ietf-transport-tls only requires a WG review before going back
to Sam.
Doh! Yup.
Thanks,
Chris
__
in the same sentence in the Abstract.
I take it we are still 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]>; <[
Hi Folks,
David and I would like to hand off this final version to Sam for
publication by Friday. I have performed an initial review and feel that
the changes address the IETF Last Call items.
The changes requested from the IETF Last Call were:
Item 1) Severity Range - The range of the Seve
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
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
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 personally
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 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 o
Hi All,
Apologies for the delay - I've still got a very heavy travel schedule for
the rest of this week and most of next.
I agree that the WG consensus is to produce syslog-transport-tls.
Alex is re-drafting syslog-sign to ride atop syslog-protocol. This will
remove the dependencies of 3164
ted before you start messing around with other things. I had
thought this was the agreement of the committee last year.
John Moehrke
GE Healthcare
-Original Message-
From: Eliot Lear [mailto:[EMAIL PROTECTED]
Sent: Friday, January 26, 2007 4:46 AM
To: Chris Lonvick
Cc: [EMAIL PROTECTE
Hi Folks,
David Harrington and I had a talk about syslog-sign and its dependencies
upon 3195bis. As was noted in the email discussion it would be messy to
try to publish syslog-sign with dependencies upon 3195, then update 3195,
then revise syslog-sign. We had a talk with Sam Hartman, our AD
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.
http://www
Hi,
The Chairs have been discussing this already. We have a candidate to
write the update. The length limit in RFC 3195 was constrained by RFC
3164 and we have moved beyond that with the transport IDs which identify
realistic maximum lengths. Updating RFC 3195 to have a greater length
shou
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 i
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
P.S
--
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-2
the WGLC
ends.
Thanks,
Chis
On Tue, 19 Dec 2006, Rainer Gerhards wrote:
Chris,
-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
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, PROCID,
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
sysl
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 between
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
http://www.employees.org/~lonvick/sign-18-19.htm
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 Work
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 this
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
Tom Petch
- Original Message -
From: "Chris Lonvick" <[EMAIL PROTECTED]>
To: &quo
dedicated 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: <
] SECURITY
[WG] syslog
[I-D] draft-ietf-syslog-protocol-19.txt
[Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt
[Shep] Chris Lonvick
===
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document
-ietf-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
===
(1.a) Who is the Document Shepherd for this document? Has the
Doc
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 t
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 concensu
Hi Rainer,
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]
Subject
for AD review.
[Area] SECURITY
[WG] syslog
[I-D] draft-ietf-syslog-protocol-18.txt
[Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt
[Shep] Chris Lonvick <[EMAIL PROTECTED]>
===
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally re
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 Sh
Hi Juergen,
enc has been dropped from syslog-protocol.
Thanks,
Chris
On Wed, 15 Nov 2006, Juergen Schoenwaelder wrote:
Hi,
I have just read draft-ietf-syslog-protocol-17.txt and I found some
minor issues and I thought I let you know about them.
a) The text describing example 1 in section 6.
B.
http://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
cause I
co-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,
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 se
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
http://www.mail-archive.com/sysl
h 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/
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 implementa
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 Folks,
We've received a liaison letter from the OIF. It's been accepted by the
IETF Secretariat and posted in the Liaison Statement repository.
https://datatracker.ietf.org/public/liaisons.cgi
Please take a moment to review the importance of our work to the OAM&P
Working Group of the O
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 Syslo
Hi All,
Please do consider the version field. If we don't have one, we would have
to live forever with the decisions we are making now. Having a version
number in there would allow a future group to re-decide things (like
byte-count v. special character) and to just change the version number
Hi,
As everyone should recall from Section 4.8 ("Hash Block") from
syslog-sign,
The hash block is a block of hashes, each separately encoded in base
64. Each hash in the hash block is the hash of the entire syslog
message represented by the hash. The hashing algorithm used
effect
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:
... 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 an
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 Harrin
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 escap
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
the syslog message payload?
Will that always have to be escaped by the sender and reversed by the
receiver?
Thanks,
Chris
On Mon, 14 Aug 2006, Tom Petch wrote:
- Original Message -
From: "David Harrington" <[EMAIL PROTECTED]>
To: "'Chris Lonvick'&quo
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 (sum
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 u
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,
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
On Thu, 6 Jul 2006, Tom Petch wrote:
B) As the document is technically inadequate as a standard for syslog over TLS,
we
would also benefit from a fresh start with an editor without H*** in their
e-mail address.
Tom Petch
Tom,
This is inappropriate.
First, remarks that discredit any group or
Hi Folks,
Everyone has now had a week to think about the IETF process on IPR claims.
The first decision that we need to make is about the terms of the claim.
I'd like to hear what people think about the terms that Huawei has
presented.
https://datatracker.ietf.org/public/ipr_detail_show.cgi?
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.
If Bazsi (or anybody else) can propose changes to
draft-ietf-syslog-transport-tls and the WG reaches consensus on the
prop
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 abou
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 o
Hi Folks,
I've got lots in my inbox that I can't catch up to this week but this
caught my eye. I have not received anything back from Huawei about the
specific claim, but according to RFC 3979 they don't have to.
Thanks,
Chris
-- Forwarded message --
Date: Wed, 21 Jun 2006 1
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 wit
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 then
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 di
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 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
royalty
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,
On Thu, 8 Jun 2006, Balazs Scheidler wrote:
On Thu, 2006-06-08 at 09:38 +0200, Rainer Gerhards wrote:
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 t
Hi,
RFC3979 is our guide here:
http://www.ietf.org/rfc/rfc3979.txt
From Section 2 of that document:
===
RFC 2026, Section 10 established three basic principles regarding the
IETF dealing with claims of Intellectual Property Rights:
(a) the IETF will make no determination about the
Hi Miao,
We will submit syslog-transport-tls before syslog-sign is submitted to the
IESG. Please take references of syslog-sign out of syslog-transport-udp
so that it is not held up in the RFC Editors queue.
Thanks,
Chris
On Fri, 19 May 2006, Miao Fuyou wrote:
In current security conside
Hi Anton,
Your proposal seems to be overlapping syslog-sign.
I think that what the community would like (this is open for debate) is
for a standard that will allow an existing implementation of syslog to use
syslog/tls in a standard way right now. The next step would be to convert
to syslog-
Hi Folks,
We have a lot of work to do in a short time. Since I've gotten busy with
many things and can't dedicate as much time to this as I'd like, I've
asked David Harrington to Co-Chair this Working Group with me.
David has offered very good advice to this Working Group in the past and
he
Hi,
I've updated our WG page:
http://www.employees.org/~lonvick/index.shtml
The most important piece of work at this moment is a review of
syslog-transport-tls.
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-00.txt
Let's get the discussion going on this. Once we get
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)"
Subject: Re: Why are we doing netconf?
Hi Folks,
This has been a debate in the netconf WG for some time. I've had talks
with many of the people participating in netconf over the past few years.
I've been urging them to use syslog-protocol if they decide to pursue
notifications within netconf. At various past IETF meetings I've us
Hi All,
This sounds good and I believe that we have had a reasonable discussion of
all of the options. Unless there are strong objections, I'll ask Fuyou
and Yuzhi to incorporate this into their document.
Thanks,
Chris
On Sat, 18 Mar 2006, Balazs Scheidler wrote:
On Fri, 2006-03-17 at 17:
Hi,
Why wouldn't this information be contained in a structured data element
within each frame?
Thanks,
Chris
On Fri, 17 Mar 2006, Rainer Gerhards wrote:
Bazsi,
Agreed, let's go for octet-counting. How would that look like? Two
octets before every message? That would limit message size to
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,
This is an issue that we need to discuss. I've had some discussions with
various people on this subject who's opinions I trust. They also suggest
that we do have 2 options as Rainer states. Let me describe this in a bit
more detail:
The consensus from all is that syslog-protocol shoul
1 - 100 of 160 matches
Mail list logo
