Subject: [Syslog] Comments on syslog-sign-26

From: WashamFan <[email-masked]>
Date: Wed, 17 Jun 2009 11:59:54 +0800

Hi,

I'd like issue some concerns here.

1. the text below is from sec 4.2.4

   Note that the Global Block Counter crosses Signature Groups; it
   allows one to roughly synchronize when two messages were sent, even
   though they went to different collectors and are part of different
   Signature Groups.

But I am still not quite clear about what the GBC field is for. IMO,
removing this field does not matter much. Or could you elaborate
on how it help sync?

2. sec 6.1.1:

Does certResendDelay or certResendCount refine the resending
behavior after the first normal message is sent or before that or
both? Are you saying resending Payload periodically in a long lived
reboot session?

3. sec 6.1.2:

Why not introduce a param called sigMaxCount to specify the 
max count of hashes in a Signature Block message?

4. signer vs. originator
an originator is specified as (hostname, app-name, procid) triple.
So does a signer? If yes. then an originator can not have multiple
signers in the same time, but multiple originators can share the
same signer. In the latter case, should every originator exchange
its Payload independently?

washam

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 17 Jun 2009 15:22:03 -0700 (PDT)

Hi,

> removing this field does not matter much. Or could you elaborate

Let's say that you have SG=3 with PRIs <50 going to one collector and PRIs 
>50 going to a different one.  The first collector would get some GBCs and 
the other collector would get different ones.  Perhaps:
one gets 1,3,5,7,9,11,12,13,14,15,16,17,18
two gets 0,2,4,6,8,10,19
>From that, you can sort'a tell what's going on, and that you havn't lost 
any.

> both? Are you saying resending Payload periodically in a long lived

Like this:
http://www.ietf.org/mail-archive/web/syslog/current/msg02332.html
Does the document need more clarification on this?

> max count of hashes in a Signature Block message?

That's limited by the overall length of the syslog message.

> its Payload independently?

That's the discussion going on between Pasi and Alex on the list right 
now.

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

Many thanks for your review and comments.

Regards,
Chris

---

From: WashamFan <[email-masked]>
Date: Thu, 18 Jun 2009 11:09:49 +0800

Hi,

>  Does the document need more clarification on this?

This URL offers a good explanation of config params for sig block. Thanks.
But my concern was related to cert block, actually. Let me express
in a clearer way:

There are three params defined. "certInitialRepeat" indicates how many
copies of Payload should be sent beforehand. But there is not clear
that how to send those copies, one after one immediately or between
interval? It seems "certResendDelay" and "certResendCount" have
nothing to do with *pre-historical* resending behavior, although I
am not sure it was the intent.

Since there is no counterpart to "sigNumberResends" for cert block,
then I assume, if "certResend*" params are greater than 0, then
Payload will be resent periodically until "session" is broken. Right?

washam

---

From: WashamFan <[email-masked]>
Date: Thu, 18 Jun 2009 11:53:55 +0800

Hi,

>  From that, you can sort'a tell what's going on, and that you havn't 

I am sorry, it seems a little bit hard for me to understand.
for collectors, they can tell what sig they lost without GBC.
for senders, they have no idea sig blocks lost or not since syslog
is a simplex protocol.

One more thing, dose the re-sent sig block have the same GBC as
the original one?

washam