Issue 3363: Use of PolicyType id (firewall-rtf) Source: Micro Focus (Dr. Jishnu Mukerji, jishnu(at)microfocus.com) Nature: Uncategorized Issue Severity: Summary: While editing the changes from the Firewall RTF into Core Chapter 15 I noticed a curious thing in the Firewall RTF report. It seems that the RTF chose to re-use a PolicyType id for a new and different policy while obsoleting a published one. The PolicyType Id in question is 37, which used to be BIDIRECTIONAL_POLICY_TYPE associated with the structure BiDirPolicy::BidirectionalPolicy and is now proposed to be BIDIRECTIONAL_INVOKE_POLICY associated with structure BiDirPolicy::InvokeMode. This appears to me to be a dangerous practice, since the fact that the published standard may have been implemented by someone using the obsolete definition. I would like to suggest that the recommendation of the Firewall RTF be modified leaving the published policy type and policy as is with a note stating that it is obsolete, and a new policy type id be allocated for BIDIRECTIONAL_INVOKE_POLICY. Resolution: Revised Text: Actions taken: February 25, 2000: received issue March 22, 2000: closed issue; Closed; No Change Discussion: End of Annotations:===== Date: Fri, 25 Feb 2000 13:04:48 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: firewall-rtf@omg.org, ab@omg.org, Andrew Watson , tag_request@omg.org Subject: Firewall RTF Report issue Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: "g/!!kWE!!QmZd96*[!! While editing the changes from the Firewall RTF into Core Chapter 15 I noticed a curious thing in the Firewall RTF report. It seems that the RTF chose to re-use a PolicyType id for a new and different policy while obsoleting a published one. The PolicyType Id in question is 37, which used to be BIDIRECTIONAL_POLICY_TYPE associated with the structure BiDirPolicy::BidirectionalPolicy and is now proposed to be BIDIRECTIONAL_INVOKE_POLICY associated with structure BiDirPolicy::InvokeMode. This appears to me to be a dangerous practice, since the fact that the published standard may have been implemented by someone using the obsolete definition. I would like to suggest that the recommendation of the Firewall RTF be modified leaving the published policy type and policy as is with a note stating that it is obsolete, and a new policy type id be allocated for BIDIRECTIONAL_INVOKE_POLICY. BTW, Andrew, I need PolicyType IDs for: BIDIRECTIONAL_INVOKE_POLICY BIDIRECTIONAL_MODE_POLICY Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: Peter.Walker@eng.sun.com Message-ID: <38B6D189.756D9F05@eng.Sun.COM> Date: Fri, 25 Feb 2000 11:01:29 -0800 From: Peter Walker Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: firewall-rtf@omg.org, ab@omg.org, Andrew Watson Subject: Re: Firewall RTF Report issue References: <38B6C43F.23BC71FD@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 9~Vd9iLjd9C$"!!Ro`!! Jishnu Mukerji wrote: > > While editing the changes from the Firewall RTF into Core Chapter 15 > I noticed a > curious thing in the Firewall RTF report. It seems that the RTF > chose to re-use > a PolicyType id for a new and different policy while obsoleting a > published one. > The PolicyType Id in question is 37, which used to be > BIDIRECTIONAL_POLICY_TYPE > associated with the structure BiDirPolicy::BidirectionalPolicy > > and is now proposed to be BIDIRECTIONAL_INVOKE_POLICY associated > with structure > BiDirPolicy::InvokeMode. > > This appears to me to be a dangerous practice, since the fact that > the published > standard may have been implemented by someone using the obsolete > definition. > > I would like to suggest that the recommendation of the Firewall RTF > be modified > leaving the published policy type and policy as is with a note > stating that it > is obsolete, and a new policy type id be allocated for > BIDIRECTIONAL_INVOKE_POLICY. > Procedurally how would that happen as I assume that the Firewall RTF no longer exists (having produced the report and passed it's dates). Is it a task for a new RTF or can it be an AB instruction to the "old" RTF to fix something before completely evaporating. Peter. -- ================================================================== Peter J. Walker Senior Staff Engineer, Enterprise Java Java Software, Platform Products 20525 Mariani, Cupertino, CA pwalker@eng.Sun.com http://java.sun.com/j2ee Phone (408)517-5679 FAX (408)863-3195 ================================================================== Date: Fri, 25 Feb 2000 14:14:35 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Peter Walker Cc: firewall-rtf@omg.org, ab@omg.org, Andrew Watson Subject: Re: Firewall RTF Report issue References: <38B6C43F.23BC71FD@fpk.hp.com> <38B6D189.756D9F05@eng.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: E?B!!ogf!!$ojd9pjQd9 Peter Walker wrote: > Jishnu Mukerji wrote: > > > > While editing the changes from the Firewall RTF into Core Chapter > 15 I noticed a > > curious thing in the Firewall RTF report. It seems that the RTF > chose to re-use > > a PolicyType id for a new and different policy while obsoleting a > published one. > > The PolicyType Id in question is 37, which used to be > BIDIRECTIONAL_POLICY_TYPE > > associated with the structure BiDirPolicy::BidirectionalPolicy > > > > and is now proposed to be BIDIRECTIONAL_INVOKE_POLICY associated > with structure > > BiDirPolicy::InvokeMode. > > > > This appears to me to be a dangerous practice, since the fact that > the published > > standard may have been implemented by someone using the obsolete > definition. > > > > I would like to suggest that the recommendation of the Firewall > RTF be modified > > leaving the published policy type and policy as is with a note > stating that it > > is obsolete, and a new policy type id be allocated for > > BIDIRECTIONAL_INVOKE_POLICY. > > > > Procedurally how would that happen as I assume that the Firewall RTF > no > longer exists (having produced the report and passed it's dates). Is > it > a task for a new RTF or can it be an AB instruction to the "old" RTF > to > fix something before completely evaporating. I guess we will depend on Andrew to advise the best path through the P&P labrynth. One could take the position that this is exactly what the RTF meant, but they erroneously proposed to reuse the already assigned PolicyType tag for something else. Such things have been fixed in the past through editorials in other adopted standards, before publication. It seems to me that the only thing that changes is the value associated with a PolicyType Tag, which is something that the RTF is not supposed to assign anyway. It is something that the editorial staff is supposed to take care of. So it might just be doable without running majorly afoul of the RTF or the P&P. What I think the AB needs to discuss is to figure out a way to provide guidelines to RTFs on matters such as these. I think it is prudent to have a policy that a published thing should not be reused for something else. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. From: Jeffrey Mischkinsky Message-Id: <200002252151.NAA14854@wheel.dcn.davis.ca.us> Subject: Re: Firewall RTF Report issue To: Peter.Walker@Eng.Sun.Com (Peter Walker) Date: Fri, 25 Feb 2000 13:51:09 -0800 (PST) Cc: jis@fpk.hp.com, firewall-rtf@omg.org, ab@omg.org, andrew@omg.org (Andrew Watson) In-Reply-To: <38B6D189.756D9F05@eng.Sun.COM> from "Peter Walker" at Feb 25, 2000 11:01:29 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &-#e9E"[d9JmIe9W%U!! 'Peter Walker' writes: > > Jishnu Mukerji wrote: > > > > While editing the changes from the Firewall RTF into Core Chapter > 15 I noticed a > > curious thing in the Firewall RTF report. It seems that the RTF > chose to re-use > > a PolicyType id for a new and different policy while obsoleting a > published one. > > The PolicyType Id in question is 37, which used to be > BIDIRECTIONAL_POLICY_TYPE > > associated with the structure BiDirPolicy::BidirectionalPolicy > > > > and is now proposed to be BIDIRECTIONAL_INVOKE_POLICY associated > with structure > > BiDirPolicy::InvokeMode. > > > > This appears to me to be a dangerous practice, since the fact that > the published > > standard may have been implemented by someone using the obsolete > definition. > > > > I would like to suggest that the recommendation of the Firewall > RTF be modified > > leaving the published policy type and policy as is with a note > stating that it > > is obsolete, and a new policy type id be allocated for > > BIDIRECTIONAL_INVOKE_POLICY. > > > > Procedurally how would that happen as I assume that the Firewall RTF > no > longer exists (having produced the report and passed it's dates). Is > it > a task for a new RTF or can it be an AB instruction to the "old" RTF > to > fix something before completely evaporating. > > Peter. In addition to Jishnu's sage words, i should note that the actual vote of the PTC has not yet happenned so someone could make a motion to adopt the RTF recommendations with the following change ..... The AB > would also have to endorse the same motion, but that could probably be > arranged. BTW, one of the reasons we decided to take the "standing" RTF for the whole year approach at the last PTC meeting was to have a way to fix these glitches which seem to inevitably arise. If worse comes to worse, the core RTF could also issue a recommenation to fix this problem whenever it feels so moved. (The official vote would have to wait a few weeks, but this won't be published for a few weeks anyway.) jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: Paul Kyzivat To: "'jis@fpk.hp.com'" , firewall-rtf@omg.org, ab@omg.org, Andrew Watson , tag_request@omg.org Subject: RE: Firewall RTF Report issue Date: Fri, 25 Feb 2000 18:53:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ppY!!,c~e9Haad9!&id9 Jishnu, I guess I should have paid more attention to that report. In my recollection, that change was never approved by the RTF. It was one that was supposed to remain open and be dealt with subsequent to the RTF, because we could not reach agreement on the semantics of the policies, or even on how many are required. That particular change proposal was my Martin. Maybe he was just trying to slip it in. (Somebody please correct me if my memory is wrong on this.) Regarding reusing the PolicyType id, I think the general opinion was that the prior specification was unimplemented and unimplementable, so that reusing the id was safe. But not unless we have agreement on what is to replace it. Paul > -----Original Message----- > From: Jishnu Mukerji [mailto:jis@fpk.hp.com] > Sent: Friday, February 25, 2000 1:05 PM > To: firewall-rtf@omg.org; ab@omg.org; Andrew Watson; > tag_request@omg.org > Subject: Firewall RTF Report issue > > > While editing the changes from the Firewall RTF into Core > Chapter 15 I noticed a > curious thing in the Firewall RTF report. It seems that the > RTF chose to re-use > a PolicyType id for a new and different policy while > obsoleting a published one. > The PolicyType Id in question is 37, which used to be > BIDIRECTIONAL_POLICY_TYPE > associated with the structure BiDirPolicy::BidirectionalPolicy > > and is now proposed to be BIDIRECTIONAL_INVOKE_POLICY > associated with structure > BiDirPolicy::InvokeMode. > > This appears to me to be a dangerous practice, since the fact > that the published > standard may have been implemented by someone using the > obsolete definition. > > I would like to suggest that the recommendation of the > Firewall RTF be modified > leaving the published policy type and policy as is with a > note stating that it > is obsolete, and a new policy type id be allocated for > BIDIRECTIONAL_INVOKE_POLICY. > > BTW, Andrew, I need PolicyType IDs for: > > BIDIRECTIONAL_INVOKE_POLICY > BIDIRECTIONAL_MODE_POLICY > > Thanks, > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > > Date: Mon, 28 Feb 2000 10:57:35 +0000 From: Owen Rees To: firewall-rtf@omg.org, ab@omg.org, Andrew Watson , tag_request@omg.org Subject: RE: Firewall RTF Report issue Message-ID: <2547683482.951735455@rees-o-3.hpl.hp.com> In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BC92@bos1.noblenet.com> X-Mailer: Mulberry/2.0.0b11 (Win32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii; format=flowed X-UIDL: h`hd9!dIe9N&*!!MDIe9 --On 25 February 2000 18:53 -0500 Paul Kyzivat wrote: > Jishnu, > > I guess I should have paid more attention to that report. > In my recollection, that change was never approved by the RTF. > It was one that was supposed to remain open and be dealt with subsequent > to the RTF, because we could not reach agreement on the semantics of the > policies, or even on how many are required. I believe that the text under discussion is the proposed replacement text under "Issue 2461: question re BiDir IIOP". This issue was deferred since the vote did not reach quorum. I was under the impression that the effect of this in terms of updates to other documents should be the same as if the proposed change had been voted down - i.e. no change to existing text. It was not entirely clear at the time whether or not a vote had been called on this issue, but of the messages I saw from people acting as if it had, there was one explicit NO (me) and one explicit ABSTAIN (Gregg Tally, Network Associates). In addition, Paul Kyzivat, Roguewave, strongly suggested that the proposed resolution be voted down; given the lack of clarity in the call, I would count that as a NO vote. > > That particular change proposal was my Martin. Maybe he was just > trying to > slip it in. (Somebody please correct me if my memory is wrong on > this.) > The style of the report does not clearly separate resolutions accepted from resolutions rejected. For example, the resolution of issue 2261 was rejected, but the rejected replacement text appears in the body of the report with no obvious indication that it should be ignored. The (lack of) resolution of issue 2461 may be less obvious since it is not listed as rejected. This raises a more serious question. Has rejected text from other issues that was included in the report been edited into the core documents? Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Sender: Peter.Walker@eng.sun.com Message-ID: <38BA9173.CD59C2E@eng.Sun.COM> Date: Mon, 28 Feb 2000 07:17:07 -0800 From: Peter Walker Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "'jis@fpk.hp.com'" , firewall-rtf@omg.org, ab@omg.org, Andrew Watson , tag_request@omg.org Subject: Re: Firewall RTF Report issue References: <9B164B713EE9D211B6DC0090273CEEA926BC92@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Ho2!!FdCe9Z)"!!'bR!! Paul Kyzivat wrote: > > Jishnu, > > I guess I should have paid more attention to that report. > In my recollection, that change was never approved by the RTF. > It was one that was supposed to remain open and be dealt with > subsequent to > the RTF, because we could not reach agreement on the semantics of > the > policies, or even on how many are required. > > That particular change proposal was my Martin. Maybe he was just > trying to > slip it in. (Somebody please correct me if my memory is wrong on > this.) > If that resulotion was part of the last vote - then Paul is right. I'm pretty sure that that particular vote remained inquorate. Pj. > Regarding reusing the PolicyType id, I think the general opinion was that > the prior specification was unimplemented and unimplementable, so that > reusing the id was safe. But not unless we have agreement on what is to > replace it. > > Paul > > > -----Original Message----- > > From: Jishnu Mukerji [mailto:jis@fpk.hp.com] > > Sent: Friday, February 25, 2000 1:05 PM > > To: firewall-rtf@omg.org; ab@omg.org; Andrew Watson; > > tag_request@omg.org > > Subject: Firewall RTF Report issue > > > > > > While editing the changes from the Firewall RTF into Core > > Chapter 15 I noticed a > > curious thing in the Firewall RTF report. It seems that the > > RTF chose to re-use > > a PolicyType id for a new and different policy while > > obsoleting a published one. > > The PolicyType Id in question is 37, which used to be > > BIDIRECTIONAL_POLICY_TYPE > > associated with the structure BiDirPolicy::BidirectionalPolicy > > > > and is now proposed to be BIDIRECTIONAL_INVOKE_POLICY > > associated with structure > > BiDirPolicy::InvokeMode. > > > > This appears to me to be a dangerous practice, since the fact > > that the published > > standard may have been implemented by someone using the > > obsolete definition. > > > > I would like to suggest that the recommendation of the > > Firewall RTF be modified > > leaving the published policy type and policy as is with a > > note stating that it > > is obsolete, and a new policy type id be allocated for > > BIDIRECTIONAL_INVOKE_POLICY. > > > > BTW, Andrew, I need PolicyType IDs for: > > > > BIDIRECTIONAL_INVOKE_POLICY > > BIDIRECTIONAL_MODE_POLICY > > > > Thanks, > > > > Jishnu. > > -- > > Jishnu Mukerji > > Systems Architect > > > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > > > > -- ================================================================== Peter J. Walker Senior Staff Engineer, Enterprise Java Java Software, Platform Products 20525 Mariani, Cupertino, CA pwalker@eng.Sun.com http://java.sun.com/j2ee Phone (408)517-5679 FAX (408)863-3195 ================================================================== Date: Mon, 28 Feb 2000 11:06:39 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Owen Rees Cc: firewall-rtf@omg.org, ab@omg.org Subject: Re: Firewall RTF Report issue References: <2547683482.951735455@rees-o-3.hpl.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: o1Z!!o1Ae9Cc*!!NH:e9 Owen Rees wrote: > --On 25 February 2000 18:53 -0500 Paul Kyzivat wrote: > > > That particular change proposal was my Martin. Maybe he was just trying to > > slip it in. (Somebody please correct me if my memory is wrong on this.) > > > > The style of the report does not clearly separate resolutions accepted from > resolutions rejected. For example, the resolution of issue 2261 was > rejected, but the rejected replacement text appears in the body of the > report with no obvious indication that it should be ignored. The (lack of) > resolution of issue 2461 may be less obvious since it is not listed as > rejected. > > This raises a more serious question. Has rejected text from other issues > that was included in the report been edited into the core documents? Oh, nothing has been edited anywhere yet. Actually, as it turns out one needs to look at the "Actions taken" field to figure out what to do with it, and I am hoping those are consistent with what transpired in votes. But will check mroe carefully before doing any edits. I wish people would not include resolution text that has not been agreed to, in an RTF report. It is just a pointless source of confusion. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Mon, 28 Feb 2000 11:26:33 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Peter Walker Cc: Paul Kyzivat , firewall-rtf@omg.org, ab@omg.org, Andrew Watson , tag_request@omg.org Subject: Re: Firewall RTF Report issue References: <9B164B713EE9D211B6DC0090273CEEA926BC92@bos1.noblenet.com> <38BA9173.CD59C2E@eng.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: o(l!!D>Oe9T\Q!!-$c!! Peter Walker wrote: > Paul Kyzivat wrote: > > > > Jishnu, > > > > I guess I should have paid more attention to that report. > > In my recollection, that change was never approved by the RTF. > > It was one that was supposed to remain open and be dealt with > subsequent to > > the RTF, because we could not reach agreement on the semantics of > the > > policies, or even on how many are required. > > > > That particular change proposal was my Martin. Maybe he was just > trying to > > slip it in. (Somebody please correct me if my memory is wrong on > this.) > > > > If that resulotion was part of the last vote - then Paul is > right. I'm > pretty sure that that particular vote remained inquorate. > > Pj. Right. Here is the deal. Only the following issues were actually resolved by the RTF: 1996, 2240, 2304, 2455, 2633, 2634, 2638, 2639, 2864, 2865, 2866. The following issues were deferred, some becuse the proposed resolutions failed a vote, and others because they were not considered at all: 2261, 2461, 2641, 2648, 2651, 2867, 2868, 2869. 2461 is the issue in question. I really wish people would not included unadopted text changes in RTF reports. So Andrew, scratch the request for those two PolicyType Ids. Sorry for raising a false alarm. Thanks for all your indulgenece and help in clarifying this matter. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Wed, 22 Mar 2000 15:30:13 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Boldt Cc: issues@emerald.omg.org, firewall-rtf@emerald.omg.org Subject: Re: issue 3363 -- Firewall RTF issue References: <4.1.20000322151916.00b35d80@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: l-Yd9'p9e9IP6e9P-6!! Juergen, You can close this issue since it is a non-issue that came out of confused reading of the Furewall RTF report by yours truly. Thanks, Jishnu. Juergen Boldt wrote: > This is issue # 3363 > > Use of PolicyType id > > While editing the changes from the Firewall RTF into Core Chapter 15 I > noticed a > curious thing in the Firewall RTF report. It seems that the RTF chose to re-use > a PolicyType id for a new and different policy while obsoleting a published > one. > The PolicyType Id in question is 37, which used to be BIDIRECTIONAL_POLICY_TYPE > associated with the structure BiDirPolicy::BidirectionalPolicy > > and is now proposed to be BIDIRECTIONAL_INVOKE_POLICY associated with structure > BiDirPolicy::InvokeMode. > > This appears to me to be a dangerous practice, since the fact that the > published > standard may have been implemented by someone using the obsolete definition. > > I would like to suggest that the recommendation of the Firewall RTF be modified > leaving the published policy type and policy as is with a note stating that it > is obsolete, and a new policy type id be allocated for > BIDIRECTIONAL_INVOKE_POLICY. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Sender: andrew@emerald.omg.org (Unverified) Message-Id: In-Reply-To: <38B6C43F.23BC71FD@fpk.hp.com> Mime-Version: 1.0 Date: Mon, 28 Feb 2000 16:19:58 -0500 To: jis@fpk.hp.com From: Andrew Watson Subject: Re: Firewall RTF Report issue Cc: firewall-rtf@omg.org, ab@omg.org Content-Type: text/plain; charset="us-ascii" X-UIDL: `_cd9iO)!!U$a!!DKOd9 Jishnu, You wrote: > While editing the changes from the Firewall RTF into Core Chapter 15 I > noticed a curious thing in the Firewall RTF report. It seems that the RTF > chose to re-use a PolicyType id for a new and different policy while > obsoleting a published one. The PolicyType Id in question is 37, which used > to be BIDIRECTIONAL_POLICY_TYPE associated with the structure > BiDirPolicy::BidirectionalPolicy and is now proposed to be > BIDIRECTIONAL_INVOKE_POLICY associated with structure > BiDirPolicy::InvokeMode. Naughty. > This appears to me to be a dangerous practice, since the fact that the > published standard may have been implemented by someone using the obsolete > definition. Absolutely. > I would like to suggest that the recommendation of the Firewall RTF be > modified leaving the published policy type and policy as is with a note > stating that it is obsolete, and a new policy type id be allocated for > BIDIRECTIONAL_INVOKE_POLICY. I concur. > BTW, Andrew, I need PolicyType IDs for: > > BIDIRECTIONAL_INVOKE_POLICY > BIDIRECTIONAL_MODE_POLICY Voila. These will be in the next OMG tags file, which will have an omg/00-03-xx number. // New Policy types for security, assigned by AJW to Jishnu, 28 Feb 2000 BIDIRECTIONAL_INVOKE_POLICY = 47 BIDIRECTIONAL_MODE_POLICY = 48 Later, you wrote: > I guess we will depend on Andrew to advise the best path through the P&P > labrynth. One could take the position that this is exactly what the RTF > meant, but they erroneously proposed to reuse the already assigned > PolicyType tag for something else. Such things have been fixed in the past > through editorials in other adopted standards, before publication. > > It seems to me that the only thing that changes is the value associated with > a PolicyType Tag, which is something that the RTF is not supposed to assign > anyway. It is something that the editorial staff is supposed to take care > of. So it might just be doable without running majorly afoul of the RTF or > the P&P. I don't see any problem with declaring this one as an editorial change, and fixing it as the RTF report is edited into the chapter (assuming the RTF report gets adopted, of course). Thanks, Andrew