Rob,

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

/jim