Subject: Re: disman issue REMOPS-2

From: [email-masked]
Date: Thu, 1 Jul 1999 11:11:16 -0400

Dave,

>> > > > Also, it isn't clear to me why ICMP is a MUST NOT for traceroute,
>> > > > but is RECOMMENDED for ping.  This seems to be an inconsistency:
>> > > > why shouldn't traceroute have the equivalent of pingCtlType?
>>
>> This is a strong argument for replacing the "MUST NOT" with language in
>> terms of "NOT RECOMMENDED", possibly with a brief note explaining why
>> anyone who DOES do it with ICMP needs to know exactly what they're doing.
>>
>> Would anyone object to this as a compromise?

>I would object to allowing multiple methods without a
>traceRouteCtlType object.  If such an object were added,
>"NOT RECOMMENDED" would be fine with me.

I prefer to leave the text as is with "MUST NOT".

In your respond to the my prior posting on this topic that included the
note from Van Jacobson you state:

>That's fine but that does not by itself motivate a MUST NOT,
>especially if you happen to use the half of the vendors who
>did it right.  Hence, I have no problem with making ICMP
>RECOMMENDED for ping, and UDP RECOMMENDED for traceroute,
>but I don't yet see the motivation for MUST NOT.

The answer is interoperability and heterogeneous networks. If you allow
alternate methods then the chance of success has decreased. Use of
UDP probes has a greater chance of success then use of ICMP echo probes
for this function.

I would like to hear from others on the list as to their opinion...

Ken

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 1 Jul 1999 09:48:37 -0700 (PDT)

Hi -

Please consider RFC 2119, especially clause 6, in considering the
distinction between "MUST NOT" and "NOT RECOMMENDED".

> From [email-masked] Thu Jul  1 08:13:19 PDT 1999
> From: [email-masked]
> X-Lotus-FromDomain: IBMUS
> To: Dave Thaler <[email-masked]>
> cc: [email-masked] (Randy Presuhn), [email-masked]
> Date: Thu, 1 Jul 1999 11:11:16 -0400
> Subject: Re: disman issue REMOPS-2
> Content-Disposition: inline
> 
> 
> 
> Dave,
> 

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com/
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's is probably coincidental.
 ------------------------------------------------------------------------

---

From: [email-masked]
Date: Fri, 2 Jul 1999 03:19:35 -0400

Hi,

>distinction between "MUST NOT" and "NOT RECOMMENDED".

Extracting from RFC2119:

    2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
        definition is an absolute prohibition of the specification.

   4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
       there may exist valid reasons in particular circumstances when the
       particular behavior is acceptable or even useful, but the full
       implications should be understood and the case carefully weighed
       before implementing any behavior described with this label.

   6. Guidance in the use of these Imperatives

       Imperatives of the type defined in this memo must be used with care
       and sparingly.  In particular, they MUST only be used where it is
       actually required for interoperation or to limit behavior which has
      potential for causing harm (e.g., limiting retransmisssions)  For
      example, they must not be used to try to impose a particular method
      on implementors where the method is not required for
      interoperability.

I still believe that the use of MUST NOT with respect to use
of ICMP Echo requests for traceroute to be correct and consistent
with RFC2119.

Ken

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 2 Jul 1999 11:22:04 -0700 (PDT)

Hi -

So far i think I've seen one person arguing for "MUST NOT" and one for
"NOT RECOMMENDED".  Does anyone else on this list have a preference
regarding just how much we should disparage the use of ICMP for
traceroute?

If no one speaks up, it'll stay "MUST NOT", though I won't defend it
if the IESG review asks for "NOT RECOMMENDED" unless there is a lot
more backing for this position.

---

From: [email-masked]
Date: Sat, 24 Jul 1999 06:33:28 -0400

The following is the current text with respect to use of UDP or
ICMP probes for traceroute:

Implementations of the remote traceroute capability as defined
within this memo SHOULD be done using UDP packets to a (hopefully)
unused port.  ICMP probes (ICMP Echo Request packets) SHOULD NOT be
used.  Many PC implementations of traceroute use the ICMP probe
method, which they should not, since this implementation method has
been known to have a high probability of failure.  Intermediate
hops become invisible when a router either refuses to send an ICMP
TTL expired message in response to an incoming ICMP packet or simply
tosses ICMP echo requests altogether.

The following are the MIB additions:

-- The registration node (point) for traceroute implementation types

traceRouteImplementationTypeDomains OBJECT IDENTIFIER
::= { traceRouteMIB 3 }

traceRouteUsingUdpProbes OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION
        "Indicates that an implementation is using udp probes to
        perform the traceroute operation."
    ::= { traceRouteImplementationTypeDomains 1 }

traceRouteCtlType OBJECT-TYPE
    SYNTAX      OBJECT IDENTIFIER
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The value of this object is used to either report or
        select the implementation method to be used for
        performing a traceroute operation. The value of this
        object MAY be selected from
        traceRouteImplementationTypeDomains.

        Additional implementation types SHOULD be allocated as
        required by implementers of the DISMAN-TRACEROUTE-MIB
        under their enterprise specific registration point and
        not beneath traceRouteImplementationTypeDomains."
    DEFVAL { traceRouteUsingUdpProbes }
    ::= { traceRouteCtlEntry 25 }

    OBJECT traceRouteCtlType
        MIN-ACCESS  read-only
        DESCRIPTION
            "Write access is not required.  In addition, the only
            value that is RECOMMENDED to be supported by an
            implementation is traceRouteUsingUdpProbes."

Comments?

Ken

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 26 Jul 1999 16:09:01 -0700 (PDT)

Hi -

> To: [email-masked]
> Date: Sat, 24 Jul 1999 06:33:28 -0400
...
>     ::= { traceRouteCtlEntry 25 }
...

I think this "MAY" should be a "may" and this "SHOULD" should be a
"should", since we're not talking about protocol or implementation
behaviour.

---

From: [email-masked]
Date: Wed, 28 Jul 1999 11:51:14 -0400 (EDT)

Re: disman issue REMOPS-2

Sorry for my untimely response; please disregard this E-mail if
this issue has been completely settled.

presuhn>So far i think I've seen one person arguing for "MUST NOT" and 
presuhn>one for "NOT RECOMMENDED".  Does anyone else on this list have
presuhn>a preference regarding just how much we should disparage the
presuhn>use of ICMP for traceroute?
presuhn>
presuhn>If no one speaks up, it'll stay "MUST NOT", though I won't defend
presuhn>it if the IESG review asks for "NOT RECOMMENDED" unless there is
presuhn>a lot more backing for this position.

For what it's worth, I slightly prefer "MUST NOT".  I can align
with "NOT RECOMMENDED".  Randy's statement above seems like a
reasonable way to resolve this.

Regards,
--Alan

 -----------------------------------------------------------------------------
 Alan Luchuk       SNMP Research, Inc.                 Voice:  +1 423 573 1434
 Software Engineer 3001 Kimberlin Heights Road         FAX:    +1 423 573 9197
 [email-masked]   Knoxville, TN  37920-9716  U.S.A.   http://www.int.snmp.com/
 -----------------------------------------------------------------------------