Subject: [eap] Proposed resolution of issue #41

From: [email-masked] (Paul Funk)
Date: Mon, 25 Nov 2002 21:31:18 -0500

--=====================_1713331830==_.ALT
Content-Type: text/plain; charset="us-ascii"

Here is a proposed resolution of issue 41 - Nak of extended types.

One thing I learned while writing this proposal: the past tense of 
Nak is "Nak'd", not "Naked".

Out-of-scope changes
--------------------------------
I've taken some liberties that go beyond the scope of this issue. 
Feel free to change things back to the way they were if there 
are objections:

1   I changed 255 to 254, on the theory that experimental use of 
EAP using type 255 is legacy behavior that should not be broken.

2   The original Vendor-specific type has everything after the 
Vendor-Id defined by the vendor, with the suggested format of 
Vendor-Type immediately following (RADIUS-style). I changed that 
to make the format uniform (Diameter-style), so all v-s types have 
a fixed format that includes Vendor-Type and are thus interpretable 
by anyone. Since Vendor-type is used as part of the protocol when 
Nak'ing, it's best to make sure everyone uses it the same way. I 
don't believe this limits vendor flexibility.

Interesting implications of this proposal
---------------------------------------------------------
Note that by using single-octet types and vendor-specific types 
in an interchangeable way, it is possible to extend EAP in all 
kinds of ways without breaking backward-compatibility. For example, 
if the authenticator starts the conversation with a vendor-specific 
type (as indicated by the first byte being 254), a legacy peer would 
Nak but a new peer could respond with a vendor-specific type 
(possibly a v-s Nak). Once both parties are talking vendor-specific, 
anything is possible. 

For example, the issue of bi-directional success and failure packets 
could be solved within this context.

Proposed Text
---------------------

5.5.  Vendor-specific

Description

   Due to EAP's popularity, the original Method Type space, which only
   provides for 255 values, is being allocated at a pace, which if
   continued, would result in exhaustion within a few years.  Since many
   of the existing uses of EAP are vendor-specific, the Vendor-Specific
   Method Type is available to allow vendors to support their own
   extended Types not suitable for general usage. 

   The Vendor-specific type is also used to expand the global Method 
   Type space beyond the original 255 values. A Vendor-Id of 0 maps the 
   original 255 possible types onto a namespace of 2^32-1 possible types, 
   allowing for virtually unlimited expansion. (Note that type 0 is 
   never used.)

   An implementation that supports the Vendor-specific attribute MUST 
   treat EAP types that are less than 256 equivalently whether they 
   appear as a single octet or as the 32-bit Vendor-Type within a 
   Vendor-specific type where Vendor-Id is 0. The single exception 
   to this rule is the Nak type, as described below.

   Peers not equipped to interpret the Vendor-specific Type MUST send a
   Nak, and negotiate a more suitable authentication method.

   A summary of the Vendor-specific Type format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |               Vendor-Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Vendor-Type                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vendor data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

   254 for Vendor-specific

Vendor-Id

   The Vendor-Id is 3 octets and represents the SMI Network Management
   Private Enterprise Code of the Vendor in network byte order, as
   allocated by IANA. A Vendor-Id of zero is reserved for use by the
   IETF in providing an expanded global EAP Type space.

Vendor-Type

   The Vendor-Type field is four octets and represents the vendor-
   specific Method Type. 

   If Vendor-Id is zero, the Vendor-Type field is an extension and 
   superset of the existing namespace for EAP types. The first 256 
   types are reserved for compatibility with single-octet EAP types 
   that have already been assigned or may be assigned in the future.
   Thus, EAP types from 0 through 255 are semantically identical 
   whether they appear as single octet EAP types or as Vendor-Types 
   when Vendor-Id is zero.

Vendor-Specific

   The Vendor-Specific field is dependent on the vendor's definition of
   that attribute. Where a Vendor-Id of zero is present, the Vendor-
   Specific field will be used for transporting the contents of EAP
   Methods of Types defined by the IETF.

5.5.1 Vendor-Specific Nak

   The Vendor-specific type may be Nak'd in either of two ways: Legacy 
   Nak or Vendor-specific Nak

5.5.1.1 Legacy Nak

   The Legacy Nak, consisting of a single octet of value 3, is used to 
   reject Vendor-specific requests entirely. This type of Nak indicates 
   that the Vendor-specific type itself is unacceptable to the peer. 
   This type of Nak provides backward compatibility for peers that 
   implement RFC2284 or earlier. 

   Peer implementations that do support the Vendor-specific type SHOULD 
   NOT use this type of Nak, even as a shortcut to rejecting all possible 
   Vendor-specific methods at once. Future specifications may depend on 
   an authenticator being able to recognize the implementation level of 
   the peer, and eliciting a Nak may provide a means of doing this.

5.5.1.2 Vendor-specific Nak

   The Vendor-specific Nak is a Nak within a Vendor-specific type with 
   Vendor-Id of 0, as shown below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 254   |            Vendor-Id = 0                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Vendor-Type = 3                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Desired Types ...
   +
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Desired Types field contains zero or more Vendor-specific 
   Types, in order of preference, with the most preferred method 
   first; each Type is In order to avoid an interminable negotiation, 
   the Peer MUST only include Types that it is willing to accept.

   Each Type in the Desired Types field MUST be in the form of a 
   Vendor-specific Type, even if it is a Type from the original 
   namespace 1 - 255.

   The Vendor-specific Nak allows individual authentication methods 
   expressed as Vendor-specific Types to be Nak'd, without rejecting 
   the Vendor-specific Type in general. In addition, it permits the 
   peer to list any authentication type -- whether IETF- or vendor-
   defined -- as acceptable.

   An example of a Vendor-specific Nak indicating that MD5-Challenge 
   would be acceptable is shown below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      254      |                       0                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               3                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       4       |                       0                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               4                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

--=====================_1713331830==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Here is a proposed resolution of issue 41 - Nak of extended types.<br>
<br>
One thing I learned while writing this proposal: the past tense of <br>
Nak is &quot;Nak'd&quot;, not &quot;Naked&quot;.<br>
<br>
<br>
Out-of-scope changes<br>
--------------------------------<br>
I've taken some liberties that go beyond the scope of this issue. <br>
Feel free to change things back to the way they were if there <br>
are objections:<br>
<br>
1&nbsp;&nbsp; I changed 255 to 254, on the theory that experimental use
of <br>
EAP using type 255 is legacy behavior that should not be broken.<br>
<br>
2&nbsp;&nbsp; The original Vendor-specific type has everything after the
<br>
Vendor-Id defined by the vendor, with the suggested format of <br>
Vendor-Type immediately following (RADIUS-style). I changed that <br>
to make the format uniform (Diameter-style), so all v-s types have <br>
a fixed format that includes Vendor-Type and are thus interpretable 
<br>
by anyone. Since Vendor-type is used as part of the protocol when <br>
Nak'ing, it's best to make sure everyone uses it the same way. I <br>
don't believe this limits vendor flexibility.<br>
<br>
<br>
Interesting implications of this proposal<br>
---------------------------------------------------------<br>
Note that by using single-octet types and vendor-specific types <br>
in an interchangeable way, it is possible to extend EAP in all <br>
kinds of ways without breaking backward-compatibility. For example, 
<br>
if the authenticator starts the conversation with a vendor-specific 
<br>
type (as indicated by the first byte being 254), a legacy peer would
<br>
Nak but a new peer could respond with a vendor-specific type <br>
(possibly a v-s Nak). Once both parties are talking vendor-specific,
<br>
anything is possible. <br>
<br>
For example, the issue of bi-directional success and failure packets
<br>
could be solved within this context.<br>
<br>
<br>
Proposed Text<br>
---------------------<br>
<br>
<tt>5.5.&nbsp; Vendor-specific<br>
<br>
Description<br>
<br>
&nbsp;&nbsp; Due to EAP's popularity, the original Method Type space,
which only<br>
&nbsp;&nbsp; provides for 255 values, is being allocated at a pace, which
if<br>
&nbsp;&nbsp; continued, would result in exhaustion within a few
years.&nbsp; Since many<br>
&nbsp;&nbsp; of the existing uses of EAP are vendor-specific, the
Vendor-Specific<br>
&nbsp;&nbsp; Method Type is available to allow vendors to support their
own<br>
&nbsp;&nbsp; extended Types not suitable for general usage. <br>
<br>
&nbsp;&nbsp; The Vendor-specific type is also used to expand the global
Method <br>
&nbsp;&nbsp; Type space beyond the original 255 values. A Vendor-Id of 0
maps the <br>
&nbsp;&nbsp; original 255 possible types onto a namespace of 2^32-1
possible types, <br>
&nbsp;&nbsp; allowing for virtually unlimited expansion. (Note that type
0 is <br>
&nbsp;&nbsp; never used.)<br>
<br>
&nbsp;&nbsp; An implementation that supports the Vendor-specific
attribute MUST <br>
&nbsp;&nbsp; treat EAP types that are less than 256 equivalently whether
they <br>
&nbsp;&nbsp; appear as a single octet or as the 32-bit Vendor-Type within
a <br>
&nbsp;&nbsp; Vendor-specific type where Vendor-Id is 0. The single
exception <br>
&nbsp;&nbsp; to this rule is the Nak type, as described below.<br>
<br>
&nbsp;&nbsp; Peers not equipped to interpret the Vendor-specific Type
MUST send a<br>
&nbsp;&nbsp; Nak, and negotiate a more suitable authentication
method.<br>
<br>
&nbsp;&nbsp; A summary of the Vendor-specific Type format is shown
below.&nbsp; The<br>
&nbsp;&nbsp; fields are transmitted from left to right.<br>
<br>
&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3<br>
&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
7 8 9 0 1<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; | Vendor data ...<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
<br>
Type<br>
<br>
&nbsp;&nbsp; 254 for Vendor-specific<br>
<br>
Vendor-Id<br>
<br>
&nbsp;&nbsp; The Vendor-Id is 3 octets and represents the SMI Network
Management<br>
&nbsp;&nbsp; Private Enterprise Code of the Vendor in network byte order,
as<br>
&nbsp;&nbsp; allocated by IANA. A Vendor-Id of zero is reserved for use
by the<br>
&nbsp;&nbsp; IETF in providing an expanded global EAP Type space.<br>
<br>
Vendor-Type<br>
<br>
&nbsp;&nbsp; The Vendor-Type field is four octets and represents the
vendor-<br>
&nbsp;&nbsp; specific Method Type. <br>
<br>
&nbsp;&nbsp; If Vendor-Id is zero, the Vendor-Type field is an extension
and <br>
&nbsp;&nbsp; superset of the existing namespace for EAP types. The first
256 <br>
&nbsp;&nbsp; types are reserved for compatibility with single-octet EAP
types <br>
&nbsp;&nbsp; that have already been assigned or may be assigned in the
future.<br>
&nbsp;&nbsp; Thus, EAP types from 0 through 255 are semantically
identical <br>
&nbsp;&nbsp; whether they appear as single octet EAP types or as
Vendor-Types <br>
&nbsp;&nbsp; when Vendor-Id is zero.<br>
<br>
Vendor-Specific<br>
<br>
&nbsp;&nbsp; The Vendor-Specific field is dependent on the vendor's
definition of<br>
&nbsp;&nbsp; that attribute. Where a Vendor-Id of zero is present, the
Vendor-<br>
&nbsp;&nbsp; Specific field will be used for transporting the contents of
EAP<br>
&nbsp;&nbsp; Methods of Types defined by the IETF.<br>
<br>
5.5.1 Vendor-Specific Nak<br>
<br>
&nbsp;&nbsp; The Vendor-specific type may be Nak'd in either of two ways:
Legacy <br>
&nbsp;&nbsp; Nak or Vendor-specific Nak<br>
<br>
5.5.1.1 Legacy Nak<br>
<br>
&nbsp;&nbsp; The Legacy Nak, consisting of a single octet of value 3, is
used to <br>
&nbsp;&nbsp; reject Vendor-specific requests entirely. This type of Nak
indicates <br>
&nbsp;&nbsp; that the Vendor-specific type itself is unacceptable to the
peer. <br>
&nbsp;&nbsp; This type of Nak provides backward compatibility for peers
that <br>
&nbsp;&nbsp; implement RFC2284 or earlier. <br>
<br>
&nbsp;&nbsp; Peer implementations that do support the Vendor-specific
type SHOULD <br>
&nbsp;&nbsp; NOT use this type of Nak, even as a shortcut to rejecting
all possible <br>
&nbsp;&nbsp; Vendor-specific methods at once. Future specifications may
depend on <br>
&nbsp;&nbsp; an authenticator being able to recognize the implementation
level of <br>
&nbsp;&nbsp; the peer, and eliciting a Nak may provide a means of doing
this.<br>
<br>
5.5.1.2 Vendor-specific Nak<br>
<br>
&nbsp;&nbsp; The Vendor-specific Nak is a Nak within a Vendor-specific
type with <br>
&nbsp;&nbsp; Vendor-Id of 0, as shown below:<br>
<br>
&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3<br>
&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
7 8 9 0 1<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp; Type = 254&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Id =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Type =
3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Desired Types ...<br>
&nbsp;&nbsp; +<br>
&nbsp;&nbsp; |<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
<br>
&nbsp;&nbsp; The Desired Types field contains zero or more
Vendor-specific <br>
&nbsp;&nbsp; Types, in order of preference, with the most preferred
method <br>
&nbsp;&nbsp; first; each Type is In order to avoid an interminable
negotiation, <br>
&nbsp;&nbsp; the Peer MUST only include Types that it is willing to
accept.<br>
<br>
&nbsp;&nbsp; Each Type in the Desired Types field MUST be in the form of
a <br>
&nbsp;&nbsp; Vendor-specific Type, even if it is a Type from the original
<br>
&nbsp;&nbsp; namespace 1 - 255.<br>
<br>
&nbsp;&nbsp; The Vendor-specific Nak allows individual authentication
methods <br>
&nbsp;&nbsp; expressed as Vendor-specific Types to be Nak'd, without
rejecting <br>
&nbsp;&nbsp; the Vendor-specific Type in general. In addition, it permits
the <br>
&nbsp;&nbsp; peer to list any authentication type -- whether IETF- or
vendor-<br>
&nbsp;&nbsp; defined -- as acceptable.<br>
<br>
&nbsp;&nbsp; An example of a Vendor-specific Nak indicating that
MD5-Challenge <br>
&nbsp;&nbsp; would be acceptable is shown below:<br>
<br>
&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3<br>
&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
7 8 9 0 1<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
254&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| <br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
<br>
<br>
<div>Paul Funk</div>
<div>Funk Software, Inc.</div>
<div>617 497-6339</div>
<div>[email-masked]</div>
</html>

--=====================_1713331830==_.ALT--