Subject: PMP> Novell Channel Type Info

From: "Scott A. Isaacson" <[email-masked]>
Date: Wed, 16 Apr 1997 12:57:57 -0600

Some comments about the draft and channel type info.  Sorry to raise
some questions about Channel Type and Channel Info again after all of
these nice quite, peaceful months with no comments...

General Question:
There is a wide mix of Channel types defined: some relatively high in a
layered protocol stack (application protocols) and some lower
(transports) and some even lower (hardware interfaces).  What if some
of the higher layer application protocols can run over multiple transports?
Do we need to put into each channel type info which transport it is
currently configured to run over or which transports it may run over or
do we not define which transports are used?  It is easy for some (FTP
will run over TCP), but for some of the Netware channel types (PServer
and NDPS) they will run over TCP or SPX.  What do we include in the
channel info for these channel types?

1. Page 37
Editorial: The use of the term PServer has several changes in
capitalization: Pserver, PServer.  Make them all consistent. Suggest
PServer
                             chNetwareRPrinter(9),  -- Novell, Inc.
                                -- prtChannelInformation keywords:
                                -- Print Server Name
                                -- Keyword: "PServer"
                                -- Syntax:  Name
                                -- Status:  Mandatory
                                -- Multiplicity: Single
                                -- Description: The PServer's SAP name
                                --
                                -- Printer Number
                                -- Keyword: "Printer"
                                -- Syntax:  Integer
                                -- Status:  Mandatory
                                -- Multiplicity  Single
                                -- Description: The printer number
                                -- There must be one PServer and one
                                -- Printer entry

2. Page 37 
Question:
If the channel type is chPortTCP(37), the only parameter identified for
channel info is "port".  Is it assumed that the IP address is already
known?   Also for all of the other TCP/IP based channels (FTP, HTTP,
etc.), is it assumed that the IP address is already known because you
are using SNMP to talk to the Printer? What if you are using SNMP over
IPX to get the at the MIB, is there somewhere else to ask it its IP address?

I ask this because if the channel type is this one, chNetwareRPrinter(9),
the transport protocol used is SPX.  Do you also want to know the full
IPX/SPX address for this node, i.e., net:node:socket?
Should we add a paramenter called "Address" or is the IPX/SPX address
obtainable from somewhere else?

3. Page 37 an 38
There has been some discussion lately about this.  Bill W. proposed
something recently that I have just now had a chance to take a
better look at and I have some revisions to his suggestion:

                             chNetwarePServer(10),  -- Novell, Inc.
                                 -- prtChannelInformation keywords:
                                 -- Server Name
                                 -- Keyword: "Server"
                                 -- Syntax:       Name
                                 -- Status:  Mandatory
                                 -- Multiplicity  Single
                                 -- Description: The name of the server for
                                 -- which the PServer is defined
                                 --
                                 -- PServer
                                 --
                                 -- Name:         "PServer"
                                 -- Syntax:       Name
                                 -- Status:       Mandatory
                                 -- Multiplicity  Single
                                 -- Description: The Bindery name of the
                                 -- PServer
                                 --
                                 -- NDS Tree
                                 --
                                 -- Keyword: "NDSTree"
                                 -- Syntax:       Name
                                 -- Status:       Mandatory
                                 -- Multiplicity  Multiple
                                 -- Description: The NDS Tree name
                                 --
                                 -- PServer
                                 --
                                 -- Keyword: "NDSPServer"
                                 -- Syntax:       Name
                                 -- Status:       Mandatory
                                 -- Multiplicity  Single
                                 -- Description: The fully qualified name
                                 -- of the PServer object in the tree
                                 -- 
                                 -- There must be exactly one Server and
                                 -- one PServer entry or exactly one NDSTree
                                 -- and one NDSPServer Entry

4. Page 108
The following line:
          -- Netware Print Server           SPX/IPX based channel
should probably be:
          -- Netware Print Server           NCP based channel
See comments below about NCP over IPX and IP.

5. Page 107
Page 107 states:
          "-- The Print Job Delivery Channel table describes the
          -- capabilities of the printer and not what is currently being
          -- performed by the printer"
In the next release of IntranetWare, NCPs will be able to run over both IP
and IPX.  When that is the case, shouldn't the channel info also include
the possible IP address as well as the IPX address or just the fact that it
can run over IP or IPX?  This relates to my earlier questions about where
the IP and IPX addresses are retrieved: are they just known or ar the
queried in a MIB someplace?

Do we need to add something like:
                                 -- Keyword: "Protocol"
                                 -- Syntax:       Name
                                 -- Status:       Mandatory
                                 -- Multiplicity  Multiple
                                 -- Description: Either "IP" or "IPX" or both
                                 -- 
6. Page 41
Will anyone ever populate a channel type of just SPX as compared to
NPrinter or PServer? Why do we have chPortSPX(41) separated out? 
Should it be part of chNetwareNPrinter and chNetwarePServer?

                  chPortSPX(41),       -- Sequenced Packet Exchange (SPX)
                                       -- socket.
                                       -- Novell, Inc. Similar to TCP, a
                                       -- bi-directional data pipe using
                                       -- Novell SPX as a transport.
                                --
                                -- prtChannelInformation keywords:
                                --
                                -- Network Number
                                --
                                -- Keyword:  "Net"
                                -- Syntax:        HexString
                                -- Status:        Mandatory
                                -- Multiplicity   Single
                                -- Description:   The network number
                                --
                                -- Node Number
                                --
                                -- Keyword:       "Node"
                                -- Syntax:        HexString
                                -- Status:        Mandatory
                                -- Multiplicity   Single
                                -- Description:   The Node Number
                                --
                                -- Socket Number
                                --
                                -- Keyword:       "Socket"
                                -- Syntax:        HexString
                                -- Status:        Mandatory
                                -- Multiplicity   Single
                                -- Description: The SPX socket number
                                -- There must be exactly one "Net" and one
                                -- "Node" and one Socket entry. A HexString
                                -- and one "Socket" entry. A HexString is a
                                -- binary value represented as a string of
                                -- ASCII characters using hexadecimal

7. Page 42
NDPS can run over TCP or SPX.  Do I need to add a parameter to chNDPS
to describe which transports are possible or is that the purpose of this
channel info?

That all for now,
Scott
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: [email-masked]
W: http://www.novell.com
************************************************************

---

From: JK Martin <[email-masked]>
Date: Wed, 16 Apr 1997 16:38:48 -0400 (EDT)

Scott,

You ask some very interesting questions.  And thanks for all the great info
about NetWare!  I'd like to try to respond to some of your questions, trying

> channel info for these channel types?

You know, this topic (like so many others) has arisen from time to time.
I recall a discussion about a year ago in which this topic was discussed
in fairly rabid detail.  And, like so many other issues, no real consensus
was resolved.

So now what do we do?  Perhaps the top-level choices are:

  1.  Ignore the problem (ie, the status quo)
  2.  Fix the problem now

If we chose to fix the problem, then at least these choices are possible:

  1.  Add another element to the Channel Entry definition

	Pro: Probably the most complete and elegant solution

	Con: This would be a very serious change to the MIB definition,
	     and we would have to determine/define how to represent the
	     the possible set of transport protocols (enums, strings, etc)

  2.  Define several more Channel Type values that "mirror" the existing
      set, where the new ones explicitly encode the relevant transport
      protocol; the existing values remain the same, but additional
      description text would explicitly state the transport used.

	For example, "chNetwarePServer" would be changed so that its
	description would explicitly state the binding to IPX/SPX, and
	a new Channel Type would be named, say, "chNetwarePServer-IP"
        or something like that.

	Pro: Least impact on the existing MIB (and existing implementations)

	Con: Lots of duplication that would be annoying in the worst case

IMHO, this issue needs to be discussed ASAP by the group, even if the net
result is "retain the status quo".  Hopefully we can resolve this on the
mailing list prior to the next scheduled PMP telecon.

> capitalization: Pserver, PServer.  Make them all consistent. Suggest

I'm a bit surprised you don't insist on "PSERVER", as that string format
seems so prevalent in NetWare documention.  But hey, you're representing
Novell, so what you say goes...  ;-)

> IPX to get the at the MIB, is there somewhere else to ask it its IP address?

I have always assumed that the IP address (or network address) can be
resolved via the related Interface index value defined as part of the
Channel Entry definition.  (Is this a naive assumption?)

> obtainable from somewhere else?

Good question.  One of the areas of general consensus for the Channel Table
in general (as I recall) is that this information serves two primary
purposes:

  1.  To provide a way to enable/disable a particular print service
      (oops, I mean "Channel" ;-), as that capability is commonly available
      via the front panels of so many printers; and, a top-level goal of
      the Printer MIB itself is to provide as much functionality via SNMP
      as would be available via the front panel.

  2.  To provide a way for a print client to "bootstrap" itself to be able
      to communicate to the printer to submit a print job.

Regarding #2 above, a further consensus was reached in which the group
acknowledged that it is both unreasonable and undesirable to attempt to
provide absolutely ALL possible information in the Printer MIB for any
given Channel Type.  Instead, only the most rudimentary info should be
made available that would allow a print client to identify whether it
would be able to communicate with the printer using a specific Channel
Types for which the print client was designed to handle.

As a bonafide "professional print driver developer", I was particularly
pleased to see the group reach such a consensus where simplicity was
the rule of the day.  8-)

> See comments below about NCP over IPX and IP.

I realize that this snippet is from the introductory text, and not
from part of an object definition, so this might not be that big of
a deal.  However, might you be suggesting that "NCP" would be one
of the proposed "transport" values for a Channel Entry?

If so, then here is where things can get really sticky.  It's one thing
for us to consider a new Channel Entry element describing the transport.
But to "factor out" differences and say "NCP" would make things far less
precise, and therefore (IMHO) far less useful.

For example, say I write a print client that can talk PSERVER, but that
the print client runs on a host that only supports IP.  If the print client
then queries the printer (via SNMP) to determine whether the printer supports
the PSERVER protocol, how can I tell whether the printer supports PSERVER
over IP (and not the usual SPX)?

Again, it may not be that you're suggesting "NCP" as a potential "transport"
protocol value, but this situation is worthy of understanding the potential
pitfalls of taking this approach.

In either case, I believe you stated earlier that should we pursue adding
"transport" as a Channel Entry element, then only the "lowest" type of
transport protocol should be used (eg, "IP", "IPX", etc).  This is a
good thing, IMHO.

>                                  -- Description: Either "IP" or "IPX" or both

I would be in favor of adding this new element, but this is going to
require a serious round of consensus from the group at large, given
the Pros and Cons listed earlier in this message.

> Should it be part of chNetwareNPrinter and chNetwarePServer?

Boy, am I glad you asked these questions!

On one hand, it should be obvious that one could develop a mechanism
to submit print jobs using a simple (raw) stream using SPX in the
exact same manner as the current "chPortTCP" Channel Type, right?

On the other hand, does such a mechanism currently exist?

If no such implementation exists, then do we want to maintain definitions
in the Printer MIB of what "could be implemented" versus what "is currently
implemented"?  This is pretty much a philosophical issue that will probably
end up being aligned with the "Big/Fat vs. Small/Light" argument for
specifications in general.

Is there anyone out there in PWG-land willing to stand up and declare
that he/she requires this Channel Type definition?

> to describe which transports are possible or is that the purpose of this

This appears to be the same issue described in a couple of your other
issues above, right?

Again, Scott, thanks for asking so many excellent questions.  Hopefully
we'll get some real discussion rolling on the mailing list now.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: [email-masked] (Bill Wagner)
Date: Wed, 16 Apr 1997 18:08:08 -0400

Scott, 
     
     Since this is an area in which I have some interest, I will provide 
     what I understand to be answers consistent with what PMP has done. I 
     cordially invite different opinions on what the consensus is, or what 
     it should be.
     
     1. No objection
     
     2. Typically, the channel refers to the service or the 'highest' level 
     protocol involved in delivering the print data to the printer. 
     Therefore, chPortTCP(37) refers to a dumb TCP/IP connection of some 
     undefined service on some host, to the interpreter. That is, there is 
     no 'print service involved. Same thing for local ports such as serial, 
     centronics and 1284.
     
     If TCP/IP is used for IPP for example, the channel would be IPP. If 
     IEEE 1284.1 is used over IEEE1284, the channel would be IEEE1284.1. 
     Etc.
     
     Each channel is correlated with the interface table in MIB-2, with the 
     prtChannelIfIndex pointing to the particular listing in the MIB-2 
     interface table that supports the channel. The Interface table has all 
     the good stuff like physical address. It is also keyed to the other 
     groups in MIB-2, including the IP group which includes the IP address 
     and more. 
     Unfortunately, the integrity of this reference is not insured, since 
     the relationship between the MIB-2 "device" and the printer is not 
     well defined. Further, for unknown reasons, the printer MIB only 
     requires the Systems group (which is useless with respect to a 
     printer) and the interfaces group to be supported. Most printer 
     implementations do support the applicable other groups of MIB-2 so 
     that the IP  is covered.  But this is not required by the Printer MIB.
     
     Yes, there is a hole with respect to IPX/SPX as well as all other non 
     IP protocols. Some implementations have this filled in proprietary 
     MIBS. Conceivably, the Netware MIB could be implemented, but I do not 
     know if anyone is doing that. But does one really care about IPX/SPX 
     addresses when one has the SAP names used?
     
     3. My suggestion with respect to the PServer was to simplify the 
     handling of the channel table. A particular Print Server can be 
     defined on multiple file servers (16 for DPI Print servers). This 
     would require 16 channels. The purpose and advantage of this is 
     unclear. The cumbersomeness is obvious. The information I suggested 
     was the same as that used for RPrinter; if it is adequate for an 
     RPrinter channel, I suggest that it is adequate for a PServer channel.

     4, 5. Following the general approach, the interfaces could be enhanced 
     so that more than one interface entry (e.g., IP, IPX) could be 
     provided over one physical interface (ethernet). If this were done,  a 
     PServer channel running over IP would be correlated to an IP interface 
     in the MIB-2 interface table. A PServer channel running over IPX would 
     be correlated to an IPX interface. 
     
     Alternatively, these may be independent channels on the same 
     interface, differentiated by another keyword in the channel 
     information object. But the distinction must provide some useful 
     information, not just an academic follow through on the structure.
     
     6.  Yes. Some implementations  use a serverless IPX/SPX connection, 
     with no print services in channel,  to provide a connection between a 
     user and a printer over which a print job (and response) is 
     communicated.

     7. As with Print Servers, if the distinction is important to a 
     management application, the IP/IPC distinction could be handled by an 
     additional keyword under channel information (and treating the two as 
     separate channels) or conceivably by defining different interfaces in 
     MIB-2. I agree that PMP should suggest a preferred way. An additional 
     keyword, such as Protocol seems fine to me. But a given channel cannot 
     be both.
     
     Bill Wagner Osicom/DPI

______________________________ Reply Separator _________________________________
Subject: PMP> Novell Channel Type Info
Author:  "Scott A. Isaacson" <[email-masked]> at Internet
Date:    4/16/97 12:57 PM

General Question:

1. Page 37

2. Page 37 
Question:

3. Page 37 an 38

4. Page 108
The following line:

5. Page 107
Page 107 states:

7. Page 42

That all for now,
Scott

---

From: [email-masked] (Ira Mcdonald x10962)
Date: Wed, 16 Apr 1997 17:15:56 PDT

Hi Scott,

I see that while I was offline writing the following reply to you and
Bill Wagner, Jay Martin offered some more good thoughts and questions.
I think some of my comments below at least partially address some of
Jay's comments as well.

Hi Bill and Scott,                             Wednesday (16 April 1997)

My comments are imbedded in your two notes below.  Because I'm prone to
sounding pedantic on communications issues, I'll apologize at the outset
and say that I applaud your patient work to wrestle with 'channels' (ie,
protocol stacks) in the Printer MIB.  It would be nice if the IETF took
up this problem more generally (but without the level of 'statistics'
baggage which characterizes the IP/ICMP/TCP/UDP groups of MIB-II and the
the other lower-layer MIBs), but I am not aware that they have.  Client
systems usually don't care about 'statistics' - they just care about the
communications paths (ie, addresses and protocol stacks used) to reach
other end systems (eg, network printers).

All of my comments are preceded by '<IEM>'.

Cheers,
- Ira McDonald (outside consultant at Xerox)
  High North Inc
  PO Box 221
  Grand Marais, MI  49839

>---------------------- Included Messages -----------------------------<
>Date: Wed, 16 Apr 1997 15:08:08 PDT
>From: [email-masked] (Bill Wagner)
>Subject: Re: PMP> Novell Channel Type Info
>To: [email-masked]
>
>     
>     Scott, 
>     

<IEM>
In UNIX or embedded systems STREAMS-based protocol stacks, the application
which receives a packet from a TCP port (for example) does NOT receive
info about which physical interface (eg, 802.3 Ethernet vs 802.5 Token
Ring) passed that packet up to the IP network layer.  Xerox engineers
believe that this is one of several instances where the Printer MIB
Channel table is 'broken' in its references to the Interfaces table (ie,
LPR has no clue whether the Ethernet or Token Ring LAN adapters delivered
a given job).

>     be correlated to an IPX interface. 

<IEM>
RFC 1573 (Evolution of Interfaces group of MIB-II) defines a number of
new 'ifTypes', and an 'ifStackTable' (which inspired some proprietary
MIB work of mine, here at Xerox).  But RFC 1573 specifically prohibits
the use of the 'ifTable' for protocol layers higher than datalink (OSI
layer 2).  It says the 'ifStackTable' tells you the details BELOW an
IP (or other) network protocol (OSI layer 3).  I haven't read the I-Ds
which update RFC 1573, but they are (after all) only I-Ds, so they
offer little help right now in finalizing the Printer MIB V2.

If a system implements the Interfaces Group per RFC 1213 (which is an
IETF Mandatory Standard), rather than updated per RFC 1573 (which is
merely an IETF Proposed Standard), then the 'ifPhysAddress' object ONLY
lists the address "at the protocol layer immediately 'below' the network
layer in the protocol stack".  If a system (eg, Novell NetWare 4.x) is
running 802.2 LLC w/ SNAP, this address does NOT clearly map to any
802.3, 802.4, or 802.5 MAC layer address (because LLC addresses assume
a priori knowledge of the mapping from LLC or LLC_SNAP 'service access
points' to the 'underlying' MAC addresses on peer systems).

>     keyword, such as Protocol seems fine to me. But a given channel cannot 

<IEM>
The 'management application' our common client team here at Xerox builds
is an ordinary 'print client' (looking for suitable printers and how to
send jobs to them).  Only a whole protocol stack is helpful.

>                                -- Description: The PServer's SAP name

<IEM>
Yes, I agree that the distinctions in the 'underlying' protocol stacks
are cogent.

>                                 -- Description: Either "IP" or "IPX" or both

<IEM>
Does NDPS only operate over one 'flavor' of RPC?  Probably a dumb question,
but perhaps relevant.  Certainly some other ISO DPA-based systems operate
over more than one 'flavor' of RPC (eg, ONC RPC vs DCE RPC).  Might also
need to be made explicit.

---

From: [email-masked] (Bill Wagner)
Date: Wed, 16 Apr 1997 21:19:23 -0400

Ira, 
     
     Thanks for the factual info. One comment struck me as odd however
     
     "Xerox engineers believe that this is one of several instances where 
     the Printer MIB Channel table is 'broken' in its references to the 
     Interfaces table (ie, LPR has no clue whether the Ethernet or Token 
     Ring LAN adapters delivered a given job)."
     
     Since, with a properly constructed interface table, Token Ring and 
     Ethernet are different interfaces and will have different interface 
     indexes.  The interface indices are identified in the channel table. I 
     guess I do not understand what the problem is.
     
     Bill Wagner  DPI/Osicom 

______________________________ Reply Separator _________________________________
Subject: Re:  PMP> Novell Channel Type Info
Author:  [email-masked] (Ira Mcdonald x10962) at Internet
Date:    4/16/97 5:15 PM

Hi Scott,

Cheers,

<IEM>

<IEM>

<IEM>

<IEM>

<IEM>

---

From: [email-masked] (Ira Mcdonald x10962)
Date: Wed, 16 Apr 1997 18:43:19 PDT

Hi Bill,

Your caveat is a 'properly contstructed interface table'.  But per
RFC 1213, the 'interface' that Internet IP or NetWare IPX operates
over may be 'LLC_SNAP' (the 'next' lower sublayer below the network
layer).  And WITHOUT the extensions in the 'ifStackTable' of 
RFC 1573, it is impossible to discover that the 'real' interface
under 'LLC_SNAP' is Ethernet vs Token Ring.

Even if you ignore that problem, and just show 'all' your primitve
interfaces, and show that an LPR 'channel' exists over IP over
Ethernet and another LPR 'channel' exists over (the same instance
of) IP over Token Ring, you can't count traffic at the LPR level
for the 'separate' channels (or associate it with the particular
'source' channel for Job Monitoring MIB purposes), because LPT
(oops, LPR) just gets packets from TCP, who gets them from IP,
who quietly 'forgets' which physical interface they came from.

If you're still confused (I certainly am, obviously), we could
trade some private email and save the long-suffering PWG members
some cycles.

Cheers,

>-------------- Included Million Messages ---------------------<
>From [email-masked] Wed Apr 16 21:22:25 1997
Date: Wed, 16 Apr 1997 18:19:23 PDT
From: [email-masked] (Bill Wagner)
Subject: Re[2]: PMP> Novell Channel Type Info
To: [email-masked]
Content-Description: cc:Mail note part
Sender: [email-masked]
Status: R

     Ira, 

     
     
     Bill Wagner  DPI/Osicom 

Hi Scott,

Cheers,

<IEM>

<IEM>

<IEM>

<IEM>

<IEM>

---

From: JK Martin <[email-masked]>
Date: Thu, 17 Apr 1997 11:20:39 -0400 (EDT)

Ira,

Like Bill, I am also curious about your statement:

Can you share some insights as to why Xerox wants to know exactly which
interface was used to deliver, say, an LPR job?  I realize that in the
realm of statistics, then this might be useful to a few folks.  But are
there any other reasons why you need this info?

	...jay