Glenn, OK, it looks like we get to the root of the issue: our understanding of facility is fundamentally different.
You assume that facility is indeed a semantic entity that uniquely identifies an "originator" (that part of the system, that originally generates the MSG content). I do not understand how this can work. Can you please explain to me how a set of only 24 different values is able to uniquely identify application classes? In a practical example, can you please explain me which facilities must be used by these "originators" (randomly selected): - http daemon - dns daemon - firewalls - scp daemon - ssh daemon - SIP gateways - network cache servers - routers - switches Thanks, Rainer > -----Original Message----- > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > Sent: Sunday, June 24, 2007 1:21 AM > To: Rainer Gerhards > Cc: tom.petch; [EMAIL PROTECTED] > Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 > containsnewtext to address ietf last call comments (fwd) > > Rainer, > Rainer Gerhards wrote: > > Glenn, > > > >> -----Original Message----- > >> From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > >> Sent: Saturday, June 23, 2007 2:45 AM > >> To: tom.petch > >> Cc: [EMAIL PROTECTED] > >> Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 > >> containsnewtext to address ietf last call comments (fwd) > >> > >> Tom, > >> I do understand the line of reasoning. But I do not agree with > the > >> conclusion. I agree that if we follow the ABNF we can have layers. > >> [It does not limit us to three layers]. But a reality check says > that > >> we can have at most 2 significant layers. Significant from the point > >> of view of operations and management. Facilities will just generate > >> SYSLOG-MSG. > > > > Facilities do not generate anything. A facility is a number in the > range > > 0..23 - that's it. Originators generate messages. > No. Facility is not a number. Perhaps the number or value that you are > referring to is an encoding of the facility. rfc3164 and later > draft-ietf-syslog-protocol-21.txt Table 1. gives the mapping between > the numerical codes and corresponding "Facility" :-) > But let us not split hairs. > > >> Given that we have three layers it will be useful to have a > reality > >> check by mapping these layers to entities that we have defined or > know > >> about. I am afraid we keep going round in loops because of the lack > > of > >> precise definitions. Without these definitions it is very difficult > >> to tell who is going wrong where. The terms and entities we know > >> understand in this context are "Facility" , "Transport". Who > generates > >> the MSG? > > > > An originator. > But the MSG ( or "content") is already present before the originator > (syslog application). This is wrong. It just does not fit the layer > mechanism. > > > >> Is that a new entity that we are defining? > > No > > > >> What real world entity does it map to ? > > Syslogd > Syslogd is a "syslog application" ? Then it is in layer 2. We do > not have a mapping for layer 1 - "content". > > > >> Why are we interested in its operations ? > > To detect problems and get performance stats (from a mib > perspective). > Yeah. It appears that we do not have a specific interest in its > operations. An example of a specific interest in "syslog application" > statistics would be "how many Kernel messages are generated hourly" > or "how many Kernel messages with severity code = 'Error' are > generated hourly". > > > >> The answer to the last question will determine the significance of > the > >> entity and the corresponding "layer". > >> I am sorry if the above sounds like a digression, but I have a > real > >> problem in mapping onto reality without answers to the above. > > > > Please note that there are actually more than three layers in the > real > > world. See > I will not try to argue about that. We can have any number of layers. > But whether all of them are significant or not is the question. That is > what we are trying to ascertain. > > > [STUFF DELETED] > > > >>> 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. > >> I will not argue. But, I will repeat, who sends the MSG, to whom ? > >> Facilty to X ? X to Facility ? Facility to Facility ? If it one of > the > >> first two cases then, what is "X" ? > > > > Using Facility here is just plainly wrong. > Well, if Facility does not generate the message, who generates the > message? I have explained the problem - the "originator" sits below > the "content" or MSG layer. So it cannot be the generator. > > > > And what do you mean by "send" - this was a lengthy discussion. > If "send" is a problem - replace "send" with "originate". Who > originates > MSG ( in this case some entity is originating the message before the > "originator"!) ? > > -protocol was forced to use "send" only for the technical term of > > putting messages on the wire. If so, than transport senders send to > > transport receivers. > > > > If you use "send" in a more logical, upper-layer view (which is > > prohibited for -protocol by WG consensus), then originators > ultimately > > send to collectors. That's it. > > > > In precise real world terms: PLGenerators send to Collector Engines. > It does not help much. According to your definitions/descriptions > PLGenerators is part of "originator" in this layered model. That is a > problem. > > > > And, yes, we are going in loops. It doesn't help that the WG always > > forgets what it requested the other day. Whatever definition you like > - > > I am pretty sure, you'll find something in the 22 revisions of > > -protocol. > > > > I am tired of moving text from one revision into the new one, just to > > remove it the next time. > > > > Folks, lets get serious and remember what you have decided over the > past > > 5 years. A little bit of consistency would definitely help. At least > it > > would be helpful the know if the spec should be precise or vague, be > > focused on the network part only or talk about things that affect > > application design, put primary effort on backwards compatibility and > so > > on. I personally have to admit that I consider the syslog > > standardization effort to have failed. Most probably, we should > conclude > > the WG and discard work done. Better than throwing more and more work > > into the waste bin. I'd have stopped working on this 3 years ago when > I > > first thought so... > > > > Rainer > >>> 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.. > >> I fully agree. > >>> Tom Petch > >> Glenn > I appreciate your efforts. I am sure that we are getting closer. > > Glenn > >>> ----- 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 > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
