Subject: [Syslog] Syslog sign - draft 17 (draft-ietf-syslog-sign-17.txt)

From: "Alexander Clemm \(alex\)" <[email-masked]>
Date: Tue, 29 Nov 2005 12:55:41 -0800

Hello,

I just wanted to let you all know that I have submitted a new draft of
syslog sign, as the old one was about to expire.  The new draft should
appear shortly if it hasn't already; here is a summary of the changes
and updates that were made.  

The changes were along the lines of what was presented at the Vancouver
meeting, the most important of which concerns utilizing structured data
to capture the fields of Signature and Certificate Blocks - a prudent
use of structured data which avoids having a payload that is essentially
"binary".  Of course, unfortunately syslog-protocol now appears to be
further away from completion than it did earlier, and really we would
like syslog protocol to be stable to that respect before basing further
work on that.  However, at the same time, the consensus of the group by
and large seems to be to retain structured data, so this provides
perhaps a view of how it can be utilized.  At the same time, please note
that syslog sign as currently worded is actually not dependent on a
specific syslog protocol syntax - if you will, you could send syslog
messages with a message body that happens to be formatted respectively
conform to the syntax as set forth in syslog-sign.  

Note that the Payload Block format was not changed.  Payload Blocks are
essentially carried as part of Certificate Blocks; those utilize
structured data, but as Payload Blocks are not associated with an actual
syslog message directly it seems as if it is not necessary to change the
way Payload Blocks are encoded.  Quite possibly, this will of course be
subject to further discussion.  

The cookie field was removed.  Identification of a Signature Block
respectively Certificate Block can occur through use of an according
SD-ID.  

Another modification that was made, which will surely require more
discussion, concerns the reboot session ID.  For devices to be able to
conform to this, they would need to be able to persist the reboot
session ID such that it survives reboots (so to be able to increment
after a reboot).  The question is to allow for the possibility of
allowing devices who cannot support such a feature to still support
syslog-sign, with the understanding that in this case, there would be no
guarantee that messages would be uniquely distinguished across reboots.
It appears that this would still be useful, provided it can be easily
distinguished whether or not reboot session ID is supported, which can
be accomplished by the choice of ID (0 if not supported, 1 through
9999999999 otherwise).  Comments or thoughts?  

Beyond that, you will find a number of editorial updates with the goal
of making the document slightly more readable.  Updated sections include
for example section 4.4 on Signature Group and Signature Priority.   

There is of course more work to be done.  In addition on closing on the
suggested items, one aspect that is currently not addressed and requires
discussion concerns any aspects about the message header of syslog
messages carrying a Signature or Certificate Block - for example,
assignment of a message ID, proper PRI etc.  

Looking forward to fruitful discussions
--- Alex

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