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
