[drinks] Notes from the Interim Meeting

Sumanth Channabasappa <sumanth@cablelabs.com> Thu, 07 October 2010 03:27 UTC

Return-Path: <sumanth@cablelabs.com>
X-Original-To: drinks@core3.amsl.com
Delivered-To: drinks@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38FA3A6FB3 for <drinks@core3.amsl.com>; Wed, 6 Oct 2010 20:27:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.194
X-Spam-Level: ***
X-Spam-Status: No, score=3.194 tagged_above=-999 required=5 tests=[AWL=-2.236, BAYES_00=-2.599, FRT_PENIS1=3.592, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MANGLED_PENIS=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYAT8dYuqz+I for <drinks@core3.amsl.com>; Wed, 6 Oct 2010 20:27:39 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id B44AF3A7002 for <Drinks@ietf.org>; Wed, 6 Oct 2010 20:27:38 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o973SdOj022246 for <Drinks@ietf.org>; Wed, 6 Oct 2010 21:28:39 -0600
Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 6 Oct 2010 21:28:39 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com)
Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 6 Oct 2010 21:28:39 -0600
From: Sumanth Channabasappa <sumanth@cablelabs.com>
To: "Drinks@ietf.org" <Drinks@ietf.org>
Date: Wed, 06 Oct 2010 21:28:36 -0600
Thread-Topic: Notes from the Interim Meeting
Thread-Index: Actlz7pWgPrjNX1EQKSQQhpWAR7K1g==
Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D201D8FB3@srvxchg>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F7D201D8FB3srvxchg_"
MIME-Version: 1.0
X-Approved: ondar
Subject: [drinks] Notes from the Interim Meeting
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DRINKS WG <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Oct 2010 03:27:49 -0000

Folks,

Thanks again to everyone who participated in the DRINKS Interim meeting a couple of weeks ago. Please find enclosed the notes below.

- Alex and Sumanth



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