>
> The second is a new draft proposed by Darren New and Marshall Rose.
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-reliable-00.txt
>
> I am pleased with the proposed architecture in the ID from Darren and
> Marshall. I had concerns about the scalability of any proposal but
> it appears that the "relays" may be used as local aggregation points
> before passing the messages along to centralized "collectors", or
> regional aggregation points for a more tiered approach. For those of
> you wishing to catch up on the BEEP protocol, drafts, and such, please
> take a look at the BEEP WG Charter and mailing list:
> http://www.ietf.org/html.charters/beep-charter.html
> http://lists.invisible.net/pipermail/bxxpwg/
I'd like to suggest to extend the model in the proposal above, so that
messages can travel several hops, not just a single relay station. So
instead of:
For example,
+--------+ +-------+ +-----------+
| Device | -----> | Relay | -----> | Collector |
+--------+ +-------+ +-----------+
Of course, more than one relay may be present between any particular
device and collector.
I'd suggest:
+--------+ +-------+ +-------+ +-----------+
| Device | -----> | Relay | -...->| Relay | -----> | Collector |
+--------+ +-------+ +-------+ +-----------+
where '...' indicates several relay hosts. This would involve changing the
COOKED BEEP DTD. I have at least two formats on my mind:
possibility #1:
C: <entry facility='24' severity='5' timestamp='20001027132215'
C: hopsFQDN='jack.invisible.net/relay1.invisible.net'
hopsIP='10.0.0.83/10.0.0.84'
C: processName='imxpd' processID='141'>
C: Replacement device found in nostril.
C: </entry>
possibility #2:
C: <entry facility='24' severity='5' timestamp='20001027132215'
C: originFQDN='jack.invisible.net' originIP='10.0.0.83'
C: processName='imxpd' processID='141'>
C: <received FQDN='relay1.invisible.net' IP='10.0.0.84'>
C: <received FQDN='relay2.invisible.net' IP='10.0.0.85'>
C: Replacement device found in nostril.
C: </entry>
And as you may see I'd suggest using originFQDN and originIP instead of
deviceFQDN and deviceIP. Otherwise I like the proposal. (though I'd be
interested how current application level proxies will cope with protocols
like BEEP)
--
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
url: http://www.balabit.hu/pgpkey.txt
