Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew text to address ietf last call comments (fwd)

["tom.petch" <cfinss at dial.pipex.com>]

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" <glenn at cysols.com>
To: "tom.petch" <cfinss at dial.pipex.com>
Cc: "Chris Lonvick" <clonvick at cisco.com>; <syslog at ietf.org>
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" <glenn at cysols.com>
> > To: "Chris Lonvick" <clonvick at cisco.com>
> > Cc: <syslog at ietf.org>
> > 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 ietf at ietf.org 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 <hartmans-ietf at mit.edu>
> >>> To: ietf at ietf.org
> >>> Cc: syslog at ietf.org
> >>> 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 at lists.ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/syslog
> >>>
> >>> _______________________________________________
> >>> Syslog mailing list
> >>> Syslog at lists.ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/syslog
> >>
> >>
> >> _______________________________________________
> >> Syslog mailing list
> >> Syslog at lists.ietf.org
> >> https://www1.ietf.org/mailman/listinfo/syslog
> >
>
>


_______________________________________________
Syslog mailing list
Syslog at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog