Issue 2536:  Establish set of REBIND exceptions (messaging-rtf)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: 1) In the specification, settings of the REBIND policy of 
 NO-REBIND or NO_RECONNECT are supposed to alert clients to 
 possible changes of policy of servants established at a different 
 location than originally bound. But, since servants may be 
 established on different POAs on the same server, or even on a 
 different server that shares a connection with the original 
 server, this policy is weak protection against QoS policy change. 
 Isn"t connection orthogonal to policy: a new connection may not 
 result in a policy change, and a maintained connection may invoke 
 a servant with a new set of policies anyhow. 
 
 Either the specification should establish a set of REBIND 
 exceptions that strongly couple to policy change, or the weakness 
 of the current set should be explained in section 5.3.1. 
 
 

Resolution: Close without action.
Revised Text: 
Actions taken:
March 15, 1999: received issue
October 4, 2000: closed issue
Discussion: 

End of Annotations:=====
]X-Sender: siegel@192.67.184.65
Date: Sat, 13 Mar 1999 12:58:57 -0500
To: issues
From: Jon Siegel <siegel@omg.org>
Subject: three issues on AMI

Hi --

Here are three issues on AMI:

1) In the specification, settings of the REBIND policy of 
NO-REBIND or NO_RECONNECT are supposed to alert clients to 
possible changes of policy of servants established at a different 
location than originally bound. But, since servants may be 
established on different POAs on the same server, or even on a 
different server that shares a connection with the original 
server, this policy is weak protection against QoS policy change. 
Isn't connection orthogonal to policy: a new connection may not 
result in a policy change, and a maintained connection may invoke 
a servant with a new set of policies anyhow. 

Either the specification should establish a set of REBIND 
exceptions that strongly couple to policy change, or the weakness 
of the current set should be explained in section 5.3.1. 

Sender: Chris.Smith@uab.ericsson.se
Message-ID: <383FE0D6.3867FEF6@uab.ericsson.se>
Date: Sat, 27 Nov 1999 14:47:02 +0100
From: Chris Smith <Chris.Smith@uab.ericsson.se>
Organization: Ericsson Utvecklings AB
X-Mailer: Mozilla 4.7C-CCK-MCD  [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: sv,en-US
MIME-Version: 1.0
To: messaging-rtf@omg.org, uabcsru@uab.ericsson.se
Subject: Messaging Issue 2536 - Establish set of REbind exceptions
Content-Type: multipart/mixed;
 boundary="------------ECE34C80EECC014D5F6EAF1B"
X-UIDL: !@o!!>,k!!(WWd9L!bd9

Issue 2536: Establish set of REBIND exceptions (messaging-rtf)

Summary: 1) In the specification, settings of the REBIND policy of
NO-REBIND or NO_RECONNECT are supposed to alert clients to possible
changes of policy of servants established at a different location than
originally bound. But, since servants may be established on different
POAs on the same server, or even on a different server that shares a
connection with the original server, this policy is weak protection
against QoS policy change. Isn't connection orthogonal to policy: a
new
connection may not result in a policy change, and a maintained
connection may invoke a servant with a new set of policies anyhow.
Either the specification should establish a set of REBIND exceptions
that strongly couple to policy change, or the weakness of the current
set should be explained in section 5.3.1. 

I think the intention of the rebind policy was to alert clients to
possible changes of client effective policies - not servant policies.
The effective policies on the client side are a combination of the
"client visible" policies in the IOR of the target object, and the
overrides set by the client at ORB, object, and current level. Its
clear
that a LOCATION_FORWARD or
OBJECT_FORWARD could result in a change to the effective policies
since
a different IOR
would be used with potentially different client visible policies.
However, even without
a LOCATION_FORWARD or OBJECT_FORWARD, a new connection establishment
might use a different
profile (of the same or different type), and might therefore result in
a
different set of
client visible policies, and so the rebind policy protects against
both
these eventualities.
The NO_REBIND value allows the client to find out about
LOCATION_FORWARD/OBJECT_FORWARD
and the NO_RECONNECT value allows the client to find out about
reconnects as well.

I dont see a problem here. A new connection may not result in a policy
change - thats true, 
but a maintained connection cannot possibly result in a new set of
client visible policies.
Servant policies which are not included in the IOR are irrelevant to
this Policy....

I propose to close without change...?
[] Chris.Smith2.vcf