Subject: [drinks] RSVP: DRINKS WG Interim Meeting in Sep

From: Sumanth Channabasappa <[email-masked]>
Date: Tue, 7 Sep 2010 15:41:44 -0600

Folks,

A reminder to RSVP, if you haven't already!

Thanks!
- S 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sumanth Channabasappa
Sent: Thursday, August 26, 2010 7:40 AM
To: [email-masked]
Subject: [drinks] DRINKS WG Interim Meeting in Sep

Dear WG participants,
 
In preparation for the upcoming interim meeting, please find enclosed the associated logistical details. If you are interested in attending, please RSVP on or before Sep 7th at: http://www.surveymonkey.com/s/6V6DH26  . 
 
In addition, please request any agenda items on the mailing list. 

Data for Reachability of Inter/tra-NetworK SIP (DRINKS) Interim Meeting (78.5) Information
------------------------------------------------------------------------------------------
 
Date & Time: September 15 2010 (Wednesday); 09:00 - 16:30 (Mountain Daylight Time) / 03:00 - 22:30  (UTC)

Location: 
     858 Coal Creek Circle, Louisville, Colorado, U.S.A., 80027-9750
 
Chairs:
     Alexander Mayrhofer <[email-masked]>
     Sumanth Channabasappa <[email-masked]> 
 
Real-time Applications and Infrastructure Area (RAI) Directors:
     Gonzalo Camarillo <[email-masked]>
     Robert Sparks <[email-masked]>
 
RAI Advisor:
     Gonzalo Camarillo <[email-masked]>
 
Mailing Lists:
     General Discussion: [email-masked]
     To Subscribe:       https://www.ietf.org/mailman/listinfo/drinks
     Archive:            http://www.ietf.org/mail-archive/web/drinks/current/maillist.html

Details
-------
+ On-Site contact person
  Sumanth Channabasappa <[email-masked]>
     
 　
+ Directions to the location, and nearby places to stay at
  http://www.cablelabs.com/about/contact/

+ Remote participation information
  1/ Web link
 
  https://www1.gotomeeting.com/join/743192888
 
  Note: Please join GoToMeeting first so that you can obtain an audio PIN; it will help us identify callers easily instead of relying on announcements.
 
  2/Conference Info
 
  - Use your microphone and speakers (VoIP) to join in via the GoToMeeting Client. Or, call in using your telephone.
 
  Dial       : 215-383-1008
  Access Code: 743-192-888
  Audio PIN  : Should be displayed on the GoToMeeting web client, after you join
 
　
 
　

_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

---

From: "Cartwright, Ken" <[email-masked]>
Date: Thu, 9 Sep 2010 09:45:30 -0400

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.

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, 9 Sep 2010 09:57:16 -0400

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

================

Progress

=============

The Requirements:

Background:

Proposal:

=======================

Document To-Do List

---

From: "Cartwright, Ken" <[email-masked]>
Date: Fri, 10 Sep 2010 14:54:20 -0400

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

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

================

Progress

=============

The Requirements:

Background:

Proposal:

=======================

Document To-Do List

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.
13) (Ken) Make the content of spppRequest more explicit so that update requests and query requests cannot be co-mingloed in the same spppRequest.

---

From: "Cartwright, Ken" <[email-masked]>
Date: Mon, 13 Sep 2010 10:56:14 -0400

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

Ken

-----Original Message-----
From: Cartwright, Ken
Sent: Thursday, September 09, 2010 9:57 AM
To: Cartwright, Ken; [email-masked]
Subject: RE: Progress Update

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

================

Progress

=============

The Requirements:

Background:

Proposal:

=======================

Document To-Do List

---

From: "Cartwright, Ken" <[email-masked]>
Date: Mon, 13 Sep 2010 17:55:17 -0400

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

Ken

-----Original Message-----
From: Cartwright, Ken
Sent: Friday, September 10, 2010 2:54 PM
To: Cartwright, Ken; [email-masked]'
Subject: RE: Progress Update

Ken

-----Original Message-----
From: Cartwright, Ken
Sent: Thursday, September 09, 2010 9:57 AM
To: Cartwright, Ken; [email-masked]
Subject: RE: Progress Update

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

================

Progress

=============

The Requirements:

Background:

Proposal:

=======================

Document To-Do List

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Mon, 13 Sep 2010 18:16:24 -0400

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
> 
> 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.
> 
> 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:
> 
> 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.
> 
> 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
> 
> 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) (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 h) (Syed / Ken) spppRequest and spppResponse data elements and the
> "transactional" element. Related to (d) above.
> 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.
> 13) (Ken) Make the content of spppRequest more explicit so that update
> requests and query requests cannot be co-mingloed in the same spppRequest.
> 
> 
> 
> are not the intended recipient, please contact the sender by reply e-mail and
> destroy all copies of the original message.
> 
> 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: Tue, 14 Sep 2010 09:16:03 -0400

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,

thanks.

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Tue, 14 Sep 2010 12:18:58 -0400

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
> 
>>                 duplicate clinet and server transaction ID attributed.  We
>> are
>> using elements.
>>         that it tightly related to my item "4a", so I went ahaead and
>> included
>> it in that section.
>> 8) Worked on how to meet Syed two requirements.  I discuss this in more
>> detail
>> below.
>> 
>> =============
>>

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Tue, 14 Sep 2010 13:22:37 -0400

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:

>>>         May want to break out the message parameters to an XML data
>>> structure
>>> in the XSD.

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Wed, 15 Sep 2010 00:21:10 -0400

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:

>>>> Btw, here's the document as it currently stands.  I have the token and am
>>>> in
>>>> progress.
>>>> 
>>>> Ken
>>>> 
>>>>         -- Did a search and replace rename on a few instances of
>>>> "DestGroup"
>>>> to "DestGrp".
>>>>         Updated the Request section to reflect our latest XSD definition
>>>> and
>>>> made a few corrections.
>>>>         Corrected the XSD structure of the spppResponse element defintion
>>>> to
>>>> remove the
>>>> 5) Compelted item "4h" in the formal To-Do list.  This one actually
>>>> belonged
>>>> to Syed, but I realized
>>>> g) (???HowDoWeWantToDocumentThis)??? Object keys (business keys vs
>>>> synthetic
>>>> keys).

---

From: "Cartwright, Ken" <[email-masked]>
Date: Tue, 21 Sep 2010 17:21:26 -0400

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

-Syed

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 22 Sep 2010 11:37:04 -0400

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

Document Changes

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

-Syed

---

From: "Cartwright, Ken" <[email-masked]>
Date: Fri, 24 Sep 2010 10:28:50 -0400

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

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

Document Changes

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

-Syed