From jf.mule@cablelabs.com Fri May 8 10:56:12 2009 Return-Path: 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 DE2113A68EE for ; Fri, 8 May 2009 10:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.467 X-Spam-Level: X-Spam-Status: No, score=0.467 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 iCJthsolPrGQ for ; Fri, 8 May 2009 10:56:12 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 5A0FD3A6DB9 for ; Fri, 8 May 2009 10:55:51 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n48HvIYb013008; Fri, 8 May 2009 11:57:18 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 8 May 2009 11:57:19 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {8A249D63-7AD8-4D7F-B807-5CFF5D80C4FF} x-cr-hashedpuzzle: Ar+o Bbhy CpKY C1JK DWG7 EYo5 EiM4 EnZD E5Ld IEZ8 ISTA I4kl J64L P6JV SikL S5Xb; 2; ZAByAGkAbgBrAHMALQByAGUAcQAtAHQAZQBhAG0AQABtAGwAaQBzAHQALgBsAGEAYgBzAC4AbgBpAGMALgBhAHQAOwBkAHIAaQBuAGsAcwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {8A249D63-7AD8-4D7F-B807-5CFF5D80C4FF}; agBmAC4AbQB1AGwAZQBAAGMAYQBiAGwAZQBsAGEAYgBzAC4AYwBvAG0A; Fri, 08 May 2009 17:57:09 GMT; VABpAG0AZQBzACAAZgBvAHIAIAByAGUAZwB1AGwAYQByACAAYwBhAGwAbABzACAAZgBvAHIAIABwAHIAbwB0AG8AYwBvAGwAIABkAGUAcwBpAGcAbgAgAHQAZQBhAG0A Content-class: urn:content-classes:message Date: Fri, 8 May 2009 11:57:09 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601C77341@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Times for regular calls for protocol design team Thread-Index: AcnCpEVOIsIIxAKySuy73cbWdh0NfwAAPFiAAWnwJSAB7h/h4A== References: <017701c9c2a5$5cf5ba10$16e12e30$@us> From: "Jean-Francois Mule" To: X-Approved: ondar Cc: drinks-req-team@mlist.labs.nic.at Subject: [drinks] Times for regular calls for protocol design team X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 17:56:13 -0000 HI, Following the last call moderated by Rich, here is a follow-up on my action items. If you are interested in contributing to the protocol dvpts, and can commit time to the protocol design team, please put your name down and vote on the times that work best for you. I've restricted options for now to have a narrower set of options but if this does not work at all for you, send me a private note and I'll see what we can do based on the respondents. http://www.doodle.com/p4xrwastpcizki58 Thanks, Jean-Francois. From jf.mule@cablelabs.com Fri May 15 00:34:09 2009 Return-Path: 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 C15023A6FA9 for ; Fri, 15 May 2009 00:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.277 X-Spam-Level: X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 g6Mqm5iJ2Ym1 for ; Fri, 15 May 2009 00:34:08 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id B55EC3A6C99 for ; Fri, 15 May 2009 00:34:08 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n4F7ZffH006440; Fri, 15 May 2009 01:35:41 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 15 May 2009 01:35:41 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2009 01:35:38 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601C776AE@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Times for regular calls for protocol design team Thread-Index: AcnCpEVOIsIIxAKySuy73cbWdh0NfwAAPFiAAWnwJSAB7h/h4AFKXUjg References: <017701c9c2a5$5cf5ba10$16e12e30$@us> From: "Jean-Francois Mule" To: X-Approved: ondar Cc: drinks-req-team@mlist.labs.nic.at Subject: Re: [drinks] Times for regular calls for protocol design team X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 07:34:09 -0000 The poll is now closed. We will hold regular calls on Thursdays from 3-4pm ET (9-10pm CET) starting 5/21 with the people who responded to the poll (this is our protocol design team). The plan is to progress a protocol document for IETF#75 that meets the current use cases and requirements. We will send meeting notes from the calls to the list so folks can see where we're headed before the Internet-Draft is put together. Jean-Francois > -----Original Message----- > From: Jean-Francois Mule > Sent: Friday, May 08, 2009 11:57 AM > To: drinks@ietf.org > Cc: drinks-req-team@mlist.labs.nic.at > Subject: Times for regular calls for protocol design team >=20 > HI, >=20 > Following the last call moderated by Rich, here is a follow-up > on my action items. >=20 > If you are interested in contributing to the protocol dvpts, and > can commit time to the protocol design team, please put your name > down and vote on the times that work best for you. I've restricted > options for now to have a narrower set of options but if this does > not work at all for you, send me a private note and I'll see what > we can do based on the respondents. >=20 > http://www.doodle.com/p4xrwastpcizki58 >=20 > Thanks, > Jean-Francois. From jf.mule@cablelabs.com Wed May 27 09:50:41 2009 Return-Path: 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 D89AD3A6BD6 for ; Wed, 27 May 2009 09:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] 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 7917XA-0i+VB for ; Wed, 27 May 2009 09:50:40 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 3FBFE3A6452 for ; Wed, 27 May 2009 09:50:40 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n4RGl7ql020049 for ; Wed, 27 May 2009 10:47:07 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 27 May 2009 10:47:07 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9DEEA.C643F3A4" Date: Wed, 27 May 2009 10:46:59 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601C77BB6@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minutes from May 21 protocol design team call Thread-Index: Acne6sDoOZPHzmdfQAO0sBMSNs2nEQ== From: "Jean-Francois Mule" To: X-Approved: ondar Subject: [drinks] Minutes from May 21 protocol design team call X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 16:50:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9DEEA.C643F3A4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ---=20 --- IETF DRINKS WG, protocol design team minutes --- May 21 2009 --- Attendees=20 Richard Shockey Debbie Guyton Ken Cartwright Manjul Maharishi Spencer Dawkins Sumanth Channabasappa Jean-Francois Mule several dogs barking --- Agenda 1/ Introductions and goals for 1st I-D 2/ Use cases and protocol requirements 3/ protocol I-D + scope + outline discussion + transport requirements + data model discussion 4/ Action item summary and next steps. --- Notes=20 Minutes reported by Debbie and Jean-Francois. Call moderated by Jean-Francois. Any comments on these notes should be sent to drinks@ietf.org We will have a weekly call, start with one hour and potentially extend the call to two hours as we have more technical debates and issues to close. 1/ Introductions of design team members and goals for 1st I-D Our main goal is to produce a protocol that meets the requirements and use cases discussed in DRINKS. Our immediate objective is to have a first Internet-Draft by the end of June 2009 (before the cut-off date for the next IETF). Rich indicated that we should continue the work on use cases and requirements in parallel. =20 Rich stated that there is consensus on a SOAP/XML protocol and there is a need to sync with the Application Area folks, especially in the security arena. This is something to keep in mind as progress is made. We discussed the outline for the general approach for developing a protocol document: - protocol capabilities - transport requirements - data model - security We then did a roundtable to get everyone's input on the goals and the approach to make progress. =20 There was general agreement on the approach. =20 The protocol should provide options to extensibility as some people may want to add elements to the data model later on (comment made by several folks).=20 =20 Debbie indicated that in XML-based protocols, it should be easier to add extensibility. Ken used EPP and NETCONF as examples of IETF protocols that lay out the approach to extensibility well and that could be followed. Richard thought that it would be useful to consult the app area AD Lisa Dusseault for input, particularly on security requirements, and perhaps have some discussions with the application ADs to get their input. # Action Item (AI): Jean-Francois before 5/28 # Jean-Francois to ping Lisa to get her on a call with this group # (URL to charter, goals & requirements, minutes of the last meeting # to give her the background). 2/ Use cases and protocol requirements Sumanth suggested that we keep the use cases and requirements doc in sync and volunteered to do so. Everyone agreed that would be good. # AI: Sumanth on a regular basis by sending mails to IETF drinks # list with deltas and proposed changes # Sumanth to keep the use case and requirement documents in sync in # case use cases need to be improved. 3/ Protocol I-D Rich summarized the current wg consensus to use SOAP/XML (in both BoF meetings) and each time we met to discuss that. Rich re-iterated some of the comments he made in previous wg about the lack of EPP implementation for SP for things like DRINKS want to do. Ken added that the protocols like EPP and NETCONF have separated transport from data model/structure definitions of the protocol. Ken recommended we follow the same approach so it gives implementers the option to implement another transport protocol to define new transport. There was general agreement to follow this model. - Scope of this protocol Jean-Francois asked the question of the scope of the protocol.=20 Ken put the emphasis on the data model: it should meet both the needs of the registry-to-registry (provisioning of the registry) and registry to cache server. We had unanimous consensus to do the client to registry protocol definition first. first - client to registry (front-end of provisioning the registry) later - registry to server (which includes registry-to-registry) - Document Outline Ken volunteered to provide a first proposal for our next call based on existing work done on provisioning and config protocols: - RFC 4741 and RFC 4743 define NETCONF, and=20 - RFC 4930 and RFC 4934, EPP and EPP over TCP We agreed to get a draft outline out before our next call based on these examples. This could help speed up things. Spencer commented that it would be good to keep the outline small for now (agreed). # AI: Ken before 5/27 COB # Ken to send a first proposal to the design team via email so we can expedite=20 - Transport requirements # AI: Jean-Francois to send input before 5/27 COB based on previous IETF DRINKS # presentation done in Dublin to the list. # AI: Debbie agreed to review her presentation and list required # features of the protocol for design team discussion. - Data model discussion We had consensus that the data model should belong in the protocol document, at least for now. Manjul volunteered to provide an initial proposal for bashing on the next call. Rich and Sumanth agreed that it would be better to have someone look at it. Rich insisted that we should refrain from adding to much for it. Jean-Francois agreed, we should keep things simple rather than try and be exhaustive. # AI: Manjul to propose a basic data model for team's review on the # next call Rich indicated we should take into account the WG comments about not being too PSTN centric in the data model, a criticism that has been often voiced given the use of PSTN and Routing Numbers in the use cases. - action item summary and next steps. Jean-Francois reviewed the action item list (see above, denoted by AI:). We concluded the call. # AI: Jean-Francois to consolidate his notes with Debbie and send # them to the DRINKS WG list Next call is Thursday May 28, 1pm MT, 3pm ET, and 9pm CET. > end. ------_=_NextPart_001_01C9DEEA.C643F3A4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minutes from May 21 protocol design team call

---
--- IETF DRINKS WG, = protocol design team minutes
--- May 21 = 2009

--- = Attendees
Richard Shockey
Debbie Guyton
Ken Cartwright
Manjul Maharishi
Spencer Dawkins
Sumanth Channabasappa
Jean-Francois Mule
several dogs barking

--- = Agenda
 1/ Introductions and goals for = 1st I-D
 2/ Use cases and protocol requirements
 3/ protocol I-D
   + scope
   + outline discussion
   + transport requirements
   + data model discussion
 4/ Action item summary and next steps.


--- = Notes
Minutes reported by Debbie and = Jean-Francois.
Call moderated by Jean-Francois.
Any comments on these notes should be sent to = drinks@ietf.org

We will have a weekly call, start = with one hour and potentially extend
the call to two hours as we have more technical debates and issues = to
close.


1/ Introductions of = design team members and goals for  1st = I-D
Our main goal is to produce a = protocol that meets the requirements and
use cases discussed in DRINKS.  Our immediate objective is to = have a
first Internet-Draft by the end of June 2009 (before the cut-off = date
for the next IETF).

Rich indicated that we should continue the work on use cases and
requirements in parallel.  

Rich stated that there is consensus on a SOAP/XML protocol and there
is a need to sync with the Application Area folks, especially in the
security arena.  This is something to keep in mind as progress = is
made.

We discussed the outline for the general approach for developing a
protocol document:
  - protocol capabilities
  - transport requirements
  - data model
  - security


We then did a roundtable to get everyone's input on the goals and = the
approach to make progress.  
There was general agreement on the approach.  

The protocol should provide options to extensibility as some people
may want to add elements to the data model later on (comment made by
several folks).
  
Debbie indicated that in XML-based protocols, it should be easier to
add extensibility.  Ken used EPP and NETCONF as examples of = IETF
protocols that lay out the approach to extensibility well and that
could be followed.

Richard thought that it would be useful to consult the app area AD
Lisa Dusseault for input, particularly on security requirements, and
perhaps have some discussions with the application ADs to get their
input.
# Action Item (AI): = Jean-Francois before 5/28
# Jean-Francois to ping = Lisa to get her on a call with this group
# (URL to charter, goals = & requirements, minutes of the last meeting
# to give her the = background).


2/ Use cases and = protocol requirements
Sumanth suggested that we keep the = use cases and requirements doc in
sync and volunteered to do so.  Everyone agreed that would be = good.

# AI:  Sumanth = on a regular basis by sending mails to IETF = drinks
# list with deltas and = proposed changes
# Sumanth to keep the = use case and requirement documents in sync in
# case use cases need to = be improved.

3/ Protocol = I-D
Rich summarized the current wg = consensus to use SOAP/XML (in both BoF
meetings) and each time we met to discuss that. Rich re-iterated = some
of the comments he made in previous wg about the lack of EPP
implementation for SP for things like DRINKS want to do.

Ken added that the protocols like EPP and NETCONF have separated = transport
from data model/structure definitions of the = protocol.  Ken
recommended we follow the same approach so it gives implementers the
option to implement another transport protocol to define new
transport.  There was general agreement to follow this = model.

- Scope of this = protocol
Jean-Francois asked the question of = the scope of the protocol.
Ken put the emphasis on the data model: it should meet both the = needs
of the registry-to-registry (provisioning of the registry) and
registry to cache server.
We had unanimous consensus to do the client to registry protocol
definition first.
   first - client to registry (front-end of provisioning the = registry)
   later - registry to server (which includes = registry-to-registry)


- Document Outline
Ken volunteered to provide a first = proposal for our next call based on
existing work done on provisioning and config protocols:
  - RFC 4741 and RFC 4743 define NETCONF, and
  - RFC 4930 and RFC 4934, EPP and EPP over TCP
We agreed to get a draft outline out before our next call based on
these examples.  This could help speed up things.
Spencer commented that it would be good to keep the outline small = for
now (agreed).
# AI: Ken before 5/27 = COB
# Ken to send a first = proposal to the design team via email so we can = expedite


- = Transport requirements
# AI: Jean-Francois to = send input before 5/27 COB based on previous IETF = DRINKS
# presentation done in = Dublin to the list.

# AI: Debbie agreed to = review her presentation and list required
# features of the = protocol for design team discussion.


- = Data model discussion
We had consensus that the data model = should belong in the protocol
document, at least for now.

Manjul volunteered to provide an initial proposal for bashing on the = next call.
Rich and Sumanth agreed that it would be better to have someone look at = it.
Rich insisted that we should refrain from adding to much for it.
Jean-Francois agreed, we should keep things simple rather than try = and
be exhaustive.

# AI: Manjul to propose = a basic data model for team's review on the
# next = call

Rich indicated we should take into = account the WG comments about not
being too PSTN centric in the data model, a criticism that has been
often voiced given the use of PSTN and Routing Numbers in the use
cases.


- action item summary and next = steps.
Jean-Francois reviewed the action = item list (see above, denoted by
AI:).

We concluded the call.

# AI: Jean-Francois to = consolidate his notes with Debbie and send
# them to the DRINKS WG = list

Next call is Thursday May 28, 1pm = MT, 3pm ET, and 9pm CET.

> end.

------_=_NextPart_001_01C9DEEA.C643F3A4-- From kcartwright@verisign.com Wed May 27 11:14:32 2009 Return-Path: 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 2ED193A712E for ; Wed, 27 May 2009 11:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 xhPc9nZeRTRC for ; Wed, 27 May 2009 11:14:30 -0700 (PDT) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id 27F9D3A6E2D for ; Wed, 27 May 2009 11:14:30 -0700 (PDT) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n4RHm4Jf013042 for ; Wed, 27 May 2009 10:48:04 -0700 Received: from oly1wnexcb02.vcorp.ad.vrsn.com ([10.55.13.57]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 11:16:12 -0700 Received: from OLY1WNEXCB04.vcorp.ad.vrsn.com ([10.55.13.59]) by oly1wnexcb02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 11:16:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9DEF7.36F75666" Date: Wed, 27 May 2009 11:16:11 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks protocol] Candidate RFC Outlines, etc Thread-Index: AcneDrpwX9afXoQeRzKT0WpMPTWYigA6Gh8A From: "Cartwright, Kenneth" To: "IETF DRINKS WG" X-OriginalArrivalTime: 27 May 2009 18:16:11.0405 (UTC) FILETIME=[36C6B3D0:01C9DEF7] Subject: [drinks] FW: [drinks protocol] Candidate RFC Outlines, etc X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 18:14:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9DEF7.36F75666 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Forwarding to the main list. ________________________________ From: Cartwright, Kenneth=20 Sent: Tuesday, May 26, 2009 10:32 AM To: Spencer Dawkins; Guyton, Deborah A; Richard Shockey; Cartwright, Kenneth; Maharishi, Manjul; Sumanth Channabasappa; Alexander Mayrhofer; Jean-Francois Mule Subject: [drinks protocol] Candidate RFC Outlines, etc Per action items from last week's call I'm offering the following items below: =20 1) A few words and proposal for the name(s) of the protocols involved. If we have a name for the two protocols then I think it may be a tad easier to discuss them. 2) The list of the existing RFCs that I looked at as seed data for the two proposed RFC outlines. 3) A proposed high level architectural approach to the protocol, as it is very difficult to propose an RFC outline without also having a high-level architectural approach to the protocol. =20 Btw, is the email recipient list above the correct email list to use? =20 Thanks. Ken. =20 Protocol Names=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 One could propose names for what Rich has accurately referred to as the "Provisioning" Protocol and the "Distribution" Protocol, VPPP and VPDP. VPPP allows provisioning into the VoIP peering "registry", and VPDP allows distribution of the resulting "registry" data views down to the "addressing servers". So, what we are embarking on as our primary focus initially is an instance of a VPPP. This sounds like a minor point, I think getting these two names agreed on adds meaningful clarity and context to what we are all talking about.=20 RegistryClient =3D VPPP Client=20 Registry =3D VPPP Server=20 Registry=3DVPDP Client=20 AddressingServer =3D VPDP Server=20 But onto the primary action item: Protocol Document Outlines and Overall Approach to the Protocol Itself. =20 Protocol Document Outlines and Overall Approach to the Protocol Itself=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 After reviewing the following RFCs and the ESPP document, my thoughts on the protocol approach and specification outline are as follows:=20 RFCs Reviewed as Models:=20 1) 4741 NETCONF Configuration Protocol=20 2) 4743 Using NETCONF over SOAP=20 3) 4930 EPP=20 4) 4931 EPP Domain Name Mapping=20 5) 4934 EPP Over TCP =20 High-Level Protocol Approach/Architecture:=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) Thick vs Thin WSDL: When designing VPPP use a "Generic/Thin WSDL" approach. This is the approach I would take if I were to SOAPify EPP, and is also the approach taken by NETCONF. This approach did not "sell" (was not adopted) when proposed to the ESPP working group I think because it was proposed after others had grown comfortable with the "Thick WSDL" approach.=20 2) Separation of Protocol "Messaging and Transport" and "Protocol Data Structures": Clearly separate, both conceptually and structurally, the specification of the protocol "messaging and transport" from the specification of the protocol data structures. This is the approach that both EPP and NETCONF takes, and seems to be the IETF way (ESPP did not take this approach). I also like how this approach creates some semblance of layering with the resulting flexibility. It also just "sounds smart", :-).=20 3) Extensibility: EPP, NETCONF, and ESPP are all inherently extensible. It is very important that the new protocol also be inherently extensible and we can perhaps take the "best of" approaches used by EPP, NETCONF, and ESPP.=20 =20 Protocol Document Outlines (2 of them):=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >>>>Outline of VPPP Specification:=20 1 Introduction=20 1.1 Protocol Overview=20 1.2 Layering=20 1.3 Data Model=20 1.4 Conventions Used in This Document=20 2 Transport Requirements=20 2.1 Connection Oriented Operation=20 2.2 Authentication=20 2.3 Mandatory Transport=20 2.4 Pipelining=20 3 XML Considerations=20 3.1 Namespaces=20 3.2 Versioning=20 4 Request and Reply Model=20 4.1 Request=20 4.2 Reply=20 4.3 Object Identity=20 4.4 Client/Server Synchronization=20 4.5 Result Codes=20 5 Protocol Commands=20 5.1 "Command 1"=20 5.1.1 Description=20 5.1.2 Example=20 5.1.2 Applicable Result Codes=20 5.2 "Command 2"=20 5.2.1 Description=20 5.2.2 Example=20 5.2.2 Applicable Result Codes=20 6 Security Considerations=20 7 IANA Considerations=20 8 Authors and Acknowledgements=20 9 References=20 9.1 Normative References=20 9.2 Informative References=20 Appendix A Formal Specification - XSD=20 Appendix B Specification Extensibility=20 =20 =20 >>>>Outline of VPPP over SOAP Specification=20 1 Introduction=20 1.1 SOAP Mapping Overview=20 1.2 Conventions Uses in This Document=20 2 SOAP Usage=20 2.1 Background=20 2.2 SOAP Repository/URL=20 2.3 SOAP over HTTP Transport=20 2.4 SOAP Headers=20 2.5 Session Management=20 3 SOAP VPPP Message Exchange=20 3.6.1 Description=20 3.6.1 Example=20 4 Security Considerations=20 5 IANA Considerations=20 6 Authors and Acknowledgements=20 7 References=20 7.1 Normative References=20 7.2 Informative References=20 Appendix A Formal Specification - WSDL=20 =20 ------_=_NextPart_001_01C9DEF7.36F75666 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Forwarding to the main = list.

From: Cartwright, Kenneth =
Sent:=20 Tuesday, May 26, 2009 10:32 AM
To: Spencer Dawkins; Guyton, = Deborah A;=20 Richard Shockey; Cartwright, Kenneth; Maharishi, Manjul; Sumanth = Channabasappa;=20 Alexander Mayrhofer; Jean-Francois Mule
Subject: [drinks = protocol]=20 Candidate RFC Outlines, etc

Per action items from last week's call = I'm=20 offering the following items below:

 

1) A few words and proposal for the name(s) = of the=20 protocols involved.  If we have a name for the two protocols then I = think=20 it may be a tad easier to discuss them.

2) The list of the existing RFCs that I = looked at as=20 seed data for the two proposed RFC outlines.

3) A proposed high level architectural = approach to the=20 protocol, as it is very difficult to propose an RFC outline without also = having=20 a high-level architectural approach to the protocol.

 

Btw, is the email recipient list above the = correct=20 email list to use?

 

Thanks.

Ken.

 

Protocol = Names

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

One could propose names for what Rich has = accurately=20 referred to as the "Provisioning" Protocol and the "Distribution" = Protocol, VPPP=20 and VPDP.  VPPP allows provisioning into the VoIP peering "registry", and = VPDP=20 allows distribution of the resulting "registry" data views down to the "addressing servers". So, what we are embarking = on as our primary focus initially is an = instance of=20 a VPPP. This sounds like a minor point, I think getting these two names = agreed=20 on adds meaningful clarity and=20 context to what we are all talking about.

RegistryClient =3D=20 VPPP Client

Registry =3D=20 VPPP Server

Registry=3DVPDP Client

AddressingServer =3D=20 VPDP Server

But onto the = primary action=20 item: Protocol Document Outlines and Overall Approach to the Protocol=20 Itself.

 

Protocol Document = Outlines=20 and Overall Approach to the Protocol Itself

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

After reviewing = the=20 following RFCs and the ESPP document, my thoughts on the protocol = approach and=20 specification outline are as=20 follows:

RFCs Reviewed as=20 Models:

1) 4741 NETCONF=20 Configuration Protocol =

2) 4743 Using = NETCONF over=20 SOAP

3) 4930 = EPP

4) 4931 EPP Domain = Name=20 Mapping

5) 4934 EPP Over=20 TCP

 

High-Level Protocol Approach/Architecture:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

1) Thick vs Thin = WSDL: When=20 designing VPPP use a = "Generic/Thin=20 WSDL" approach. This is the approach I would take if I were to SOAPify = EPP, and=20 is also the approach taken by NETCONF. This approach did not "sell" (was not adopted) when proposed to the = ESPP=20 working group I think because it=20 was proposed after others had grown comfortable with the = "Thick=20 WSDL" approach. =

2) Separation of = Protocol=20 "Messaging and Transport" and "Protocol Data Structures": Clearly = separate, both=20 conceptually and structurally, the specification of the protocol = "messaging and=20 transport" from the specification of the protocol data structures. This = is the=20 approach that both EPP and NETCONF takes, and seems to be the IETF = way (ESPP did not take this approach). I = also like=20 how this approach creates some semblance of layering with the resulting=20 flexibility. It also just "sounds smart", :-).

3) = Extensibility: EPP, NETCONF, and ESPP are all = inherently=20 extensible. It is very important = that the=20 new protocol also be inherently extensible and we can perhaps take the = "best of"=20 approaches used by EPP, NETCONF, and ESPP.

 

Protocol Document = Outlines=20 (2 of them):

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 

>>>>Outline of=20 VPPP Specification: =

1 = Introduction

1.1 Protocol=20 Overview

1.2 = Layering

1.3 Data = Model

1.4 Conventions = Used in This=20 Document

2 Transport=20 Requirements

2.1 Connection = Oriented=20 Operation

2.2=20 Authentication =

2.3 Mandatory=20 Transport

2.4 = Pipelining

3 XML=20 Considerations =

3.1 = Namespaces

3.2 = Versioning

4 Request and = Reply=20 Model

4.1 = Request

4.2 = Reply

4.3 Object=20 Identity

4.4 Client/Server=20 Synchronization =

4.5 Result = Codes

5 Protocol=20 Commands

5.1 "Command = 1"

5.1.1=20 Description

5.1.2 = Example

5.1.2 Applicable = Result=20 Codes

5.2 "Command = 2"

5.2.1=20 Description

5.2.2 = Example

5.2.2 Applicable = Result=20 Codes

6 Security=20 Considerations =

7 IANA=20 Considerations =

8 Authors and=20 Acknowledgements =

9 = References

9.1 Normative=20 References

9.2 Informative=20 References

Appendix A Formal=20 Specification - XSD =

Appendix B = Specification=20 Extensibility

 

 

>>>>Outline of=20 VPPP over SOAP Specification=20

1 = Introduction

1.1 SOAP Mapping=20 Overview

1.2 Conventions = Uses in This=20 Document

2 SOAP = Usage

2.1 = Background

2.2 SOAP=20 Repository/URL =

2.3 SOAP over HTTP = Transport

2.4 SOAP = Headers

2.5 Session=20 Management

3 SOAP VPPP = Message=20 Exchange

3.6.1=20 Description

3.6.1 = Example

4 Security=20 Considerations =

5 IANA=20 Considerations =

6 Authors and=20 Acknowledgements =

7 = References

7.1 Normative=20 References

7.2 Informative=20 References

Appendix A Formal=20 Specification - WSDL =

 

------_=_NextPart_001_01C9DEF7.36F75666-- From richard@shockey.us Wed May 27 15:00:28 2009 Return-Path: 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 788FB3A67EB for ; Wed, 27 May 2009 15:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 ULOS0jMuf1Lu for ; Wed, 27 May 2009 15:00:26 -0700 (PDT) Received: from outbound-mail-147.bluehost.com (outbound-mail-147.bluehost.com [67.222.38.37]) by core3.amsl.com (Postfix) with SMTP id 396573A6F2B for ; Wed, 27 May 2009 15:00:23 -0700 (PDT) Received: (qmail 25821 invoked by uid 0); 27 May 2009 21:55:26 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 27 May 2009 21:55:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=VosRUcTqtA7uygOtHQwZL3TGATz2iuQm6VB+5DSJ2ks+OWeEJ3vi7axOlgO6fZXbcU1KYoOzNhHfw7xQRThte8Av7OBJuMq/sLkPqLtHvDb+5DtR9MbYYmQs5goMC9Wc; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1M9R5p-0005gD-HF; Wed, 27 May 2009 15:55:26 -0600 From: "Richard Shockey" To: "'Jean-Francois Mule'" , References: <9AAEDF491EF7CA48AB587781B8F5D7C601C77BB6@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C601C77BB6@srvxchg3.cablelabs.com> Date: Wed, 27 May 2009 17:55:09 -0400 Message-ID: <024801c9df15$ced0afa0$6c720ee0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0249_01C9DEF4.47BF0FA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acne6sDoOZPHzmdfQAO0sBMSNs2nEQAKmKCg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: Re: [drinks] Minutes from May 21 protocol design team call X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 22:00:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0249_01C9DEF4.47BF0FA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit For the record the dogs were Molly, Hobbs and Zoe, all rescue Dalmatians. They may wish to participate in the future design team discussions, especially when barking is involved. We certainly know there is a fair amount of barking in the IETF. From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Jean-Francois Mule Sent: Wednesday, May 27, 2009 12:47 PM To: drinks@ietf.org Subject: [drinks] Minutes from May 21 protocol design team call --- --- IETF DRINKS WG, protocol design team minutes --- May 21 2009 --- Attendees Richard Shockey Debbie Guyton Ken Cartwright Manjul Maharishi Spencer Dawkins Sumanth Channabasappa Jean-Francois Mule several dogs barking --- Agenda 1/ Introductions and goals for 1st I-D 2/ Use cases and protocol requirements 3/ protocol I-D + scope + outline discussion + transport requirements + data model discussion 4/ Action item summary and next steps. --- Notes Minutes reported by Debbie and Jean-Francois. Call moderated by Jean-Francois. Any comments on these notes should be sent to drinks@ietf.org We will have a weekly call, start with one hour and potentially extend the call to two hours as we have more technical debates and issues to close. 1/ Introductions of design team members and goals for 1st I-D Our main goal is to produce a protocol that meets the requirements and use cases discussed in DRINKS. Our immediate objective is to have a first Internet-Draft by the end of June 2009 (before the cut-off date for the next IETF). Rich indicated that we should continue the work on use cases and requirements in parallel. Rich stated that there is consensus on a SOAP/XML protocol and there is a need to sync with the Application Area folks, especially in the security arena. This is something to keep in mind as progress is made. We discussed the outline for the general approach for developing a protocol document: - protocol capabilities - transport requirements - data model - security We then did a roundtable to get everyone's input on the goals and the approach to make progress. There was general agreement on the approach. The protocol should provide options to extensibility as some people may want to add elements to the data model later on (comment made by several folks). Debbie indicated that in XML-based protocols, it should be easier to add extensibility. Ken used EPP and NETCONF as examples of IETF protocols that lay out the approach to extensibility well and that could be followed. Richard thought that it would be useful to consult the app area AD Lisa Dusseault for input, particularly on security requirements, and perhaps have some discussions with the application ADs to get their input. # Action Item (AI): Jean-Francois before 5/28 # Jean-Francois to ping Lisa to get her on a call with this group # (URL to charter, goals & requirements, minutes of the last meeting # to give her the background). 2/ Use cases and protocol requirements Sumanth suggested that we keep the use cases and requirements doc in sync and volunteered to do so. Everyone agreed that would be good. # AI: Sumanth on a regular basis by sending mails to IETF drinks # list with deltas and proposed changes # Sumanth to keep the use case and requirement documents in sync in # case use cases need to be improved. 3/ Protocol I-D Rich summarized the current wg consensus to use SOAP/XML (in both BoF meetings) and each time we met to discuss that. Rich re-iterated some of the comments he made in previous wg about the lack of EPP implementation for SP for things like DRINKS want to do. Ken added that the protocols like EPP and NETCONF have separated transport from data model/structure definitions of the protocol. Ken recommended we follow the same approach so it gives implementers the option to implement another transport protocol to define new transport. There was general agreement to follow this model. - Scope of this protocol Jean-Francois asked the question of the scope of the protocol. Ken put the emphasis on the data model: it should meet both the needs of the registry-to-registry (provisioning of the registry) and registry to cache server. We had unanimous consensus to do the client to registry protocol definition first. first - client to registry (front-end of provisioning the registry) later - registry to server (which includes registry-to-registry) - Document Outline Ken volunteered to provide a first proposal for our next call based on existing work done on provisioning and config protocols: - RFC 4741 and RFC 4743 define NETCONF, and - RFC 4930 and RFC 4934, EPP and EPP over TCP We agreed to get a draft outline out before our next call based on these examples. This could help speed up things. Spencer commented that it would be good to keep the outline small for now (agreed). # AI: Ken before 5/27 COB # Ken to send a first proposal to the design team via email so we can expedite - Transport requirements # AI: Jean-Francois to send input before 5/27 COB based on previous IETF DRINKS # presentation done in Dublin to the list. # AI: Debbie agreed to review her presentation and list required # features of the protocol for design team discussion. - Data model discussion We had consensus that the data model should belong in the protocol document, at least for now. Manjul volunteered to provide an initial proposal for bashing on the next call. Rich and Sumanth agreed that it would be better to have someone look at it. Rich insisted that we should refrain from adding to much for it. Jean-Francois agreed, we should keep things simple rather than try and be exhaustive. # AI: Manjul to propose a basic data model for team's review on the # next call Rich indicated we should take into account the WG comments about not being too PSTN centric in the data model, a criticism that has been often voiced given the use of PSTN and Routing Numbers in the use cases. - action item summary and next steps. Jean-Francois reviewed the action item list (see above, denoted by AI:). We concluded the call. # AI: Jean-Francois to consolidate his notes with Debbie and send # them to the DRINKS WG list Next call is Thursday May 28, 1pm MT, 3pm ET, and 9pm CET. > end. ------=_NextPart_000_0249_01C9DEF4.47BF0FA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minutes from May 21 protocol design team call

For the record the dogs were Molly, Hobbs and Zoe, all = rescue Dalmatians.

 

They may wish to participate in the future design team = discussions, especially when barking is involved.  

 

We certainly know there is a fair amount of barking in = the IETF.

 

From:= drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of = Jean-Francois Mule
Sent: Wednesday, May 27, 2009 12:47 PM
To: drinks@ietf.org
Subject: [drinks] Minutes from May 21 protocol design team = call

 

---
--- IETF DRINKS WG, protocol design team minutes
--- May 21 2009

--- Attendees
Richard = Shockey
Debbie Guyton
Ken Cartwright
Manjul Maharishi
Spencer Dawkins
Sumanth Channabasappa
Jean-Francois Mule
several dogs barking

--- Agenda
 1/ = Introductions and goals for 1st I-D
 2/ Use cases and protocol requirements
 3/ protocol I-D
   + scope
   + outline discussion
   + transport requirements
   + data model discussion
 4/ Action item summary and next steps.


--- Notes
Minutes = reported by Debbie and Jean-Francois.
Call moderated by Jean-Francois.
Any comments on these notes should be sent to drinks@ietf.org

We will have = a weekly call, start with one hour and potentially extend
the call to two hours as we have more technical debates and issues = to
close.


1/ Introductions of design team members = and goals for  1st I-D
Our main goal = is to produce a protocol that meets the requirements and
use cases discussed in DRINKS.  Our immediate objective is to = have a
first Internet-Draft by the end of June 2009 (before the cut-off = date
for the next IETF).

Rich indicated that we should continue the work on use cases and
requirements in parallel.  

Rich stated that there is consensus on a SOAP/XML protocol and there
is a need to sync with the Application Area folks, especially in the
security arena.  This is something to keep in mind as progress = is
made.

We discussed the outline for the general approach for developing a
protocol document:
  - protocol capabilities
  - transport requirements
  - data model
  - security


We then did a roundtable to get everyone's input on the goals and = the
approach to make progress.  
There was general agreement on the approach.  

The protocol should provide options to extensibility as some people
may want to add elements to the data model later on (comment made by
several folks).
  
Debbie indicated that in XML-based protocols, it should be easier to
add extensibility.  Ken used EPP and NETCONF as examples of = IETF
protocols that lay out the approach to extensibility well and that
could be followed.

Richard thought that it would be useful to consult the app area AD
Lisa Dusseault for input, particularly on security requirements, and
perhaps have some discussions with the application ADs to get their
input.
# Action Item (AI): Jean-Francois = before 5/28
# Jean-Francois to ping Lisa to get her on a call with this = group
# (URL to charter, goals & requirements, minutes of the last = meeting
# to give her the background).


2/ Use cases and protocol requirements
Sumanth = suggested that we keep the use cases and requirements doc in
sync and volunteered to do so.  Everyone agreed that would be = good.

# AI:  Sumanth on a regular = basis by sending mails to IETF drinks
# list with deltas and proposed changes
# Sumanth to keep the use case and requirement documents in sync = in
# case use cases need to be improved.

3/ Protocol I-D
Rich = summarized the current wg consensus to use SOAP/XML (in both BoF
meetings) and each time we met to discuss that. Rich re-iterated = some
of the comments he made in previous wg about the lack of EPP
implementation for SP for things like DRINKS want to do.

Ken added that the protocols like EPP and NETCONF have separated = transport
from data model/structure definitions of the = protocol.  Ken
recommended we follow the same approach so it gives implementers the
option to implement another transport protocol to define new
transport.  There was general agreement to follow this = model.

- Scope of this protocol
Jean-Francois = asked the question of the scope of the protocol.
Ken put the emphasis on the data model: it should meet both the = needs
of the registry-to-registry (provisioning of the registry) and
registry to cache server.
We had unanimous consensus to do the client to registry protocol
definition first.
   first - client to registry (front-end of provisioning the registry)
   later - registry to server (which includes = registry-to-registry)


- Document Outline
Ken = volunteered to provide a first proposal for our next call based on
existing work done on provisioning and config protocols:
  - RFC 4741 and RFC 4743 define NETCONF, and
  - RFC 4930 and RFC 4934, EPP and EPP over TCP
We agreed to get a draft outline out before our next call based on
these examples.  This could help speed up things.
Spencer commented that it would be good to keep the outline small = for
now (agreed).
# AI: Ken before 5/27 = COB
# Ken to send a first proposal to the design team via email so we can = expedite


- Transport requirements
# AI: Jean-Francois to send input before 5/27 COB based on previous IETF = DRINKS
# presentation done in Dublin to the list.

# AI: Debbie agreed to review her presentation and list = required
# features of the protocol for design team discussion.


- Data model discussion
We had = consensus that the data model should belong in the protocol
document, at least for now.

Manjul volunteered to provide an initial proposal for bashing on the = next call.
Rich and Sumanth agreed that it would be better to have someone look at = it.
Rich insisted that we should refrain from adding to much for it.
Jean-Francois agreed, we should keep things simple rather than try = and
be exhaustive.

# AI: Manjul to propose a basic data = model for team's review on the
# next call

Rich = indicated we should take into account the WG comments about not
being too PSTN centric in the data model, a criticism that has been
often voiced given the use of PSTN and Routing Numbers in the use
cases.


- action item summary and next = steps.
Jean-Francois = reviewed the action item list (see above, denoted by
AI:).

We concluded the call.

# AI: Jean-Francois to consolidate his = notes with Debbie and send
# them to the DRINKS WG list

Next call is = Thursday May 28, 1pm MT, 3pm ET, and 9pm CET.

> end.

------=_NextPart_000_0249_01C9DEF4.47BF0FA0--