Re: traceroute-mib-2
"Randy Presuhn" <[email protected]>
| Newsgroups | gmane.ietf.disman |
|---|---|
| Message-ID | <002401c41b7a$6013ffe0$7f1afea9@oemcomputer> |
Hi - (as technical contributor - sorry for tardiness in commenting, particularly since the WG chair issued last call *long* ago!) > From: "Juergen Quittek" <[email protected]> > To: <[email protected]> > Sent: Sunday, January 25, 2004 4:50 AM > Subject: [Disman] traceroute-mib-2 > > Dear all, > > The DISMAN-TRACEROUTE-MIB defines the initial TTL value > for a traceroute operations as > > traceRouteCtlInitialTtl OBJECT-TYPE > SYNTAX Unsigned32 (0..255) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The value of this object specifies the initial TTL value to > use. This enables bypassing the initial (often well known) > portion of a path." > DEFVAL { 1 } > ::= { traceRouteCtlEntry 18 } > > The range of this object is (0..255). > I don't see how a value of 0 would make any sense. > Therefore I suggest to change the SYNTAX clause to > > SYNTAX Unsigned32 (1..255) > > Any comments? ... I *think* the motivation for including zero was to allow this MIB to be used to generate relatively obnoxious test PDUs. (I guess a local LAN device might respond to one of these; RFC 791 sounds like it says that they're supposed to be discarded upon receipt, but I'll leave that to the IP experts. If they are supposed to be discarded, then any device that responds is exhibiting an interesting failure mode. (Would these show up in ifInDiscards?) If they are not supposed to be discarded, then we'd be doubly wrong to exclude the value.) I'm not sure that there is any great value in prohibiting zero, and I'd rather not make changes unless there is clear value in doing so. Randy