Issue 3253: Number of security policies supporteb by PolicyEvaluator arbitrarily large (rad-ftf) Source: 2AB (Mr. Bob Burt, bburt@2ab.com) Nature: Uncategorized Issue Severity: Summary: The number of security policies supported by a PolicyEvaluator could be arbitrarily large. Because of this the operation "list_policies" in the PolicyEvaluatorAdmin interface might be changed to: PolicyNameIter list_policies(in num_ret, in max_iter, out PolicyNameList policy_names); where max_iter is maximum number of entries held by the iterator, num_ret is the maximum number of entries returned in the "out PolicyNameList list" argument, and "policy_names" is sequence of PolicyNames having at most "num_ret" entries. If the list of policy names has less than "num_ret" entries, the iterator will be nil. The iterator interface would look like: interface PolicyNameIter { long how_many(); boolean next_n(in long val, out PolicyNameList policy_names); void destroy(); }; Note this technique could be carried to the extreme for all those operations that return a PolicyEvaluatorList. However, it seems less likely that one would has assigned large numbers of evaluator in the same way one might have large numbers of security policies. Resolution: resolved Revised Text: Add an iterator to the list_policies operation. PolicyNameList list_policies(in unsigned long seq_max, in unsigned long iter_max, out PolicyNameListIterator iter) raises (TooMany); interface PolicyNameListIterator { unsigned long how_many(); boolean next_one(out PolicyName name); boolean next_n(in unsigned long how_many, out PolicyNameList list); void destroy(); }; NOTE: The operations next_one and next_n return false if there is no PolicyName left to return, return true if a PolicyName or PolicyNameList are returned. NOTE: The TooMany exception if raised for list_policies if the number of PolicyNames found (based on the seq_max and iter_max arguments) exceeds the implementations limit. The implementation limit can be optionally configurable by the implementation. Actions taken: January 26, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== X-Sender: bburt@mindspring.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 26 Jan 2000 14:30:50 -0600 To: From: Bob Burt Subject: RAD FTF comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: N3f!!Q/;e9i6V!!BQ@e9 A couple of minor issues for the RAD FTF: ============================================================================= Issue 1: The number of security policies supported by a PolicyEvaluator could be arbitrarily large. Because of this the operation "list_policies" in the PolicyEvaluatorAdmin interface might be changed to: PolicyNameIter list_policies(in num_ret, in max_iter, out PolicyNameList policy_names); where max_iter is maximum number of entries held by the iterator, num_ret is the maximum number of entries returned in the "out PolicyNameList list" argument, and "policy_names" is sequence of PolicyNames having at most "num_ret" entries. If the list of policy names has less than "num_ret" entries, the iterator will be nil. The iterator interface would look like: interface PolicyNameIter { long how_many(); boolean next_n(in long val, out PolicyNameList policy_names); void destroy(); }; Note this technique could be carried to the extreme for all those operations that return a PolicyEvaluatorList. However, it seems less likely that one would has assigned large numbers of evaluator in the same way one might have large numbers of security policies. Date: Thu, 27 Jan 2000 16:47:23 -0500 From: Konstantin Beznosov X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 CC: rad-ftf@omg.org Subject: Re: RAD FTF comments References: <3.0.32.20000127074047.009a6c90@mindspring.com> Content-Type: multipart/mixed; boundary="------------AAF0149C42CE84154C1405C7" X-UIDL: R]@!!c1`!!gi'e9D-"e9 Comments inlined: Bob Burt wrote: > > Comments inlined: > > At 05:22 PM 1/26/00 -0500, Konstantin Beznosov wrote: > >Carol, do you think we can address the issues raised by Bob even > though > they are > >formally 1 day late? I hope we can. > > > >In any case, my comments are inlined below. I skipped those issues > and their > >proposed resolutions that I agree with. > > > >Bob Burt wrote: > >> > >> A couple of minor issues for the RAD FTF: > >> > >> > > ============================================================================= > >> Issue 1: > >> > >> The number of security policies supported by a PolicyEvaluator > could be > >> arbitrarily large. Because of this the operation "list_policies" > in the > >> PolicyEvaluatorAdmin interface might be changed to: > >> > >> PolicyNameIter list_policies(in num_ret, in max_iter, > out > >> PolicyNameList policy_names); > > > >Iterator is a good approach, I believe. I'm not sure I understand > completely the > >semantics of the operation above. What is max_iter parameter for? > Does the > >semantics imply that policy_names will contain first num_ret policy > names, > and > >the iterator will contain the rest? > > > The max_iter value is the maximum number of PolicyNames that the > iterator > may hold. Basically it allows a client to manage the amount of data > that > the server must collect for it. For example, the request might > result in a > total of 5,000,000 PolicyNames and the client knows he can deal with > at > most 10,000. He might say return me the first 100 in the out > parameter and > let the iterator hold 9,500. How does the client specify that the iterator should hold all of the names that did not fit into policy_names? > >> > >> where max_iter is maximum number of entries held by the iterator, > num_ret > >> is the maximum number of entries returned in the "out > PolicyNameList list" > >> argument, and "policy_names" is sequence of PolicyNames having at > most > >> "num_ret" entries. If the list of policy names has less than > "num_ret" > >> entries, the iterator will be nil. > > > >Also, I suggest to follow the naming convention that we used so far > in the > spec, > >i.e. spell out names of formal parameters, operations and > classes. That > is, name > >the iterator PolicyNameIterator, and operation parameters > "maximum_policy_names" > >instead of "num_ret". > > > Fine with me, names a name. > >> > >> The iterator interface would look like: > >> > >> interface PolicyNameIter { > >> long how_many(); > >> > >> boolean next_n(in long val, out PolicyNameList > policy_names); > >> > >> void destroy(); > >> }; > >> > >The semantics of next_n is not clear. What does it return via > return value? > >What if the client wants to go back and begin from the > beginning. Does it > have > >to get another iterator? Why not just have an operation, that will > re-set the > >iterator? Why "destroy"? What if the server will re-use the > iterator? > >Since indexing and the number of elements is a non negative number > it is > better > >to use "unsigned long" everywhere instead of "long". > > > The pattern for the iterator is used throughout many OMG specs > including > those in CORBAmed (e.g. PIDS). The next_n returns the next "val" > number of > PolicyNames, it returns true if there are no more PolicyNames to > return. Why not to use an exception if the client requires next elements when the iterator is already at the end of the list. Since there is how_many(), the client should be able to count how many it already obtained and how many are left. So, getting out of boundaries is an exceptional case here. If you agree, then the following could be the operation signature: PolicyNameList policy_names get_next_elements(in unsigned long how_many) raises NoMoreElements; > > The above pattern typically assumes that the transient iterator can > only be > iterated through once, when the last PolicyName is returned, it > automatically destroys itself (for clients too lazy or inattentive > to > delete it). Is it a requirement or an assumption that the client can not invoke the iterator once it got the last element? Your explanation also implies that if I'm a disciplined client and want to invoke destroy() right after I got the last element, I will have to expect that the iterator object is already gone and I will receive a system exception. Is it correct? > The destroy operation is required to allows clients tell > servers that they are through with the iterator. If not, that object > stays > around forever, not good. As far as resetting the iterator, > typically such > iterators are implemented with databases and cursors (the iterator > does not > have all of the data in memory), resetting the iterator is just as > much > overhead as reinvoking the original operation that returned it and > complicates the iterator interface. "Typically" does not mean "always." For example, listing of a directory can for sure be stored in memory :) A server, that can not "rewind" its iterators can always raise NO_IMPLEMENT exception when a method to reset the iterator is called, and be compliant with the spec. This way, those who can and can't "rewind" their iterators will be happy, won't they? > > As far a "unsigned long" vs "long", that is fine but your sematics > might > say that -1 returns all of the remining values. it can be done using "0" instead of "-1" since, to me, 0 makes as much sense as -1, when it is used to specify number of elements to be returned. X-Sender: bburt@mindspring.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 29 Jan 2000 14:20:28 -0600 To: From: Bob Burt Subject: Re: RAD FTF comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: "l$e9:eF!!:S]d9HfO!! Hi Konstanteen, Some comments on your latest comments inlined. >============================================================================= >>> >> Issue 1: >> >>How does the client specify that the iterator should hold all of the >>> names >that did not fit into policy_names? >> Most that use this pattern do not provide semantics for returning all (regardless of how many), but rather allow the client to specify max_iter = 10000000. That is a real big number, that would hopefully get them all. The client could check to see if how_many returns 10000000 thus indicating there might be more. Another technique might be to specify semantics that if max_iter == -1 then return all. I personally like the client to set the upper bound. >> >>Why not to use an exception if the client requires next elements when the >>iterator is already at the end of the list. Since there is how_many(), the >>client should be able to count how many it already obtained and how many are >>left. So, getting out of boundaries is an exceptional case here. >> >>If you agree, then the following could be the operation signature: >>PolicyNameList policy_names get_next_elements(in unsigned long how_many) >raises >>NoMoreElements; >> Actually this is different than the typical pattern I described. Remember this pattern allows the server to destroy the object (iterator) when it returns the last item. If a client called after that, it would get SystemException::INV_OBJECT. If it is done the way you described, the iterator object must remain instantiated indefinitely just in case some client wants to retrieve an item (and get an exception). Just does'nt make object lifecycle management very clean. >> >>Is it a requirement or an assumption that the client can not invoke the >iterator once it got the last element? Your explanation also implies that if I'm a disciplined client and want to invoke destroy() right after I got the last element, I will have to expect that the iterator object is already gone and I will receive a system exception. Is it correct? >> Yes that is the way this pattern works. The "destroy" operation is there for clients that don't want to iterate through all of the items. Even with this the server must implement some form of lifecycle management such as a timer (the iterator can live a certain length of time) or some evictor pattern (old interators are destroyed to make room for new ones). Bottom line is servers must be able to make arbitrary decisions to destroy such transient objects, and when they do, there is always the possiblity that some client is holding an object ref that is no longer valid. >>"Typically" does not mean "always." For example, listing of a directory >can for sure be stored in memory :) A server, that can not "rewind" its iterators can always raise NO_IMPLEMENT exception when a method to reset the iterator is called, and be compliant with the spec. This way, those who can and can't "rewind" their iterators will be happy, won't they? >> Yes it could be done that way, but remember why we are using an iterator! We are trying to flow control a large amount of data across a network. An iterator that is bi-directional means that you open yourself for lots of avoidable network traffic. My thoughts are that it would probably be better to only provide the single pass farward iterator and let the client put the items in a local collection that he can iterate bi-directionally. That way the client can go back and forth all he wants, but each item is sent across the net at most once. I personally detest NO_IMPLEMENT exceptions. Maybe my hangup. Just imagine yourself a client programmer that now must be able to deal with those that can and those that can't. If your client cannnot handle both situations, then it is now dependent on a specific implementation and the benefit of using a standard service is gone. >>> >>> As far a "unsigned long" vs "long", that is fine but your sematics >>> might >>> say that -1 returns all of the remining values. >> >>it can be done using "0" instead of "-1" since, to me, 0 makes as >>> much >sense as >>-1, when it is used to specify number of elements to be returned. >> I don't agree here. Zero is very meaningful. A value of "0" for max_iter means don't bother creating an iterator, I will get all of my items via the out sequence. A value of "0" for max_ret says don't send any in the out sequence, but return them all in the iterator. Now a value of "0" for both "max_ret" and "max_iter" does not make any sense. That would essentially be a no-op. X-Sender: carolbrt@mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Aug 2000 20:14:47 -0500 To: rad-ftf@omg.org From: Carol Burt Subject: [RAD-FTF Issue 3253] Discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: I1jd9SY!"!_nKe92"$e9 Issue 3253: Use of names in defined exceptions states: Some of the exceptions defined could use names that are less like to conflict with standard language objects and thus would not have to be fully qualified. For example, InternalError conflicts with java.lang.InternalError. Perhaps RadInternalError might be nicer. ComponentError might be another candidate for RadComponentError. Comment: The IDL looked like this at one time. This is the source of issue 3178D where the text uses these name. For some reason the "Rad" prefix was removed in the final editing. Chris suggested linking these issues. Since this is an IDL change, I'll wait a few days for opinions to be expressed before I propose the following resolution: Change the following exception names and all references to them in the text: InternalError to RadInternalError ComponentError to RadComponentError This would leave these specific names the same in Issue 3178D (other names are noted in 3178D that still need to be corrected). _________________________________________________________ Carol Burt 2AB, Inc. cburt@2ab.com www.2ab.com 205-621-7455 ext 103 Member, OMG Architecture Board OMG Domain Member _________________________________________________________ "Solutions for Distributed Business (SM)" X-Sender: carolbrt@mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Aug 2000 20:25:44 -0500 To: rad-ftf@omg.org From: Carol Burt Subject: [RAD-FTF Issue 3253] Discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: ?V_!!NE9!!nRY!!J3:e9 Issue 3253 description: Number of security policies supported by PolicyEvaluator arbitrarily large suggested resolution: to add an iterator to list_policies() Issue description that contains a proposed resolution: The number of security policies supported by a PolicyEvaluator could be arbitrarily large. Because of this the operation "list_policies" in the PolicyEvaluatorAdmin interface might be changed to: PolicyNameIter list_policies(in num_ret, in max_iter, out PolicyNameList policy_names); where max_iter is maximum number of entries held by the iterator, num_ret is the maximum number of entries returned in the "out PolicyNameList list" argument, and "policy_names" is sequence of PolicyNames having at most "num_ret" entries. If the list of policy names has less than "num_ret" entries, the iterator will be nil. The iterator interface would look like: interface PolicyNameIter { long how_many(); boolean next_n(in long val, out PolicyNameList policy_names); void destroy(); }; Note this technique could be carried to the extreme for all those operations that return a PolicyEvaluatorList. However, it seems less likely that one would has assigned large numbers of evaluator in the same way one might have large numbers of security policies. Discussion? I would propose adding only the one iterator to the list_policies in the PolicyEvaluatorAdmin interface. _________________________________________________________ Carol Burt 2AB, Inc. cburt@2ab.com www.2ab.com 205-621-7455 ext 103 Member, OMG Architecture Board OMG Domain Member _________________________________________________________ "Solutions for Distributed Business (SM)" X-Sender: bburt@mindspring.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 11 Aug 2000 07:53:53 -0500 To: Carol Burt , rad-ftf@omg.org From: Bob Burt Subject: Re: [RAD-FTF Issue 3253] Discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: 3M"e96Issue 3253 description: Number of security policies supported by >PolicyEvaluator arbitrarily large suggested resolution: to add an iterator >to list_policies() > >Issue description that contains a proposed resolution: The number of >security policies supported by a PolicyEvaluator could be arbitrarily >large. Because of this the operation "list_policies" in the >PolicyEvaluatorAdmin interface might be changed to: PolicyNameIter >list_policies(in num_ret, in max_iter, out PolicyNameList policy_names); >where max_iter is maximum number of entries held by the iterator, num_ret >is the maximum number of entries returned in the "out PolicyNameList list" >argument, and "policy_names" is sequence of PolicyNames having at most >"num_ret" entries. If the list of policy names has less than "num_ret" >entries, the iterator will be nil. The iterator interface would look like: >interface PolicyNameIter { long how_many(); boolean next_n(in long val, out >PolicyNameList policy_names); void destroy(); }; Note this technique could >be carried to the extreme for all those operations that return a >PolicyEvaluatorList. However, it seems less likely that one would has >assigned large numbers of evaluator in the same way one might have large >numbers of security policies. > >Discussion? I would propose adding only the one iterator to the >list_policies in the PolicyEvaluatorAdmin interface. >_________________________________________________________ >Carol Burt 2AB, Inc. >cburt@2ab.com www.2ab.com >205-621-7455 ext 103 >Member, OMG Architecture Board OMG Domain Member >_________________________________________________________ > "Solutions for Distributed Business (SM)" > > From: "Chris White" To: "Carol Burt" , Subject: RE: [RAD-FTF Issue 3253] Discussion Date: Fri, 11 Aug 2000 12:40:23 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.2.7.2.20000810201908.00b2fac8@mindspring.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: jDbd9-iQd9?CLe9?4)!! Ok with me to add the one iterator. -----Original Message----- From: Carol Burt [mailto:cburt@2ab.com] Sent: Thursday, August 10, 2000 9:26 PM To: rad-ftf@omg.org Subject: [RAD-FTF Issue 3253] Discussion Issue 3253 description: Number of security policies supported by PolicyEvaluator arbitrarily large suggested resolution: to add an iterator to list_policies() Issue description that contains a proposed resolution: The number of security policies supported by a PolicyEvaluator could be arbitrarily large. Because of this the operation "list_policies" in the PolicyEvaluatorAdmin interface might be changed to: PolicyNameIter list_policies(in num_ret, in max_iter, out PolicyNameList policy_names); where max_iter is maximum number of entries held by the iterator, num_ret is the maximum number of entries returned in the "out PolicyNameList list" argument, and "policy_names" is sequence of PolicyNames having at most "num_ret" entries. If the list of policy names has less than "num_ret" entries, the iterator will be nil. The iterator interface would look like: interface PolicyNameIter { long how_many(); boolean next_n(in long val, out PolicyNameList policy_names); void destroy(); }; Note this technique could be carried to the extreme for all those operations that return a PolicyEvaluatorList. However, it seems less likely that one would has assigned large numbers of evaluator in the same way one might have large numbers of security policies. Discussion? I would propose adding only the one iterator to the list_policies in the PolicyEvaluatorAdmin interface. _________________________________________________________ Carol Burt 2AB, Inc. cburt@2ab.com www.2ab.com 205-621-7455 ext 103 Member, OMG Architecture Board OMG Domain Member _________________________________________________________ "Solutions for Distributed Business (SM)" From: "Chris White" To: "Carol Burt" , Subject: RE: [RAD-FTF Issue 3253] Discussion Date: Fri, 11 Aug 2000 12:40:26 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.2.7.2.20000810195800.00b2f548@mindspring.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 3c Subject: Re: [RAD-FTF Issue 3253] Proposed Resolution In-Reply-To: <3.0.32.20000811075352.009356a0@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: GQa!!5%F!!=JW!!/f2e9 As I've heard no objections, this is the proposed resolution I am using for the poll in vote #2. At 07:53 AM 8/11/2000 -0500, you wrote: I would suggest using iterators more in line with suggestions from "Henning/Vinoski". Unfortunately the OMG has not endorsed a standard pattern for using iterators and every service has its own variant. PolicyNameList list_policies(in unsigned long seq_max, in unsigned long iter_max, out PolicyNameListIterator iter) raises (TooMany); interface PolicyNameListIterator { unsigned long how_many(); boolean next_one(out PolicyName name); boolean next_n(in unsigned long how_many, out PolicyNameList list); void destroy(); }; NOTE: The operations next_one and next_n return false if there is no PolicyName left to return, return true if a PolicyName or PolicyNameList are returned. NOTE: The TooMany exception if raised for list_policies if the number of PolicyNames found (based on the seq_max and iter_max arguments) exceeds the implementations limit. The implementation limit can be optionaly configurable by the implementation. At 08:25 PM 8/10/00 -0500, Carol Burt wrote: >Issue 3253 description: Number of security policies supported by >PolicyEvaluator arbitrarily large suggested resolution: to add an iterator >to list_policies() > >Issue description that contains a proposed resolution: The number of >security policies supported by a PolicyEvaluator could be arbitrarily >large. Because of this the operation "list_policies" in the >PolicyEvaluatorAdmin interface might be changed to: PolicyNameIter >list_policies(in num_ret, in max_iter, out PolicyNameList policy_names); >where max_iter is maximum number of entries held by the iterator, num_ret >is the maximum number of entries returned in the "out PolicyNameList list" >argument, and "policy_names" is sequence of PolicyNames having at most >"num_ret" entries. If the list of policy names has less than "num_ret" >entries, the iterator will be nil. The iterator interface would look like: >interface PolicyNameIter { long how_many(); boolean next_n(in long val, out >PolicyNameList policy_names); void destroy(); }; Note this technique could >be carried to the extreme for all those operations that return a >PolicyEvaluatorList. However, it seems less likely that one would has >assigned large numbers of evaluator in the same way one might have large >numbers of security policies. > >Discussion? I would propose adding only the one iterator to the >list_policies in the PolicyEvaluatorAdmin interface. >_________________________________________________________ >Carol Burt 2AB, Inc. >cburt@2ab.com www.2ab.com >205-621-7455 ext 103 >Member, OMG Architecture Board OMG Domain Member >_________________________________________________________ > "Solutions for Distributed Business (SM)" > > _________________________________________________________ Carol Burt 2AB, Inc. cburt@2ab.com www.2ab.com 205-621-7455 ext 103 Member, OMG Architecture Board OMG Domain Member _________________________________________________________ "Solutions for Distributed Business (SM)"