Subject: RE: Schedule for remote operations work

From: PRUNET Vincent CNET/DSE/SOP <[email-masked]>
Date: Fri, 4 Sep 1998 18:03:16 +0200

I do agree with Juergen and some others that remote operations is not a good
name for the ping/traceroute/dnslookup mib.
On the other hand, we cannot name this mib 'ping/traceroute' as the
dnslookup feature was just added. For the same reason,
'ping/traceroute/dnslookup' might be too restrictive in the near future.
A few suggestions : 	end to end reachability mib, 
			basic (or elementary) end to end monitoring mib

Vincent
			
> -----Message d'origine-----
> De:	David Harrington [SMTP:[email-masked]]
> Date:	vendredi 4 septembre 1998 17:08
> À:	Kenneth White
> Cc:	[email-masked]
> Objet:	Re: Schedule for remote operations work
> 
> Kenneth White wrote:
> > 
> > ---------------------- Forwarded by Kenneth White/Raleigh/IBM on
> 09/03/98 08:57
> > PM ---------------------------
> > 
> > Kenneth White
> > 09/03/98 08:40 PM
> > To: [email-masked]
> > cc:
> > From: Kenneth White/Raleigh/IBM @ IBMUS
> > Subject: Re: Schedule for remote operations work
> > 
> > Juergen,
> > 
> > >I do agree with statement 1) and 2), but I am confused by the wordings
> > >at the start of your message. For me, the remote operations work
> > >within DISMAN is the Script MIB.
> > 
> > The consensus of the working group meeting in Chicago was to allow
> > the work of a dedicated MIB for ping and traceroute. It is thought that
> > there is actually a need for both a dedicated MIB approach as well
> > as hard-wired scripts.
> > 
> > ><draft-ietf-disman-remops-mib-01.txt.gz> defines a ping/traceroute MIB
> > >and we should stop calling this baby a "remote operations" MIB.
> > 
> > As a result of the discussion in Chicago I added a dnsLookup capability
> so the
> > MIB is actually
> > more then ping and traceroute. Do we really need to debate the name?
> > 
> > Ken
> 
> I agree with Juergen on this one. Let's name this MIB according to
> its explicit functionality. "Remote operations" doesn't imply that
> it specifically supports ping/traceroute/dnslookup. Naming it this
> broadly leaves its contents and purpose open to reinterpretation and 
> it could turn into a creeping-feature tarbaby.
> 
> dbh
> -- 
> -----------------------------------------------------
> #include <std.disclaimer> 
> David Harrington  [email-masked] 
> Spectrum Network Management Platform Core Group
> Cabletron Systems Inc. 
> -----------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Sep 1998 19:09:09 +0200

>>>>> PRUNET Vincent CNET/DSE/SOP writes:

PRUNET> On the other hand, we cannot name this mib 'ping/traceroute'
PRUNET> as the dnslookup feature was just added. For the same reason,
PRUNET> 'ping/traceroute/dnslookup' might be too restrictive in the
PRUNET> near future.

Well, I have not been in Chicago so I do not know the whole story, but
I am not sure how much sense it makes to add the DNS lookup stuff. Is
this really needed? DNS allows you to talk to non-local DNS servers in
order to resolve names. You usually set a few parameters in your
resolver library and you are done. Much faster and easier than doing
complex operations on a MIB via SNMP. If we continue the MIB approach,
I would also like to know if and how this interfaces with existing DNS
MIBs.

BTW, the text in the new ID talks about gethostbyname() and
gethostbyaddr() functions. This is not really correct if you want to
do DNS lookups as these functions usually do a lot more than just DNS
lookups.
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)