Hi,
<apologies for the delay; I'm battling what seems to be a hardware
fault in the disk drive of my laptop. chkdsk (ntfs) gets to 48% of
the C: partition and then sits there _forever_ while making sounds
such as "zzzzt, zzzzt, zzzzt, thonk, thang" - (International: "zzzzt,
zzzzt, zzzzt, thonk, thäng"). It seems to continue to be operational
as long as I don't try to access one specific filder on the C: drive
so I'll use it until I can get a replacement.>
: responding to this and the other comments :
At 10:35 PM 4/5/01 +0200, Albert Mietus wrote:
>First, let me say that I'm sorry to not send this comment earlier, As
>I already noticed them in *-6 (which is the 1st I saw), but I hope my
>bits help.
OK, I was this close >< to getting this one in front of the IESG. :-)
>Some comments
>
>General
>=======
>
>I think the RFC becomes a lot clearer when the syslog message is
>described in three parts, instead of as 2 parts.
>Now, the message is described as (informally)
> syslog := PRI MSG
> PRI := "<" up-to-3-digits ">"
> MSG := [ 3-header-parts ] free-text
>Then, in text is explained that the "3-header-parts" (timestamp,
>host and tag) are more or less default [my interpretation]
>
>I suggest to rewrite this, so that the message consist of 3 parts, of
>which 1 is optional. Like (again informal)
> syslog := PRI HEADER CONTEXT
> PRI := "<" up-to-3-digits ">" -- as before
> HEADER := "" -- empty, not recommended
> :or: 3-header-parts -- as before
> CONTEXT := free-text
>Basically, the "HEADER" part is inserted into the description
>(notice: not to the protocol) This way, it becomes clearer how a
>message is buildup (read: as it should be build-up).
It sounds like other agree that 3 parts will be clearer. I'll give
that a shot.
>Details
>=======
>
>4.2.4 (HOSTNAME size)
>---------------------
>I'm missing a hint/recommendation about the maximal size of the
>HOSTNAME part. Although this RFC will not specify the size of a
>hostname; its size is important.
>Maybe a RECOMMENDED on the max HOSTNAME length (how about 32 bytes)
>can be included. With this is added, a (recommended) minimal size of
>the CONTEXT can be calculated
I think that making any recommendation may conflict with STD-13.
I'd prefer to just reference the authoritative source of that
information.
>CONTEXT (is this right?)
>------------------------
>As I'm not a native speaker of English, I can be wrong. But I'm
>thinking tha CONTEXT is a misleading word. I usually mixup "context"
>en "content". But I'm quite sure the latter word is more appropriate
>within syslog's rfc.
>And just maybe, the word "message" or "error" is even better.
>(Hope not to (re)start a flamewar:-)
The way that I learned the word:
Context - The whole text of a discourse or writing.
..but I'm not stuck on it. I'll go with CONTENT unless anyone objects.
>HOSTNAME, with/without domain (several places)
>----------------------------------------------
>* In 4.2.3 is stated that HOSTNAME MUST NOT include the domainname (New
>in *-07, I think).
>* Whereas, in 5.2 can be found (I quote)
> "... Traditionally, however, only the hostname
> has been included in the HOSTNAME field."
>This can be misleading; especially as 5.2 describes the FQDN (so
>including the domain) is a good idea (in the content part)
>* Example 4 includes a domainname in the (not valid) HEADER part. This
>example is about a non-valid TIMESTAMP, so the use of the FQDN can
>give the wrong impression about hostnames. Either use a hostname only
>or add a paraphrase about the invalid HOSTNAME part
>* In 4.2.1 is stated that the HOSTNAME is "as it knows itself". Many systems
>know them-self including the domainname (e.g use `hostname` on a un*x
>system). Please add something like "only the systemname, not including
>a domainname"
OK. I'll patch these up.
>HOSTNAME, for relays
>--------------------
>4.2.2 says that a relay should (sometimes) add a HOSTNAME, or a
>IPno, when the device's HOSTNAME isn't known. What is the IPno of the
>(sending) device isn't known (which probably is only possible in
>theory).
I'd have to say that a device must know its own IP address. If it
is too difficult for the equivalent of syslogd on some device to
look it up, it could send it without the name or address as that
(and most other fields) are optional. I really don't want to
encourage that behaviour so I would opt to continue saying that it
is preferable to use the hostname or the IP address. Thoughts?
>Also add something like "The IPno of the sending interface, when the
>device has serval interfaces"
I'd rather clear that up to represent both cases. In a Cisco router,
the default behaviour is to use the IP address of the sending
interface. However, you can specify the "sending IP address" to be
used on all syslog packets regardless of the interface it goes out on.
(I havn't looked at any other routers. ;-) Some people have used IP
Filter or similar to prevent the receipt of unwanted messages and they
don't want to have to list all of the interfaces of a router as being
in their 'permit' list. It's far simpler to just list one address and
then force the router to continually use that address. Thoughts?
>4.2.2, CONTEXT truncation, for relays
>Sometimes, a relay MUST truncate the package. However it isn't
>specified HOW this should be done, nor an advise is given. I think
>"removal of an appropriate number of bytes on the right-side" is
>meant. But this can be specified.
>On the other hand, removal of bugus HEADER bytes (so the left side of
>the newly CONTEXT field) is possible wiser.
"Truncate" implies chopping off the end. I'll be specific. Chopping
off the front is possible but I've never seen any receiver do that and
we are documenting existing observed behaviour. (The snips of Eric's
original code chops at the end. ;-)
>Hope my bits help, and with excuses for some misuse of the English language
>
>Albert Mietus
>PTS Software BV, Holland
>GSM +31 6 53732 336
>[EMAIL PROTECTED]
Thanks to Alfonso, Gregory, and Andrew as well as Albert for your review
and thoughts. If I missed anything specific in the follow-ups, please
bring it back to the list. I'll clear these things up (if my drive
cooperates) and get a new draft out rsn.
Let's continue to review syslog-reliable and keep it in WG Last Call
as well. Once we get the next version of syslog-syslog accepted on
the list, then we can give Darren a day to make sure the references
havn't changed and submit both of them to the IESG. I'll also take
this opportunity to encourage everyone to look over John's note on
syslog-sign.
Thanks,
Chris
