Hi Tom,
Juergen's explanation has nothing to do with RFC3411. The fact that
syslog can be 3164 or -protocol or signed is really immaterial to this
discussion, since these happen above the addressing level.
This discussion has to do with choosing from three standard mechanisms
for representing addresses in SMIv2 MIB modules. There are advantages
and disadvantages to each of the three standard approaches to
representing address formats, and these should be understood to make
the proper choice. (Juergen is well versed in the intracacies of the
advantages and disadvantages, and is trying to provide some advice).
The three standards are:
1) TDomain (RFC3417) - which defines a mechanism to represent
snmp-specific addresses (at layer7). This was defined explicitly for
use in the MIB modules that are part of SNMPv3, and are designed only
for managing SNMP, and the addresses defined (e.g.
SnmpUDPDomain/SnmpUDPAddress) can not be easily reused to represent
addresses used by other protocols.
snmpUDPDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over UDP over IPv4 transport domain.
The corresponding transport address is of type
SnmpUDPAddress."
::= { snmpDomains 1 }
SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current
DESCRIPTION
"Represents a UDP over IPv4 address:
octets contents encoding
1-4 IP-address network-byte order
5-6 UDP-port network-byte order
"
SYNTAX OCTET STRING (SIZE (6))
Tdomain includes definitions for snmp-specific addresses. For
syslog to use TDomain will require us to develop hardcoded OID
assignments for a syslogUDPDomain and syslogUDPAddress,
syslogTCPDomain, syslogTCPAddress, syslogTLSDomain, syslogTLSAddress,
and so on. Those hardcoded values can then be used in TDomain/TAddress
fields in MIB modules.
To provide an SSH transport extension would require publishing
a new MIB module to define the new hardcoded values syslogSSHDomain,
syslogSSHAddress.
The SNMP community realized it is really undesirable to have
to write a whole new MIB module just to say what the address domain
would be and what the address would look like.
The suggestion that a syslog address is always
syslog/tls/tcp/IANAport might lead one to select the TDomain approach,
but this is not really required. One ting to point out is that IANA
assigns a requested "default" port, but operators can often change
what port is actually used.
2) TransportDomain - which defines a mechanism that represents
(layer4) transport addresses, independent of the application. This
better permitted showing the transport addresses of non-snmp-things in
MIB modules.
transportDomainUdpIpv4 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4 for
global IPv4 addresses."
::= { transportDomains 1 }
TransportAddressIPv4 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d:2d"
STATUS current
DESCRIPTION
"Represents a transport address consisting of an IPv4
address and a port number (as used for example by UDP,
TCP and SCTP):
octets contents encoding
1-4 IPv4 address network-byte order
5-6 port number network-byte order
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific
format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair."
SYNTAX OCTET STRING (SIZE (6))
To use this in a MIB module, you define a pair of fields: a
transportDomain field identifies the type of address being used, and a
corresponding field of transportAddress with the actual address value.
The corresponding address value MUST be of the type defined in
TransportDomain.
Syslog could use this approach, BUT - there are no existing
definitions for a TLS/TCP transport address, so if we want to use
this, we need to define such a transportDomain and corresponding
transportAddress. The current syslog mib document does not provide
such an update.
There is an additional complication. RFC3419 provides an enumeration
to select a transportDomain; this is done so a transportDomain can be
used as a field in an index without having the whole OID of a
transportDomain be part of the INDEX; you can use an integer
identifier.
In order to add a new transportDomain therefore requires updating
RFC3419 to keep the enumeration in sync with the possible values of
transportDomain.
So while using trasportDomain would require us to make fewer hardcoded
defintiions than Tdomain, the IETF process involved in doing the
updates to support TLS is harder.
3) InetAddressType (RFC4001) defines a mechanism that represents
internet (layer 3) addresses, and can supplement that with a
PortNumber. This address is independent of the application using it,
and is suitable for showing layer 3 addresses in MIB modules. It was
motivated by the need to represent IP addresses in MIB modules so that
either an IPv4 or an IPv6 or a DNS address could be used in the same
managed object.
Juergen, if I got any of this wrong, please feel free to correct me.
--
Now to the problem at hand:
The syslog MIB module uses a combination of types, without explanation
for why each type is used where it is.
The transportDomain is used without discussing how/where/when a TLS
transportDomain will be defined so the syslog/TLS transport can be
represented.
Some current usages in the syslog mib appear to be incorrect. You need
to think of these domain/address pairings as being discriminated
unions - the first field identifies the format of the second field;
you cannot use one part of the pair without the other. In the syslog
mib module, the type field declares what the format of the next field
is, but the address value field then describes a format that is NOT
one of the address formats supported.
This problem is exarcerbated by mib module decriptions that are
unclear, partly because the WG members are not reviewing this document
and helping the author write clear descriptions.
This problem is also exacerbated by replies from the author that do
not answer **the questions being asked** by the MIB experts so they
can provide advice.
For example:
Question from Juergen:
> syslogEntityControlBindAddrType InetAddressType
> syslogEntityControlBindAddr InetAddress
> syslogEntityControlTransportDomain TransportDomain
> syslogEntityControlService SyslogService
>
> looks a bit crazy to me.
> - Why have both InetAddressType and TransportDomain?
Answer from Glenn:
> We will not have this.
We ALREADY have this; We are using both InetAddress and
TransportDomain standards for representing addresses in the syslog mib
module. Why do we need to use BOTH standards rather than using ONE
standard to represent addresses?
dbh
> -----Original Message-----
> From: tom.petch [mailto:[EMAIL PROTECTED]
> Sent: Sunday, December 24, 2006 2:08 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: TransportDomain. Was: Re: [Syslog]
> Submissionofdraft-ietf-syslog-device-mib-12.txt
>
> ----- Original Message -----
> From: "Juergen Schoenwaelder" <[EMAIL PROTECTED]>
> To: "tom.petch" <[EMAIL PROTECTED]>
> Cc: "Glenn M. Keeni" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Friday, December 22, 2006 8:44 PM
> Subject: Re: TransportDomain. Was: Re: [Syslog] Submission
> ofdraft-ietf-syslog-device-mib-12.txt
>
> > On Fri, Dec 22, 2006 at 07:17:18PM +0100, tom.petch wrote:
> >
> > > I am not convinced that the proposed solutions match the
> underlying problem.
> > >
> > > Syslog:
> > > - can be -protocol or RFC3164 (or RFC3164bis or ...)
> > > - may be signed.
> > > - may be secured with TLS (or SSH or DTLS or ...)
> > > - could run over UDP or TCP (or SCTP or ..)
> > >
> > > What we have then done is to bind -protocol to TLS to TCP in a
> > > package and asked IANA for a port number less that 1024 for that
> > > combination
> > >
> > > So I think that trying to analyse it in terms of, eg,
> InetAddressType,
> > > InetAddress, InetPortNumber and SyslogEncapsulation won't work.
> >
> > I don't get your message - can you enlighten us please?
> >
> My pleasure :-)
>
> My sense is that your analysis of the protocols is
> syslog
> encapsulation
> transport
> somewhat RFC3411-like so we might have an enumeration for
> encapsulation, one (or
> more) for transport and problem solved. I am saying that the
> structure
> (architecture/layers) is not like that (no dbh:-), that we
> have 'tls/tcp/IANA port' all tied up in a bundle together,
> take it or leave it.
> Were we ever to do anything different in future, most likely
> it would be a
> another package, perhaps SSH/TCP/different IANA port or TCP
> per se, so the
> decomposition you imply does not make sense to me.
>
> Also, there is more than one flavour of syslog (-protocol,
> RFC3164) and perhaps
> we need that specifying more than we need to specify what
> lies underneath. So
> option c) is the closest but may not be enough.
>
> Tom Petch
> > /js
> >
> > --
> > Juergen Schoenwaelder {International|Jacobs} University Bremen
> > <http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725
> Bremen, Germany
>
>
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
>
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
