Glenn I can define two layers in the ABNF (one that generates MSG and one that generates SYSLOG-MSG) but SYSLOG-MSG is not ready to go on the wire so a third layer is needed, ie a transport, which is worth a mention in -protocol even if it is not defined there. So two layers in the ABNF, two in -protocol, three in the syslog stack as a whole. Transport matters - the point of this work it to provide security and it is the (TLS) transport that gives us that; whether you see that as part of operations and management is a point of view.
Tom Petch ----- Original Message ----- From: "Glenn M. Keeni" <[EMAIL PROTECTED]> To: "tom.petch" <[EMAIL PROTECTED]> Cc: "Chris Lonvick" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, June 23, 2007 2:44 AM Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew text 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. > 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
