RE: [Syslog] Dbh re-Review of -mib-11, part 3
Just one comment... In general the default values will be used ( IPv4, UDP, port 512 etc.) by syslog entities. 514 is the IANA assigned port for UPD syslog. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
syslog architecture Re: [Syslog] Mib terminology and MIB design
An architecture is very useful for me as long as it captures the essence of the engineering being architected, and this I am becoming increasingly unclear about. My use case is masses of dumb devices that just about support syslog (with a struggle) feeding a small number of powerful servers. Others on the list talk of servers as senders while the existence of relays is highly plausible. I now know of the Windows case of multiple applications each as its own sender but you now seem to be extending that to a host (to use the IP term) with multiple syslog processes each of which can be sender/relay/collector; and that seems an over-complication which noone is asking for. We already have an architecture - sender, relay, collector - which allows for a combined collector/relay and sender/relay (as defined in -protocol). I think we need a good reason to move away from that. Note in passing that -protocol uses the terms 'application' and 'system' Tom Petch - Original Message - From: David Harrington [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 15, 2006 7:23 PM Subject: RE: [Syslog] Mib terminology and MIB design Hi, [posting as a contributor] Tom mentions that we should not use the term entity here, because it conflicts with the SNMP usage of that term. Since this is a MIB module designed for use in an SNMP environment, that is a really good point. It would hurt us to have conflicts between the terminology used to describe syslog things, and the terminology used to describe SNMP things in this mib module. Which raises an interesting question. Is the terminology used for syslog and the terminology used for SNMP compatible? Could we make them more compatible (without modifying any of the other syslog documents?) One approach to consider would be to use the RFC3411 descriptive architecture to describe the syslog architecture. The processes of preparing messages, dealing with message security, and sending messages via different transports are all services provided by the engine: +---+ | SNMP entity | | | | +-+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | ++ | | | | | Transport | | | | | | Subsystem | | | | | ++ | | | | | | | | ++ ++ +---+ +---+ | | | | | Dispatcher | | Message| | Security | | Access| | | | | || | Processing | | Subsystem | | Control | | | | | || | Subsystem | | | | Subsystem | | | | | ++ ++ +---+ +---+ | | | +-+ | | | | +-+ | | | Application(s) | | | | | | | | +-+ +--+ +--+| | | | | Command | | Notification | | Proxy|| | | | | Generator | | Receiver | | Forwarder|| | | | +-+ +--+ +--+| | | | | | | | +-+ +--+ +--+| | | | | Command | | Notification | | Other|| | | | | Responder | | Originator | | || | | | +-+ +--+ +--+| | | +-+ | | | +---+ One engine can support multiple SNMP applications. SNMP applications are the things that define the roles, e.g. a notification originator (Cf: a syslog sender), a notification receiver (Cf: a syslog receiver), and a proxy forwarder (Cf: syslog relay). The RFC3411 architecture also supports command generator (that makes requests) and command responder (that processes requests and responds) that do not apply to syslog. The SNMP applications describe functionality that is combined with other functionality provided by software or devices; to put this in syslog terms, the facilities would utilize the SNMP application style functionality to generate, receive, or relay messages. Since this is a MIB document, we could provide
[Syslog] RE: Framing...
Hi, The chairs believe there is consensus, and will ask Miao to change the -tls- document to say that FRAME-LEN is the count of the octets of the SYSLOG-MSG. dbh -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Monday, December 18, 2006 9:55 AM To: Chris Lonvick; David Harrington; Miao Fuyou Subject: Framing... Hi all, I just wonder if we have reached consensus to change the octet counter to just cover the SYSLOG-MSG len. I have to admit that I am hesitant to release the open source software with the wrong framing. I know that it is not appropriate to claim anything of an implementation of a draft, but as it looks we have consensus, I'd like to release what will most probable become reality. Of course, I'll include big disclaimers on that functionality. But on the other hand, I would really like to get some feedback from practice. I am also preparing a document that describes why I have implemented the framing and why it is a big advantage over traditional syslog/tcp. If we have a consensus, could we declare it? Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt
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 syslog protocol as defined in RFC [14] because it utilizes the STRUCTURED-DATA elements defined in that document. It may also be used with syslog packets over traditional UDP [4] as described in RFC 3164 [10]. It may also be used with the Reliable Delivery of syslog as described in RFC 3195 [11], and it may be used with other message delivery mechanisms. Designers of other efforts to define event notification mechanisms are encouraged to consider this specification in their design. Would it be better to RECOMMEND this mechanism be used with [14]? That would be consistent with the RECOMMENDation in Section 3. === Fourth paragraph in Section 3: When used in conjunction with RFC [14], the syslog messages defined in this document carry the signature and certificate data as STRUCTURED DATA, as defined, while the MSG part of the syslog messages is simply empty - the contents of the messages is not intended for interpretation by humans but by applications that use those messages to build an authenticated log. Would it be better to state that the MSG part of the message MUST be empty? It's suggested here but not explicitly stated. === From Section 4.1 A Signature Block message that is compliant with RFC [14] MUST contain valid APP-NAME, PROCID, and MSGID fields. Specifically, as value for APP-NAME, syslog (without the double quotes) MUST be used. As value for MSG-ID, sig (without the double quotes) MUST be used. As value for the PRI field, 110 MUST be used, corresponding to facility 13 and severity 6 (informational). The Signature Block is carried as Structured Data within the Signature Block message, per the definitions that follow in the next section. Perhaps restructure that as: A Signature Block message that is compliant with RFC [14] MUST contain valid APP-NAME, PROCID, and MSGID fields. Specifically, the value for APP-NAME MUST be syslog (without the double quotes). The value for MSG-ID MUST be sig (without the double quotes). The value for the PRI field MSUT be 110, corresponding to facility 13 and severity 6 (informational). The Signature Block is carried as Structured Data within the Signature Block message, per the definitions that follow in the next section. Similar in Section 5.3.1. === Section 4.2.7 gives the definition of the syslog message that needs to be hashed: starting with the of the PRI portion of the header part of the message and ending with the Unicode byte order mask, BOM. That needs to be changed as the BOM is not the end of the message. === The count for ssign is a maximum of 2-bytes and is a value of between 1 and 99. This will likely fit into a message with a length of 2048 octets as stated in Section 4.2.7 if the hashes are 160-bytes. Is this acceptable to the group? We started this with the idea that this mechanism would be run atop RFC 3164 with a maximum length of 1024 octets. However, would a greater efficiency be gained by increasing the length of the syslog-sign message and the length of the Count? === The word monotonically increasing is used in a few places. I think that we're actually trying to say sequentially increasing. === The SD-ID values in Section 9 (IANA Considerations) need to be in tables so that the IANA can cut-n-paste. === Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt
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, and MSGID fields. Specifically, the value for APP-NAME MUST be syslog (without the double quotes). The value for MSG-ID MUST be sig (without the double quotes). The value for the PRI field MSUT be 110, corresponding to facility 13 and severity 6 (informational). The Signature Block is carried as Structured Data within the Signature Block message, per the definitions that follow in the next section. Similar in Section 5.3.1. Syslog-protocol does not reserve any specific values for APP-NAME, PROCID and MSGID. So (at least theoretically), another implementor migth use the suggested values for any other case. As an implementor, I would probably like to consistenly use the same APP-NAME. For example, all messages in rsyslog will be logged as rsyslogd. I have just quickly read the IANA section (9.1): there is no such registry like APP-NAME. It might eventually be a good idea to create one, but I am not sure if it is worth the trouble. In any case, I think that must be spelled out in -protocol (else I can implement somthing compliant to -protocol but not -sign). Same goes for MSGID. My recommendation (without a full read of the document...) is to remove any dependencies on APP-NAME, PROCID and MSGID and use structured data fields for them. Otherwise, I foresee that I need a lot of hardcoded exception inside a syslog implementation to mangle this fields so that the happen to be right for -sign while they are invalid from the overall application point of view. -- Version field: I recommend renaming it to something like Sig-Version to avoid mistaking -protocol VERSION and -sign Version. -- I hope I will be able to do a full review by the end of the week. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] RE: Framing...
Yes, exactly.
Thanks,
Miao
-Original Message-
From: Juergen Schoenwaelder [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 19, 2006 12:58 AM
To: David Harrington
Cc: 'Rainer Gerhards'; 'Chris Lonvick'; 'Miao Fuyou'; [EMAIL PROTECTED]
Subject: Re: [Syslog] RE: Framing...
On Mon, Dec 18, 2006 at 11:18:56AM -0500, David Harrington wrote:
The chairs believe there is consensus, and will ask Miao to
change the
-tls- document to say that FRAME-LEN is the count of the
octets of the
SYSLOG-MSG.
Perhaps also consider to change FRAME-LEN to MSG-LEN to
better reflect the purpose of the value.
/js
--
Juergen Schoenwaelder {International|Jacobs}
University Bremen
http://www.eecs.iu-bremen.de/P.O. Box 750 561,
28725 Bremen, Germany
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
