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. > 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. >Is that a new entity that we are defining? No >What real world entity does it map to ? Syslogd >Why are we interested in its operations ? To detect problems and get performance stats (from a mib perspective). > 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 http://www.rsyslog.com/module-Static_Docs-view-f-/generic_design.html.ph tml The text in this link was offered for inclusion in the draft, but it was objected as being not network-centric enough. As a result, -protcol-20 defined the 3 layers that we actually have from a network point of view: http://tools.ietf.org/id/draft-ietf-syslog-protocol-20.txt That was rejected as being to complex. So -21 went back to 2 layers and consequently needed to use very vague terms. The problem simply is that you cannot put the complexity of real-world syslog (and its POSIX API) into a two-layer network view. If you are forced to, you need to remove many subtleties. To use the terms from my precise architecture description: An -protocol-21 originator is a combination of a) PLOrig b) remote PLOrig c) PLGenerator d) PLGExt e) Message Router A relay is a combination of a) GWI b) GWO c) RelayEng d) RelayEngExt e) Message Router A collector is a combination of a) Store, Disc, ... b) CollectorEng c) CollectorEngExt d) Message Router As you can see, they have much in common. But you cannot precisely define them if you are not permitted to define them precisely - aka "you get what you pay for" ;) > > 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. And what do you mean by "send" - this was a lengthy discussion. -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. 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 > > > > ----- 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
