Subject: [drinks] Rough Notes and AI list from the call on 9/9

From: Sumanth Channabasappa <[email-masked]>
Date: Thu, 9 Sep 2010 09:15:38 -0600

IETF DRINKS DESIGN TEAM CALL 
============================
9/9/2010, 10:00a-10:50a (Eastern)/8:00a-8:50a (Mountain)

Participants
============
- Ken Cartwright
- Jean-Francois Mule
- Sumanth Channabasappa 
 
Apologies
---------
- Syed Ali 

ACTION ITEMS UPDATE (from the last meeting)
===================
AI: Alex to ping the volunteer reviewers for the use cases document
    Update: Alex has sent across a request to the volunteers, no responses yet (on the list)
      
AI: Alex volunteered to provide details regarding a web-based I-D change management tool
    Update: Alex sent across an email on 9/8
 
AI: Ken has the token and will share the changes on the list
    Update: Ken sent across a summary of his changes on 9/9
 
AI: Syed to send across protocol examples to the mailing list
    Update: Pending?

AGENDA
======
0/ Updates from the I-D authors
1/ Design team agenda and Goals for the F2F
2/ Any other topics

NOTES
=====
0/ AI updates from last time
   - See updates above.

0/ Updates from the I-D authors
   - See Ken's email from earlier today (9/9) for details regarding the changes made
   - There were a few discussions around the changes that were made between Ken and Jean-Francois, mostly details on suggestions (e.g., the complexity of supporting partial success)
   - Further discussions will be held on the mailing list
 
1/ Design team agenda and Goals for the F2F
   - The WG Chairs sent across the agenda via email on 9/7
   - The design team did not have any further comments or updates
   - We have the following RSVPs 
      > In-person      : Ken C, Syed A, Jean-Francois M, Sumanth
      > Teleconference : Alex M, Manjul M, Otmar L, David S (tentative)
 
2/ Any other topics
   - None

---

From: Sumanth Channabasappa <[email-masked]>
Date: Thu, 30 Sep 2010 18:01:38 -0600

IETF DRINKS DESIGN TEAM CALL 
============================
9/30/2010, 10:00a-11:03a (Eastern)/8:00a-9:03a (Mountain)

Participants
============
- Jean-Francois Mule
- Manjul Maharishi
- Ken Cartwright
- Syed Ali (latter part of the call)

- Sumanth Channabasappa 

ACTION ITEMS 
============
[Tokens for editing the protocol I-D]
(Syed) Today (9/30) and Tomorrow (10/1)
(Ken)  Monday (9/4) 
(Jean-Francois) Tue and Wed (9/5 and 9/6)

[Authors]
Submit a revision with the recent changes on or around 9/7

[Ken] Modify the draft to associate egress routes with route records, and not Route Groups
[Syed] Add clarifications to the use of the regexp field in the URI type, with examples
[Jean-Francois] Suggest the use of namespace and value pair for the enterprise ID  

AGENDA
======
1/ Updates following the F2F from the protocol authors (Ken and Syed)
2/ Progress towards the next version of the protocol I-D (items completed and TBD)

NOTES
=====
1. Updates following the F2F from the protocol authors (Ken and Syed) 

[Ken] provided an update regarding the changes he has made. See his email from 9/13

Discussions
~~~~~~~~~~~

[Ken] pointed out that the egress routes -- as specified currently -- make sense only w.r.t. the NAPTR record type. So the question is, should we associate the egress routes with the route records, instead of the Route Groups?

After some discussion we agreed that it may be a good idea to associate the egress routes with the record routes. [Manjul] pointed out that this has the added benefit of clarity since the provisioner creates the route group and the recipient creates the egress, and this explicit association will make it easier (and required) to create the proper relationships.  

In addition, Jean-Francois suggested that we should allow for the egress routes to be associated with other record types, such as URI. We had some discussion on how this could be done (since there is no DNS RR for the URI type).  I am unsure if there was a specific resolution (design team, please pitch in).

AI: Ken to make the association changes.

~~~~

[Jean-Francois] then questioned the usage of the regexp field in the URI type.
[Syed] explained that there are two attributes to the URI type: the regular expression pattern and the replacement string. The input is a number you apply the regexp to obtain the final identifier (e.g., sip:<input number>@XYZ.COM). The regexp is needed since it's absence would limit the usefulness of the URI type when there is a a 1-1 binding between the E.164 number and the resource record, i.e., the binding between a number and a route cannot be provided. The goal of this was similar to the use of NAPTRs, except to be protocol-agnostic.

[Jean-Francois] asked as to what happens if we provide the URI string as SIP:xyz.com?
[Syed] explained that this works, except that you will need an out-of-band mechanism to backfill the user part. An example of the use is a deployment where one PBX wants to apply a different regexp than others.

AI: Syed to add this clarification.
~~~~

[Jean-Francois] What did we do with the enterprise ID?
[Ken] Nothing
[Jean-Francois] can we use Brian Rose's suggestion to use namespace and value? 
[Team] Yes

AI: Jean-Francois to make this change.

2. Progress towards the next version of the protocol I-D (items completed and TBD)

- See AIs and the handling of tokens