Subject: Re: Unit_Sw_Version

From: "Hattig, Myron" <[email-masked]>
Date: Wed, 20 Jan 1999 14:26:37 -0800

Art,

I agree there are already multiple unit directories.

Also if we focus on just networking protocols, it is not
really the job of an IETF group to define a general networking anything.
IETF groups only worry about IP.

A general networking unit_directory would not have a Unit_Spec_Id
value owned by the IANA. I'm not sure what value the Unit_Spec_Id
would have because there is not one group defining all networking
protocols.

To address Joseph's points directly:

> As far as the choice of the Unit_SW_Version, the fundamental
> constraint is
> that the combination of Unit_Spec_ID and Unit_SW_Version
> *must* be globally
> unique.

Unless there are multiple versions of IPv4/1394, the combination
of IANA Unit_Spec_ID and EtherType for Unit_Sw_Version is globally
unique. I'm a little concerned about when we define IPv4/1394 with
1394 bridges. That's why I suggested adding the RFC number to the
Unit_Sw_Version. This way if some derivative of IPv4/1394 crops up
a matching pnp driver can be identified.

> 1. Having a single unit directory per node simplifies the plug'n'play
> process on systems which create one internal device object per unit
> directory.

Creating one unit directory per node for all things does not work so well.
Currently different drivers get loaded based finding different unit
directories on 1394 devices. If there is a single unit directory per
node, then there is no way to determine when one driver gets loaded vs
another. This would require one monolithic pnp driver, thus there are no
benefits to having pnp drivers at all. Am I'm missing the point ???

> 2. Each unit directory typically represents a logical device
> -- a drive, a
> scanner, and so on. Associating a unit directory with each packet type
> (IPv4, IPv6, MCAP, ARP and so on), or each network protocol that is
> implemented on the node does not fit into this model. On the
> other hand,
> having a single unit directory to represent a logical network
> device on the
> node *does* fit into this model

I'm not sure of the strict definition of packet type, but some demux
happens somewhere in the stack that identifies a scanner packet from
an IP packet from an AV/C packet, etc. To avoid creating a
monolithic driver that supports all applications, don't we have
to have separate unit directories for each packet type?

Here is another point that may be causing distress about using the
EtherType. I'm not expecting different unit directories for MCAP and
ARP (which have their own EtherTypes). Instead, I'm expecting a single
unit directory with the EtherType of IPv4 to imply support for ARP
and MCAP. Adding the RFC number advances the notion that MCAP and ARP
are implied. Heck, maybe we should just have the RFC number be the
Unit_Sw_Version.

-myron