Subject: RE: [Disman] FW: draft-ietf-disman-remops-mib-v2-09.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 11 Mar 2006 23:12:51 +0100

OK, looked into this in some more detail.
Inline my responses. Document author or WG chair can chime
in if they want.

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Friday, March 10, 2006 15:32
> To: Disman (E-mail) (E-mail)
> Cc: David Kessens (E-mail); Pekka Savola (E-mail)
> Subject: [Disman] 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-masked] [mailto:[email-masked]]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.
> 

Possibly that could be clarified somewhat. I think it is an implementation
matter (the way I interpret it), but even that could be stated.
If WG chair and author/editor agree, pls sens a proposed piece of text
that I can tell RFC-Editor to add.

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

The format is REQUIRED in order for the SNMP agent to be able to determine
(and validate) the content of the lookupCtlTargetAddress object itself.
So it is inherent in the use of these TCs, and not because it is
needed for underlying lookup functions.

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

They are listed as "for example", so I think that that is OK.

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

Fine. Even so the initial value would be the one to start from, no?

So I do not see a need to add text.

Bert

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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 13 Mar 2006 10:13:15 +0200 (EET)

...
> that I can tell RFC-Editor to add.

Agreed.  I don't think this is a major issue itself, but if the intent 
is to give consistent results across implementations, some things need 
to be said about this.

> needed for underlying lookup functions.

But it would be possible to have a lookup type where the TC is 
basically "any text string that is less than 50 characters in length?
Because if you give an address to look up with 'nslookup', the 
address is just an opaque text blob..

> They are listed as "for example", so I think that that is OK.

I have to disagree with this because the example doesn't work. (On the 
other hand, if the spec said, "getaddrinfo() or gethostbyname() and 
gethostbyname2()", then I think it would be workable though deprecated 
by the latest IPv6 API documents.

> So I do not see a need to add text.

Certainly, but the problem is that the text doesn't say "initial", so 
the above description could be interpreted to be normative, i.e., "all 
the traceroute probes must originate from this port number".

...

to e.g.,:

>>             "Specifies the initial UDP port to send the traceroute

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 15 Mar 2006 01:19:05 +0100

Hi Pekka,

--On 3/13/06 10:13 AM +0200 Pekka Savola wrote:

> Agreed.  I don't think this is a major issue itself, but if the intent is
> to give consistent results across implementations, some things need to be
> said about this.

Would you be fine with the change I proposed in a message to Joel Halpern:

OLD:
3.3.3.  lookupResultsTable

   The lookupResultsTable is used to store the results of lookup
   operations.  The lookupResultsTable is initially indexed by the same

NEW:
3.3.3.  lookupResultsTable

   The lookupResultsTable is used to store the results of lookup
   operations.  Results to be reported here SHOULD be results of
   a lookup function that is commonly used by applications at the
   managed node. This implies that results are not necessarily
   consistent with the results of a pure DNS lookup at the
   managed node, but may be influenced by local lookup tables or
   other source of information, depending on the configuration of
   the managed node.

   The lookupResultsTable is initially indexed by the same

?

Thanks,

    Juergen

---

From: Pekka Savola <[email-masked]>
Date: Wed, 15 Mar 2006 09:47:08 +0200 (EET)

>  The lookupResultsTable is initially indexed by the same

Yes, looks excellent.

(FWIW, I think I've been convinced now the NSLOOKUP TC problem is 
something that needs to be addressed on a different forum, and the 
current approach seems good enough for now.)