🚀 go-pugleaf

> Should the issue of colliding Protocol ID values be a non-issue, given
> that the two address spaces of id fields already are separated?  

Yes, it looks like I didn't explain the conditions I was imposing on
the problem very well.  My point was that you couldn't build a single 
network layer (with only one NSAP/IP address) to handle both types 
(ISO and ARPA) transparently to the upper layers (either ISO or TCP).  
If you have the same network address for both types (ISO or ARPA) and 
you receive a packet and must determine what type of packet it is, then
comes the problem of colliding values of the ARPA version bits and
ISO protocol ID.  (the problem is similar to if the 802.3/ethernet length
and type fields weren't well chosen to not conflict)  Looks like I was 
unfortunately thinking in the context of the problem my final had posed,
instead of the conditions implied by the basenote...

						kevin

Ps: under those conditions, I'd think you'd assume it to be an ARPA
    packet, check what should be the length field with the length 
    (or similarly use the checksum) and if it succeeds, assume an
    ARPA packet, else it's to be parsed in the ISO context.