Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew text to address ietf last call comments (fwd)
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
Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew text to address ietf last call comments (fwd)
Glenn 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. 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.. Tom Petch - 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
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
