Hi Bill Wagner,
I've watched this thread with bated breath...I was delighted to see that
you mentioned the 'ifStackTable' in RFC 1573. My comments are tucked
into your note below.
Cheers,
- Ira McDonald (outside consultant at Xerox)
High North Inc
imcdonal at eso.mc.xerox.com
>----------------------------------------------------------------------<
>Date: Mon, 26 Aug 1996 08:47:11 PDT
>From: bwagner at digprod.com (Bill Wagner)
>Subject: prtChannelMagicCookie object
>To: pwg at pwg.org>> There have been few comments on the prtChannelMagicCookie object,
> which either means everyone is happy with it or no one has given it
> too much thought. The following comments were exchanged with David
> Kellerman; I fully understand why David did not include some of the
> more outrageous suggestions. But I think that the utility of this
> magic cookie should be considered beyond the specific TCP/IP context
> for which it was originally proposed.
>> As is often the case with agreements at the PWG
> meetings, each individual has a different notion about what was agreed
> to. My understanding was that, as suggested by the whimsical name,
> this object was to serve several purposes; but primary was the notion
> of providing information that could allow an administrator (or
> program) to establish a printing connection to the printer on the
> combined information on the interface and channels groups; and,
> considering the Job Monitoring MIB, to be able to correlate a specific
> job to a specific channel. I missed the objectives of human readable
> (an unfortunate term, meaning different things to different people)
> and distinguishing different channels of the same type (except to the
> extent of identifying an interface/channel path.)
The problem with being "able to correlate a specific job to a specific
channel" was alluded to in a recent note (forwarded by Bob Pentecost)
from Jeff Dunham of the HP Jet Direct team - when any network layer
protocol sits on two or more physical/datalink interfaces at once, it
normally does NOT export info about which interface received each incoming
packet to the transport layer and eventually to the application layer -
thus, the application layer usually knows the source address of the job,
but it does NOT know which interface received the job and (because the
Printer MIB Channel Table only has one-to-one Channel/Interface mapping)
is therefore unable to correctly identify the 'JobSourceChannel'.
Of course, in certain protocol suites (eg, Internet suite) it is common
to 'multi-home' the network layer (here, IP, Internet Protocol) - with
one network address per physical interface - but this is not always
the case, even in TCP/IP networks.
>> With regard to specific points. I suggest that:
>> 1. The object be mandatory (although the definition of specific fields
> to be included for each channel may allow a way to specify 'unknown').
>> 2. If there is no applicable information for a particular type, the
> response be a null (0 length). This is consistent with the RFC 1573.
>> 3. The objective of defining a path could not only be alternately
> addressed by the Network Services Monitoring MIB, but also by the
> extensions to the interface group (rfc1573) (which allows a
> multi-layer definition of an 'interface' supported by a 'stack'
> table,) particularly in conjunction with cited media-specific
> mibs. Indeed, I think questions like 'what TCP port is being used ?'
> would be answered by this combination.
Ok - what's wrong here - the NSM MIB (RFC 1565) addresses ONLY the
application layer (OSI layer 7) - the 'ifStackTable' in the Evolution
of the Interfaces Group of MIB-II (RFC 1573) addresses ONLY the physical
and datalink layers (OSI layers 1 and 2) - there is a real big space in
the middle (including the TCP port number for LPR)...
> Also, things like serial port
> setup and (heaven forbid) parallel port setup, including all
> parameters considered necessary to make a connection, could be
> defined. However, it is a mite cumbersome. And if we
> desire to make life easier by including the TCP port number in this
> new object, why not suggest including other critical parameters for
> other channels. For example, why not provide
> a. baudrate, data bits, stop bits, parity, and flow control
> information for RS-232 interfaces?
> b. The standard IEEE1284-1994 product identification string would
> be useful for 1284-ports (useful if one is doing a parallel port
> redirector to the network, and information perhaps not otherwise
> accessible though the network)
Why not use the standard IETF RS232 MIB (RFC 1659)?
Why not use the standard IETF Parallel MIB (RFC 1660)?
> c. SCSI type and port number
> d. printer name; zone name (perhaps net, node and socket number)
> for AppleTalk
Why not use the standard IETF AppleTalk MIB (RFC 1742)?
- I know - as most implementors say, "It's too big!"
So something smaller than the Brooklyn Bridge is needed - the AppleTalk
MIB has 16 groups and 254 objects - just for one protocol suite!
But I really doubt you can cram it all into a SINGLE character string
(255 octets max).
> e. more stuff for LPD... Queue name
I could probably name a dozen parameters for LPR/LPD - I won't - my list
would be different from yours (max connections, alternate listen ports,
and on and on).
> f. for Pserver... pserver name as well as queue.. and if you have
> queue, you need fileserver or context, and should have identification
> if it is NDS or bindery based
> etc.
For the Internet suite (IP, TCP, UDP, original SNMPv1) we have the groups
in MIB-I and MIB-II (RFC 1213). If there's a standard IETF MIB for NetWare,
it's well hidden. The standard IETF MIB for SNA NAUs (RFC 1665) leaves
a lot of the steps in the stack as an exercise to the reader (although
it serves its stated purposes well).
>> That is, I suggest we solicit an identification of the type of
> information appropriate for each type of channel that would be
> desirable.
>> Bill Wagner, DPI
If you folks carry on with this 'one object / all solutions' approach,
where there is an existing IETF physical/datalink MIB, please consider
stealing your source material from that MIB (rather than the favorite
variables of the vendors represented at the relevant PWG meeting).
Cheers,
- Ira McDonald
PS - Search for the string 'MIB' in RFC 1920 (Internet Official Protocol
Standards, March 1996) for a quick list of current (and predecessor) IETF
MIBs (many still experimental) - RFC 1920 says it expires '15-July-96',
but there wasn't a newer 'STD1' when I checked 'ds.internic.net' via FTP
quite recently - be forewarned to watch out for a new version fairly soon.