Thu, 13 January 1994 02:21 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa18205; 12 Jan 94 21:21 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18201; 12 Jan 94 21:21 EST
Received: from by CNRI.Reston.VA.US id aa23878; 12 Jan 94 21:21 EST
Received: by (5.65c/Spike-2.0) id AA10842; Wed, 12 Jan 1994 20:33:08 -0500
Precedence: bulk
Return-Path: <>
Received: from by (5.65c/Spike-2.0) id AA10805; Wed, 12 Jan 1994 20:33:04 -0500
Received: by; id AA07286; Wed, 12 Jan 94 17:29:48 -0800
Received: by; id AA15445; Wed, 12 Jan 1994 20:29:40 -0500
Message-Id: <>
In-Reply-To: Your message of "Wed, 12 Jan 94 11:29:51 EST." <>
Date: Wed, 12 Jan 94 20:29:34 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
X-Mts: smtp


>First: the NLPID as defined uses the low 4 bits as flags; this means
>we are using a block of 16 NLPID values in effect. This is NG. The flags
>need to be moved elsewhere. There is also a need for another flag for
>Error-report Suppression.

I agree on the MLPID flags being moved.  Could they be first octets in
the header?

Error-report suppression seems like could idea.  Why not make it as part
of one of the support protocols options?


>TTLs: some feedback and further thinking leads me to believe that
>scaling the TTL when translating datagrams is not such a good idea
>(although it must be done when going to and from IPX). It would be
>better to keep it to hop count.

I think the TTL should just become a hop count in any proprosal as this
is how it is used by most.  

During translation of protocolthe TTL as a hop count would not be
decremented unless the point of translation was in fact a hop.

>We still want a nominal time associated with it, for when a router
>hangs onto a datagram for a longer than usual time (typically waiting
>for some kind of subnetwork setup). Probably 1/10 second is good; it
>must be less than IP's (1 sec) and less than CLNP (500 msec)

This will be handled by the transport layer or should in my opinion.

>It also seems that 8 bits is really sufficient. It is a log function
>of network size. If a net with 1 billion hosts has a topological diameter
>of (say) 30, then a diameter of 250 with the same branchiness implies
>something like 10^82 hosts. (There are something like 10^78 neutrons
>in the observable universe if I recall correctly. :-)

As a log function it should work...  I would be interested on more
comments on this.

  •   Robert L Ullmann
  •   bound