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

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> 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.

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).

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
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.

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.

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.}

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.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>