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

["Glenn Mansfield Keeni" <glenn@cysol.co.jp>]

From: "Juergen Schoenwaelder" <schoenw@ibr.cs.tu-bs.de>
To: <glenn@cysol.co.jp>
Cc: <bwijnen@lucent.com>; <mibs@ops.ietf.org>
Sent: Monday, April 08, 2002 6:39 PM
Subject: Re: Psudo WG Last Call for:
http://www.ietf.org/internet-drafts/draft-ietf-ops-taddress-mib-02.txt


>
> >>>>> Glenn Mansfield Keeni writes:
>
> Glenn> Hi, The following are the comments on the taddress-mib-02
> Glenn> draft.  some are cosmetic others require discussion:
>
> Glenn> Page-4 Sec-3 para 1. s/following definitions/follwing/
>
> I do not see how that improves much.
Not a big deal really. Just that the enumerations (2), (3), (4) do
not look so much like definitions as they look like an enumeration of
textual conventions, object registrations, etc.
>
> 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.
Yes. There is a mention of  "transport address type" but that is
syntatctically not quiet the same as "TransportAddressType".
> 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:
Does that hold for IPv4 addresses ?  The comment above is related to
IPv4 addresses.
>
>    [21]  Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe, A.
>          and B. Zill, "IPv6 Scoped Address Architecture", draft-ietf-
>          ipngwg-scoping-arch-03.txt, November 2001.

>
> Glenn> Technical issues:
>
> 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.
And a non-global UDP address can use transportDomainUdpIpv4 too.
Have I missed something ?
I am looking at this as a matter of classification - if we need a class
for "non-global" then we need a class for "global" too.
Incidentally what type of usage is foreseen for transportDomainUdpIpv4z.
>
> 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?
>
There are several points here -
1. Users and/or applications may not have a concrete address. They
   may have a DNS name- which may translate into one or more IPv4 or
   IPv6 addresses. [InetAddressType = 16]
   In this case using "unknown" is not an accurate rendering of facts. -
   it is known that the address belongs to the {Udp|Tcp}Ip space,
   and that its value may be found from the DNS and that if found the
   address will belong to either the IPv4 or the IPv6 address space.

2. Users and/or applications DO NOT need to know whether the
   transport will be v4 or v6. It suffices to know whether the transport
   is IP or otherwise and if IP then whether it TCP or UDP. The underlying
   APIs should take care of that.

3. I agree that there may be cases where a user and/or application may
   want to be specific about the transport. But, making that a requirement
   leads to unfriendly applications (where one has to specify V4 or V6 ).

Having said that - I must say that there is confusion on the naming and
definitions. There is no clear definition of "transport domain"
in any SNMP document. It appears that "transport domain" just refers
to address space which could be (IP{v4|v6}:{Udp|Tcp}). But it has
"transport"
in its name. And then we need to think of protocol translations {V6->V4
etc.} !

Glenn