Preliminary minutes for OASIS WS- Reliable Exchange 8/25 TC
Teleconference
Date: 8/25/2005
Tom Rutt chaired meeting and took minutes for meeting.
|
First Name
|
Last Name
|
Role
|
Company
|
|
Charlton
|
Barreto
|
Voting Member
|
Adobe Systems*
|
|
Duane
|
Nickull
|
Voting Member
|
Adobe Systems*
|
|
Mark
|
Little
|
Voting Member
|
Arjuna Technologies Limited*
|
|
Lei
|
Jin
|
Voting Member
|
BEA Systems, Inc.*
|
|
Dave
|
Orchard
|
Voting Member
|
BEA Systems, Inc.*
|
|
Gilbert
|
Pilz
|
Voting Member
|
BEA Systems, Inc.*
|
|
Ian
|
Jones
|
Applicant
|
BTplc*
|
|
Andreas
|
Bjarlestam
|
Voting Member
|
Ericsson*
|
|
Jacques
|
Durand
|
Voting Member
|
Fujitsu Limited*
|
|
Tom
|
Rutt
|
TC Chair
|
Fujitsu Limited*
|
|
Robert
|
Freund
|
Voting Member
|
Hitachi, Ltd.*
|
|
Eisaku
|
Nishiyama
|
Voting Member
|
Hitachi, Ltd.*
|
|
Nobuyuki
|
Yamamoto
|
Voting Member
|
Hitachi, Ltd.*
|
|
Doug
|
Davis
|
Voting Member
|
IBM*
|
|
Christopher
|
Ferris
|
Voting Member
|
IBM*
|
|
Daniel
|
Millwood
|
Voting Member
|
IBM*
|
|
Rebecca
|
Bergersen
|
Voting Member
|
IONA Technologies*
|
|
Stefan
|
Batres
|
Voting Member
|
Microsoft Corporation*
|
|
Paul
|
Cotton
|
Voting Member
|
Microsoft Corporation*
|
|
Colleen
|
Evans
|
Voting Member
|
Microsoft Corporation*
|
|
Marc
|
Goodner
|
Voting Member
|
Microsoft Corporation*
|
|
Christopher
|
Kurt
|
Voting Member
|
Microsoft Corporation*
|
|
Jonathan
|
Marsh
|
Voting Member
|
Microsoft Corporation*
|
|
Jorgen
|
Thelin
|
Voting Member
|
Microsoft Corporation*
|
|
Asir
|
Vedamuthu
|
Voting Member
|
Microsoft Corporation*
|
|
Chouthri
|
Palanisamy
|
Voting Member
|
NEC Corporation*
|
|
Abbie
|
Barbir
|
Voting Member
|
Nortel Networks Limited*
|
|
Paul
|
Knight
|
Voting Member
|
Nortel Networks Limited*
|
|
Martin
|
Chapman
|
Voting Member
|
Oracle Corporation*
|
|
Sumit
|
Gupta
|
Voting Member
|
Oracle Corporation*
|
|
Anish
|
Karmarkar
|
Voting Member
|
Oracle Corporation*
|
|
Ashok
|
Malhotra
|
Voting Member
|
Oracle Corporation*
|
|
jeff
|
mischkinsky
|
Voting Member
|
Oracle Corporation*
|
|
Eric
|
Rajkovic
|
Voting Member
|
Oracle Corporation*
|
|
Steve
|
Winkler
|
Voting Member
|
SAP AG*
|
|
Pete
|
Wenzel
|
Voting Member
|
SeeBeyond *
|
|
Giovanni
|
Boschi
|
Voting Member
|
Sonic Software
|
|
Dave
|
Chappell
|
Voting Member
|
Sonic Software
|
|
Vikas
|
Deolaliker
|
Voting Member
|
Sonoa Systems, Inc.*
|
|
Doug
|
Bunting
|
Voting Member
|
Sun Microsystems*
|
|
Ram
|
Jeyaraman
|
Member
|
Sun Microsystems*
|
|
Dan
|
Leshchiner
|
Voting Member
|
Tibco Software Inc.*
|
|
Shivajee
|
Samdarshi
|
Voting Member
|
Tibco Software Inc.*
|
|
Vadim
|
Furman
|
Voting Member
|
webMethods, Inc.*
|
42 of 49 voting members
(>25 thus meeting is quorate)
2
Review and approval of the agenda
1)
Roll Call
2)
Review and approval of the agenda
3)
Approval of the August 18th meeting minutes
4)
AI Review
5)
Any new issues since last conf-call
6)
Discussion of Issues
8)
Any New Business
8.1)
audio recording of Teleconf for backup
3
Approval of the August 18th meeting minutes
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14148/Minutes%20Teleconf%2008-18-2005.html
Correction.
For issue 17 xml namespace uri yyymm
should be yyyymm
Becky moved
to approve minutes with correction, Charlton seconded.
NO
Objections, Minutes 8/18 with correction are approved..
4
AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
#0002: OASIS Staff should fix typographical error in charter of
missing space between “produces” and “do” the next time the charter is updated.
Owner: James Bryce Clark
Status: Open
Assigned: 2005-07-06
Due: 2005-07-08
#0012: Chair took an action item to get a ruling from Jamie on CVS
repository usage.
Owner: Paul Fremantle
Status: Open
Assigned: 2005-07-17
Due: ---
Chris Kurt: the OASIS will
have a deployment for several environments.
They are moving this forward, there will be a board meeting this Friday.
Chris K can report back next week or by
email.
#0013: Chairs will propose a mechanism to manage the Queue on the
conference calls.
Owner: Sanjay Patil
Status: Open
Assigned: 2005-07-17
Due: ---
#0016: Marc G will form a team to discuss how do deal with
conformance related issues on the specification.
Owner: Marc Goodner
Status: closed, mark sent out proposal for Subcommittee.
Assigned: 2005-07-29
Due: 2005-09-08
Marc G: has been doing research on this. Mark will present motion for subcommittee
next week.
#0018: Fix any problems with Issue URLs
Owner: Marc Goodner
Status: Close
Assigned: 2005-08-04
Due: 2005-08-18
Closed no problems noted.
#0024: Provide concrete proposal for issue "InOrder
delivery assurance spanning multiple sequences"
Owner: Andreas Bjarlestam
Status: Open
Assigned: 2005-08-12
Due: 2005-08-25
Leave open
#0025: Propose a "namespace change policy" for the schemas
produced by the TC
Owner: Christopher Ferris
Status: Open
Assigned: 2005-08-23
Due: ---
5
Potential New issues since last conf-call
· Re: [ws-rx] draft full agenda for 8/25 Teleconf
From Duane Nickull
<dnickull@adobe.com> on 25 Aug 2005 14:18:50 -0000
The issue originator, in the above email, states that, in light of
the discussion linked below,
he
would like to withdraw this new issue from consideration.
Considered withdrawn, no new issues to be added
this week.
· RE: [ws-rx] New Issue: Harmonization of Line
Numbers accross PDF, DOC versions of working draft
From "Paul Cotton" <pcotton@microsoft.com> on 18 Aug
2005 18:41:19 -0000
· Re: [ws-rx] New Issue: Harmonization of Line
Numbers accross PDF,DOC versions of working draft
From Duane Nickull
<dnickull@adobe.com> on 18 Aug 2005 16:10:07 -0000
· Re: [ws-rx] New Issue: Harmonization of Line
Numbers accross PDF,DOC versions of working draft
From Doug Bunting <Doug.Bunting@Sun.COM> on 18 Aug 2005 15:00:38
-0000
· Re: [ws-rx] New Issue: Harmonization of Line
Numbers accross PDF,DOC versions of working draft
From Doug Bunting <Doug.Bunting@Sun.COM> on 18 Aug 2005 14:50:42
-0000
· Re: [ws-rx] New Issue: Harmonization of Line
Numbers accross PDF, DOCversions of working draft
From Christopher B Ferris <chrisfer@us.ibm.com> on 18 Aug 2005
12:00:39 -0000
· Re: [ws-rx] New Issue: Harmonization of Line
Numbers accross PDF,DOC versions of working draft
From Duane Nickull
<dnickull@adobe.com> on 18 Aug 2005 02:27:43 -0000
· Re: [ws-rx] New Issue: Harmonization of Line
Numbers accross PDF,DOC versions of working draft
From Doug Bunting <Doug.Bunting@Sun.COM> on 18 Aug 2005 00:49:53
-0000
· New Issue: Harmonization of Line Numbers accross
PDF,DOC versions of working draft
From Duane Nickull
<dnickull@adobe.com> on 17 Aug 2005 22:05:47 -0000
6
Discussion of Issues
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14147/ReliableMessagingIssues.xml
6.1 i001 Bilateral sequence negotiation
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14147/ReliableMessagingIssues.xml#i001
Proposals:
· Re: [ws-rx] i001 and Proposal
From Christopher B Ferris <chrisfer@us.ibm.com> on 25 Aug 2005
17:55:25 -0000
· i001 and Proposal
From "Lei Jin" <ljin@bea.com> on 25 Aug 2005 17:30:00
-0000
· RE: [ws-rx] Proposal to close i001
From "Lei Jin" <ljin@bea.com> on 24 Aug 2005 03:38:36
-0000
· RE: [ws-rx] Proposal to close i001
From "Marc Goodner"
<mgoodner@microsoft.com> on 24 Aug 2005 01:31:57 -0000
· Re: [ws-rx] Proposal to close i001
From Doug Davis <dug@us.ibm.com> on 24 Aug 2005 01:09:36 -0000
· Proposal to close i001
From "Marc Goodner"
<mgoodner@microsoft.com> on 23 Aug 2005 23:12:16 -0000
Lei Jin: The current draft
shows offer as optional element. However
the policy declares a condition under which it must be used. The limitation in the policy document is
unnecessary.
Delete lines in reliable messaging policy document.
Proposal:
Delete lines 221-226 of WSRX-ReliableMessagingPolicy document.
Marc G: with this restatement it is not a duplicate of i021. It is a restatement, which is in line with
the.
Tom: Put this on the agenda
for next week with Lei Jin proposal.
Anish: will the proposal remove all cases
when Offer must be present.
Lei Jin : yes.
6.2 i004 wsa:messageID uniqueness requirments for retransmission
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14147/ReliableMessagingIssues.xml#i004
Proposals:
· RE: [ws-rx] Proposal for i004
From Jacques Durand <JDurand@us.fujitsu.com> on 25 Aug 2005
18:25:41 -0000
· Re: [ws-rx] Proposal for i004
From Anish Karmarkar
<Anish.Karmarkar@oracle.com> on 25 Aug 2005 17:45:53 -0000
· RE: [ws-rx] Proposal for i004
From Christopher B Ferris <chrisfer@us.ibm.com> on 25 Aug 2005
12:10:56 -0000
· RE: [ws-rx] Proposal for i004
From "Marc Goodner"
<mgoodner@microsoft.com> on 25 Aug 2005 07:42:02 -0000
· Re: [ws-rx] Proposal for i004
From Anish Karmarkar
<Anish.Karmarkar@oracle.com> on 25 Aug 2005 07:29:20 -0000
· Proposal for i004
From "Marc Goodner"
<mgoodner@microsoft.com> on 23 Aug 2005 23:13:29 -0000
Late posting from Jacques Durand:
I think Anish has a
point.
I believe that Resending MUST not alter wsa:messageId, nor anything in the
SOAP envelope.
- wsa:messageId
may have some relevance w/r to MEPs, and whoever on
the Sender side will verify that a wsa:RelatedTo is
correlating with a previous wsa:messageId must be
sure of the messageId that has been received,
regardless of which retry made it to the RMD. If messageId
may be altered by the RMS or further intermediary, that won't work.
- also, that may affect
the validity of signatures. In 6.3 of SOAP Binding for WS-Addressing, there is
clear requirement that "To avoid breaking signatures,intermediaries MUST NOT change the XML
representation of WS-Addressing headers when relaying those headers." The
RMS may act as intermediary, and resending is just a relaying technique...
Jacques
Marc G: the proposal is that web service addressing says the message
ID can be reused for a retransmitted message. I do not believe we need to redocument the usage of message ID within ws-rm. Anish asked for the text from ws
addressing, and I gave him text from the member submission. This text is no longer in the CR for ws addressing.
Jacques: the resending mechanism relies on not changing anything in
the soap envelope. We should clarify
this in the text.
Stefan: you also have to include the rm
headers.
Doug : my reading of wsrm
does not require resending of bitwise message.
Anish: we may not need to explicitly mention
messageID. We
should recommend the latest recommendation for ws
addressing. That sentence has been
removed. I do not see message ID as
different from any other stuff. One of
the principles is that duplicates are detected by seqID/messageNo.
We should require them to contain the
same information. The endpoint can
determine the meaning of sameness.
Giovanni: if it has the same
sequence ID and sequence No it is the same message. I do not think it is the job of RM to say what
this means exactly. We could build in a
long list of headers to not be modified, however this might not be suitable.
Steve W: ws
addressing defines message ID to uniquely define a message. Within RM we should indicate the content of a
wsa:messageID in the context
of a ws-rm message.
I advocate that we do say something in the spec about this.
Jacques: WS RM policy assertions talks about retransmission of a
message. This needs to be well
defined. Is it the same soap envelope? There may be intermediaries which will add
additional headers. The duplicate
elimination can work with just the sequence ID/ sequence NO.
Stefan: it can suffice to say
a resend is using the same sequenceID and sequence
no.
Giovani:
I can imagine non essential headers being added, which are entirely
harmless in differentiating the send from the resend.
Steve W: Reliable retransmission requires that the same message is
sent (or that the same thing must happen).
Tom R: we might have trouble
crafting the exact statement on meaning of retransmitting the “same message”.
Anish: if the rm
layer can change messages (e.g. message ID) then it does not work for existing
contracts for intended for the original message. The contract between layers above and below rm must be specified in a clear way. Security layer may be below or above the rm layer, this is a different issue. However the rm should
not change things from above it.
Stephan: we might want to look for a statement using “semantically
equivalent to the original:
Anish: This is ok
Giovanni: I would be happy with stephan’s statement “semantically equivalent”. We might add “has same body”. The problem
seems to be with headers. However it
will be difficult to provide an explicit header list.
Jacques: I am fine with the statement of Stephan. I think the use of messageID
header should also be clarified as part of the semantics of the message. If messageID
changes it can cause great trouble
Hamid: the retransmission rule can be
stated as “the message that is resent is exactly the same as it came from the
layers above.” We do not care about the
layers below.
Doug B: That definition does not make sense from an on the wire
observation point of view. We need to
maintain consistency of avoiding implementation dependent concerns.
Anish: I do not see security layer to any
other layer. You could write a module to
change a header or body. We just have to write what the ws
rm layer does.
Stefan: RE: semantic equivalence of retransmission and mesageID. If the
message ID is there when the rm layer gets it it will be retransmitted.
Dave O: if we used “semantic
equivalence” we have to define what we mean by equivalence. If we do anything around equivalence with
retransmission we have to define that.
Doug D: I would like to rely on the statement that sequenceID/seqNo is the same. An RM could, in special cases be allowed to
send a “smaller version” if it had indication of it being too large.
Dave O: I am worried about going into that kind of complexity. RM should avoid being a framing protocol. I would like to leave this out of scope.
Doug D: I do not think rm should talk about such an optimization, but should be
left out of scope.
Anish: serialization could be different, However could we
put constraints on the RM processing.
Chris F: I agree with Doug D, The message ID is
not part of the RM spec.
Giovanni: people bring up different cases, however there are changes
which are harmless, and changes which can have a problem, We are not it a position to explain all these
cases, so we should remain silent.
Jacques: retransmission is sending the same soap envelope.
Tom: We need to continue discussion on the email list.
Tom: if we make any statement it should be testable on wire.
6.3 i005 Source resend of nacks
messages when ack already received
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14147/ReliableMessagingIssues.xml#i005
Proposal:
· RE: [ws-rx] Issue i005
From "Winkler, Steve" <steve.winkler@sap.com> on 25
Aug 2005 18:16:55 -0000
· RE: [ws-rx] Issue i005
From "Winkler, Steve" <steve.winkler@sap.com> on 25
Aug 2005 18:07:45 -0000
· RE: [ws-rx] Issue i005
From "Marc Goodner"
<mgoodner@microsoft.com> on 25 Aug 2005 16:58:30 -0000
· Re: [ws-rx] Issue i005
From Anish Karmarkar
<Anish.Karmarkar@oracle.com> on 25 Aug 2005 06:43:32 -0000
· Issue i005
From "Winkler, Steve" <steve.winkler@sap.com> on 18
Aug 2005 21:10:51 -0000
Steve proposal:
'If the RM
Source should receive a <SequenceAcknowledgement>containing
a Nack, the
RM Source SHOULD retransmit
the message corresponding to the Nack. After
the notification of
successful receipt of a given message by the RM
Destination, the RM Source SHOULD NOT attempt to
retransmit the message
in the event that it
receives a negative acknowledgement for it at a
later point in time.'
Steve W: The core of this
issue is the question at the F2F on what happens when an rm
source received a nack for which it already has
received an ack. The spec does not specify behaviour
on receipt of a NACK. I was hoping to
spell out the proper behaviour. While you would be allowed to retransmit on
NACK you would not have to.
Tom R: the discussions seem to be on how strong the statement should
be.
Marc G: I suggested:
I propose the following more succinct wording to be used at Section 3.2,
after line 338 in place of what you have proposed below.
"The RM Source MAY retransmit the message corresponding to the <Nack>
element when it has not already received an acknowledgement for that
message."
Steve: I prefere the use of “should”
rather than May.
Anish:
this proposal does not deal with the original issue. The original issue is what the send should do
when it receives a nack for a message it has received
an ack to. Marc’s
statement does not address this directly.
Steve: I prefer “SHOULD NOT retransmit, but “MAY” retransmit.
Marc G: if you received an ack you do not
need to retransmit.
Anish: that is not clear from the
statement.
Steve: That is the reason
this issue was raised.
Doug D: the sentence Marc proposed can be misleading.
Steve: the spec needs to be clear on this.
Doug B: which issue are we trying to resolve.
Steve : both, we need to state what happens
when a NACK is received. This is not
stated in the spec,
That is why I wanted to add text stating this as well as the text
for the issue.
Giovanni: we are proposing a restriction on retransmission, when it
can retransmit at any time.
Steve W: that is why I want the SHOULD. If you have good reasons to not do it, then
it is ok.
Giovanni: we need text to describe the original intent of the NACK.
Hamid: from implementation point of view,
when you receive an ack the message is deleted from
the rm sender storage. If a nack comes, the
message will not be available for retransmission. When it gets an ack,
it can remove from the database.
Steve: That is a valid implementation, and the current text would
not effect that implementation.
Bob F: a fault should be raised on receiving a nack
when sender cannot retransmit.
SteveW: use of retransmit on nack after ack would have to be
subject to some policy. In some cases an
error might be appropriate.
Anish: It is quite possible that the ack reaches the sender out of order from the NACK. Thus I do not see the need for a fault. It does not change the protocol,
a smart implementation can ignore the nack.
Gil: What is the harm of either of these scenarios.
The RM gets nack
for thing it got ack for. If it does nothing the
protocol will work. If it sends
it again the protocol will work. There
is no harm in either behaviour.
Bob F: The optimization for NACK behaviour
depends on the use. If we permit a nack to trigger retransmission after an ack
occurs, we need to state what the sender can do. This Nack feature is
a misfeature in these circumstances.
Bob F: if an ack is not authoritative, and
the receiver can change its mind, then we need a recovery mechanism. We are going down a murky area here. The protocol style of keeping messages after ack for future nack is a lot
different than allowing to remove storage on ack.
Vikas: we should stay away from murky
protocol behaviour.
Giovanni: we could state destination never send nack
after it receives an ack. But the sender still has to deal with this if
it occurs due to a delay of one of the messages. How are we helping.
Chris F: I tend to agree with Bob, but it is impossible to prevent a
nack being received after the ack
was received. Adding rmd
should not issue a Nack after it sends an ack (it must not expect to receive
retransmit after ack)
It is better to clarify the destination behaviour
to tighten the protocol.
Duane N: if a nack is received after the ack, it is irrelevant, the ack is
authorative. A
best practice should state the nack is ignored in
such a case. This is independent of the
RMD behaviour.
Jeff M: I agree with chris,
say the rmd cannot send a nack
after an ack.
Steve W: The reason I worded it the way I did, was that some people
were interested in the feature of retransmitting on nack
after ack. Does
anyone see this as important.
Gill: what is the use case.
Steve W: I have none. I can
reformulate based on this discussion and send this out for further discussion. I take silence as meaning no one is in
support of this feature.
Bob F: Dropping the nack instead of
retransmitting is a minor optimization.
Doug Davis: If we are heading
for nack being a noop we
should remove it.
Tom: The discussion is that is would be ignored only if it sender has
received an ack.
Agreed to wait for new proposal from Steve
Action: Steve Winkler to make new proposal for
i005, reflecting tc
discussion
6.4 i012 Anonymous acksTo
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14147/ReliableMessagingIssues.xml#i012
Proposal:
· Re: [ws-rx] Proposal for i012
From Anish Karmarkar
<Anish.Karmarkar@oracle.com> on 25 Aug 2005 18:29:37 -0000
· RE: [ws-rx] Proposal for i012
From Christopher B Ferris <chrisfer@us.ibm.com> on 25 Aug 2005
15:04:50 -0000
· RE: [ws-rx] Proposal for i012
From "Lei Jin" <ljin@bea.com> on 24 Aug 2005 22:00:09 -0000
· Proposal for i012
From "Marc Goodner"
<mgoodner@microsoft.com> on 23 Aug 2005 23:15:51 -0000
Skipped
due to lack of time or concensus on email list.
Keep discussing on
list.
6.5 i019 Sequence termination
on Fault
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14147/ReliableMessagingIssues.xml#i019
Proposal:
· RE: [ws-rx] i0019 - a formal proposal - take 2
From Jacques Durand <JDurand@us.fujitsu.com> on 25 Aug 2005
18:10:11 -0000
· RE: [ws-rx] i0019 - a formal proposal - take 2
From Doug Davis <dug@us.ibm.com> on 25 Aug 2005 17:54:05 -0000
· RE: [ws-rx] i0019 - a formal proposal - take 2
From Jacques Durand <JDurand@us.fujitsu.com> on 25 Aug 2005
17:16:40 -0000
· i0019 - a formal proposal - take 2
From Doug Davis <dug@us.ibm.com> on 25 Aug 2005 13:55:50 -0000
· Re: [ws-rx] i0019 - a formal proposal
From Doug Davis <dug@us.ibm.com> on 25 Aug 2005 13:55:05 -0000
· RE: [ws-rx] i0019 - a formal proposal
From Doug Davis <dug@us.ibm.com> on 25 Aug 2005 13:47:59 -0000
· Re: [ws-rx] i0019 - a formal proposal
From Christopher B Ferris <chrisfer@us.ibm.com> on 25 Aug 2005
13:42:59 -0000
· Re: [ws-rx] i0019 - a formal proposal
From Doug Davis <dug@us.ibm.com> on 25 Aug 2005 12:37:08 -0000
· RE: [ws-rx] i0019 - a proposal: (more complete)
From Jacques Durand <JDurand@us.fujitsu.com> on 25 Aug 2005
01:37:01 -0000
· Re: [ws-rx] i0019 - a proposal: (more complete)
From Shivajee Samdarshi
<shivajee@tibco.com> on 25 Aug 2005 00:52:59 -0000
· RE: [ws-rx] i0019 - a formal proposal
From Jacques Durand <JDurand@us.fujitsu.com> on 25 Aug 2005
00:50:58 -0000
· RE: [ws-rx] i0019 - a proposal: (more complete)
From Doug Davis <dug@us.ibm.com> on 24 Aug 2005 16:30:11 -0000
· RE: [ws-rx] i0019 - a proposal: (more complete)
From Jacques Durand <JDurand@us.fujitsu.com> on 24 Aug 2005
00:19:39 -0000
· RE: [ws-rx] i0019 - a formal proposal
From Doug Davis <dug@us.ibm.com> on 19 Aug 2005 05:50:33 -0000
Tom: Can formal proposal – take 2 cover it.
Doug D: are people happy with the proposal.
Doug D; I believer it covers both.
Action: Doug Davis will put out a new proposal
for, both i0019 and i0028, by next Tuesday.
7
Any New Business
7.1
audio recording of Teleconf for backup purposes
Doug
B: by US
law, a call cannot be recorded unless all participant
agree.
Agreed toPut this out for further
discussion.
7.2
Accolades to pro temp chair
Paul
C: I would like to thank the pro tem chair, Tom Rutt for
his good job filling in for Paul and Sanjay..
All
agreed by unanimous consent.
Meeting
adjourned at 5:30 PM EDT.