Minutes for DRINKS at IETF-interim-2010-drinks-1
minutes-interim-2010-drinks-1-00

IETF DRINKS DESIGN INTERIM MEETING
==================================
September 15, 2010 (Wednesday); 0900 - 1630 (Mountain Daylight Time) / 1500 -
2230  (UTC)

Participants
============
[In-Person]
- Jean-Francois Mule
- Ken Cartwright
- Syed Ali
- Sumanth Channabasappa

[Remote; note: some participants were in and out]
- Alexander Mayrhofer
- David Schwartz
- Otmar Lendl
- Manjul Maharishi
- Penn Ffautz
- Gonzalo Camarillo

ACTION ITEMS
============

I-D Changes
-----------

[Ken C]
- come up with a way to make the source identity types enumeration extensible,
and add client certificate type - commit changes to linearize bulk requests,
and  add informative text to clarify that the order of processing is the same
as the order in the request. - make agreed upon XML Schema changes (see below)

[Syed]
- to add informative text regarding COR claim operation
- make agreed upon XML Schema changes (see below)

[Alex]
- review requirements section

[Sumanth]
- Propose re-use of existing data types within the XML Schema

Others
------

[David S] may volunteer to propose the third case (continue through entire
request and note down all errors during bulk provisioning.

[Otmar] propose separate prefix type for open numbering plan [DONE]

[Penn] is requested to keep the team informed of the Global SPID I-D

AGENDA
======
0. Administrivia

1. WG & document status

2 & 3. Protocol Document
   Link: http://tools.ietf.org/wg/drinks/draft-ietf-drinks-spprov/

4. Use Cases & Requirements Draft
   Link:
   http://tools.ietf.org/wg/drinks/draft-ietf-drinks-usecases-requirements/

5. Transport Document
   Link: http://tools.ietf.org/wg/drinks/draft-ietf-drinks-sppp-over-soap/

6. Wrap-up

NOTES
=====
0. Administrivia
----------------

- Participants were welcomed, and we went over the 'Note Well', 'Agenda' and
'Meeting Logistics' - The following volunteered as 'official' note takers: Syed
A, Alex M - Sumanth volunteered to be the Jabber scribe; however, given the
lack of attendance on Jabber no discussions were noted there.

1. WG & document status
-----------------------

+ We discussed the revised milestones 
(http://tools.ietf.org/wg/drinks/charters) - Sep 2010: Request Publication of
Usecases draft - Dec 2010: Request Publication of Protocol & Transport draft -
Current goal: shutdown WG after/in Prague

+ We also briefly touched on the related efforts, specifically the Global SPID
- Penn is working on an I-D that is currently in internal review and will use
IANA enterprise numbers (by the end of Sep) - FYI, this is not going to be a
DRINKS WG document

2 & 3  Protocol Document
- Link: http://tools.ietf.org/wg/drinks/draft-ietf-drinks-spprov/

- The discussions started with a quick overview of the document by Ken
Cartwright, and a list of all the changes made by the authors (Ken, Syed,
Jean-Francois); see emails prior to the interim for details

+ During the process we identified the following open issues
 a) Partial success; bulk processing
 b) Source based routing and source identity (Section 6.1)
 c) Synchronous and asynchronous COR claims
 d) Bulk Provisioning changes
 e) Response code structure -- we did not discuss this
  f) XML Schema review

~~~
A) Partial success

- Brief overview: If you are provisioning a large data set with multiple
entries into the Registry and an error is found, you have the following
options: 1) Stop when you find the first error and rollback 2) Stop when you
find the first error and commit everything until then -> this is termed Partial
Success 3) Continue through the entire request, and note down all the errors

Question: Which ones should we support?

 - Resolution: The general agreement was to support 1) and 2). However, there
 was discussion on 3), which we agreed to not support in the current version.
 David S volunteered to come with an extension (independent of the current
 protocol I-D) for consideration by the team and ascertain interest.

~~~

B) Source based routing and source identity type

Source Based Routing:
 The question was whether we should support this. There was significant
 discussion among the participants ranging from whether routing information
 should be made available to the particular querying organization to the
 relationships between the various entities (e.g., should we have a
 relationship between the destination group to the peer and not just the Route
 Group). We realized a few things, such as:
-  we are missing the ability to associate relationships at an organizational
level in addition to egress and ingress points (which may be fine) - there are
various factors that one may consider beyond the criteria we are speaking
about, such as time of day, IP address etc. - we don't want to control on a
per-organization basis as to which routes can be seen

Resolution: Given the additional complexity this may introduce we decided not
to make any changes to the I-D.

Source Identity Types:
- We reviewed the existing source identity types to see if they were sufficient
or not.

Resolution: Two suggestions were provided: add client certificates as a type,
and figure out a way to make the enumeration extensible.

~~~

C) Synchronous and Asynchronous COR claim

Background:  When the provisioning entity requests the addition of a PI, it can
claim to be the COR. The question is: should we support synchronous and
asynchronous operations? Today it is asynchronous. An example of synchronous
operations is in Section 9.3 of the document titled "sp_example.txt", sent by
Syed via email on on 9/15 (~midnight Eastern time)

Resolution: After much discussion we decided not to support synchronous COR
claims. In addition, Syed will add informative text regarding COR claim
operation to explain this.

AIs: Syed to add informative text regarding COR claim operation (we will only
support asynchronous operations; see discussion below for details).

~~~

D) Bulk Requests
Ken proposed a way to simplify bulk requests where you have a linear set of
requests rather than a gathering of linear requests as is documented in the
submitted version of the I-D. Resolution: We agreed to the changes. In addition
Ken will add informative text to clarify that the order of processing is the
same as the order in the request.

~~~

E) Response Code Structure
- We did not get to discuss this; David to follow-up on the design team calls.

~~~

F) XML Schema
+ We then reviewed the XML Schema and came up with a few recommendations; some
of which are captured here (others were captured by the authors) - Remove
transactional attribute from the 'spppUpdateRequest' element - Modify
'spppb:ObjectResult' to reflect the suggested changes - Associate PI <-> NAPTR
- Re-use well-known data types (AI: Sumanth to send suggestions)

+ We also had some open discussions
- Open numbering plan: Otmar proposed a separate prefix type (see email from
9/15) - Email from:
http://www.ietf.org/mail-archive/web/drinks/current/msg00766.html
  > The main issue is that everywhere in the document, we are free of the
  resolution protocols, except in the case where we use a NAPTR. Why do we need
  it? > Based on the discussions from a few months ago, the reason for NAPTR is
  that it is well understood and implemented > Otmar indicated that a URI type
  cannot be resolved if we stick to just NAPTR

  AI: Otmar to check the discussions on this from a few months ago and re-ask
  the question if the responses do not provide clarity

- Metadata? For example, Security attributes for a phone number, capacity in
the SIP Routing Group. The rank associated with the destination group is
currently in the route record - can we place it on the route group?
   > Resolution: This is out of scope for now

AI: (Alex) Requirements Section

4. Use Cases & Requirements Draft
---------------------------------

Link: http://tools.ietf.org/wg/drinks/draft-ietf-drinks-usecases-requirements/
- We are awaiting feedback from the volunteer reviewers (Jon P, Sohel K)
- Once we get and incorporate comments, we will request WGLC

5. Transport Document
---------------------
Link: http://tools.ietf.org/wg/drinks/draft-ietf-drinks-sppp-over-soap/
- No updates on this document; we briefly discussed that we should make some
progress later in the year to get this done in a timely manner

6. Wrap-up
----------
- Summary of action items; see AI list at the beginning

+ Next steps
- Make the discussed updates (I-D authors) and submit a revision to the
protocol I-D in the next couple of weeks - Prepare for Beijing