Subject: [Syslog] Syslog-sign: Configuration parameters

From: <[email-masked]>
Date: Tue, 3 Feb 2009 11:33:58 +0100

I'm still having difficulties in understanding the text in
Sections 6.1.1 and 6.1.2.

I'll attempt to rephrase the text to one possible interpretation -- if
the original intent was something else, please propose new wording :)

6.1.1 Configuration Parameters for Certificate Blocks

   Certificate Blocks are always sent at the beginning of a new reboot
   session.  To ensure reliably delivery (see Section 8.5), it is
   useful to send multiple copies. This is controlled by
   "certInitialRepeat" parameter:

     certInitialRepeat = number of times each Certificate Block is
     sent before the first message is sent.

   It is also useful to resend Certificate Blocks every now and then
   for long-lived reboot sessions. This is controlled by the
   certMaxInterval and certMaxCount parameters:

     certMaxInterval = resend the Certificate Blocks if this
     many seconds have elapsed since the previous transmission.

     certMaxCount = resend the Certificate Blocks if this
     many other syslog messages have been sent since the previous
     transmission.

   It is desirable to allow for configuration where Certificate Blocks
   are not sent at all after the first normal syslog message has been
   sent.  This could be expressed by setting both certMaxInterval and
   certMaxCount to "0".  However, it is RECOMMENDED to send
   redundant Certificate Blocks even after the first message is sent
   when the UDP transport [RFC5426] is used.

6.1.2.  Configuration Parameters for Signature Blocks

   To ensure reliably delivery (see Section 8.5), it is useful to send
   the same Signature Block multiple times. This is controlled by the
   "sigRepeat" parameter:

     sigRepeat = number of times a Signature Block is resent.
     It is RECOMMENDED to use a value greater than 0 in particular
     when the UDP transport [RFC5426] is used.

   The following parameters control how often Signature Blocks
   are sent (note that the maximum message length may also
   force sending; see Sections 4.2.6 and 4.2.7):

     sigMaxInterval = send a Signature Block if this many seconds
     have elapsed since the previous Signature Block. Note that
     this applies even when no other syslog messages have been
     sent since the previous Signature Block.

     sigMaxCount = send a Signature Block if this many other
     syslog messages have been sent since the previous
     Signature Block.

(NOTE: the original text about sigResendDelay/sigResendCount
talks about *redundant* sendings -- the text about
sigMaxInterval/sigMaxCount above is about non-redundant
messages. I didn't quite understand what the original text
was trying to say, though...)

Best regards,
Pasi
_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 3 Feb 2009 12:53:50 -0800 (PST)

Hi Pasi,

>   when the UDP transport [RFC5426] is used.

This looks good.

> was trying to say, though...)

It needs to be "Resend" as these are redundant.  Let me give a very simple 
case to show:
If we configure the sender to have:
- a Signature Block Count (CNT) of 50
- sigRepeat=2
- sigResendDelay=30sec
- sigResendCount=34
then:
     time      Sender                   Collector
     0s          ---syslog messages 1-50--->
     14s         ---sig block for msgs 1-50--->
     44s         ---syslog messages 51-60--->
     44s         ---sig block for msgs 1-50---> (R1,1)
     52s         ---syslog messages 61-95--->
     52s         ---sig block for msgs 1-50---> (R1,2)
     60s         ---syslog messages 95-100--->
     60s         ---sig block for msgs 51-100--->

For the first 14 seconds, the device sends 50 messages and then the
Signature Block for them.  Thirty seconds later, the sigResendDelay timer
trips to send the first redundant Signature Block of the first 50
messages - shown as (R1,1).  Eight seconds after that, the sender sees
that it has sent 34 messages since sending out the previous redundant
Signature Block so it sends out the second redundant Signature Block of
the first 50 messages - shown as (R1,2).

I do take your point that there is nothing to kick out the initial 
signature block on a slow system.  Same example:
     time      Sender                   Collector
     0s          ---syslog messages 1-47--->
     ...eight years later, still nothing else...

So there should be a sigMaxInterval.

I would rewrite it as follows:
===
6.1.2.  Configuration Parameters for Signature Blocks

   The following parameters control how often the redundant Signature
   Blocks are sent.

     sigResendDelay = send a redundant Signature Block if this many seconds
     have elapsed since sending the original Signature Block, or any
     previous redundant Signature Blocks.

     sigResendCount = send a Signature Block if this many other syslog
     messages have been sent since sending the original Signature Block,
     or any previous redundant Signature Blocks.

     sigMaxInterval = send a Signature Block if this many seconds
     have elapsed since the previous Signature Block was sent. Note that
     this applies even in the case where no other syslog messages have been
     sent since the previous Signature Block.

   As an example of these parameters in use, consider if we configure the
   sender to have:
    - a Signature Block Count (CNT) of 50
    - sigRepeat=2
    - sigResendDelay=30sec
    - sigResendCount=34
    - sigMaxInterval=300sec
   then:
     time      Sender                   Collector
     0s          ---syslog messages 1-50--->
     14s         ---sig block for msgs 1-50--->
     44s         ---syslog messages 51-60--->
     44s         ---sig block for msgs 1-50---> (R1,1)
     52s         ---syslog messages 61-95--->
     52s         ---sig block for msgs 1-50---> (R1,2)
     60s         ---syslog messages 95-100--->
     60s         ---sig block for msgs 51-100--->
     360s        ---syslog messages 101-115--->
     360s        ---sig block for msgs 101-115--->
     390s        ---syslog messages 116-125--->
     390s        ---sig block for msgs 101-115---> (R2,1)

    For the first 14 seconds, the device sends 50 messages and then the
    Signature Block for them.  Thirty seconds later, the sigResendDelay
    timer trips to send the first redundant Signature Block of the first 50
    messages - shown as (R1,1).  Eight seconds after that, the sender sees
    that it has sent 34 messages since sending out the previous redundant
    Signature Block so it sends out the second redundant Signature Block of
    the first 50 messages - shown as (R1,2).  Three hundred seconds after
    that, the system has only sent 15 more messages so the sigMaxInterval
    timer is tripped and a signature block for them is sent.  The CNT value
    in that Signature Block will be 15.  The example continues to show that
    thirty seconds later the first redundant Signature Block of those 15
    messages will be sent.  The second will be sent within another thirty
    seconds.

===

Make sense?
Best regards,
Chris

---

From: <[email-masked]>
Date: Thu, 19 Feb 2009 12:41:28 +0100

Chris Lonvick wrote:

> It needs to be "Resend" as these are redundant.  Let me give
> a very simple case to show:
> timer trips to send the first redundant Signature Block of the first
> 50 messages - shown as (R1,1).  Eight seconds after that, the sender
> sees that it has sent 34 messages since sending out the previous
> redundant Signature Block so it sends out the second redundant
> Signature Block of the first 50 messages - shown as (R1,2).

Thanks for the explanation -- I think I now understood this!

> 6.1.2.  Configuration Parameters for Signature Blocks

Perhaps we should deal with non-redundant signature blocks first,
and retransmissions afterward? How about:

   The following parameters control how often Signature Blocks are
   generated (note that the maximum message length may also force
   generating a Signature Block; see Sections 4.2.6 and 4.2.7):

   sigMaxInterval = generate a new Signature Block if this many seconds
   have elapsed since the previous new Signature Block (not counting
   retransmissions). Note that this applies even when no other syslog
   messages have been sent since the previous Signature Block.

   sigMaxCount = generate a Signature Block if this many other syslog
   messages have been sent since the previous new Signature Block
   (not counting retransmissions).

(Changed "send" to "generate" here)

>    The following parameters control how often the redundant Signature

How about:

   The retransmitted Signature Blocks are not sent immediately after
   the original transmission, but slightly later. The following
   parameters control when the retransmissions are done (note that
   these are independent of the parameters controlling when new
   Signature Blocks are generated):

>     sigResendDelay = send a redundant Signature Block if this many
>     seconds have elapsed since sending the original Signature
>     Block, or any previous redundant Signature Blocks.

How about:

   sigResendDelay = retransmit if this many seconds have elapsed
   since the previous sending of this Signature Block.

("any" could refer to any Signature Block, even a new one.)

>      sigResendCount = send a Signature Block if this many other
>      syslog messages have been sent since sending the original
>      Signature Block, or any previous redundant Signature Blocks.

How about:

   sigResendCount = retransmit if this many other syslog messages have
   been sent since the previous sending of this Signature Block.

Best regards,
Pasi

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 25 Feb 2009 11:21:28 -0800 (PST)

Hi Pasi,

All of this looks good to me.  I believe that Alex will be able to get a 
new ID out next week.

Best regards,
Chris