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
Hi,
[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
Hi,
As a co-chair looking for a way forward, I was considering asking for
..
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
As someone who works fr the offending company, I might point
out that the lodged IPR statement does not accurately reference
the draft at all. It talks about section IV and section V.
The current draft has no section IV or section V.
The draft does have sections labelled section 4 and section 5.
[ Charset ISO-8859-1 unsupported, converting... ]
Truncation of UTF-8 is actually slightly worse than has been described.
It is possible to determine from the UTF-8 octets where one coded
character ends and another begins. But because Unicode contains
combining characters, with no limit on
Anton and all,
I have now changed section 6.1 to:
###
6.1. Message Length
..
Well written and very sensible.
Darren
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
[ Charset ISO-8859-1 unsupported, converting... ]
Rainer and all:
..
Receivers SHOULD follow this order of preference when it comes to truncation:
1) No truncation
2) Truncation by dropping SD-ELEMENTs
3) If 2) not sufficient, truncate MSG
I don't think that this is a good
data for that field.
If you don't understand the difference here, I think the fields need
to be defined something like this:
field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255
missing ::= -
And as someone else pointed out to me, PRINTUSASCII includes the
:-) Just a comment on the list: it is my observation that sometimes
discussion peeks and at other times there is virtually none. For the
time being, I think everything that needed to be said is said and so
folks are waiting if I manage to come up with the right text to cover
the consensus [I
Darren,
I have seen nobody backing your position, so I think it was consensus to
ignore these comments.
And nobody decrying them either.
So are you saying, you need me too's on comments before you'll make
any replies to issues people bring up ?
It shouldn't take everyone to speak out about
Hi WG,
I have received notes via private mail telling me there seem to be some
existing (and eventually soon upcoming) valid use cases for binary data
in syslog. I think there is no point in arguing whether that's fortunate
or not. It simply looks like that's the way it is. I do not like
WG,
there has not been much discussion about the header fields and their
order recently. I think this is a sign the issue has been settled. To
make sure I got the right understanding of the resulting consensus, I
propose that we use the following format:
PRIVERSION SP TIMESTAMP SP
I think there is general agreement to specify minimum msg size, not
maximum msg size in syslog-protocol.
FWIW, I think this is a much better idea.
Darren
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
Are we happy to recharter when these are done to cover TCP ?
Darren
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
[ Charset ISO-8859-1 unsupported, converting... ]
Which system is this source from?
BSD
On Solaris, if you send \r\n characters, you will see ^M\n in the log.
Yes and Solaris allows for non-ascii data through the use of escaping.
Darren
___
Why?
Because the community implementing syslog protocol things seems to be
ignoring what the group has been doing.
This may be because they're unaware of the work or because it is being
regarded as a WTF?! and doing their own thing.
Most people seem to be ignoring 3195. Lets learn from that
I see it the other way round. If the charter can be specific, it should
be, to keep the subsequent discussion focussed on the more contentious
areas. Based on the post-Vancouver discussion, I see no alternative
to including PRI and if that is the case, then we should nail that
down now.
Rainer,
FWIIW, I've seen Netscreen, NetGear and some LinkSys devices send a Null
character at the end of each message. Not all versions of the firmware would
include the Null at the end which leads me to believe it may be a bug in
some releases of the firmware.
When sending syslog over
WG,
PRIVERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG
I would put the SD-IDs after the message.
This raises the question of what terminates the MSG part ;)
Using the above syntax, how do you distinguish between [] at the start
of the message from actualy SD-ID data?
I
2) Is there another charter under which the working group would better
be able to make progress?
I believe the answer to this is yes.
There is very relevant work this group could do and should do.
If you look at what the community at large has done with implementing
syslog in recent
Hi all,
If I get the essence in Darren's message right,
what he is proposing is to create a layered architecture for syslog.
Yes, by using what's gone before us as the way to start doing that.
Please face it: on the WG mailing list, we are pressing for ever and
ever change. More and more
Chris,
What I'd like to see happen is for 3195 to be broken up into 2 or
more new RFCs, one (or more) which cover the protocol and one which
defines their use over BEEP.
i.e. One which covers the COOKED profile, one which covers a RAW
profile and one which covers one or both of these over BEEP.
[ Charset ISO-8859-1 unsupported, converting... ]
1) What secure substrate should the WG look towards:
__ ssl
__ ssh
__ dtls
http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt
__ other
I believe it should be SSL 3.0 / TLS 1.0.
I agree and for all the
23 matches
Mail list logo
