Subject: [Syslog] TLS TransportDomain

From: "David Harrington" <[email-masked]>
Date: Thu, 14 Dec 2006 18:24:51 -0500

Hi Glenn,

     How will the syslog/TLS transport address be specified in this
     object?

Response.
     A syslog TLS transport domain will be defined. E.g. something
like
     SyslogTLSTransportDomain. We will specify that as the
     syslogEntityControlTransportDomain.
     Thus, we will have something like:
          syslogEntityControlTransportDomain :
SyslogTLSTransportDomain
          syslogEntityControlService: SyslogTLSPort

Where and when will SyslogTLSTransportDomain be defined?
Would it not make sense to define it in this mib module?

I notice that RFC3419 uses the naming convention 
"transportDomain<transport protocol><network protocol>"
So wouldn't it make sense to use transportDomainTLSIPv4?

RFC3419 is meant to make transportDomains more generic than RFC3417,
which is used to define snmp-specific transportDomains. I don't think
we need to design syslog-specific transportDomains, but if so, then
the naming convention from RFC3417 is <application protocol><transport
protocol>Domain, such as snmpUDPDomain. With our byte-count header for
syslog/TLS, a syslogTLSDomain might alert an application that there
will be byte-counts in the stream.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Dec 2006 08:44:43 +0100

> will be byte-counts in the stream.

There are two things here that should not be mixed together:

(1) There is the transport layer endpoint you connect to in case of
    TLS which can be well represented by TransportDomain and
    TransportAddress pairs or perhaps even more handy using
    TransportType and TransportAddress pairs (if you do not expected
    vendor specific layer 4 endpoints). Alternatively, you can also
    use an (InetAddressType, InetAddress, InetPort) triple (and I have
    the feeling that the later has been kind of more popular so far).

(2) There is the additional information that after connecting to the
    transport endpoint, you are talking TLS and you have to use the
    SYSLOG over TLS framing. This, I think, goes beyond what the
    Transport* TCs (or the Inet* TCs) try to represent.

In SNMP land, the TAddress and TDomain carry this additional knowledge
and hence we keep defining new TCs and OIDs for new SNMP transports.

An alternative is to have a construction where you specify the
transport endpoint in one of the ways explained under (1) and you have
an additional object which defines the encapsulation method.

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany