Ken, Te problem I see with separating out the sticky combination into its own BIRD is that the other BIRD that deals with the rest of the combinations will have to make provisions for avoiding or forbidding that sticky combination. I is usually hard to remove something that was put into the spec, and I am afraid that this division of BIRD-s would just further complicate matters. Do you really think that addressing the sticky combination would take that much discussion time after we have gone this far in our understanding of it? Thanks, Arpad ================================================================== ________________________________ From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Willis Sent: Wednesday, July 14, 2010 9:00 AM To: 'IBIS-ATM' Subject: [ibis-macro] yesterday's IBIS-ATM presentation Hello IBIS-ATM members, Todd gave a good presentation yesterday, and things have simplified considerably. For the 9 flows that were presented yesterday, 8 of them are well-defined and agreed upon. I propose that we: - immediately push forward with a BIRD that covers those 8 flows, and get that in place - move the "sticky" 9th combination (tx_GetWave > rx_modified_ImpulseResponse) to its own separate BIRD Sigrity is ready to vote along these lines at our next meeting. This let's us take advantage of the good work that has been done and quickly get this "clarification BIRD" in place for the majority of AMI combinations. For the remaining "sticky" combination, there are 3 different potential solutions that have been identified so far. It will take some more discussion to finalize, and I don't see value in delaying the other 8 any longer. Focusing on that one in its own BIRD should expedite its resolution as well. Thanks, Ken Willis Sigrity, Inc. 860-871-7070 kwillis@xxxxxxxxxxx