Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim

From: Darren Reed <[email-masked]>
Date: Tue, 4 Jul 2006 05:27:28 +1000 (EST)

Chris,

The approach I'd like to take is to see what Balazs Scheidler can
come up with, that is different to the proposed approach, to make
syslog function over a TLS transport in syslog-ng and look at turning
that into an i-d.

While it may not guarantee us any better situation with respect to
patents, etc, I have more faith working on documenting something
that is written to be open and free than involving people who have
a financial interest in the protocol going in certain diretions.

I suppose this is a get working code first and then refine/
document it.

Thoughts?

Darren

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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 4 Jul 2006 09:14:02 +0200

Darren,

I think this is a good proposal, though most importantly Balazs needs to
like it ;)

I just see one problem. We need to deliver a secure transport by
November. Implementing, documenting and discussing a new approach is
probably beyond that time frame (especially given the summer holidays).
So it might still make sense to use either the current -transport-tls or
do a very minimalistic 3195bis.

So we agree on the medium-term approach but not necessarily on the
short-term one.

Rainer

> -----Original Message-----
> From: Darren Reed [mailto:[email-masked]] 
> Sent: Monday, July 03, 2006 9:27 PM
> To: Chris Lonvick
> Cc: [email-masked]
> Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim
> 
> Chris,
>

---

From: Balazs Scheidler <[email-masked]>
Date: Wed, 05 Jul 2006 11:32:54 +0200

> I suppose this is a get working code first and then refine/

Sorry, for being absent from the group for a couple of weeks, I was
getting married and it took some time and distracted a bit from my work.
But I'm back again.

About the proposal. Thanks Darren, I'm honored. However, I'm not sure
this is a very good idea. I was really pondering with the idea of
implementing something in syslog-ng that works now and avoid waiting for
the results of this group indefinitely. 

However I don't think this would respect the work of this group, and
probably what I'd come up with would not be that different from what was
defined here so far, especially as I was trying to be involved in the
discussion. 

RFC3195bis is a nice idea, even though I previously disliked that
protocol myself. I'll have to reread that RFC to form my opinion.

-- 
Bazsi

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 5 Jul 2006 09:25:55 -0700 (PDT)

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
proposed changes, then the document will be revised to reflect that.

Please check me if I'm wrong on this, but I think that the only changes 
between syslog-ng and what's in syslog-transport-tls are
- framing,
- changes to address the threat model (listed in our Charter).

Thanks,
Chris

---

From: Balazs Scheidler <[email-masked]>
Date: Wed, 05 Jul 2006 19:13:27 +0200

> - changes to address the threat model (listed in our Charter).

Yes, the changes are about as simple as that. syslog-ng currently uses
EOL characters for record termination, and we agreed to using
byte-counted records instead to permit any kind of character within the
message.

-- 
Bazsi

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 6 Jul 2006 09:56:19 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Chris Lonvick" <[email-masked]>
To: "Darren Reed" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 05, 2006 6:25 PM
Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim

> final revision must reflect WG consensus.

I think that draft-ietf-syslog-transport-tls is seriously flawed and I have
already made some comments on this, have others pending.  But I am now reluctant
to make any constructive suggestions lest my text be slightly modified,
incorporated into this I-D and then made subject to an IPR claim.

I believe we need a new document, or at least a new editor who is prepared to
rewrite everything.  I am not saying it should be that of Bazsi, just anyone who
does not have H*** in their e-mail address.

Tom Petch

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 6 Jul 2006 12:02:48 +0200

Tom,

I do not know if rewriting really helps. I suspect Huawei's patent
lawyers, like patent lawyers everywhere, did a good job in wording the
patent application so generally that probably evertyhing we do in
respect to syslog/tls would fall under their claim. Eventually, that
would even apply to anything that securely transports syslog. You do not
know without the claim details. I'd guess it says something like
"transporting system logs over a secure channel" ;).

My personal opinion is that we should continue with -transport-tls,
Chris' A) option. My reasoning:

1. the proposed licensing terms look fair enough to me
2. the patent is probably quite "trollish" and it is 
   questionable if
   a) it will be granted at all
   b) survive appeal (if somebody appeals)
3. I'd like to see documented and standardized a tls transport
   as it is already in use today. This hopefully helps getting
   it quickly implemented.

A technical issue regarding 3: I know that the current approach is
flawed. Maybe I do not see all the seriousness of it. I still think it
is good enough as a starting point, bringing together what is done in
practice already. Once we are finished with transport-tls, we can look
into better alternatives. One such is 3195bis, the other -transport-ssh.
-transport-ssh probably has most potential when it comes in trying to
converge different NM protocols. But we could also end up defining no
separate transport but using NETCONF notifications with a syslog event
message data model.

I do not know how to prevent that your comments (and mine and anybody
elses) comment become part of Huawei's IP. Maybe it would help to
publish them as a separate document, if the volume justifies that.

All in all, I still go for option A) as the best compromise. This is
made on the understanding that we do *not* modify/enhance -transport-tls
much further (just the bare necessities). This argument is based on my
"we must publish" POV.

Rainer

> From: Tom Petch [mailto:[email-masked]] 
> Sent: Thursday, July 06, 2006 9:56 AM
> To: Chris Lonvick
> Cc: [email-masked]

---

From: Balazs Scheidler <[email-masked]>
Date: Thu, 06 Jul 2006 18:26:30 +0200

> protocol myself. I'll have to reread that RFC to form my opinion.

I have now refreshed my memories on RFC3195, and my technical opinion is
as follows:

beep in general:
- I like its extensibility and multiple channels, and its support for
optional authentication/encryption
- I don't like its complexity as we have to think with embedded devices
in mind
- depends on a whole lot of things, and as I see generating the XML
constructs should use a real DOM implementation, as constructing XML
with sprintf is asking for trouble (ie: escaping)

syslog/raw profile:
- this profile does not offer anything more than simple syslog over TCP
as currently implemented in syslog-ng and other products, it has
significant overhead though: 
  - bandwidth wise: about 30 octets per message, 
  - code wise: the beep framework (beep itself, xml, character sets,
entities etc), this can be simplified significantly by supporting a
single channel only, always using utf8 and hand-crafting XML with
sprintf/parsing it with sax/handmade parser
- this profile does not solve record termination, where the latest
consensus was to be completely transparent for any unicode character, in
syslog/raw CRLF line termination is used when multiple messages are
included in a single BEEP frame.
- the profile permits a maximum of 1024 bytes per message

syslog/cooked profile:
- I like the fact that every hop in the message path is properly
identified, and proper identification of senders can be performed,
- I like that application layer ACKs are present, however I think that
it is too verbose (about 30-35 bytes to acknowledge a single  message,
about 35-40 to nack it)
- I don't like that the new format still uses BSD timestamp, no year and
no timezone information

So as I see, there is absolutely no point in implementing syslog/raw,
using the existing protocols is enough for legacy support and
implementing syslog/raw is not any easier than using syslog/cooked. And
it has issues with record termination and maximum message length.

syslog/cooked could be updated with the latest header changes in
syslog-transport-udp and with some adjustments it could provide a nice
platform for new protocol features in the long run.

What this boils down, is that I could support RFC3195bis, especially if
we decide that we are bothered by the IPR claim of Huawei.

-- 
Bazsi

---

From: "David Harrington" <[email-masked]>
Date: Thu, 6 Jul 2006 13:25:57 -0400

Hi Tom,

The editors' responsibility is to make the document reflect WG
consensus, as best they can.

The co-chairs and the AD are responsible for ensuring that the editors
represented the WG consensus in the document, and to determine WG
consensus if it is not clear to the editors.

Please propose text worded as you wish to see it, and ask for WG
comments.
If Chris feels there is WG consensus on the wording, then that wording
would go into the document, without being slightly modified. 

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> Sent: Thursday, July 06, 2006 3:56 AM
> To: Chris Lonvick
> Cc: [email-masked]