Glenn I think that the existing, already agreeed text in protocol-21 does give us a three way split in the stack. Looking at the ABNF, there is MSG which is prepended by additional fields to form SYSLOG-MSG which will in turn be prepended before the PDU is placed on the wire. So I can see a top layer generating and interpreting MSG, a middle layer turning that into SYSLOG-MSG and a lower layer providing the UDP/TLS/etc headers/trailers.
In turn, this can drive statistics and error counters, so that a single MSG which is sent with two different facility codes each over three transports would count as 1 in the upper layer, 2 in the middle and 6 in the lower. Or an invalid facility would increment an error counter in the middle layer. I am not saying this is the only split or the best split and I am certainly not saying any implementation has to make any of this layering apparent in its code structure; but I do think that a three-way split is sensible. But, as I have said before, I also see an inconsistency in the definitions added to protocol-21, one that I would like to see resolved.. Tom Petch ----- Original Message ----- From: "Glenn M. Keeni" <[EMAIL PROTECTED]> To: "Chris Lonvick" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, June 20, 2007 3:56 PM Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew text to address ietf last call comments (fwd) > Hi, > My comments follow. > > Glenn > > +------------------------------------------------------------+ > > 1. Page 4. > "syslog content" is the management information contained > in a syslog message. > a. Are we sure about this "management information"? > It seems to be a restriction on the scope of the > information that can be carried in a syslog message. > I suggest that we drop the term "management". It > does not add any value but raises several questions. > b. What is the difference in a "syslog content" and > "syslog message" > Do we need a distinction? > > 2. The "syslog application" layer handles generation, > interpretation, routing and storage of syslog messages. > "handles generation" is confusing. Then the > syslog message will first appear at this layer. > But it appears before ( on top of) this layer > More about this in (c) > > 3. I do not agree with the first layer "content" . > On page-5 the "functions" of the layers are given, the > functions of the "content" layer are not given. > It is not clear what abstraction is intended in a layer. > But whatever that is - layer-1 (syslog content) and > layer-2(syslog application) do not belong to the same > genre. Layer-1 does not belong there. > > 4. On page-6 > The boxes represent syslog-enabled applications. > a. Is a syslog-enabled application not a syslog > application ? > The boxes in Diagram-2 are labelled "collector" , > "originator" which are syslog applications. > > [The following comments are not related to recent changes > in the document. But, they are relevant and will need to be > addressed some time. ] > > 5. If, syslog-mib-tc is being published then we probably do > not need to have the paragraphs other than the first one in > section 6.2.1 > > 6. 6.2.5 APP-NAME > The APP-NAME field SHOULD identify the device or application > that originated the message. > > We need to explain "device" or drop the term. Is a host a > device? > > +----------------------------------------------------------+ > > > Chris Lonvick wrote: > > Hi Folks, > > > > This note from Sam to [EMAIL PROTECTED] for those of you who don't > > subscribe. > > > > Thanks, > > Chris > > > > ---------- Forwarded message ---------- > > Date: Fri, 15 Jun 2007 19:48:25 -0400 (EDT) > > From: Sam Hartman <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains > > new text > > to address ietf last call comments > > > > > > > > I'd like to draw the attention of the community to section 3 of > > draft-ietf-syslog-protocol-21.txt. This text contains text and a > > clarified model of the various layers in the syslog architecture and > > new terminology for the parties. > > > > I believe this is responsive to the ietf last call comments and I > > believe the changes have been discussed sufficiently in the WG. > > > > I am not asking for a new last call but I do want to make people aware > > of the text. If people believe a new last call is necessary please > > let me know now. Currently the document is scheduled on the Thursday, > > June 21 telechat. > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
