Subject: [Geopriv] Comments on [draft-ietf-ecrit-phonebcp-00.txt]

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 11 Jan 2007 11:00:12 -0500

General Comments
phonebcp has requirements for end devices, proxies, and PSAPs. It would be useful if there were some way to easily distinguish which requirements applied to which elements, such as specific subsections for the different elements, or by numbering the requirements, with a separate numbering scheme for each element. I would like to be able to use this document by telling vendors that they must comply with it. I would want to tell proxy vendors they must comply with the proxy requirements, and SIP endpoint vendors that they must comply with the SIP endpoint requirements. The easier it is for them to locate all the individual requirements that apply, the greater the likelihood that they will successfully comply. I'm happy to help with this, in any way.

I also believe this document needs considerably more detail. Some specifics on this are at the end of this email, along with an offer to help write some of those specifics. In general, I would like to see this document provide specifications at a level so that device behavior is highly consistent and predictable between different vendors.

Specific Comments
Section 2
Numbered list, number 2 
It really doesn't matter whether the user dialed a "visited" or "home" number, so long as the number is recognized by the device as an emergency number. Could this be genericized to say "User dials an emergency number that is known to the device."?

Bullet list, 3rd bullet
When I read "as the uri of an emergency call", this suggested "Request-URI" to me. But Section 6.1 says this would be the uri in "To:". There are just so many URIs in SIP Invite. Could this be made more explicit to say "as the "To:" uri of an emergency call"?
4th bullet
And say that the PSAP's URI is the "Request-URI". I think it's also important to note that the LoST query validated the location.

Section 4
2nd paragraph
[editorial] expand "LCPs" acronym

[editorial] 3rd and 7th paragraphs are redundant; 4th and 8th are also effectively redundant. Recommend deleting 3rd paragraph, and merging the best parts of 4 and 8.

I have grave concerns over the mandating of LLDP in consumer products, and will address this in a separate email. I realize LLDP has been discussed before, but I don't think it was fully resolved.

Section 6.1
Item 1
The initial SHOULD statement is too weak. I would prefer "If the device recognizes the dialstring as an emergency call, and it successfully gets a uri as a response to a LoST query, then it MUST place that uri in the Request-URI. If the device recognizes the call as an emergency call, but does not succeed in getting a uri from a LoST query, then it MUST place an "sos" service URN in the Request-URI. [I assume that the reference to the "To:" field for the "sos" service urn should have been "Request-URI".]
I appreciate the purpose of draft-rosen-iptel-dialstring-04, but I'm not sure it's really appropriate or needed as a requirement in this bcp. That is, devices will continue to format dial strings just as they always have (e.g., sip:[email-masked]), unless VSPs adopt the changes recommended in the referenced draft. And it's not at all clear to me when those changes will happen. I recommend saying that "If the device cannot do local dialstring interpretation, then it is expected that the device will place the dialed digits in the Request-URI, consistent with the expectations of its VSP's proxy."

Item 2
The "SHOULD" statement regarding the service URN is too weak. Stating that "To:" must be present seems unnecessary to me, since RFC 3261 already requires it. I would prefer: 
If the device recognizes the dial string as an emergency number, it MUST place an "sos" service URN in the To: header. sips MUST be specified ... TLS connection. If the device does not recognize the dial string, it is expected that the device will place the dialed digits in the To: header, consistent with the expectations of its VSP's proxy.

Item 3
[editorial] Expand "AoR"

RFC 3261 requires From:. The MUST statement seems redundant.
How is this requirement intended to modify the requirements of RFC 3261, in which AoR in To: is effectively a "MAY" ("possibly" is the exact word used), and where it is explicit that "Anonymous" with a meaningless URI is perfectly ok? 

Item 4
RFC 3261 requires Via:, and it frequently has the local IP address and port of the device. This requirement is suggesting it should be something else? 

Item 5
Need to include reference (draft-rosenberg-sip-ua-loose-route-00) for loose route parameter? I didn't have a clue what a loose route parameter was.

References
[editorial] update dhcp-civil reference to RFC 4676, here and in document text.

-------------------------------------------
What I think is missing
---------------------------------
I'm happy to provide text for any of these items. The way I see it, if it isn't in phonebcp, I'm going to have to write it anyway, either to go into a document at another standards body, or for the company I'm with to be able to provide requirements to its equipment vendors.

Per the framework document, this phonebcp needs to address what happens when it receives multiple locations.

Requirements for multipart (per the discussion on the email reflector)

Expanded requirements on the disabling of features. For example, instead of simply listing "Outbound Call Blocking", it might be better to say "The calling device MUST NOT apply any outbound call blocking rules to dial strings or URIs that are defined in the device as emergency dial strings or URIs." In many cases, these features are frequently provided out of a VSP features server. Therefore, requirements for disabling of features need to be written for VSP features, as well as calling device features.

Requirements for routers that may have VoiP behind them

Considerably more detail on location determination. Here is a slightly updated version of what I sent previously:
Endpoint device
 1. If the device has a DHCP client, the client MUST support RFC 3825 and RFC 4676. [There is an expectation that the responding DHCP server has the intelligence to respond to only one or the other.]
   a. If the device is configured to use DHCP for bootstrapping, it MUST include both options in its DHCP REQUEST.
   b. When this device initiates an emergency call (see section on requirements for recognizing emeregency calls), it MUST send a DHCP INFORM message to refresh the location information. [Should it only use the option that was previously successful?]
 2. If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in <LLDP-MED reference>.
 3. The device MUST support whatever L7 mechanism we come up with.
 4. The device MUST support certain discovery mechanisms for finding that L7 server.
    a. Server discovery MUST be done before any VPNs are initiated.
 5. If the device allows for bootstrapping methods other than DHCP, it SHOULD support being configured to request location through a DHCP INFORM message with options as described in RFC 3825 and RFC 4676, when it is configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, static IP address).
   a. If the device is configured to request location through DHCPINFORM, then it MUST include both options in a DHCP INFORM message sent shortly after bootstrap, and before any VPN sessions are initiated.
   b. When this device initiates an emergency call (see section on requirements for recognizing emeregency calls), it MUST send a DHCP INFORM message to refresh the location information. [Should it only use the option that was previously successful?]
 6. Interactions of the various methods
   a. If a device receives location information from both LLDP-MED and DHCP which takes precedence?
   b. If a device successfully receives location information through either DHCP or LLDP-MED, it MUST NOT request a location through the L7 mechanism.
7. Location from embedded GPS?
8. Handling of multiple locations? 
9. The device MUST discover a LoST server. [This needs more detail, as to precisely which steps to take, and how to determone which steps to take.]
10. The device MUST do a LoST query, using its location, for each "sos" URI that is known to it.

Devices with DHCP servers
 1. The DHCP server MUST support RFC 3825 and RFC 4676. The device MUST be configurable to respond to either 0 (zero) or 1 of these options. The device MUST NOT allow both options to be enabled simultaneously.
 2. If the device supports LLDP-MED, it MUST meet the requirements of an LLDP-MED Network Connectivity Device, as defined in <LLDP-MED reference>. This is NOT a requirement for the device to support LLDP-MED -- only a requirement that if LLDP-MED is implemented, it must be done according to the spec.
 3. We might want to require this device to participate in some of the L7 server discovery mechanisms. 
 4. If the device has a WAN interface, it MUST meet requirements 1, 3, 5, 6, and 7 of the Endpoint device, over that WAN interface.
 5. A different set of L7 server discover mechanisms will probably need to be recommended.
 6. Do we want to require the device to be able to translate an L7 response on the WAN side to a DHCP response to LAN devices? Should this occur automatically?
 7. If the device receives location information via DHCP on its WAN interface, it MUST automatically configure itself to pass this information on to LAN-side devices that request it.
8. Does this device have a role in LoST discovery?

Barbara Stark
BellSouth Science & Technology (a recently acquired part of AT&T)

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA624

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 11 Jan 2007 14:45:50 -0500

Barbara,

Devices with DHCP servers 
 1. The DHCP server MUST support RFC 3825 and RFC 4676. The device MUST be
configurable to respond to either 0 (zero) or 1 of these options. The device
MUST NOT allow both options to be enabled simultaneously. 

I don't agree with this.  Assuming you are worried about the 2 locations
conflicting with one another (one in NY and the other in CA), the same
problem *could* exist if location was discovered via dhcp, then lldp-med,
then L7.  It's not the dhcp admin's job to determine whether the host
wants/needs civil or geo.  The host *could* need both assuming eventual use
by multiple applications.  The 'smarts' to figure out which one to use needs
to be at the host.

-Marc-

---

From: John Schnizlein <[email-masked]>
Date: Thu, 11 Jan 2007 15:02:32 -0500

Some of the proposed requirements on a DHCP host (copied below)  
appear to be in conflict with the clear intent of the design of DHCP  
to empower the host to acquire and use DHCP information as it  
chooses.  For example, RFC 2131 enables the host to choose among  
offers from multiple DHCP servers.  It also specifies (page 21, and  
sect 9.8 of RFC 2132) a list of the configuration parameters it prefers.

What is the compelling reason to reverse this design of DHCP, which  
has been working well in a wide variety of situations?

On Jan 11, 2007, at 11:00 AM, Stark, Barbara wrote:

> Endpoint device
>  1. If the device has a DHCP client, the client MUST support RFC  
> 3825 and RFC 4676. [There is an expectation that the responding  
> DHCP server has the intelligence to respond to only one or the other.]

But the host is in a better position to be able to resolve any  
conflict than the DHCP server.
>    a. If the device is configured to use DHCP for bootstrapping, it  
> MUST include both options in its DHCP REQUEST.
This conflicts with the intent of DHCP to enable clients to specify  
which parameters are of most use to it.
>    b. When this device initiates an emergency call (see section on  
> requirements for recognizing emeregency calls), it MUST send a DHCP  
> INFORM message to refresh the location information. [Should it only  
> use the option that was previously successful?]
For stationary hosts, this proposal would simply impose a gratuitous  
load on the DHCP server.
>  2. If the device supports LLDP-MED, it MUST support the “Location  
> Identification TLV” as defined in <LLDP-MED reference>.
The possibility that a host gets location from both the local switch  
port through LLDP-MED and DHCP highlights the fact that the host -  
not the DHCP server - is in the better position to resolve (if only  
because it can detect) conflicts.
>  3. The device MUST support whatever L7 mechanism we come up with.
A "MUST" requirement for an unspecified future potential mechanism  
(excluding the fact that the nature of any requirement for a layer-7  
mechanism is unclear) is Bad Practice.
>  5. If the device allows for bootstrapping methods other than DHCP,  
> it SHOULD support being configured to request location through a  
> DHCP INFORM message with options as described in RFC 3825 and RFC  
> 4676, when it is configured to use one of these alternate bootstrap  
> methods (e.g., PPPoE, PPPoA, static IP address).
I do not understand the presumption that if host configuration is  
done through some protocol other than the Dynamic Host Configuration  
Protocol (DHCP), DHCP must nevertheless be used to configure location.
>    a. If the device is configured to request location through  
> DHCPINFORM, then it MUST include both options in a DHCP INFORM  
> message sent shortly after bootstrap, and before any VPN sessions  
> are initiated.
>
>    b. When this device initiates an emergency call (see section on  
> requirements for recognizing emeregency calls), it MUST send a DHCP  
> INFORM message to refresh the location information. [Should it only  
> use the option that was previously successful?]
Gratuitous load on the DHCP server is not "Best ... Practice".
>  ...
>  1. The DHCP server MUST support RFC 3825 and RFC 4676. The device  
> MUST be configurable to respond to either 0 (zero) or 1 of these  
> options. The device MUST NOT allow both options to be enabled  
> simultaneously.
The DHCP server has no way to know if the geographic (latitude &  
longitude) or civic (street) address is more useful to the host.  The  
general principle of DHCP servers is to provide the configuration  
parameters that the client requests.

John

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 12 Jan 2007 11:39:24 -0500

Marc,
My primary concern is to ensure that the device can properly select a
location to use in an emergency call. I don't know what these other
applications are that need a special location format, and have seen no
use cases describing them. I do understand the emergency use case, and I
have no clue as to how a device would "know" what the correct location
is for emergency services, if it is given several. If you can provide
precise logic as to how a device would go about selecting among multiple
locations, then I'd be fine with supporting the providing of multiple
locations.
 
However, I can't think of any such logic. Since I can't think of such
logic, and since no one else has provided any, I believe the proper
strategy is to minimize the possibility of a device receiving multiple
locations.
 
As for the possibility of receiving multiple locations via DHCP, L7, and
LLDP-MED, I believe this should be avoided by doing these protocols
sequencially, and stopping after one succeeds.
 
In general, I do not believe the device is in the best position to
figure out how to select among multiple locations. The end user may be,
but end users frequently demonstrate low reliability, when they are
required to make decisions. It can also be difficult to get an end user
to make a decision when the device is "headless" (has no user interface
display). The device may also be unaware of the sort of network it is
behind, and whether or not it may be mobile.
Barbara

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]]
Sent: Thursday, January 11, 2007 2:46 PM
To: Stark, Barbara; 'GEOPRIV WG'
Subject: RE: [Geopriv] Comments on [draft-ietf-ecrit-phonebcp-00.txt]

Barbara,

Devices with DHCP servers 
 1. The DHCP server MUST support RFC 3825 and RFC 4676. The device MUST
be configurable to respond to either 0 (zero) or 1 of these options. The
device MUST NOT allow both options to be enabled simultaneously. 

I don't agree with this.  Assuming you are worried about the 2 locations
conflicting with one another (one in NY and the other in CA), the same
problem *could* exist if location was discovered via dhcp, then
lldp-med, then L7.  It's not the dhcp admin's job to determine whether
the host wants/needs civil or geo.  The host *could* need both assuming
eventual use by multiple applications.  The 'smarts' to figure out which
one to use needs to be at the host.

-Marc-

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 12 Jan 2007 13:26:29 -0500

Comments in line, below.
Barbara

> From: John Schnizlein [mailto:[email-masked]]
> Sent: Thursday, January 11, 2007 3:03 PM
> To: Stark, Barbara
> Cc: GEOPRIV WG
> Subject: Re: [Geopriv] Comments on [draft-ietf-ecrit-phonebcp-00.txt]
> 
> 

I see no suggestion that the design of DHCP be reversed or changed in anyway. The proposed requirements merely suggest how the protocol should be used. But thank you for mentioning the example of multiple DHCP servers. I believe that this example strengthens my argument that intelligence in selecting among multiple locations needs to be in the device providing location, and not in the device receiving location.

It is well known that today's consumer products do not work well in the presence of multiple DHCP offers. I have yet to see a consumer device that can intelligently select the "correct" offer. This is because consumer-grade devices don't provide users with a mechanism for "configuration parameters" to be specified for allowing a decision to be made. And if they did, most people would be clueless as to what to do with these "configuration parameters". Generally, the device is assisted in its decision by an end user, who realizes the error of having multiple DHCP servers, and turns the "wrong" one off, or repositions it in the network so that it doesn't provide offers where it shouldn't. Access networks are also designed so that consumer devices get one and only one offer. Multiple DHCP offers to consumer-grade devices is a Bad Thing, and should be avoided. I've yet to meet someone who did this on purpose, and was happy with the end result.

But just because multiple offers is undesirable when dealing with consumer-grade devices, doesn't mean we need to "reverse the design of DHCP". It just means we need to design our networks so that these devices don't get multiple offers. Similarly, we need to make sure that consumer-grade devices are not confused by multiple locations. This does not mean that devices "that operate on a network where the network operator controls the specification of every device connected to it" need to abide by this restriction. I do not believe that these requirements should apply to such devices. The requirements I propose are purely intended for consumer-grade devices, that are intended to operate anywhere.

> conflict than the DHCP server.

I disagree. The host knows much less about its position in the world, than the DHCP server does. The one exception to this is if it has a GPS. If it has a GPS, then it shouldn't be doing DHCP to get location. The end user may be in a better position. See my response to Marc on end user reliability.

> mechanism is unclear) is Bad Practice.

Attempting to finalize phonebcp before we have the L7 mechanism in motion is Bad Practice. I cannot support finalization of phonebcp until the L7 mechanism is known. Therefore, I consider this reference to the L7 mechanism to be an appropriate placeholder in this document at this time.

> Protocol (DHCP), DHCP must nevertheless be used to configure location.

I have talked to several service providers who are using (or considering using) DHCP INFORM to provide additional configuration information (beyond IP layer configuration), even though they use PPPoE or static IP addresses for IP layer configuration. In some of these conversations, they were specifically wanting to consider DHCP INFORM for providing location information.

> parameters that the client requests.

Please provide precise logic as to how the client is supposed to determine the correct location to use, when it is sent multiple locations via DHCP. By "precise logic", I do not mean a phrase such as "based on configuration parameters". I mean what are the parameters, what are their default settings, and how are they parsed in a decision-making process. In the absence of such logic, consumer-grade DHCP servers must somehow be restricted to sending just one. This does present the question of how a DHCP server makes a decision. I would expect that if it, too, is requesting location from an upstream network, then the upstream network should only send one. If the DHCP server is set to be manually configured, then it must only allow for one manual entry to be active at any given time, and must not try to use DHCP, L7, LLDP-MED. If it has GPS, and successfully gets coordinates via GPS, then it must use those coordinates. If it derives location from data sent to it by downstream network elements, then that location needs to be unique. I think it would probably be good to get rid of the "MUST NOT allow both options" statement, and replace it with a decision tree for how a server decides what to send.

Again, let me say that these requirements are intended for consumer-grade equipment, and not for enterprise equipment. 

*****

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Jan 2007 18:11:27 -0500

On Jan 12, 2007, at 11:39 AM, Stark, Barbara wrote:

> Marc,
> My primary concern is to ensure that the device can properly select  
> a location to use in an emergency call. I don't know what these  
> other applications are that need a special location format, and  
> have seen no use cases describing them. I do understand the  
> emergency use case, and I have no clue as to how a device would  
> "know" what the correct location is for emergency services, if it  
> is given several. If you can provide precise logic as to how a  
> device would go about selecting among multiple locations, then I'd  
> be fine with supporting the providing of multiple locations.

I think the primary difficulty is that the current description  
doesn't quite distinguish between three actors:

- the DHCP stack and the OS
- the VoIP application
- the emergency part of that application

In an embedded device, these are clearly closely related and not  
distinguishable from a user perspective, but we presumably want the  
BCP to apply to softphones as well. (Plus, non-emergency-VoIP  
applications may need location information, e.g., for presence and  
ordering pizza.)

It would be better to say that, say, the 'emergency services part of  
the VoIP application needs to pick one location format', making it  
clear that this could simply involve asking the OS for that data  
element. You may want to pick a shorter phrase than 'emergency  
services part of the VoIP application', but it needs to be clear that  
this is not the whole PC or even phone.

This also plays into a second issue, namely that not all applications  
will have direct DHCP access, so mandating, for example, that the  
application does an INFORM query at call time may mean that no  
Windows application or non-root Linux application, say, can be  
compliant. (I don't know whether these restrictions actually exist,  
but somebody better ask some real DHCP experts...)

>
> However, I can't think of any such logic. Since I can't think of  
> such logic, and since no one else has provided any, I believe the  
> proper strategy is to minimize the possibility of a device  
> receiving multiple locations.
>
> As for the possibility of receiving multiple locations via DHCP,  
> L7, and LLDP-MED, I believe this should be avoided by doing these  
> protocols sequencially, and stopping after one succeeds.

I agree that predictability is a good thing. You don't want two  
phones in the same organization to return different values, or,  
worse, do some randomization where it returns L7 geo on Tuesdays and  
DHCP civic on Thursdays.

I don't think the order much matters, so picking by cost seems  
easiest: DHCP is generally done already, for example. (There may be  
other criteria, but I don't think it's worth a whole lot of arguing.)

The only problem is that you may indeed get different locations from  
different sources. To pick a pseudo-realistic example that might  
represent a mid-sized company:

- DHCP is configured to give you the campus address;

- LLDP-MED gives you the port address (room)

- L7 gives you the official billing address as known to the provider

Clearly, in this case it sure would be nice if the SIP request  
contained the LLDP-MED-derived address, even if that wasn't the first  
choice in your ordering.

Indeed, here it is relatively easy to come up with a set of rules  
that eliminate many undesirable low-precision outcomes:

(1) If civic, pick the one with the lowest-level element (room,  
cubicle, etc.)

(2) If geo, pick the one with the highest resolution/lowest uncertainty.

The details are obviously a bit messier.

> figure out how to select among multiple locations. The end user may  
> be, but end users frequently demonstrate low reliability, when they  
> are required to make decisions. It can also be difficult to get an  
> end user to make a decision when the device is "headless" (has no  
> user interface display). The device may also be unaware of the sort  
> of network it is behind, and whether or not it may be mobile.

While I don't disagree, I think there is value in warning users that  
different methods are returning contradictory results. If you get  
diverging results, there is a good chance that they are all wrong or  
at least that one of them is wrong. I'd rather be warned of that than  
being unlucky enough to be forced into picking the wrong one.  
Obviously, this has to happen on boot, not at emergency call time.

Another, slippery slope is if the user recognizes that the location  
information is wrong, but it happens to be the preferred location  
method. Ideally, the user would immediately contact the sys admin,  
who promptly fixes the problem. In reality, you are in a hotel where  
the technical staff thinks that wireless is the old-fashioned name  
for an AM radio.

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 16 Jan 2007 15:09:26 -0500

Barbara,
 
The 'precise logic' as to which location type to use is the responsibility
of the host application.  I may be running a mapping program that prefers
geo-location and at the same time I may call for pizza delivery that prefers
a civil location.  How is the DHCP admin to know which one a host may need
at network initialization time?  I believe the same logic you are wanting in
the DHCP server could be done in the phone.
 
I do think it's OK for phonebcp to state that when making an emergency call,
civil or geo (pick one) location types are preferred.
 
-Marc-

  _____  

From: Stark, Barbara [mailto:[email-masked]] 
Sent: Friday, January 12, 2007 11:39 AM
To: Marc Linsner; GEOPRIV WG
Subject: RE: [Geopriv] Comments on [draft-ietf-ecrit-phonebcp-00.txt]

Marc,
My primary concern is to ensure that the device can properly select a
location to use in an emergency call. I don't know what these other
applications are that need a special location format, and have seen no use
cases describing them. I do understand the emergency use case, and I have no
clue as to how a device would "know" what the correct location is for
emergency services, if it is given several. If you can provide precise logic
as to how a device would go about selecting among multiple locations, then
I'd be fine with supporting the providing of multiple locations.
 
However, I can't think of any such logic. Since I can't think of such logic,
and since no one else has provided any, I believe the proper strategy is to
minimize the possibility of a device receiving multiple locations.

In general, I do not believe the device is in the best position to figure
out how to select among multiple locations. The end user may be, but end
users frequently demonstrate low reliability, when they are required to make
decisions. It can also be difficult to get an end user to make a decision
when the device is "headless" (has no user interface display). The device
may also be unaware of the sort of network it is behind, and whether or not
it may be mobile.
Barbara

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]]
Sent: Thursday, January 11, 2007 2:46 PM
To: Stark, Barbara; 'GEOPRIV WG'
Subject: RE: [Geopriv] Comments on [draft-ietf-ecrit-phonebcp-00.txt]

Barbara,

-Marc-

*****

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from all
computers. GA622