Subject: [Syslog] IESG secure transport requirement can be quickly solved...

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 20 Jun 2006 15:43:30 +0200

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

Section 9:
- new URIs for 3195bis (also in some other places)
[we can reuse well-known port 601 for -protocol]

Overall
References to 3164 must be changed to -syslog-protocol. This seems quite
trivial, because the  references are easy to spot and do not touch any
substance (except outlined above).

Other than these minor things, there are *NO* other changes necessary.
I'd expect that an initial version of 3195bis can be created within a
single working day. Add some quick review and a very limited number of
edits to change discovered nits - and we have something to publish by
summer.

I find this extremely tempting. It breaks the deadlock situation we are
currently in. Especially as we have planned to do 3195bis some time
later anyhow. I don't know if the authors of 3195 would volunteer to do
the edit. But I hope so.

I would appreciate if the chairs could try to reach consensus on my
proposal.

Comments are appreciated.
Thanks,
Rainer

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 20 Jun 2006 07:05:10 -0700 (PDT)

Hi Everyone,

> Comments are appreciated.

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

---

From: "David Harrington" <[email-masked]>
Date: Wed, 21 Jun 2006 13:06:11 -0400

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-masked] 
[email-masked]
[email-masked]

> -----Original Message-----
> From: Chris Lonvick [mailto:[email-masked]] 
> Sent: Tuesday, June 20, 2006 10:05 AM
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: Re: [Syslog] IESG secure transport requirement can 
> be quicklysolved...
> 
> Hi Everyone,
> 
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 21 Jun 2006 14:44:15 -0400

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-masked] 
[email-masked]
[email-masked]
co-chair, Syslog WG

---

From: "David Harrington" <[email-masked]>
Date: Wed, 21 Jun 2006 13:58:07 -0400

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-masked] 
[email-masked]
[email-masked]

> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Tuesday, June 20, 2006 9:44 AM
> To: [email-masked]
> Subject: [Syslog] IESG secure transport requirement can be 
> quickly solved...
> 
> Hi all,
>

---

From: Darren Reed <[email-masked]>
Date: Thu, 22 Jun 2006 12:47:40 +1000 (EST)

> [speaking as co-chair]

Please resign as co-chair.

Your company is involed with IPR action regarding the work of this
group and until your company gives up this path, we cannot accept
any direction or input from you as co-chair.

I ask all those in this working group to ignore any email from David
Harrington in his role as co-chair as it compromises the abililty
of this working group to produce free, open standards.

Darren

---

From: Darren Reed <[email-masked]>
Date: Thu, 22 Jun 2006 12:49:44 +1000 (EST)

> As a co-chair looking for a way forward, I was considering asking for
..

Darren

---

From: Miao Fuyou <[email-masked]>
Date: Thu, 22 Jun 2006 13:49:24 +0800

Hi, 

IMO, most current security protocols(TLS, DTLS, SSH, IPsec) provide similiar
security service for application, such as confidentiality, integrity,
anti-replay and peer identity authentication. In the same time, most of the
applications share similiar security threats, such as hijacking, MITM,
falsification, eveasdropping etc. So, it may does make much sense to invest
too much effort on evaluating/matching security threats and service. In the
same time, most current security protocols come from security mechanisms
specific to some applications. For example, SSL was designed to secure HTTP,
SSH is an application protocol for interactive shell command. They are not
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? 

Taking convenience in mind: the order may be: DTLS -> TLS -> SSH -> BEEP(?)
-> IPsec

>From an implementer's perspective, I think DTLS costs the least  effort to
implement, TLS second. I have not much idea on how much SSH and BEEP take,
but I believe it cost more than DTLS/TLS. There is few RFC3195
implementation, it sounds bad to revive an market-abandoned solution to just
satisfy IESG. IPsec? It costs the specifcation and program developer
nothing, but it costs too much to provision, never a good solution for
Syslog.

My 1 cent!

Miao
> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, June 22, 2006 1:58 AM
> To: 'Rainer Gerhards'; [email-masked]
> Subject: [Syslog] Secure transport alternatives
> 
> Hi,
> 
> 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?
>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 22 Jun 2006 09:43:22 +0200

Darren,

I think we have been through this. I see your point and I agree that the
IPR action is, well, unfortunate ;) [I had some stronger words in
previous posts and still fully support them] I also understand and to
some extent support the position that there is some personal liability
of a high-rank person with the companie's actions.

HOWEVER, I do not find it productive to try to force David out of this.
Yes, there is a problem. We are aware of it. I think we can handle it.
But David's advise is very well thought-out, he has lots of IETF
experience and he is still willing to help. I also can only spekulate on
his personal involvement in the IPR issue. I do not know what he has
advised. Also, I think we *need* his help if we intend to reach our
goal. I still very much welcome him in the co-chair position. If for all
upcoming next drafts similar IPR issues from Huawei arise, I would very
probably be fully on your side. So far, I consider it as a single case
and hope that the lessions are already learned. Actually, I am not ready
to sacrifice a syslog standard for the sake of penalizing Huawei. That
wouldn't help anything ... and it wouldn't even be smart ;) Huawei (and
the probably just unfortunate I-D editors) is already penalized by the
growind dis-acceptance of the TLS draft. I personally would also object
any further I-D author from Huawei right at this stage. This is not
because I distrust the author but Huawei's legal department.

We have put so much work into this syslog effort, we shouldn't give up
just because of a single incident. And IMHO we give up on it if we try
to fight out this issue right at that time. I suggest we cool down a
little and let things evolve. That will also provide better picture of
who does what.

Just my 2cts, but I hope I find support for it.

Rainer

> From: Darren Reed [mailto:[email-masked]] 
> Sent: Thursday, June 22, 2006 4:48 AM
> To: David Harrington
> Cc: 'Chris Lonvick'; Rainer Gerhards; [email-masked]

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 22 Jun 2006 09:58:40 +0200

Miao,

technically, I agree with you. HOWEVER, I need to point out that your
company is the root cause of the problem. The IPR rights claimed on your
transport-tls document have taken it hostage. Even though the licensing
terms seem reasonable (which needs to be prooven in undisclosed detail),
there honestly is nothing novel in the draft. Your legal department is
not even telling us which section is claimed to have been invented by
Huawei. The simplest and most productive way to solve the current issue
is make your legal department drop the patent claim. My understanding is
that it can be easily challenged (for those with big legal
departments...) so it will probably be without substance, too.

You should also talk to your legal department and superiors that
Huawei's peformance in this WG is costing Huawei a lot of its goodwill
in the community and probably even in the end-user space. For example,
the largest German IT-Site (Heise press[1]) has carried a story about
Huawei's move and Huawei has not made a good picture in the user
feedback. I also promise that I personally will try to get more press
coverage of this move. 

It is one thing to secure one's intellectual property. It is another
thing to be a patent troll. And it is yet another thing to be a patent
troll who steals other people's work. I have to admit that I consider
Huawei (as far as the syslog WG is concerned) to be part of the third
camp.

Get *that IPR issue* solved and the technical issue is solved, too. In
the mean time, we try to provide an open standard. RFC 3195bis seems to
be the most appropriate choice here, because it can't be taken hostage
by another abusive patent claim as it bases on well-defined prior art
(RFC 3195). Far more important standardization efforts have been brought
to a hold by IPR claims  (think: SPAM). Claiming IPR where there are
none is of no utility. Huawei needs to learn this.

[1] http://www.heise.de/newsticker/meldung/74342 (in German)

Rainer 

> From: Miao Fuyou [mailto:[email-masked]] 
> Sent: Thursday, June 22, 2006 7:49 AM
> To: 'David Harrington'; Rainer Gerhards; [email-masked]
> Subject: RE: [Syslog] Secure transport alternatives
> 
> 
> Hi, 
> 
> > > implementing it becomes easier as support libraries 
> become visible.
> > I
> > > syslog-transport-tls, which has been encrumbered by a 
> patent claim.
> > As
> > >  - handling of invalid message formatting must be removed 
> (no longer
> > a
> > > concern)
> > > I'd expect that an initial version of 3195bis can be 
> created within
> > a
> > > single working day. Add some quick review and a very 
> limited number
> > of

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 22 Jun 2006 09:35:33 +0200

David

You will know, and the archives show, that I spent much time in 2005 arguing for
SSH as the transport for isms and, happily, the WG agreed.  The archives also
show that my efforts in syslog were to no avail and the WG overwhelmingly chose
TLS.  The argument in favour was the marketing one - syslogoTLS is already out
there, just feel all those 220,000 hits in Google.  And it was on that basis,
that WG member's would commit to producing such products, that the WG was
rechartered, as opposed to being wound up.

(I now see that I should have threatened the syslog WG with an IPR claim on TLS
and then we would not be having this discussion :-)

But, in all seriousness, changing from TLS to anything is a charter change that
I think needs the approval of the IESG, and should require commitment, similar
to that given at the turn of the year, to produce conformant products.

Tom Petch

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 22 Jun 2006 10:48:16 +0200

Tom,
> to that given at the turn of the year, to produce conformant products.

I do not agree here. We have deliberately not used the term "TLS" in the
charter. The relevant excerpts are:

###
The threats that this WG will primarily address are modification,
disclosure, and masquerading. A secondary threat is message stream
modification. Threats that will not be addressed by this WG are DoS and
traffic analysis. The primary attacks may be thwarted by a secure
transport. However, it must be remembered that a great deal of the
success of syslog has been attributed to its ease of implementation and
relatively low maintenance level. The Working Group will consider those
factors, as well as current implementations, when deciding upon a
secure transport.
###

###
- A document will be produced that requires a secure transport for the
delivery of syslog messages.
###

As far as I remember (not looked up the archive yet), we did this
intentionally so that we could change transports if need arises. At
least for now, I think this need has arisen.

The really bad thing about the IPR claim is that we do not even know
what actually has been claimed. But I do not intend to invest any of my
work into something that somebody else claims exclusive rights on. So
-tls is a dead end for me as long as the claim is not dropped. I foresee
similar harsh reaction at least of the open source commuity (*the* major
driving factor behind syslog implementation) when we standardize
something encrumbered by a patent.

Rainer

---

From: Darren J Moffat <[email-masked]>
Date: Thu, 22 Jun 2006 11:14:08 +0100

> convenient for the application to invoke the security service provided by

That to me sounds like GSSAPI or SASL.

Any reason these aren't being considered ?

-- 
Darren J Moffat

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 22 Jun 2006 12:02:54 +0200

Rainer

Looking at the outstanding milestones, I see

Nov 2006    Submit Syslog UDP Transport Mapping to the IESG for consideration as
a PROPOSED STANDARD
Nov 2006    Submit Syslog Protocol to the IESG for consideration as a PROPOSED
STANDARD
Nov 2006    Submit Syslog TLS Transport Mapping to the IESG for consideration as
a PROPOSED STANDARD
Nov 2006    Submit Syslog Device MIB to IESG for consideration as a PROPOSED
STANDARD
Nov 2006    Submit a document that defines a message signing and ordering
mechanism to the IESG for consideration as a PROPOSED STANDARD

which is why I see TLS as embedded in the charter (as well as, more obscurely,
in the discussions that led up to the charter change).

Tom Petch

----- Original Message -----
From: "Rainer Gerhards" <[email-masked]>
To: "Tom Petch" <[email-masked]>; "David Harrington"
<[email-masked]>; <[email-masked]>
Sent: Thursday, June 22, 2006 10:48 AM
Subject: RE: [Syslog] Secure transport alternatives

Tom,

###

###

Rainer

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 22 Jun 2006 14:13:19 +0200

Tom,

I have to admit I have overlooked this item. I agree that we (especially
me) were very TLS-minded. My memories tell me we intentionally left the
door open for other transports, but I may be wrong. As it looks, I need
to re-visit the mailing list archive. I hope I will be able to do so
soon.

I also have on my mind that we intended to do 3195bis after tls was
finshed, so we did not plan to totally abandon it. Again, all of this
out of my memory...

Rainer 

> From: Tom Petch [mailto:[email-masked]] 
> Sent: Thursday, June 22, 2006 12:03 PM
> To: Rainer Gerhards; David Harrington; [email-masked]
> Subject: Re: [Syslog] Secure transport alternatives
> 
> Rainer
> 
> > > > to submit syslog-protocol, -transport-UDP and 
> RFC3195bis within a
> > > few
> > > > weeks.
> > > >
> > > > We all know that 3195 has limited acceptance in the 
> community and
> > > very
> > > > our charter. Also, it *is* something that can be used 
> in practice
> > > and
> > > > am saying this on the assumption that we do not revisit 
> the basics
> > > of
> > > > trivial, because the  references are easy to spot and 
> do not touch
> > > any
> > > > edits to change discovered nits - and we have something 
> to publish
> > > by
> > > > summer.
> > > >

---

From: "Moehrke, John \(GE Healthcare\)" <[email-masked]>
Date: Thu, 22 Jun 2006 08:20:51 -0400

An advantage of TLS over SSH that is not technical in nature is that
TLS/SSL is already found in very low end devices as it is used for other
purposes. Utilizing it is far better than requiring that these devices
now take on the additional SSH (or other) protocols. SSH tends not to be
as widely deployed in embedded systems as most of it's general purpose
uses are in interactive-remote-control type applications.

John

> Sent: Thursday, June 22, 2006 7:13 AM
> To: Tom Petch; David Harrington; [email-masked]
> netconf/SSH
> > > > > it looks, this will need months to solve. RFC3195bis 
> can not be
> > > > taken

---

From: "David Harrington" <[email-masked]>
Date: Thu, 22 Jun 2006 08:36:10 -0400

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-masked] 
[email-masked]
[email-masked]

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, June 22, 2006 6:14 AM
> To: Miao Fuyou
> Cc: 'David Harrington'; 'Rainer Gerhards'; [email-masked]

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 22 Jun 2006 15:02:56 +0200

David,

> from the netconf-over-SSH draft. 

I have gone throught the netconf-over-ssh draft with syslog on my mind.
I agree, it should be fairly easy to adapt.

> been much expresseed interest in netconf over BEEP.

I agree it is questionable if RFC 3195 will succeed. I have seen some
companies (also at least one of the big guys) make investment in 3195. I
am not sure if it simply is too early to abandon it. If we do not want
to abandon it, we need to create a 3195bis, because 3195 will not be
usable together with syslog-protocol (because it mandates a different
format).

> the WG can compare the three approaches? 

After my review, I think I am able to do that. So I volunteer.

> that as a syslog secure transport solution?

I, too, think this is an option. Wouldn't it be sufficient to adopt
draft-shafer-netconf-syslog-00.txt as a WG document? (Provided Phil
would be happy with that...). I guess that would obviously involve some
coordination between the syslog and netconf WG, which I hope is not a
big problem.

Rainer

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 22 Jun 2006 17:09:22 +0200

David, WG,

> From: David Harrington [mailto:[email-masked]] 

[snip]

> 1) please indicate which secure transports you consider to be

-transport-ssh, rfc3195bis, [-transport-tls]

> 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

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-ssh-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.

> 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

---

From: Darren Reed <[email-masked]>
Date: Fri, 23 Jun 2006 01:18:37 +1000 (EST)

David,

Your actions as co-chair of this group represent a conflict of interest
for so long as Huawei maintains it has an intellectual property claim
with respect to its work.  I would request that you either step down as
co-chair of the group, cease employment with Huawei or convince Huawei
to cease the IPR action.  Of course the latter two of these are not what
I would call reasonable demands to make of anyone given that there are
financial issues (and more) involved, but I would request that you
step down as co-chair of this group.

I would also ask Darren Moffat (and others within this IETF group)
to ignore this request and others coming from you, regardless of their
relevance to the IPR,  because your involvement with Huawei makes you
unfit for this role within the syslog IETF group.  If you do not wish
to step down then the best we can do is to ignore your attempts to
continue to function in this role and continue to apply pressure for
it to be resolved.

This group needs to develop open standards, not IP for Huawei.
Your involvement as co-chair and Huawei's IPR claim cast that
shadow over this group.

I'm sure we all would welcome your continued involvement with the
group, just not as co-chair.  If Chris is having difficulties with
managing the IETF side of things by himself then I'm sure we can
find someone else to fill in for you.  In no way am I implying you
are doing a bad role now or in the past, just that your current
association makes you ineligable for being co-chair.

Cheers,
Darren

---

From: "David Harrington" <[email-masked]>
Date: Thu, 22 Jun 2006 12:22:00 -0400

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-masked] 
[email-masked]
[email-masked]

> Sent: Thursday, June 22, 2006 11:09 AM
> To: David Harrington; Chris Lonvick
> Cc: [email-masked]
> Subject: RE: [Syslog] IESG secure transport requirement can 
> be quicklysolved...
> 
> David, WG,
> 
> > > > I would appreciate if the chairs could try to reach consensus
on
> > my

---

From: "David Harrington" <[email-masked]>
Date: Thu, 22 Jun 2006 12:37:19 -0400

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-masked] 
[email-masked]
[email-masked]

---

From: Darren J Moffat <[email-masked]>
Date: Fri, 23 Jun 2006 09:07:35 +0100

> [posting as a contributor]

I'll see what I can do but I'm not sure if I have the time available in 
the next couple of months.

-- 
Darren J Moffat

---

From: Miao Fuyou <[email-masked]>
Date: Fri, 23 Jun 2006 18:04:19 +0800

> 1) please indicate which secure transports you consider to be 

TLS/DTLS/SSH/BEEP/GSSAPI

> 2) please indicate which secure transports address which 
> syslog threats (they're listed in syslog/tls),

Similiar

> 3) please indicate which secure transport you volunteer to 
> write a draft for, and
> implement in your products  (and do you have the 
> decision-making authority to commit what gets implemented in 
> shipping products?).> 

TLS/DTLS

-----Original Message-----
> Sent: Thursday, June 22, 2006 2:44 AM
> To: 'Chris Lonvick'; 'Rainer Gerhards'
> Cc: [email-masked]
> 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. 
> 

TLS/DTLS

> 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
> 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-masked]
> [email-masked]
> [email-masked]
> co-chair, Syslog WG 
> 
>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 23 Jun 2006 14:24:44 +0200

Hi David,

thanks for the advise, I will do as suggested. I am currently thinking
about the framing used inside the session. Once ready, I will publish it
on my website and send a link to the WG. I would appreciate, though,
some feedback on the overall picture based on what I currently have:

Thanks,
Rainer

> Sent: Thursday, June 22, 2006 6:22 PM
> To: Rainer Gerhards; 'Chris Lonvick'
> Cc: [email-masked]