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. 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? Is that a new entity that we are defining? What real world entity does it map to ? Why are we interested in its operations ? 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. > 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" ? > > 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
