Subject: RE: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLCReview of draft-ietf-syslog-sign-20.txt

From: "Alexander Clemm \(alex\)" <[email-masked]>
Date: Thu, 21 Dec 2006 01:51:38 -0800

Hi Chris, Rainer, others

from my perspective, I do believe it is important to be able to easily
tell apart a syslog-sign message from another message.  It is true and I
agree with you that SD-ID can be legitimately used for that purpose,
although I do consider it a bit of an "overloading" of what it is that
SD-ID identifies.  I think per se it is fine to do this, but this does
mean that syslog-sign should be used only in conjunction with
syslog-protocol - this route practically precludes use in conjunction
with RFC 3164, because I don't think we should require looking into the
message body to distinguish a syslog-sign message.  

Now (and this goes more to the other message thread), as to whether or
not to support RFC 3164, technically there is nothing that would prevent
it from being supported in addition to syslog protocol (as it is
currently specified) so in a sense it doesn't hurt to specify it that
way.  Of course, to force migration to syslog protocol is a valid
argument to preclude it.  On the other hand, I would not be surprised if
there are cases who would like to use the ability to sign _without_
having to change the entire protocol in the process - basically, that
would like to have the signing capability but that do not want to incur
the additional cost of having to switch.  I am also thinking of
scenarios where you are in essence "bolting on" a separate signing
capability outside the actual sender of the syslog messages (which might
be a legacy sender doing RFC 3164), that simply injects additional
syslog messages into the message stream.    

If this is not a concern, I am fine to go with the suggestions that were
made.  In that case, the choice of PRI may not matter either, although
if one is chosen, 110 is the one that IMHO makes the most sense.  In
terms of wording, would we want to leave completely open what
implementations choose as APP-NAME and simply leave specification of it
out, or still make a suggestion in terms of "SHOULD"?   

Best regards
--- Alex

-----Original Message-----
From: Rainer Gerhards [mailto:[email-masked]] 
Sent: Wednesday, December 20, 2006 6:51 AM
To: Chris Lonvick (clonvick)
Cc: [email-masked]
Subject: RE: APP-NAME,PROCID and MSGID in syslog sign - was: RE:
[Syslog] clonvick WGLCReview of draft-ietf-syslog-sign-20.txt

Chris,

> -----Original Message-----
> From: Chris Lonvick [mailto:[email-masked]]
> Sent: Wednesday, December 20, 2006 3:37 PM
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog]

> clonvick WGLC Review of draft-ietf-syslog-sign-20.txt
> 
> Hi Rainer,
> 
> Ahh..  I see your point now.  (Sorry - being a little slow this week.)
> 
> All:  I'm tending to agree with Rainer's point that no value should be

> specified for APP-NAME.  Does anyone think that the document should 
> suggest something for fixed-function devices such as printers which 
> might not have a syslogd?  Currently syslog-protocol allows a NILVALUE

> if nothing better can be used.

I think they should use whatever the use with other messages. For
example, they might use "router". Sure, this is not intelligent. But my
point is that this should not be of concern for syslog-sign.

> 
> Similarly, PROCID may be NIVALUE in syslog-protocol if the device 
> cannot produce it.  I'm OK with that for syslog-sign as well.
> 
> Finally, I'd still like to keep "sig" for the MSGID.  This should
allow
> for parsers (automated and manual searches) to find syslog-sign 
> messages quickly.

I do not object it, as long as we caution implementors that a MSGID of
"sig" does not necessarily indicate this is a syslog-sign message. We
can not guarantee that, because we did not reserve any message ids at
all. So it may be a clue, but it is nothing to rely on. Which brings me
to the point: what is the advantage of an unreliable indicator?

>This won't be the only mechanism to identify a syslog-sign  message.  I

>believe that a syslog-sign message would have to:
> - be sent to PRI = 110
> - have MSGID = "sig"
> - contain an SD-ID with the SD-PARAM of "ssign" or "ssign-cert"
> I don't think that we need a registry of MSGIDs for this.

For me, the SD-ID is the only valid indicator that this is a syslog-sign
message. We can not rely on PRI as operators like to reconfigure PRI.
Even if we mandate a fixed PRI in the specification, real-world
implementations will ignore that requirement and still allow the
operator to override it (and this for a good reason). On the other hand,
SD-IDs *are* under IANA control and the absolutely positively identify
the element that they are contained in. This is what we designed them
for. So why not use them for their design purpose?

With RFC 3164 syslog, we obviously can not totally be assured that the
SD-ID will be valid. But we should keep in mind that we most probably
will try to obsolete 3164 either via -protocol or a follow-up RFC. I
already questioned the point in supporting this (informational!)
document in a new standard. Is this really a wise idea?

Rainer
> 
> If anyone has issues with any of this, please speak up now.  I'd like 
> to get this settled so we can update and send this to the IESG when 
> the WGLC ends.
> 
> Thanks,
> Chis
> 
> 
> On Tue, 19 Dec 2006, Rainer Gerhards wrote:
> 
> > Chris,
> >
> >> -----Original Message-----
> >> From: Chris Lonvick [mailto:[email-masked]]
> >> Sent: Tuesday, December 19, 2006 10:18 PM
> >> To: Rainer Gerhards
> >> Cc: [email-masked]
> >> Subject: RE: [Syslog] clonvick WGLC Review of 
> >> draft-ietf-syslog-sign-20.txt
> >>
> >> Hi Rainer,
> >>
> >> On Mon, 18 Dec 2006, Rainer Gerhards wrote:
> >>
> >>> Hi,
> >>>
> >>> So far, I have not been able to do a full review. But this
> >> triggers my
> >>> attention immediately...
> >>>
> >>>> Perhaps restructure that as:
> >>>>
> >>>>     A Signature Block message that is compliant with RFC xxxx 
> >>>> [14] MUST
> >>>>     contain valid APP-NAME, PROCID, and MSGID fields.
> >>>> Specifically, the
> >>>>     value for APP-NAME MUST be "syslog" (without the
> >> double quotes).
> >>>>     The value for MSG-ID MUST be "sig" (without the double 
> >>>> quotes).  The
> >>>>     value for the PRI field MSUT be 110, corresponding to
> >> facility 13
> >>>>     and severity 6 (informational).  The Signature Block
> >> is carried as
> >>>>     Structured Data within the Signature Block message, per the
> >>>>     definitions that follow in the next section.
> >>>>
> >>>> Similar in Section 5.3.1.
> >>>
> >>> Syslog-protocol does not reserve any specific values for APP-NAME,

> >>> PROCID and MSGID. So (at least theoretically), another
> >> implementor migth
> >>> use the suggested values for any other case.
> >>>
> >>> As an implementor, I would probably like to consistenly use the
> same
> >>> APP-NAME. For example, all messages in rsyslog will be logged as 
> >>> "rsyslogd".
> >>>
> >>> I have just quickly read the IANA section (9.1): there is no such 
> >>> registry like "APP-NAME". It might eventually be a good
> >> idea to create
> >>> one, but I am not sure if it is worth the trouble. In any
> >> case, I think
> >>> that must be spelled out in -protocol (else I can implement
> somthing
> >>> compliant to -protocol but not -sign). Same goes for MSGID.
> >>>
> >>> My recommendation (without a full read of the document...)
> >> is to remove
> >>> any dependencies on APP-NAME, PROCID and MSGID and use
> >> structured data
> >>> fields for them. Otherwise, I foresee that I need a lot of
> hardcoded
> >>> exception inside a syslog implementation to "mangle" this
> >> fields so that
> >>> the happen to be right for -sign while they are invalid
> >> from the overall
> >>> application point of view.
> >>
> >> We're going to have "ssign" and "ssign-cert" as the SD-IDs used for

> >> syslog-sign.  I don't think that there are any dependencies on 
> >> APP-NAME, PROCID and MSGID for the proper working of syslog-sign;
> >
> > From the quoted text above:
> >
> >>>     value for ####APP-NAME MUST be "syslog"#### (without the
double
> > quotes).
> >>>     The value for ####MSG-ID MUST be "sig"#### (without the double
> >
> > If APP-NAME and MSG-ID *MUST* contain something specific, I think
> there
> > is a strong dependency.
> >
> >> they're just there
> >> to make sure that these messages are placed consistently into the 
> >> right bins.  The "ssign" and "ssign-cert" SD-IDs will be reserved 
> >> for
> this.
> >
> > I do not see how this addresses the concerns I mentioned above. I
can
> > not implement it without interfering with my application design in a
> way
> > that I do not find justified. How does mandating a specific APP-NAME
> and
> > MSG-ID make sure that they are put into the right bins? Many stock 
> > syslogds can not even filter on these fields...
> >
> > Rainer
> >

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 21 Dec 2006 11:21:46 +0100

Alex,

thanks for your well thought-out reply. I am just commenting on one
sentence (below), because this is IMHO the key issue...

> From: Alexander Clemm (alex) [mailto:[email-masked]]
> Sent: Thursday, December 21, 2006 10:52 AM
> To: Rainer Gerhards; Chris Lonvick (clonvick)
> Cc: [email-masked]

I can life with "SHOULD". But I would prefer to leave it out. The reason
is the definition of APP-NAME (syslog-protocol, section 6.2.5):

---
The APP-NAME field SHOULD identify the device or application that
generated the message. 
---

Of course, one can argue that syslog-sign is the "application" that
generated the message. However, this is not in the spirit of
syslog-protocol. The discussion was focussed about software programs
being an application. So typical value would be "syslogd", "postfix",
"kernel", "mySuperApp", ... It is not safe to mandate (or expect) that
APP-NAME "syslog" will only be used by syslog-sign. There is nothing we
can make a reservation for it. Forcing my to use "syslog" as app-name
causes grief in my application design, because the APP-NAME is something
that is already well defined and *independent* of the message content. I
would prefer not to introduce a dependency between the message content
and the APP-NAME.

-- more from the same section --
It is a string without further semantics.
---

That means in plain words: you can put whatever you like into APP-NAME.
It is NOT a semantical object. The same goes for MSGID and PROCID.
Please note that all fields MAY be operator-assigend.

When discussing compatibility with RFC 3164, we should keep in mind that
3164 does NOT reflect what is used in the majority of cases (this is the
main argument to updating it, see the other thread). So it is already a
very slippery slope to define field usage on top of 3164.

[side note: this discussion and reminder is one of the reasons I think
we need to update 3164 quite soon - the arguments need to be re-iterated
ever and ever again and we all sometimes forget about them (me included
;))].

Rainer