Re: Psudo WG Last Call for: http://www.ietf.org/internet-drafts/draft-ietf-ops-taddress-mib-02.txt

[Glenn Mansfield Keeni <glenn@cysols.com>]

Juergen Schoenwaelder wrote:

  >>>>>>Glenn Mansfield Keeni writes:
  >>>>>>
  >
  > Glenn> Page-5 3.1.1 TransportAddressType appears for the first time
  > Glenn> Would it be better to move this section towards the end of the
  > Glenn> document or someplace after TransportAddressType is defined.
  >
  >
  >>> The concept of a transport address type is defined in section 3
  >>>enumeration 3 well before 3.1.1.
  >>>
  >
  > Glenn> Yes. There is a mention of "transport address type" but that is
  > Glenn> syntatctically not quiet the same as "TransportAddressType".
  >
  > Do you want me to put "TransportAddressType" in braces in 3.1.1. or
  > what? Please propose concrete edits.

Moving Section 3.1 and the corresponding subsections to a new section
after section 5 would help.  I do not see any big problems with that.
In case there are problems we can live with something like "...transport
address type (TransportAddressType) ..." and same for TransportDomain.


  >
  > Glenn> Page-7 definition of transportDomainUdpIpv4z you have used the
  > Glenn> term "non-global" which is correct. But "private" may be better
  > Glenn> those are the terms that appear in RFC1597 (?)
  >
  >
  >>> non-global != private. See the following reference for details:
  >>>
  >
  > Glenn> Does that hold for IPv4 addresses ?  The comment above is
  > Glenn> related to IPv4 addresses.
  >
  > Although not explicitly stated, the conclusions in the IPv6 DT were
  > that this is also true for IPv4. 127.0.0.1 is an example of an IPv4
  > address which has a local scope. The notion of private IP addresses in
  > RFC 1597 is not the same notion as globally scoped and non-globally
  > scoped IP addresses as far as I can tell.

  >
  > Glenn> There are provisions transportDomainUdpIpv4 (global +
  > Glenn> non-global) and transportDomainUdpIv4z (non-global) and
  > Glenn> similarly for TCP and v6. But, what about the global domain -
  > Glenn> for which the corresponding addresses *are* from the global
  > Glenn> pool ? I would think it is necessary.
  >
  >
  >>> I do not understand this comment. A global UDP address will use
  >>>transportDomainUdpIpv4.
  >>>
  >
  > Glenn> And a non-global UDP address can use transportDomainUdpIpv4
  > Glenn> too.  Have I missed something ?  I am looking at this as a
  > Glenn> matter of classification - if we need a class for "non-global"
  > Glenn> then we need a class for "global" too.  Incidentally what type
  > Glenn> of usage is foreseen for transportDomainUdpIpv4z.
  >
  > You can represent non-globally scoped IP addresses using
  > transportDomainUdpIpv4z but you do not have to in cases where this
  > does not add value (that is the transport address is still unique).
The problem is that the usage of TDomain/TAddress and their new
embodiments TransportAddress/Domain is not clear. One may want to
define a set of Parameters for private addresses and a different set
of parameters for global addresses. That is what I had in mind.
  >
  > Glenn> More important - this affects us and implementations on all
  > Glenn> dual (v4/v6) stack systems rightaway-
  >
  > Glenn> There is the need for the following transport domains:
  > Glenn> transportDomainUdpIpv4OrIpv6 and transportDomainTcpIpv4OrIpv6
  > Glenn> which will be used when the underlying IP transport (version)
  > Glenn> is either unknown or unspecified. (as far as the command
  > Glenn> generators are concerned, in the SNMP context).
  >
  >
  >>> Why? If you have a concrete address, then you know the concrete
  >>>domain. If you do not know a concrete value, you just use
  >>>unknown(0) or zeroDotZero in case you use OIDs. Perhaps I am
  >>>missing the point.  Can you provide a concrete example?
  >>>
  >
  > Glenn> There are several points here - 1. Users and/or applications
  > Glenn> may not have a concrete address. They may have a DNS name-
  > Glenn> which may translate into one or more IPv4 or IPv6
  > Glenn> addresses. [InetAddressType = 16] In this case using "unknown"
  > Glenn> is not an accurate rendering of facts. - it is known that the
  > Glenn> address belongs to the {Udp|Tcp}Ip space, and that its value
  > Glenn> may be found from the DNS and that if found the address will
  > Glenn> belong to either the IPv4 or the IPv6 address space.
  >
  > Once you have resolved the DNS name, you have an IPv6 or an IPv4

Yes only AFTER the DNS name is resolved I will have the adress.
But I may want to set my application parameters using the DNS name.
  > address. If you resolve the DNS name whenever you use the transport
  > address, then the DNS name is the endpoint you want to represent.
  > Note that a TranportAddressType/TransportAddress always resolves to a
  > single address and the question how you represent multiple transport
  > addresses (which may or may not belong to the same DNS name) is just
  > out of scope for a single TranportAddressType/TransportAddress pair.
  >
  > Glenn> 2. Users and/or applications DO NOT need to know whether the
  > Glenn> transport will be v4 or v6. It suffices to know whether the
  > Glenn> transport is IP or otherwise and if IP then whether it TCP or
  > Glenn> UDP. The underlying APIs should take care of that.
  >
  > I don't see how that relates to TranportAddressType/TransportAddress
  > pairs in MIB modules.

Using the SNMP-TARGET-MIB as an example, I would prefer to assign a
set of security parameters to host  A.somedomain.com and
specify that the address belongs to the TCP over IP domain of addresses
(V4 and V6). I would not even want to reconfigure my tables because a
new version of IP has arrived.
  >
  > Glenn> 3. I agree that there may be cases where a user and/or
  > Glenn> application may want to be specific about the transport. But,
  > Glenn> making that a requirement leads to unfriendly applications
  > Glenn> (where one has to specify V4 or V6 ).
  >
  > The application which reads or writes MIB objects might choose to do
  > whatever name lookups it likes. Unless you want to deferr that lookup
  > to the managed device, I do not see why the stuff we have today does
  > not work.
  >

Presently we will *have* to reconfigure the management environment
(e.g. TARGET-MIB), for every host/network specific parameter, every time
a new version of IP arrives. That is because we do not have an 
IP-version-independent way of specifying an address in our MIB tables.
[unless we use the INET-Address-MIB, but that too works for the IP layer
only]

  > Glenn> Having said that - I must say that there is confusion on the
  > Glenn> naming and definitions. There is no clear definition of
  > Glenn> "transport domain" in any SNMP document. It appears that
  > Glenn> "transport domain" just refers to address space which could be
  > Glenn> (IP{v4|v6}:{Udp|Tcp}). But it has "transport" in its name. And
  > Glenn> then we need to think of protocol translations {V6->V4 etc.} !
  >
  > I do not understand why the term "transport" implies that we have to
  > think of protocol translations {V6->V4 etc.}
I did not make myself clear. What I meant is that the "transport" in the
"transportDomain" seems to imply the transport "service" and, that is
wrong because
      1. we may not know what service will be used (if the service
         definition includes the underlying IP layer)
      2. in some cases multiple services may be used - e.g in the
         case of V4->V6 translators.
  >
  > Perhaps it would be useful to show a concrete MIB example where the
  > current definitions would not work so that I better can understand
  > what your problem is.
The TARGET-MIB example above should suffice.

I would reiterate that we need clear definitions of the terms
"transport domain" and "transport address". If it is a well defined and
often used term - I may have missed it, please correct me. To me it
appears as an ill defined and often misused term.
The SNMP RFCs say
RFC1903:
TDomain ::= TEXTUAL-CONVENTION
      STATUS       current
      DESCRIPTION
            "Denotes a kind of transport service.

            Some possible values, such as snmpUDPDomain, are defined in
            'Transport Mappings for Version 2 of the Simple Network
            Management Protocol (SNMPv2)'."

rfc2573.txt
   snmpTargetAddrTDomain OBJECT-TYPE
         SYNTAX      TDomain
         MAX-ACCESS  read-create
         STATUS      current
         DESCRIPTION
             "This object indicates the transport type of the address
              contained in the snmpTargetAddrTAddress object."
         ::= { snmpTargetAddrEntry 2 }

The above RFCs and the current draft refer to transport endpoints
freely without defining what exactly is a transport endpoint. It
is not even clear what is a "transport" in this context. There are
examples but definition by example is a good source for confusion
particularly when we try to extend the scope of the definitions
as we are trying to do now.

The INET-ADDRESS-MIB which defines InetAddressType and InetAddresses
is neater in restriciting the definitions to addresses of Internet
Network layer addresses and their types.

Along the same lines it appears to me that transportAddress and
transportDomain be defined as  addresses (of some entity) and
the name of address Domain in which the address must be interpreted.
This could be further supplimented with rules of usage as is done
for the inetAddressType = dns(16).

  >
  > /js
  >
  >

Glenn