Issue 7314: Processing of NegotiateSession messages at various stages of connection set (firewall-traversal-ftf) Source: (Ms. Rebecca Bergersen, becky(at)bergersen.org) Nature: Uncategorized Issue Severity: Summary: PROBLEM: The BiDir GIOP Document discusses three stages of connection setup, but it is unclear when each stage begins and when it ends. It is also unclear what NegotiateSession or Firewall activity can take place in each stage and what the order of processing may be. RECOMMENDATION: Rewrite the relevant portions of the document to specify the following (excerpted without edit from Brian Niebuhr's discussion of NegotiateSession contexts and the stages of setup): "...during connection setup, only firewall contexts can be in the negotiate session message, NOTHING ELSE. After the connection is setup, there is a period before the first request or locate request where we can do session setup items. I think that in that period, only Bidir contexts can be sent, NOTHING ELSE. The first request or locate request indicates the connection_established period. Again, during that period I think only the Bidir contexts should be legal. This makes things very simple. There are no conflicts between firewall and bidir, and nothing else can go in a negotiate session message." Resolution: Revised Text: Actions taken: May 6, 2004: received issue Discussion: End of Annotations:===== ubject: Firewall Issue: Processing of NegotiateSession messages at various stages of connection setup is ill-defined Date: Thu, 6 May 2004 17:17:01 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: Processing of NegotiateSession messages at various stages of connection setup is ill-defined Thread-Index: AcQzr4/xDGsFg85FS3+tiQjpN1nh5w== From: "Bergersen, Rebecca" To: , Cc: "Bergersen, Rebecca" PROBLEM: The BiDir GIOP Document discusses three stages of connection setup, but it is unclear when each stage begins and when it ends. It is also unclear what NegotiateSession or Firewall activity can take place in each stage and what the order of processing may be. RECOMMENDATION: Rewrite the relevant portions of the document to specify the following (excerpted without edit from Brian Niebuhr's discussion of NegotiateSession contexts and the stages of setup): "...during connection setup, only firewall contexts can be in the negotiate session message, NOTHING ELSE. After the connection is setup, there is a period before the first request or locate request where we can do session setup items. I think that in that period, only Bidir contexts can be sent, NOTHING ELSE. The first request or locate request indicates the connection_established period. Again, during that period I think only the Bidir contexts should be legal. This makes things very simple. There are no conflicts between firewall and bidir, and nothing else can go in a negotiate session message." Respectfully, Rebecca Bergersen PRINCIPAL ARCHITECT, MIDDLEWARE STANDARDS rebecca.bergersen@iona.com ------------------------------------------------------- IONA Technologies 200 West Street Waltham, MA 02451 USA Tel: (781) 902-8265 Fax: (781) 902-8001 ------------------------------------------------------- Making Software Work Together TM Date: Thu, 06 May 2004 19:34:37 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: issues@omg.org, firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: Processing of NegotiateSession messages at various stages of connection setup is ill-defined X-Virus-Scanned: Symantec AntiVirus Scan Engine Bergersen, Rebecca wrote: ... RECOMMENDATION: Rewrite the relevant portions of the document to specify the following (excerpted without edit from Brian Niebuhr's discussion of NegotiateSession contexts and the stages of setup): "...during connection setup, only firewall contexts can be in the negotiate session message, NOTHING ELSE. After the connection is setup, there is a period before the first request or locate request where we can do session setup items. I think that in that period, only Bidir contexts can be sent, NOTHING ELSE. The first request or locate request indicates the connection_established period. Again, during that period I think only the Bidir contexts should be legal. This makes things very simple. There are no conflicts between firewall and bidir, and nothing else can go in a negotiate session message." The truth is that you can always send the first and subsequent bi-directional offers after the first GIOP request. Thus, there is really no difference between the session setup stage and the session established stage. Joncheng Respectfully, Rebecca Bergersen PRINCIPAL ARCHITECT, MIDDLEWARE STANDARDS rebecca.bergersen@iona.com ------------------------------------------------------- IONA Technologies 200 West Street Waltham, MA 02451 USA Tel: (781) 902-8265 Fax: (781) 902-8001 ------------------------------------------------------- Making Software Work Together TM Subject: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Date: Thu, 3 Jun 2004 16:39:20 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Thread-Index: AcRJqtZbsXtCUOt1Sv2Yqvfj5tZJOQ== From: "Bergersen, Rebecca" To: , Hi! Tom and I had an email exchange discussing the interpretation of the use of Offer, Export and Allow Policies I put forward in resolutions on Ballot 4. After a couple of interchanges, I sent him a diagram and explanations. This seemed to clear up the misunderstanding and as you have seen, he modified his vote. So, I have attached most of our email exchange to this email. As Tom explained in his change of vote, as you have seen, he now agrees with my point of view but thinks the text is still confusing and should include the diagram and explanations that were part of that exchange. Please take a look at the email thread, particularly the diagram and accompanying explanation. Since Tom and I are the only ones who have voted so far, it might be possible to revise the text on the ballot and still complete the vote by EOB Tuesday. I will work with Tom in coming up with revisions. --Rebecca X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C44996.4F7EEABA" Subject: RE: Tom Rutt Vote on Firewall FTF Vote 4 Date: Thu, 3 Jun 2004 14:12:20 -0400 Message-ID: <7ED3E4E1953E8C43BE701691ABB717DA072649@amereast-ems2.boston.amer.iona.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tom Rutt Vote on Firewall FTF Vote 4 Thread-Index: AcRJj1tR7gAIjQ1iQk+aaf1N43qfZgAALnuQ From: "Bergersen, Rebecca" To: "Tom Rutt" Cc: "Bergersen, Rebecca" Comments inline. In particular, look at the bottom of my comments for a diagram that might help. --Becky > -----Original Message----- > From: Tom Rutt [mailto:tom@coastin.com] > Sent: Thursday, June 03, 2004 1:22 PM > To: Bergersen, Rebecca > Subject: Re: Tom Rutt Vote on Firewall FTF Vote 4 > > > I do not mind discussing the vote. > > Bergersen, Rebecca wrote: > > >Hi, Tom! > > > >I don't know if I should be discussing your vote with you, > but I think you are factually wrong on issue 7315 and this > has affected your perception and vote on this and other > issues (you mention 7351 specifically). > > > >You said the proposal, "assumes that > bidirectionalOfferPolicy is a client-side policy for the > connection initiator, when in fact it is a server-side policy for > >the conection initiator." The draft adopted spec says, in > section 15.9 "A BidirectionalOfferPolicy can be applied to a > client ORB, > > > This is the problem, the draft adopted spec uses client orb to mean > connection initiator. And the resolution changes the language to say connection initiator. > > > and it can be overridden for specific object references > received by the client ORB." This is definitely client-side > policy management. > > > This is an error, cited by Syracuse in another issue. The > fact that the > initiator has the POA for this object > instance makes it the server-side as far as policy is > concerned. But the initiator does not have the POA. The acceptor has the POA; the initiator invokes on a reference to that object on the acceptor side. The Offer service context is included in that invocation. Item 3 explicitly states that the OfferPolicy is associated with "specific object references received by the connection initiator ORB". Those object references are to objects on the other side of the connection - the connection acceptor - that's where the POA is. I did > not raise a new issue, but I now > do not understand the difference between export and offer > policy. They > seem to be the same the way > I have characterized it. > The export policy is put on POAs on the connection initiator side. They indicate what servants may used as callback object (i.e. the servants of those POAs having the export policy set to ALLOW. When the POA is created, the ones that have an Export policy of ALLOW have a BiDirId generated for its servants. The offer policy is put (by an override) on object references received from outside the connection initiator. Those references are to POAs (their servants) on the connection acceptor side. If the offer policy is set to ALLOW, an invocation on the object reference that has that effective policy carries an offer service context. The offer service context contains the BiDirIds of the POAs that had an export policy of ALLOW. Since the export policy is set only on POAs, it is a server-side policy. Since the offer policy is set on object references to a POA (its servants) on the other side of the connection, it is a client-side policy. It may also be set on the connection initiator ORB or on a thread in the connection initiator. > >In the resolution the terms "client" and "server" were used > in reference to the text in sections 4.9.1 and 4.9.2, where > those terms are the ones that are used. > > > >You also said, for number two, "It needs to be clarified > that 2. pertains to a server-side policy at the initiator." > The second sentence in #2 of the resolution says, "To > identify such objects, a server-side > BidirectionalExportPolicy is applied to a POA on the > connection initiator side using the > PortableServer::POA::create_POA operation." It *is* directly > stated that a server-side policy on the connection initiator > side is used, Tom. > > > > > I have no major concern about 2, it was just to have clarity and > consistency. the confustion behind 3. was > my main concern, along with the confustion in 1. > > >Finally, for number three, you said, "the offer policy is a > server-side policy > >at the connection initiator orb." As I've pointed out > above, this is absolutely not the intent of the spec. > > > > > Well this means the spec is very confused. I would ask you are the > bidirIDs that the connection initiator > puts in the offer policy pertaining to POAs and object instances that > reside on the connection initiatory orb > or on the connection acceptor orb? I say the orb that has the poa is > the server. As I've said above, the BiDirIds are for POAs sitting in the connection initiator side. These are the objects that are going to be called back from the connection acceptor side. Here's the picture I've been using, where CB is the callback object and OBJ is the object used by the initiator to contact the acceptor. Invocations on OBJ carry Offer service contexts containing BiDirIds of objects that the acceptor can call back. Connection Initiator Connection Acceptor (offer policy) (allow policy) +---------------+ +---------------+ | | | | | CB POA | | CB reference | |(export policy)| Bidir | (allow policy)| |( BiDirId) | connection | | | |<----\ | | | OBJ reference | \----->| OBJ POA | | (offer policy)| | | | | | | +---------------+ +---------------+ > > Please explain your interpretation to me of what the offer policy is > intended to do. The offer policy allows or disallows invocations on the object to which the policy has been applied to carry offer service contexts. If OBJ has had an offer policy override applied to it with a value of ALLOW, the effective policy set when an invocation is made on that object contains an Offer policy of ALLOW. If the value was DENY, then the effective policy set contains an Offer policy of DENY. The policy could be placed on the initiator ORB and the thread as well. However the effective policy overrides resolve themselves, that is the policy applied when an invocation is made on the object. If the effective policy set contains an Offer policy of ALLOW, the invocation will carry an Offer service context that contains the BiDirIds of the CB POAs that haven't already been sent to the Acceptor in previous Offers. If the effective policy set contains an Offer policy of DENY or does not contain an Offer policy, then no Offer service context will be included when the object is invoked. Thus, no BiDirIds will be transmitted in the invocation and there is no implication of bi-directionality involved in the invocation - it's just a standard GIOP Request (or whatever). > > > --Becky > > > > > > > >>-----Original Message----- > >>From: Tom Rutt [mailto:tom@coastin.com] > >>Sent: Wednesday, June 02, 2004 8:35 PM > >>To: firewall-traversal-ftf@omg.org; Bergersen, Rebecca; > >>firewall-ftf@omg.org > >>Subject: Tom Rutt Vote on Firewall FTF Vote 4 > >> > >> > >> > >>Tom Rutt vote on proposals for Firewall FTF Vote 4. > >> > >>I spent several hours going thru these proposed resolutions, and I > >>realized that there are still many problems > >>in the draft adopted specs which will require major work and > >>agreement > >>to resolve. Quite frankly, I do not > >>wish to continue at this level of effort for an activity > which is not > >>that important to my company, and for > >>which I see almost no way to reach fruition in the limited > >>time this FTF > >>has before it runs out. > >> > >>I am concerned with the number of oprn technical issues (most > >>of the 33) > >>which do not yet have proposed resolutions, even when we are within > >>three weeks of the next OMG meeting. > >> > >>Since I spent the effort to work on this vote: I am > >>submitting my vote > >>as follows for Vote 4. > >> > >>I have severe concerns about many of the proposals in vote > 4. I have > >>voted No on many of them, and have given detailed reasons for > >>my NO votes. > >> > >>Issue 6311: Negotiation Session message is unwieldy > >>(firewall-traversal-ftf) > >>YES . no change required > >> > >>Issue 7307: Firewall issue - Number of BiDirIds in a > BiDirOffer Issue > >>NO . The statement is overly constraining on implementations. If a > >>connection initiator knows what > >>Object references it has passed to a given connection > >>respondor, it only > >>is required to send the > >>BIDIR IDs pertaining to that subset of objects it can act as > >>server for. > >> > >>7308: Firewall Issue: Response to failed BiDir challenge is unclear > >>NO: - The current placement of the proposed sentence makes it > >>apply to > >>the entire paragraph above. The discussion > >>seems to indicate the connection termination only applies to the > >>Strong-failed case. Also, it is not clear why the > >>connection responsor must kill the transport connection in > >>all cases (it > >>may want to continue to receive invocations from that > >>connection initiator as client. > >> > >>Issue 7309: Firewall Issue: Connection over which BiDir > >>offers are sent > >>is unspecified > >>NO: This introduces the concept of the bidirectional state > of a given > >>transport connection. This > >>classification is troublesome, as indicated by Issue 7356. > Also, the > >>connection initiator may, in many cases, > >>not need to send all bidir offers to all connection > responders it is > >>currently connected to. > >> > >>Issue 7310: Firewall Issue: Random BiDirIds can't be used for > >>persistent > >>POAs > >>YES > >> > >>Issue 7311: Interplay of Contexts allowed in NegotiateSession > >>messages > >>too ill-defined > >>YES . duplicate of 7314 > >> > >>Issue 7312: What BiDirIds shall be sent over what bidirectional > >>connections? > >>NO: This extra complexity, to an already overwhelming set of three > >>policy constructs (export, offer, accept) is > >>not warranted, if the resolutions for 7307 and 7309 are not > accepted. > >>Also, the proposal seems do define two > >>different values for ALLOW and ALLOW_ALL with no > explanation for the > >>difference between them or the reason > >>to need both values. > >> > >>Issue 7313: Firewall FTF Issue: No end-to-end security for firewall > >>traversal > >>YES > >> > >>Issue 7314: Processing of NegotiateSession messages at > >>various stages of > >>connection set > >>YES: - notice this text never introduces the state > .connection is now > >>bidirectional., because it does not have to. > >> > >> > >>Issue 7315: Targets of Export and Offer Policies incompletely > >>specified > >>NO: While I agree that connection initiator and connection > >>acceptor need > >>to be used in several places where > >>the text .client orb. or .server orb. is used (including in section > >>5.8), this proposal is flawed. It assumes that > >>bidirectionalOfferPolicy > >>is a client-side policy for the connection initiator, when in > >>fact it is > >>a server-side policy for > >>the conection initiator. Also in 1. the words .client (i.e. > >>connection > >>initiator) for some connections and a server (i.e. connection > >>acceptor) > >>for others:. is wrong. The words client and server should not > >>be used in > >>this sentence. It needs to be clarified that 2. > >>pertains to a server-side policy at the initiator. Proposal 3. is > >>incorrect, in that the offer policy is a server-side policy > >>at the connection initiator orb. The existing text in the > >>draft adopted > >>spec is already to be confused, in that it states > >>object references received by the client, but this > >>.clarification. in 3. > >>makes things worse, since it the offer policy is a > server-side policy > >>at the connection initiator orb.is severely flawed. > >>This is related to issue 7351 > >> > >>Issue 7316: Expected behavior of a non-conformant implementation > >>YES > >> > >>Issue 7317: connection_complete field of the > >>FirewallPathRespContext is > >>under specified > >>YES : no change required > >> > >>Issue 7318: How many BI_DIR_GIOP_OFFER service contexts are allowed > >>NO: If the proposal is agreed, then we need to add a > >>clarification that > >>two contexts in a message can be answered by a single > >>Return service context pertaining to both of them. > >> > >>Issue 7332: GIOP and IIOP versioning must be clearly and > consistently > >>specified > >>NO: While I agree with the sentiment, the proposal has only > >>just begun > >>to fix the problem. The procedures for > >>Giop 1.2 bidir have been erroneously removed in the draft > >>adopted GIOP > >>spec. > >>The GIOP spec must continue to retain its existing bidir Section, > >>clarifying that it pertains to versions 1.2 thru 1.4, > >>while the new stuff needs its own section, clarifying that > it is for > >>GIOP 1.5 and beyond. > >> > >>Issue 7351: Limitation and ambiguity in the use of > >>BidirectionalOfferPolicy of DENY > >>NO: This issue has identified a problem with the offer policy text > >>(since it applies to a server-side policy > >>In the connection initiator. So .references received by > >>Client ORB. is > >>an incorrect statement which needs to > >>Be fixed. It was not fixed in the proposed resolution 3 to > issue 7315. > >> > >>Issue 7352: Bi-directional connections considered volatile at > >>connection > >>acceptor side > >>NO: While I agree that the clarification needs to ber made, > >>the current > >>text uses the word .register. > >>an object reference, which is not a defined term in this > >>spec. This will > >>only add confusion, for it is unclear > >>whether an invocation on a persistent connection initiator > >>served object > >>reference which was , say, > >>obtained from a name service by the connection acceptor, acting as > >>client, is really a callback. > >> > >>Issue 7356: when is a connection a "bi-directional connection"? > >>NO . with giop 1.2 bidir the first message on the transport > >>connection > >>contained the service context for bidir, > >>thus each transport connection could be considered either > >>bidir or not > >>bidir. With the new bidir from this spec, > >>this determination can happen at any time over the life of > >>the transport > >>connection. I suggest resolving this by not > >>using the term bidirection connection (as if it were a state) > >>throughout > >>the document. Given policy settings, many > >>connection can become bidirectional capable, and is bidir > >>after a bidir > >>offer is accepted. Can a bidir offer be > >>retracted? Needs further discussion. > >> > >> > >> > >>-- > >>---------------------------------------------------- > >>Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > >>Tel: +1 732 801 5744 Fax: +1 732 774 5133 > >> > >> > >> > >> > >> > >> > > > > > > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Received: from amereast-smg1.iona.com ([10.70.2.37]) by amereast-ems2.IONAGLOBAL.COM with Microsoft SMTPSVC(5.0.2195.6713); Thu, 3 Jun 2004 15:23:48 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_004_01C449A0.4B4ABA00" Received: from panda.host4u.net (panda.host4u.net [216.71.64.116]) by amereast-smg1.iona.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id i53JNlQ12171 for ; Thu, 3 Jun 2004 15:23:47 -0400 (EDT) Received: from coastin.com (pool-141-153-146-77.mad.east.verizon.net [141.153.146.77]) by panda.host4u.net (8.11.6/8.11.6) with ESMTP id i53JNdD29914 for ; Thu, 3 Jun 2004 14:23:40 -0500 content-class: urn:content-classes:message Subject: Re: Tom Rutt Vote on Firewall FTF Vote 4 Date: Thu, 3 Jun 2004 15:23:21 -0400 Message-ID: <40BF7AA9.3050603@coastin.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tom Rutt Vote on Firewall FTF Vote 4 Thread-Index: AcRJoEuO4xDkSHcjR5Knn8dsio2H6g== From: "Tom Rutt" To: "Bergersen, Rebecca" Becky: Please lets take this discussion to the list soon. Well I never got your interpretation (which makes sense to me given the diagram and explanation) from evaluating and reading the spec over the years. If this is the intent of the spec, the diagram you show and the paragraphs below needs to go into the spec to make this clear. I never dreamt in my foggiest dreams that a policy would have to explicitly be put on every object reference in the connection initiator to every object on the connection acceptor . I actually read the text (given the confusion of "client orb" being used) as being an overide per initiator's object servants to the POA level policy on that initator. This seemed confusing to me, but a viable thing to do. Is it your understanding that in most cases the offer policy will be placed on the initiator orb as allow, and not be overridden for any specific object reference. Other cases might be to disallow for orb level, with allow for a few specific instances. Would it be valid to have an offer policy on the initiator orb as disallow, while having POA policys with export =allow? Bergersen, Rebecca wrote: >Comments inline. In particular, look at the bottom of my comments for a diagram that might help. > --Becky > > > >The export policy is put on POAs on the connection initiator side. They indicate what servants may used as callback object (i.e. the servants of those POAs having the export policy set to ALLOW. When the POA is created, the ones that have an Export policy of ALLOW have a BiDirId generated for its servants. > >The offer policy is put (by an override) on object references received from outside the connection initiator. Those references are to POAs (their servants) on the connection acceptor side. If the offer policy is set to ALLOW, an invocation on the object reference that has that effective policy carries an offer service context. The offer service context contains the BiDirIds of the POAs that had an export policy of ALLOW. > >Since the export policy is set only on POAs, it is a server-side policy. Since the offer policy is set on object references to a POA (its servants) on the other side of the connection, it is a client-side policy. It may also be set on the connection initiator ORB or on a thread in the connection initiator. > > > >As I've said above, the BiDirIds are for POAs sitting in the connection initiator side. These are the objects that are going to be called back from the connection acceptor side. > >Here's the picture I've been using, where CB is the callback object and OBJ is the object used by the initiator to contact the acceptor. Invocations on OBJ carry Offer service contexts containing BiDirIds of objects that the acceptor can call back. > > Connection Initiator Connection Acceptor > (offer policy) (allow policy) > +---------------+ +---------------+ > | | | | > | CB POA | | CB reference | > |(export policy)| Bidir | (allow policy)| > |( BiDirId) | connection | | > | |<----\ | | > | OBJ reference | \----->| OBJ POA | > | (offer policy)| | | > | | | | > +---------------+ +---------------+ > > > > >>Please explain your interpretation to me of what the offer policy is >>intended to do. >> >> > >The offer policy allows or disallows invocations on the object to which the policy has been applied to carry offer service contexts. If OBJ has had an offer policy override applied to it with a value of ALLOW, the effective policy set when an invocation is made on that object contains an Offer policy of ALLOW. If the value was DENY, then the effective policy set contains an Offer policy of DENY. The policy could be placed on the initiator ORB and the thread as well. However the effective policy overrides resolve themselves, that is the policy applied when an invocation is made on the object. > >If the effective policy set contains an Offer policy of ALLOW, the invocation will carry an Offer service context that contains the BiDirIds of the CB POAs that haven't already been sent to the Acceptor in previous Offers. If the effective policy set contains an Offer policy of DENY or does not contain an Offer policy, then no Offer service context will be included when the object is invoked. Thus, no BiDirIds will be transmitted in the invocation and there is no implication of bi-directionality involved in the invocation - it's just a standard GIOP Request (or whatever). > > > >>>--Becky >>> >>> >>> >>>> >>>>Issue 7315: Targets of Export and Offer Policies incompletely >>>>specified >>>>NO: While I agree that connection initiator and connection >>>>acceptor need >>>>to be used in several places where >>>>the text .client orb. or .server orb. is used (including in section >>>>5.8), this proposal is flawed. It assumes that >>>>bidirectionalOfferPolicy >>>>is a client-side policy for the connection initiator, when in >>>>fact it is >>>>a server-side policy for >>>>the conection initiator. Also in 1. the words .client (i.e. >>>>connection >>>>initiator) for some connections and a server (i.e. connection >>>>acceptor) >>>>for others:. is wrong. The words client and server should not >>>>be used in >>>>this sentence. It needs to be clarified that 2. >>>>pertains to a server-side policy at the initiator. Proposal 3. is >>>>incorrect, in that the offer policy is a server-side policy >>>>at the connection initiator orb. The existing text in the >>>>draft adopted >>>>spec is already to be confused, in that it states >>>>object references received by the client, but this >>>>.clarification. in 3. >>>>makes things worse, since it the offer policy is a >>>> >>>> >>server-side policy >> >> >>>>at the connection initiator orb.is severely flawed. >>>>This is related to issue 7351 >>>> >>>> After you answer these new questions, I will reconsider my vote for this one. Tom Rutt ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_005_01C449A6.DB944986" Subject: RE: Tom Rutt Vote on Firewall FTF Vote 4 Date: Thu, 3 Jun 2004 16:10:47 -0400 Message-ID: <7ED3E4E1953E8C43BE701691ABB717DA07264A@amereast-ems2.boston.amer.iona.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tom Rutt Vote on Firewall FTF Vote 4 Thread-Index: AcRJoEuO4xDkSHcjR5Knn8dsio2H6gAAoHOQ From: "Bergersen, Rebecca" To: "Tom Rutt" Cc: "Bergersen, Rebecca" Hi, Tom! To answer a couple of you questions, I believe that there would be two common scenarios for using the Offer Policy: 1. Most of the object references in a component on the initiator could be used to initiate a bidirectional connection or be used to transmit BiDirIds. To accomplish this, an Offer policy with a value of ALLOW would be placed on the connection initiator ORB and those objects that are NOT allowed to be used for the bidirectional protocol would have an individual override placed on them with an Offer policy with a value of DENY. 2. Most, but not all, of the object references in a component on the initiator would NOT be used to initiate a bidirectional connection or be used to transmit BiDirIds. To accomplish this, either an Offer Policy with a value of DENY would be placed on the connection initiator ORB or no Offer policy would be placed on the connection initiator ORB. The effect is the same, though placing an Offer with DENY on the ORB makes the program's intentions more explicit. Those object references that ARE used to convey an Offer service context would have an Offer policy with a value of ALLOW placed on them using an override. In both cases, and I think scenario #2 is probably the most common, there are only a few placements of the Offer policy. I've also answered your other points inline. By the way, it's all right with me to put this thread on the list any time. Since the diagram seemed to clear things up for you, the email containing that should probably be the head of the thread. --Becky > -----Original Message----- > From: Tom Rutt [mailto:tom@coastin.com] > Sent: Thursday, June 03, 2004 3:23 PM > To: Bergersen, Rebecca > Subject: Re: Tom Rutt Vote on Firewall FTF Vote 4 > > > Becky: > > Please lets take this discussion to the list soon. > > Well I never got your interpretation (which makes sense to me > given the > diagram and explanation) > from evaluating and reading the spec over the years. > > If this is the intent of the spec, the diagram you show and the > paragraphs below needs to go into the spec > to make this clear. > > I never dreamt in my foggiest dreams that a policy would have to > explicitly be put on every > object reference in the connection initiator to every object on the > connection acceptor . It wouldn't. Since it's a client-side Policy, it can be placed on the connection initiator ORB and all of the objects would inherit it in their effective policy sets. There's no need to put the policy on every object reference. >I actually read the text (given the > confusion of > "client orb" being used) as being an overide per > initiator's object servants to the POA level policy on that > initator. > This seemed confusing to me, > but a viable thing to do. > > Is it your understanding that in most cases the offer policy will be > placed on the initiator orb as allow, and > not be overridden for any specific object reference. Discussed above. > > Other cases might be to disallow for orb level, with allow for a few > specific instances. Discussed above. > > Would it be valid to have an offer policy on the initiator orb as > disallow, while having POA policys with export =allow? Sure. The Offer policy governs the inclusion of an Offer Service Context on an invocation. The ORB could have a general Offer policy of DENY and a couple of object references to POAs on the the Acceptor side could have that Offer policy overriden with a value of ALLOW. The POAs could have Export policies with a value of ALLOW. Their BiDirIds would only be transmitted when one of the objects with an Offer value of ALLOW is invoked. Invocations on other object references would not carry an Offer Service Context since their effective policy set would have an Offer policy with a value of DENY inherited from the ORB. If no object references override that value, the BiDirIds that were generated for the POAs with an Export policy of ALLOW are simply never transmitted. > > > > Bergersen, Rebecca wrote: > > >Comments inline. In particular, look at the bottom of my > comments for a diagram that might help. > > --Becky > > > > > > > >The export policy is put on POAs on the connection initiator > side. They indicate what servants may used as callback > object (i.e. the servants of those POAs having the export > policy set to ALLOW. When the POA is created, the ones that > have an Export policy of ALLOW have a BiDirId generated for > its servants. > > > >The offer policy is put (by an override) on object > references received from outside the connection initiator. > Those references are to POAs (their servants) on the > connection acceptor side. If the offer policy is set to > ALLOW, an invocation on the object reference that has that > effective policy carries an offer service context. The offer > service context contains the BiDirIds of the POAs that had an > export policy of ALLOW. > > > >Since the export policy is set only on POAs, it is a > server-side policy. Since the offer policy is set on object > references to a POA (its servants) on the other side of the > connection, it is a client-side policy. It may also be set > on the connection initiator ORB or on a thread in the > connection initiator. > > > > > > > >As I've said above, the BiDirIds are for POAs sitting in the > connection initiator side. These are the objects that are > going to be called back from the connection acceptor side. > > > >Here's the picture I've been using, where CB is the callback > object and OBJ is the object used by the initiator to contact > the acceptor. Invocations on OBJ carry Offer service > contexts containing BiDirIds of objects that the acceptor can > call back. > > > > Connection Initiator Connection Acceptor > > (offer policy) (allow policy) > > +---------------+ +---------------+ > > | | | | > > | CB POA | | CB reference | > > |(export policy)| Bidir | (allow policy)| > > |( BiDirId) | connection | | > > | |<----\ | | > > | OBJ reference | \----->| OBJ POA | > > | (offer policy)| | | > > | | | | > > +---------------+ +---------------+ > > > > > > > > > >>Please explain your interpretation to me of what the offer > policy is > >>intended to do. > >> > >> > > > >The offer policy allows or disallows invocations on the > object to which the policy has been applied to carry offer > service contexts. If OBJ has had an offer policy override > applied to it with a value of ALLOW, the effective policy set > when an invocation is made on that object contains an Offer > policy of ALLOW. If the value was DENY, then the effective > policy set contains an Offer policy of DENY. The policy > could be placed on the initiator ORB and the thread as well. > However the effective policy overrides resolve themselves, > that is the policy applied when an invocation is made on the object. > > > >If the effective policy set contains an Offer policy of > ALLOW, the invocation will carry an Offer service context > that contains the BiDirIds of the CB POAs that haven't > already been sent to the Acceptor in previous Offers. If the > effective policy set contains an Offer policy of DENY or does > not contain an Offer policy, then no Offer service context > will be included when the object is invoked. Thus, no > BiDirIds will be transmitted in the invocation and there is > no implication of bi-directionality involved in the > invocation - it's just a standard GIOP Request (or whatever). > > > > > > > >>>--Becky > >>> > >>> > >>> > >>>> > >>>>Issue 7315: Targets of Export and Offer Policies incompletely > >>>>specified > >>>>NO: While I agree that connection initiator and connection > >>>>acceptor need > >>>>to be used in several places where > >>>>the text .client orb. or .server orb. is used (including > in section > >>>>5.8), this proposal is flawed. It assumes that > >>>>bidirectionalOfferPolicy > >>>>is a client-side policy for the connection initiator, when in > >>>>fact it is > >>>>a server-side policy for > >>>>the conection initiator. Also in 1. the words .client (i.e. > >>>>connection > >>>>initiator) for some connections and a server (i.e. connection > >>>>acceptor) > >>>>for others:. is wrong. The words client and server should not > >>>>be used in > >>>>this sentence. It needs to be clarified that 2. > >>>>pertains to a server-side policy at the initiator. Proposal 3. is > >>>>incorrect, in that the offer policy is a server-side policy > >>>>at the connection initiator orb. The existing text in the > >>>>draft adopted > >>>>spec is already to be confused, in that it states > >>>>object references received by the client, but this > >>>>.clarification. in 3. > >>>>makes things worse, since it the offer policy is a > >>>> > >>>> > >>server-side policy > >> > >> > >>>>at the connection initiator orb.is severely flawed. > >>>>This is related to issue 7351 > >>>> > >>>> > After you answer these new questions, I will reconsider my > vote for this one. > > Tom Rutt > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_006_01C449A7.CDF25696" Subject: RE: Tom Rutt Vote on Firewall FTF Vote 4 Date: Thu, 3 Jun 2004 16:17:33 -0400 Message-ID: <7ED3E4E1953E8C43BE701691ABB717DA0728AC@amereast-ems2.boston.amer.iona.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tom Rutt Vote on Firewall FTF Vote 4 Thread-Index: AcRJoEuO4xDkSHcjR5Knn8dsio2H6gAAoHOQAAET5YA= From: "Bergersen, Rebecca" To: "Bergersen, Rebecca" , "Tom Rutt" Whoops - I noticed an ambiguity in my explanation: > > Would it be valid to have an offer policy on the initiator orb as > > disallow, while having POA policys with export =allow? > > Sure. The Offer policy governs the inclusion of an Offer > Service Context on an invocation. The ORB could have a > general Offer policy of DENY and a couple of object > references to POAs on the the Acceptor side could have that > Offer policy overriden with a value of ALLOW. The POAs could > have Export policies with a value of ALLOW. I meant "The POAs" ON THE CONNECTION INITIATOR SIDE "could have Export policies with a value of ALLOW." I wasn't referring to the POAs in the previous sentence that live on the connection acceptor side. Sorry. I'm trying to type too fast. --Becky > -----Original Message----- > From: Bergersen, Rebecca > Sent: Thursday, June 03, 2004 4:11 PM > To: 'Tom Rutt' > Cc: Bergersen, Rebecca > Subject: RE: Tom Rutt Vote on Firewall FTF Vote 4 > > > Hi, Tom! > > To answer a couple of you questions, I believe that there > would be two common scenarios for using the Offer Policy: > > 1. Most of the object references in a component on the > initiator could be used to initiate a bidirectional > connection or be used to transmit BiDirIds. To accomplish > this, an Offer policy with a value of ALLOW would be placed > on the connection initiator ORB and those objects that are > NOT allowed to be used for the bidirectional protocol would > have an individual override placed on them with an Offer > policy with a value of DENY. > > 2. Most, but not all, of the object references in a component > on the initiator would NOT be used to initiate a > bidirectional connection or be used to transmit BiDirIds. To > accomplish this, either an Offer Policy with a value of DENY > would be placed on the connection initiator ORB or no Offer > policy would be placed on the connection initiator ORB. The > effect is the same, though placing an Offer with DENY on the > ORB makes the program's intentions more explicit. Those > object references that ARE used to convey an Offer service > context would have an Offer policy with a value of ALLOW > placed on them using an override. > > In both cases, and I think scenario #2 is probably the most > common, there are only a few placements of the Offer policy. > > I've also answered your other points inline. > > By the way, it's all right with me to put this thread on the > list any time. Since the diagram seemed to clear things up > for you, the email containing that should probably be the > head of the thread. > > --Becky > > > -----Original Message----- > > From: Tom Rutt [mailto:tom@coastin.com] > > Sent: Thursday, June 03, 2004 3:23 PM > > To: Bergersen, Rebecca > > Subject: Re: Tom Rutt Vote on Firewall FTF Vote 4 > > > > > > Becky: > > > > Please lets take this discussion to the list soon. > > > > Well I never got your interpretation (which makes sense to me > > given the > > diagram and explanation) > > from evaluating and reading the spec over the years. > > > > If this is the intent of the spec, the diagram you show and the > > paragraphs below needs to go into the spec > > to make this clear. > > > > I never dreamt in my foggiest dreams that a policy would have to > > explicitly be put on every > > object reference in the connection initiator to every object on the > > connection acceptor . > > It wouldn't. Since it's a client-side Policy, it can be > placed on the connection initiator ORB and all of the objects > would inherit it in their effective policy sets. There's no > need to put the policy on every object reference. > > >I actually read the text (given the > > confusion of > > "client orb" being used) as being an overide per > > initiator's object servants to the POA level policy on that > > initator. > > This seemed confusing to me, > > but a viable thing to do. > > > > Is it your understanding that in most cases the offer > policy will be > > placed on the initiator orb as allow, and > > not be overridden for any specific object reference. > > Discussed above. > > > > > Other cases might be to disallow for orb level, with allow > for a few > > specific instances. > > Discussed above. > > > > > Would it be valid to have an offer policy on the initiator orb as > > disallow, while having POA policys with export =allow? > > Sure. The Offer policy governs the inclusion of an Offer > Service Context on an invocation. The ORB could have a > general Offer policy of DENY and a couple of object > references to POAs on the the Acceptor side could have that > Offer policy overriden with a value of ALLOW. The POAs could > have Export policies with a value of ALLOW. Their BiDirIds > would only be transmitted when one of the objects with an > Offer value of ALLOW is invoked. Invocations on other object > references would not carry an Offer Service Context since > their effective policy set would have an Offer policy with a > value of DENY inherited from the ORB. If no object > references override that value, the BiDirIds that were > generated for the POAs with an Export policy of ALLOW are > simply never transmitted. > > > > > > > > > Bergersen, Rebecca wrote: > > > > >Comments inline. In particular, look at the bottom of my > > comments for a diagram that might help. > > > --Becky > > > > > > > > > > > >The export policy is put on POAs on the connection initiator > > side. They indicate what servants may used as callback > > object (i.e. the servants of those POAs having the export > > policy set to ALLOW. When the POA is created, the ones that > > have an Export policy of ALLOW have a BiDirId generated for > > its servants. > > > > > >The offer policy is put (by an override) on object > > references received from outside the connection initiator. > > Those references are to POAs (their servants) on the > > connection acceptor side. If the offer policy is set to > > ALLOW, an invocation on the object reference that has that > > effective policy carries an offer service context. The offer > > service context contains the BiDirIds of the POAs that had an > > export policy of ALLOW. > > > > > >Since the export policy is set only on POAs, it is a > > server-side policy. Since the offer policy is set on object > > references to a POA (its servants) on the other side of the > > connection, it is a client-side policy. It may also be set > > on the connection initiator ORB or on a thread in the > > connection initiator. > > > > > > > > > > > >As I've said above, the BiDirIds are for POAs sitting in the > > connection initiator side. These are the objects that are > > going to be called back from the connection acceptor side. > > > > > >Here's the picture I've been using, where CB is the callback > > object and OBJ is the object used by the initiator to contact > > the acceptor. Invocations on OBJ carry Offer service > > contexts containing BiDirIds of objects that the acceptor can > > call back. > > > > > > Connection Initiator Connection Acceptor > > > (offer policy) (allow policy) > > > +---------------+ +---------------+ > > > | | | | > > > | CB POA | | CB reference | > > > |(export policy)| Bidir | (allow policy)| > > > |( BiDirId) | connection | | > > > | |<----\ | | > > > | OBJ reference | \----->| OBJ POA | > > > | (offer policy)| | | > > > | | | | > > > +---------------+ +---------------+ > > > > > > > > > > > > > > >>Please explain your interpretation to me of what the offer > > policy is > > >>intended to do. > > >> > > >> > > > > > >The offer policy allows or disallows invocations on the > > object to which the policy has been applied to carry offer > > service contexts. If OBJ has had an offer policy override > > applied to it with a value of ALLOW, the effective policy set > > when an invocation is made on that object contains an Offer > > policy of ALLOW. If the value was DENY, then the effective > > policy set contains an Offer policy of DENY. The policy > > could be placed on the initiator ORB and the thread as well. > > However the effective policy overrides resolve themselves, > > that is the policy applied when an invocation is made on > the object. > > > > > >If the effective policy set contains an Offer policy of > > ALLOW, the invocation will carry an Offer service context > > that contains the BiDirIds of the CB POAs that haven't > > already been sent to the Acceptor in previous Offers. If the > > effective policy set contains an Offer policy of DENY or does > > not contain an Offer policy, then no Offer service context > > will be included when the object is invoked. Thus, no > > BiDirIds will be transmitted in the invocation and there is > > no implication of bi-directionality involved in the > > invocation - it's just a standard GIOP Request (or whatever). > > > > > > > > > > > >>>--Becky > > >>> > > >>> > > >>> > > >>>> > > >>>>Issue 7315: Targets of Export and Offer Policies incompletely > > >>>>specified > > >>>>NO: While I agree that connection initiator and connection > > >>>>acceptor need > > >>>>to be used in several places where > > >>>>the text .client orb. or .server orb. is used (including > > in section > > >>>>5.8), this proposal is flawed. It assumes that > > >>>>bidirectionalOfferPolicy > > >>>>is a client-side policy for the connection initiator, when in > > >>>>fact it is > > >>>>a server-side policy for > > >>>>the conection initiator. Also in 1. the words .client (i.e. > > >>>>connection > > >>>>initiator) for some connections and a server (i.e. connection > > >>>>acceptor) > > >>>>for others:. is wrong. The words client and server should not > > >>>>be used in > > >>>>this sentence. It needs to be clarified that 2. > > >>>>pertains to a server-side policy at the initiator. > Proposal 3. is > > >>>>incorrect, in that the offer policy is a server-side policy > > >>>>at the connection initiator orb. The existing text in the > > >>>>draft adopted > > >>>>spec is already to be confused, in that it states > > >>>>object references received by the client, but this > > >>>>.clarification. in 3. > > >>>>makes things worse, since it the offer policy is a > > >>>> > > >>>> > > >>server-side policy > > >> > > >> > > >>>>at the connection initiator orb.is severely flawed. > > >>>>This is related to issue 7351 > > >>>> > > >>>> > > After you answer these new questions, I will reconsider my > > vote for this one. > > > > Tom Rutt > > ---------------------------------------------------- > > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > > > > > >