Subject: Re: [drinks] Progress Update

From: "Cartwright, Ken" <[email-masked]>
Date: Thu, 30 Sep 2010 10:37:30 -0400

Hi Syed,

> - Any reason why we shouldn't allow adds for multiple RteRec within
> 'AddRteRecRqstType'. For now added maxOccurs="unbounded"

We agreed that we did not want to have a set of sets in the spppUpdaterequest.  That would need to be changes back to be the default masOccurs=1.

Ken
-----Original Message-----
From: Maharishi, Manjul
Sent: Thursday, September 30, 2010 10:07 AM
To: Syed Ali
Cc: Cartwright, Ken
Subject: FW: [drinks] Progress Update

Hi Syed,

Looks like you got the wrong Ken...fwding to Ken Cartwright...

Also, your address for DRINKS IETF seems to expand to [email-masked], instead of [email-masked], that may explain why you were unable to send it across!.

Manjul

-----Original Message-----
From: Ali, Syed Wasim [mailto:[email-masked]]
Sent: Thursday, September 30, 2010 4:05 AM
To: [email-masked]; Sumanth Channabasappa; Maharishi, Manjul; Alexander Mayrhofer; [email-masked]; David Schwartz
Subject: FW: [drinks] Progress Update

I have unsuccessfully tried to send this email to [email-masked] only to find it bounce right back. Not sure why. Any way, ... I figured I will send it to you guys for the morning meeting

-Syed

------ Forwarded Message
> From: Syed Ali <[email-masked]>
> Date: Thu, 30 Sep 2010 04:00:18 -0400
> To: "[email-masked]" <[email-masked]>
> Conversation: [drinks] Progress Update
> Subject: RE: [drinks] Progress Update
>
>
>
> Attached:
>
> - sp_example.txt -- updated SP examples that will be added to the
> proto doc
> - draft-....01v13.xml -- updated the XML schema
>
> Tasks from the 9/15 Interim meeting:
>
> - change assignedCorDateTime to corDateTime -- the date and time when
> the <cor> attribute was last changed; most likely due to NP update
> [DONE -- Ken made the change to the schema]
>
> - move the <rterec> from PubIDType to TNType.
> [DONE -- Ken made the change to the schema]
>
> CORInfoType to be moved from PubIDType to TN, TNRange, LRN [DONE --
> Ken made the change to the schema]
>
> - If CORClaim is set to true on a TNRange add operation, a success
> response means CORClaim for *all* TNs in the TNRange. Add an example
> [Open]
>
> - Check whether the ere attribute of URIType should be of type
> RegexParamType.
> [No changed needed. ere type is "string" and it is meant to only
> capture the regex pattern. the <uri> element serves as the replacement
> string]
>
> - add example each for SourceIdentSchemeType in the examples section
> to clearly describe the usage ... uri, ip, rootDomain [Open]
>
> - add example that involves URIType
> [Open]
>
>
> Update to schema:
>
> - For the <spppUpdateResponse> moved the <clientTransId> and
> <serverTransId> to the beginning of the <sequence> for consistency
> with the <spppUpdateRequest>
>
> - Last I remember, we wanted to retain the "prefix" attribute for
> TNRange in order to support length variance associated with the Open
> Number Plan. It was missing from the latest schema, so I added it back in.
>
> - Any reason why we shouldn't allow adds for multiple RteRec within
> 'AddRteRecRqstType'. For now added maxOccurs="unbounded"
>
> Question:
>
> - ObjKeyType is optional for the GetXXX operations. Is the intent to
> allow
> *ALL* object fetch? For instance, GetRteRecsRqstType with no
> ObjKeyType in the body of the message as a way to ask the SP server to
> return *ALL* RteRecType objects from the Registry. There are a couple
> of issues with this. One, lack of object key means that SP server
> doesn't have the <rantId> field to use as a filter. Two, some SP
> implementation may prefer to limit the number of objects that can be obtained for a single GetXXX operation.
>
> Notes:
>
> I noticed that NAPTR.PREF is removed in favor of "priority" defined in
> the RteRecRefType. I suppose this is Ok.
>
> Next steps:
>
> I continue to hold the token for the document and I plan to finish the
> remaining tasks by COB Friday 9/29.
>
> -Syed
>
>
> On 9/24/10 10:28 AM, "Cartwright, Ken" <[email-masked]> wrote:
>
>> One last change before I had the token back to Syed.  Attached is the
>> updated version of the document.  This change corrects the use of
>> priority relative to Route Records and their relationships to Route
>> Groups.
>>
>> Syed, you've got the token now.
>>
>> Ken
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Cartwright, Ken
>> Sent: Wednesday, September 22, 2010 11:37 AM
>> To: Ali, Syed Wasim; [email-masked]
>> Subject: Re: [drinks] Progress Update
>>
>> Syed handed the token back to me for a couple hours this morning so
>> that I could go ahead and do the Route Rec management updates to the
>> doc.  This is now done and here is the next rev of the document.
>>
>> Ken
>>
>> -----Original Message-----
>> From: Cartwright, Ken
>> Sent: Tuesday, September 21, 2010 5:21 PM
>> To: 'Ali, Syed Wasim'; [email-masked]
>> Subject: RE: [drinks] Progress Update
>>
>> Here is the next version of the protocol document.  Based on the
>> decisions we made at the face-to-face, the final version of this
>> document is now clearly within shouting distance.  And the document
>> overall is notably simpler and shorter.
>>
>> Syed, if you want it, you can have the token now.  At some point I'll
>> need it back for maybe one day before we finalize it to wrap up a
>> couple to-do items of mine.
>>
>> What I've done since the last update is as follows:
>>
>> XSD Changes (which have resulted in a notably simpler and cleaner
>> XSD) =======================================
>> 1) Search and replace cleaned up a few naming inconsistencies using
>> the word "Object".  The preference is not to use "Obj".
>> 2) Per agreement at meeting, made RqstObjResultCodeType inherit from
>> ResultCodeType, and added the word "Type" onto the end of each of
>> these names to get them in sync with our naming convention.
>> 3) Per agreement at meeting, changes all of the operation object types (e.g.
>> AddRteGrpRqstType) so that they now contain a single object instance.
>> 4) Per agreement at the meeting, cleaned up what was the spppRequest
>> and spppResponse element definitions to remove the transactional flag
>> and to explicitly break our updates from queries.  This resulted in
>> the spppUpdateRequest/Response and spppQueryRequest/Response.  Also
>> made all operation object types and query types inherit from their
>> corresponding abstract base types.
>> 5) Per agreement at the meeting, changed the multiplicity of the
>> ingressRte element to allow reference to more tan one Route Group.
>> 6) Per agreement at the meeting, change "assignedCorDateTime"
>> elementname to "corDateTime".  Also tightened up the multiplicity
>> indicator on the corClaim element in relation to our discussion about
>> the confusion resulting from having a default value provided for an optional data element.
>> 7) Per agreement at the meeting, moved RteRec out of PIType base type
>> and into the concrete type(s) it is needed for (i.e. TNType).
>> 8) Per agreement at the meeting, added priority into the RteGrpType.
>> 9) Per agreement at the meeting, changed RteRecs in RteGrpType to be
>> references rather than embedded objects, therefore promoting RteRecs
>> to first class object type.  As discussed, this also necessitate adding a "name"
>> element in the abstract base RteRecType.
>> 10) Misc other cleanups.
>>
>> Document Changes
>> ======================================
>> 1) Placed the new XSD into the XSD section of the document.
>> 2) Updated all the sections that describe the base data structures of
>> the protocol to reflect all the XSD changes listed above (layering,
>> spppUpdateRequest/Response, spppQueryRequest/Response, response codes, etc).
>> 3) Updated all the following protocol command sections to reflect the
>> XSD changes listed above:
>>         -- add and get route groups
>>         -- add and get dest groups
>>         -- add, accept, reject, and get route group offers
>>
>> Ken
>>
>>
>> -----Original Message-----
>> From: Ali, Syed Wasim [mailto:[email-masked]]
>> Sent: Wednesday, September 15, 2010 12:21 AM
>> To: Ali, Syed Wasim; Cartwright, Ken; [email-masked]
>> Subject: Re: [drinks] Progress Update
>>
>>
>> Attached is the updated examples section. Added descriptive text and
>> made a few updates to the XML messages.
>>
>> -Syed
>>
>>
>> On 9/14/10 1:22 PM, "Syed Ali" <[email-masked]> wrote:
>>
>>>
>>>
>>> Hi,
>>>
>>> Attached is the first draft of the sppp example section. I will add
>>> the text in the sub-sections in the protocol document .xml this
>>> afternoon to make the examples fit a hypothetical provisioning
>>> scenario for which the diagram is already in place. Also, I will
>>> email the updated sppp protocol document later today.
>>>
>>> thanks,
>>>
>>> -Syed
>>>
>>>
>>> On 9/14/10 12:18 PM, "Syed Ali" <[email-masked]> wrote:
>>>
>>>>
>>>>
>>>> Ken,
>>>>
>>>> The examples I have put together are based on the schema that has
>>>> gotten nods already. And I agree, after tomorrow's f2f and review
>>>> of the proposed changes, we can decide how to move forward.
>>>>
>>>> Just to be clear, I am not proposing anything new in regards to the
>>>> "partial success". If an SP operation (such as addPubIdsRqst)
>>>> allows for multiple embedded objects for provisioning (such as 2 or
>>>> more <pi>), there is an opportunity for the server to point out
>>>> which embedded object (i.e. one of the many <pi>) is the cause of
>>>> the failure. Prior understanding where an operation (such as
>>>> addPubIdRqst) is inherently transactional remains unchanged.
>>>>
>>>> -Syed
>>>>
>>>>
>>>> On 9/14/10 9:16 AM, "Cartwright, Ken" <[email-masked]> wrote:
>>>>
>>>>> Ok, you can have the token.  But before adding any of the XML into
>>>>> the examples section I think we need to talk through the proposed
>>>>> XSD changes that are designed to meet the partial success, and
>>>>> synchronous COR claim response.
>>>>> This is of course because the examples will change based on that decision.
>>>>> Also keep in mind that these proposed XSD changes are right now
>>>>> only reflected in the XSD section, not the body of the doc.
>>>>>
>>>>> My plan was for us to review these changes at the meeting
>>>>> tomorrow, and if we do agree to the changes, I would then make the
>>>>> resulting changes to the body of the doc over the subsequent few
>>>>> days, then hand off the token on Monday.
>>>>>
>>>>> Ken
>>>>>
>>>>> -----Original Message-----
>>>>> From: Ali, Syed Wasim [mailto:[email-masked]]
>>>>> Sent: Monday, September 13, 2010 6:16 PM
>>>>> To: Cartwright, Ken; [email-masked]
>>>>> Subject: Re: [drinks] Progress Update
>>>>>
>>>>> Ken,
>>>>>
>>>>> Let me know if I can have the token for the doc. I will add my
>>>>> updates from the todo list and publish it tomorrow mid-day.
>>>>>
>>>>> thanks.
>>>>>
>>>>>
>>>>> On 9/13/10 5:55 PM, "Cartwright, Ken" <[email-masked]> wrote:
>>>>>
>>>>>> Here is what is likely to be the last update I will have prior to
>>>>>> the Wednesday meeting.  The changes to this version are simply a
>>>>>> few cleanups to the XSD so that it validates.
>>>>>>
>>>>>> Ken
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Cartwright, Ken
>>>>>> Sent: Monday, September 13, 2010 10:56 AM
>>>>>> To: [email-masked]'
>>>>>> Subject: RE: Progress Update
>>>>>>
>>>>>> Here's the next update to the doc.  Also attached is the running
>>>>>> list of changes.  Items 9, 10, and 11 are the latest changes I
>>>>>> made since my late update.
>>>>>>
>>>>>> Syed and JFM, you will of course want to review these asap.
>>>>>>
>>>>>> Ken
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Cartwright, Ken
>>>>>> Sent: Friday, September 10, 2010 2:54 PM
>>>>>> To: Cartwright, Ken; [email-masked]'
>>>>>> Subject: RE: Progress Update
>>>>>>
>>>>>> Here's the next update.  I've completed item 7 from the To-Do
>>>>>> list and incorporated all comments from my Pre-IETF document
>>>>>> review (see second attached document), save 1.  The one comment
>>>>>> that I did not fully address
>>>>>> is:
>>>>>>
>>>>>> "KJC:  Need to describe how multiple response messages are supported."
>>>>>>
>>>>>> There are a few different opinions on how/if/toWhatExtent we want
>>>>>> to support that.  We need to discuss this and put it to bed at
>>>>>> the face-to-face meeting next week.  This item is priority one as
>>>>>> far as I am concerned.  And this of course is related to the
>>>>>> "Proposal for Syeds two requirements" referred to in the email
>>>>>> below.
>>>>>>
>>>>>> I'll continue to work this over the weekend and Monday and send
>>>>>> out another update no later than COB Monday.
>>>>>>
>>>>>> Ken
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Cartwright, Ken
>>>>>> Sent: Thursday, September 09, 2010 9:57 AM
>>>>>> To: Cartwright, Ken; [email-masked]
>>>>>> Subject: RE: Progress Update
>>>>>>
>>>>>> Btw, here's the document as it currently stands.  I have the
>>>>>> token and am in progress.
>>>>>>
>>>>>> Ken
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf Of Cartwright, Ken
>>>>>> Sent: Thursday, September 09, 2010 9:46 AM
>>>>>> To: [email-masked]
>>>>>> Subject: [drinks] Progress Update
>>>>>>
>>>>>>
>>>>>> Below is my progress update for the past two weeks and a proposal
>>>>>> for how to handle the two goals/requirements that Syed has.  We
>>>>>> can discuss this on today's call.
>>>>>>
>>>>>> ================
>>>>>>
>>>>>> Progress
>>>>>>
>>>>>> 1) Completed my item "1" from the formal To-Do list
>>>>>>         -- Added in the section describing the addDestGrps operation
>>>>>>         -- Added in the section describing the getDestGrps operation
>>>>>>         -- Did a search and replace rename on a few instances of
>>>>>> "DestGroup"
>>>>>> to "DestGrp".
>>>>>>                 This syncs up with the "RteGrp" name.
>>>>>> 2) Fixed a few grammatical issues in the addRteGrp and getRteGrp
>>>>>> sections.
>>>>>> 3) Fixed a few issues with the XML.  Someone inserted the use of
>>>>>> "&" in section headers without escaping it.  So I replaced them
>>>>>> wiht "and".
>>>>>> 4) Completed my item "4a" from the formal To-Do list
>>>>>>         Updated the Request section to reflect our latest XSD
>>>>>> definition and made a few corrections.
>>>>>>         Updated the Reply/response section to reflect our latest
>>>>>> XSD definition and made a few corrections.
>>>>>>         Corrected the XSD structure of the spppResponse element
>>>>>> defintion to remove the
>>>>>>                 duplicate clinet and server transaction ID attributed.
>>>>>> We
>>>>>> are
>>>>>> using elements.
>>>>>> 5) Compelted item "4h" in the formal To-Do list.  This one
>>>>>> actually belonged to Syed, but I realized
>>>>>>         that it tightly related to my item "4a", so I went ahaead
>>>>>> and included it in that section.
>>>>>> 6) Tentatively Completed item "4e" in the formal To-Do list.
>>>>>>         May want to break out the message parameters to an XML
>>>>>> data structure in the XSD.
>>>>>> 7) Working on action item 7
>>>>>> 8) Worked on how to meet Syed two requirements.  I discuss this
>>>>>> in more detail below.
>>>>>>
>>>>>> =============
>>>>>>
>>>>>> Proposal for Syeds two requirements:
>>>>>>
>>>>>> The Requirements:
>>>>>> 1) Allow partial success within a given request (iow, the result
>>>>>> of a given request is not all or nothing).
>>>>>> 2) Allow the detailed result of the objects within a request to
>>>>>> be echoed back ti the client (specifically for the Public
>>>>>> Identifier and its COR request result.
>>>>>>
>>>>>> Background:
>>>>>>
>>>>>> 1) I think both requirements are of course reasonable if you have
>>>>>> systems that need them and that are therefore ok with te moderate
>>>>>> performance and complexity that they result in.  Which of course
>>>>>> Syed does.  So I'm in agreement that we should make the necessary
>>>>>> modifications to support them.
>>>>>> 2) The protocol was not initially constructed to address these
>>>>>> two requirements because they were not requirements at the time.
>>>>>> 3) To help answer the first requirement we had just bolted on the
>>>>>> "transactional" attribute to the spppRequest, and made the
>>>>>> content of an spppRequest to be zero or more, object and relied
>>>>>> on the parameterized response messages/codes to add the details
>>>>>> about what failed.  However, I've come to believe that this is no
>>>>>> longer a clean and effective way to handle them.
>>>>>>
>>>>>> Proposal:
>>>>>>
>>>>>> 1) Change all the object operation objects so that they do not
>>>>>> support multiple objects.  Iow, addDestGrps, would become
>>>>>> addDestGrp, and addPIs would become addPI.  This eliminates the
>>>>>> complexity of the response that results from allowing both
>>>>>> multiple objects and multiple object requests to be passed into
>>>>>> an spppRequest operation.
>>>>>> 2) Change the response data structure and so that it can handle
>>>>>> echoing back all of the objects that were passed in and the
>>>>>> result of each.
>>>>>> 3) I'll make the necessary changes to document and XSD over the
>>>>>> next couple days.
>>>>>>
>>>>>> =======================
>>>>>>
>>>>>>
>>>>>> Document To-Do List
>>>>>>
>>>>>> XX 1) (Ken) Write the add/get Destination Group operation
>>>>>> sub-sections of section 8.
>>>>>> 2) (Syed) Write the general "del" operation sections of sub-section 8.
>>>>>> 3) (Alex & Ken) Make sure that the portions of section 8 that I
>>>>>> wrote and the portions that Syed will write are in sync from a
>>>>>> specificity standpoint and a functionality stand point, and that
>>>>>> they are all correct from a spelling and grammar perspective.
>>>>>> 4) Update/tweak/add sections that describe the XSD and protocol
>>>>>> concepts that apply to all of the operations in section 8. This
>>>>>> includes the following:
>>>>>> XX a) (Ken) BasicRqstType and BasicRspns Type
>>>>>> b) (Syed) BaseObjType
>>>>>> d) (Syed) Transactional boundaries and transaction IDs XX e)
>>>>>> (Ken) Response codes
>>>>>> f) (Ken) Authorization to objects and information
>>>>>> g) (???HowDoWeWantToDocumentThis)??? Object keys (business keys
>>>>>> vs synthetic keys).
>>>>>> XX h) (Syed / Ken) spppRequest and spppResponse data elements and
>>>>>> the "transactional" element. Related to (d) above.
>>>>>> j) (Ken) Organization ID documentation.
>>>>>> 5) (Syed) Evaluate and incorporate what Syed comes up with on the
>>>>>> open number plan concept and add this into Syed's Public Identity
>>>>>> portion of section 8.
>>>>>> 6) (Syed, Alex for SIP Redirect example) Add more information in
>>>>>> section
>>>>>> 8
>>>>>> to
>>>>>> explain how the URIType is used (to meet the LUF requirements).
>>>>>> This will be part of an example section. We will add an example
>>>>>> appendix at the end.
>>>>>> Working 7) (JFM first pass then, Ken) Clean up and partially
>>>>>> re-organized the introductory sections 1 through 7 to make them
>>>>>> more focused and clear cut.
>>>>>> Perhaps move parts of their content into section 8, etc.
>>>>>> 7.5) (Alex) Review the requirements section. I'm not sure why we
>>>>>> have the use cases and requirements re-stated in this document. I
>>>>>> think we should not do that. Also see my comments on section 1
>>>>>> through 7 sent out on Monday, 7/26.
>>>>>>  8) (Sumanth) Make sure the terminology and definitions in the
>>>>>> intro sections are now in sync with our new understandings of the
>>>>>> use cases in the use case document.
>>>>>> 9) Updates to Public Identifier Type Documentation and XSD as follows:
>>>>>> a) (JFM)corClaimStatus boolean instead of "approved" enum and
>>>>>> corClaimStatusChanges date/Time
>>>>>> b) (Syed) Open numbering plan support for TN Range
>>>>>> c) (JFM) TNRange should not inherit from TN
>>>>>> 11) (Ken) File based bulk provisioning.
>>>>>> 12) (Ken, Alex) Data validation rules for each data element.
>>>>>> 13) (Ken) Make the content of spppRequest more explicit so that
>>>>>> update requests and query requests cannot be co-mingloed in the
>>>>>> same spppRequest.
>>>>>>
>>>>>>
>>>>>>
>>>>>> This e-mail message is for the sole use of the intended
>>>>>> recipient(s)and may contain confidential and privileged
>>>>>> information of Transaction Network Services.
>>>>>> Any unauthorised review, use, disclosure or distribution is prohibited.
>>>>>> If
>>>>>> you
>>>>>> are not the intended recipient, please contact the sender by
>>>>>> reply e-mail and destroy all copies of the original message.
>>>>>>
>>>>>> _______________________________________________
>>>>>> drinks mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/drinks
>>>>>>
>>>>>> This e-mail message is for the sole use of the intended
>>>>>> recipient(s)and may contain confidential and privileged
>>>>>> information of Transaction Network Services.
>>>>>> Any unauthorised review, use, disclosure or distribution is prohibited.
>>>>>> If
>>>>>> you
>>>>>> are not the intended recipient, please contact the sender by
>>>>>> reply e-mail and destroy all copies of the original message.
>>>>>>
>>>>>
>>>>>
>>>>> This e-mail message is for the sole use of the intended
>>>>> recipient(s)and may contain confidential and privileged
>>>>> information of Transaction Network Services.
>>>>> Any unauthorised review, use, disclosure or distribution is
>>>>> prohibited. If you are not the intended recipient, please contact
>>>>> the sender by reply e-mail and destroy all copies of the original
>>>>> message.
>>>>>
>>>>
>>>> _______________________________________________
>>>> drinks mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/drinks
>>>
>>
>>
>> This e-mail message is for the sole use of the intended
>> recipient(s)and may contain confidential and privileged information
>> of Transaction Network Services.
>> Any unauthorised review, use, disclosure or distribution is
>> prohibited. If you are not the intended recipient, please contact the
>> sender by reply e-mail and destroy all copies of the original
>> message.
>>
>>
>> This e-mail message is for the sole use of the intended
>> recipient(s)and may contain confidential and privileged information
>> of Transaction Network Services.
>> Any unauthorised review, use, disclosure or distribution is
>> prohibited. If you are not the intended recipient, please contact the
>> sender by reply e-mail and destroy all copies of the original
>> message.
>>
>
>

------ End of Forwarded Message

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: "Cartwright, Ken" <[email-masked]>
Date: Thu, 30 Sep 2010 10:48:43 -0400

Sorry, my typos below (was multi-tasking) make my point unclear.  Let me try again.

In Colorado we agreed that we did not want to have a set of sets passed into the spppUpdateRequest.  That introduces a lot of complexity the response structures, etc, and it not necessary. So the maxOccurs needs to be the default value of 1 on those.  So if you changed those to maxOccurs="unbounded" then it needs to be changed back to minOccurs=1 (the default).

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cartwright, Ken
Sent: Thursday, September 30, 2010 10:38 AM
To: Maharishi, Manjul; Syed Ali; [email-masked]
Subject: Re: [drinks] Progress Update

Hi Syed,

Ken
-----Original Message-----
From: Maharishi, Manjul
Sent: Thursday, September 30, 2010 10:07 AM
To: Syed Ali
Cc: Cartwright, Ken
Subject: FW: [drinks] Progress Update

Hi Syed,

Manjul

-----Original Message-----
From: Ali, Syed Wasim [mailto:[email-masked]]
Sent: Thursday, September 30, 2010 4:05 AM
To: [email-masked]; Sumanth Channabasappa; Maharishi, Manjul; Alexander Mayrhofer; [email-masked]; David Schwartz
Subject: FW: [drinks] Progress Update

-Syed

------ Forwarded Message