ACC Group Definitions - replacment

So I am still waiting for paid support to get back to me on a status update.  I have not seen anyone logging into my boxes since I opened the ticket up 5/24/2011 and after they acknowledged receipt of all login information.
RLeibl are you still available to help resolve this issue?  It is causing me no end of problems because I have to update my groups for PCI compliance firewall rule-sets and this is preventing me from moving forward without having to manually go through and update 9 firewalls x 5 different sections in the firewall setup.

Hi

Some notes that may be interesting for all of you:

•  When replacing objects (originally this was 'claiming a previously deployed
  object), the ASG is _very_ strict. If the object doesn't match _exactly_ the
  object is not replaced.  This may yield some unexpected results.
  
  
  
  •  Some objects contain lists which contain other objects (roughly speaking). A
    network group contains a list of, well, the network objects.
    When claiming (replacing) such an object, it is critical that the list is in
    the exact same order in the object that is sent from the ACC and the object
    that should be replaced on the ASG.
    
  •  This is on purpose. Treating arrays as ordered is safer than treating them
    as unordered (think: packetfilter rules), and, the object claiming is supposed
    to re-claim objects that have previously been deployed, not objects that just
    happen to 'be there' and should now be controlled via ACC.
    
  
  
•  We found that this behaviour may be too strict in several cases.
  
  
  
•  There are objects that are changed on the ASG, e.g. DNS groups.
  
•  The ASG seems to disregard ordering in cases where ordering is not
  relevant. So when an object is undeployed and made into a local object, it
  seems as if it would be possible that the order of the members changes.
  

•  We changed the behaviour of the ASG (with ASG Beta V8.165) such that the
  order of lists is only relevant in some cases (in fact, we mark, for each
  list, if the list is supposed to be ordered, or not).
  

btw. sorry for being so late. It's crazy busy right now ...

Hi

Some notes that may be interesting for all of you:

•  When replacing objects (originally this was 'claiming a previously deployed
  object), the ASG is _very_ strict. If the object doesn't match _exactly_ the
  object is not replaced.  This may yield some unexpected results.
  
  
  
  •  Some objects contain lists which contain other objects (roughly speaking). A
    network group contains a list of, well, the network objects.
    When claiming (replacing) such an object, it is critical that the list is in
    the exact same order in the object that is sent from the ACC and the object
    that should be replaced on the ASG.
    
  •  This is on purpose. Treating arrays as ordered is safer than treating them
    as unordered (think: packetfilter rules), and, the object claiming is supposed
    to re-claim objects that have previously been deployed, not objects that just
    happen to 'be there' and should now be controlled via ACC.
    
  
  
•  We found that this behaviour may be too strict in several cases.
  
  
  
•  There are objects that are changed on the ASG, e.g. DNS groups.
  
•  The ASG seems to disregard ordering in cases where ordering is not
  relevant. So when an object is undeployed and made into a local object, it
  seems as if it would be possible that the order of the members changes.
  

•  We changed the behaviour of the ASG (with ASG Beta V8.165) such that the
  order of lists is only relevant in some cases (in fact, we mark, for each
  list, if the list is supposed to be ordered, or not).
  

btw. sorry for being so late. It's crazy busy right now ...