FW: draft-ietf-disman-remops-mib-v2-09.txt

FYI and follow up.
I have not looked at this in detail yet (may not
get to it untill Tuesday next week). So forwarding
to WG for review/comment/response.

Bert

-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Pekka Savola
Sent: Friday, March 10, 2006 11:23
To: Ops Directorate
Subject: draft-ietf-disman-remops-mib-v2-09.txt


On Thu, 9 Mar 2006, David Kessens wrote:
...

I don't usually look at MIB modules, but did take a peek at 
draft-ietf-disman-remops-mib-v2-09.txt.

A couple of comments below.

Substantial
-----------

I have a number of concerns about NSLOOKUP part of the MIB mobule.

1) It's not clear whether the host, given e.g., 'dns' as a lookup 
type, is only supposed to make a DNS lookup (which is what 'nslookup' 
does), or also consult /etc/hosts or equivalent (also possibly NIS or 
other similar directories as specified by /etc/nsswitch.conf or 
equivalent) if appropriate.

2) In lookupCtlTargetAddressType (for example), the user is required 
to specify whether the address in IP->name conversion is IPv4 or IPv6 
address.  This is unfortunate; you should not need to specify that, as 
the lookup functions are able to figure it out on their own. You 
should be able to give also 'ip' which would do v4 lookup if the 
address is v4 or v6 lookup if the address is v6, as appropriate.

3) The specification includes a lot of 'getaddrinfo() or 
gethostbyname()' and 'getnameinfo() or gethostbyaddr()', but the 
latter functions do not support IPv6.  Is there any reason to mention 
those at all, because you can't implement this MIB mobule (so that it 
could support v6) just by using gethostbyname/gethostbyaddr?  I'd 
suggest just mentioning getaddrinfo/getnameinfo().


Editorial
---------

==> usually (not sure about MIB modules), differences to the previous 
RFC are listed in the draft, maybe in an appendix.  This information 
is mostly available in the draft, but it's scattered in 3 places.  Not 
sure if it'd make sense to sum it up.

     traceRouteCtlPort OBJECT-TYPE
        SYNTAX      Unsigned32 (1..65535)
        UNITS       "UDP Port"
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
            "Specifies the UDP port to send the traceroute
            request to.  Need to specify a port that is not in
            use at the destination (target) host.  The default
            value for this object is the IANA assigned port,
            33434, for the traceroute function."
        DEFVAL { 33434 }
        ::= { traceRouteCtlEntry 9 }

==> actually, most implementations use the UDP port number for the 
_first_ traceroute they send, incrementing the port number for next 
messages, so that you can distinguish which hop the replies came 
from.  So, the text may require a minor tweak.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings