Tom,
> 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.
I agree.
> 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.
I agree that it is a point of view. I do not see the necessity of
the two layers for MSG and SYSLOG-MSG as a part of operations and
management.
The reason being that it will generally be the same entity
("application", "module" call it whatever) that will generate MSG and
SYSLOG-MSG.
>
> Tom Petch
Glenn
>
> ----- 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
