From sumanth@cablelabs.com Wed Dec 14 08:10:35 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BFE21F8BFE for ; Wed, 14 Dec 2011 08:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foVuS1OQLpDr for ; Wed, 14 Dec 2011 08:10:12 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 44EC621F8BBB for ; Wed, 14 Dec 2011 08:10:04 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id pBEGA3nf003655 for ; Wed, 14 Dec 2011 09:10:03 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 14 Dec 2011 09:10:03 -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, 14 Dec 2011 09:10:03 -0700 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Wed, 14 Dec 2011 09:10:01 -0700 Thread-Topic: Notes from Taipei Thread-Index: Acy6ep46IZgt+mUlSzqjFzxE1uuFhw== Message-ID: <76AC5FEF83F1E64491446437EA81A61F81DE3E2CDF@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Notes from Taipei X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 16:10:35 -0000 Folks, The draft notes from Taipei have been posted at: http://www.ietf.org/procee= dings/82/minutes/drinks.txt =20 Please feel free to provide any comments or corrections to this list. I hav= e also reproduced the notes below for your convenience. Thanks! - S DRINKS WG meeting - FRIDAY, Nov 18, 2011, 1120-1210pm =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 WG Chairs: - Alexander Mayrhofer - Sumanth Channabasappa Area Directors: =09 - Gonzalo Camarillo - Robert Sparks =20 Mailing List - Address: drinks@ietf.org - To Subscribe: https://www.ietf.org/mailman/listinfo/drinks - Archive: http://www.ietf.org/mail-archive/web/drinks/ Jabber Chat: - Room Address: xmpp:drinks@jabber.ietf.org - Logs: http://jabber.ietf.org/logs/drinks/ =20 Summary of AIs: -------------- - [I-D Authors] Complete the remaining changes as illustrated (e.g., editor= ial nits, further comments) - [Alex] Assist with the completion of the Internationalization considerati= ons - [WG Chairs] Modify the WG timelines - [WG Chairs] Establish an interim meeting - [Design Team] Consider using the IETF issue tracker, if useful - [WG] Decide on the nomenclature for the WG documents 1) Welcome and Administrivia (Presenter: Alex) - Alex presented the Note Well, and the agenda - Scribes were identified: Sumanth (note taker and Jabber scribe)=20 - Alex presented the Note Well and administrivia 2) WG status review (Presenter: Alex) Link: http://www.ietf.org/proceedings/82/slides/drinks-0.ppt=20 - No changes to the scope of the work - The use cases document is at a late stage within the IESG, pending one= comment around security considerations - We reworked the protocol and transport documents, based on discussions= at the interim meeting=20 - We also responded to a liaison statement from the ITU regarding the Gl= obal SPID, where we asked them to follow the work going on in DISPATCH 3) Discussions at the Interim and current action items (Presenter: Sumanth) Link: http://www.ietf.org/proceedings/82/slides/drinks-1.ppt=20 =20 - The last interim meeting was held on Aug 31, 2011 - We saw a demo of OpenSPPP (demonstrating running code), and we discuss= ed the protocol and transport I-Ds - However there was a recommendation to change the document split betwee= n the protocol and transport docs to make it even more generic to support a= dditional mechanisms, such as RESTful Web Services. - We then discussed what this split would look like and recommended the = following: > Protocol document to contain object definitions; and the normative r= equirements around operations, response codes and object identity > Concrete representations of operations, responses and object identit= y to go into the transport document - The latest updates reflect these changes - The chairs asked if there were any objections to this split, and proce= eding as indicated? > No objections were noted from the room;=20 4) Protocol document (Presenter: Syed; on behalf of the authors) Link to presentation: http://www.ietf.org/proceedings/82/slides/drinks-2= .pptx Link to I-D: http://tools.ietf.org/id/draft-ietf-drinks-spprov/ - Syed presented an overview of the all the changes that have been made,= primarily to accommodate the change in the split as discussed in agenda it= em #3 - In addition, he indicated the additional topics that are still TBD, mo= st notably support for internationalization=20 > There was quite a bit of discussion around this; Pete Resnick attend= ed as an expert advisor=20 > See email from Alex on 11/17 (http://www.ietf.org/mail-archive/web/d= rinks/current/msg01070.html)=20 > Discussions at the meeting revolved around whether we want to make t= he identifiers case sensitive or case insensitive=20 =3D Ken, Alex and Dean indicated that case insensitive would be pre= ferred =3D Pete explained some potential issues/surprises around this (e.g= ., if we type ASCII on a Japanese Keyboard, then it may not be ASCII). =20 =3D If you normalize (something like NFC), and you have a particula= r encoding (likely/hopefully UTF-8), then you can do octet-by-octet compari= son and do reasonably well, but there are still edge cases where users woul= d be "surprised" that certain things don't match. =3D Different scenarios provide different surprises. You can also u= se NFKC > In summary, there was no decision on this. Alex will follow-up with = the WG to make a recommendation 5) Transport document (Presenter: Syed; on behalf of Ken) Link to presentation: http://www.ietf.org/proceedings/82/slides/drinks-3= .pptx Link to I-D: http://tools.ietf.org/id/draft-ietf-drinks-sppp-over-soap/ =20 - The presentation contained a summary of the changes that have been mad= e, based on the change in direction - No specific concerns were noted 6) Proposed next steps (Presenters: Chairs) Link: http://www.ietf.org/proceedings/82/slides/drinks-4.ppt =20 - Three main items were discussed - 1) Nomenclature to reflect the split > "SPP Framework" instead of "SPP Protocol"? > "SPP Protocol over SOAP" instead of "SPPP over SOAP over HTTP"? =20 =3D There was general agreement =20 - 2) I-D completion timelines > The WG chairs proposed a revised completion timeline, Jan for protoc= ol and Feb for transport > There was a recommendation to move them by a month (Ken, Dean) > The WG chairs will reflect this change =20 - 3) Interim meeting > The chairs proposed a virtual interim in the January timeframe > The WG was OK with this; chairs to follow-up 7) Open Mic Time - Sumanth (as the use cases I-D editor) asked for feedback around securit= y considerations; specifically to say: OLD: =20 " A provisioning protocol or interface that implements the described us= e cases MUST therefore provide data confidentiality, and MUST ensure messag= e integrity for the provisioning flow. Authentication and authorization of= the provisioning entities are REQUIRED features of the protocol and interf= aces." NEW: " A provisioning framework or protocol that implements the described use c= ases MUST therefore provide data confidentiality and message integrity. Su= ch frameworks and protocols MUST specify mechanisms to authenticate and aut= horize any entity that provisions data into the registry, i.e., that the en= tity is who it says it is, and is allowed to use the provisioning interface= . The determination of whether such an entity is authorized to provision sp= ecific data elements (e.g., a certain public identifier or TN Range) - whil= e REQUIRED - may be left to local policy." =20 > There were no objections to this =20 - Syed proposed that we use the IETF issue tracker > Alex indicated that this works well, and we can decide to use it, if = we all agree. =20 From sumanth@cablelabs.com Wed Dec 14 08:13:03 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF5A21F8C04 for ; Wed, 14 Dec 2011 08:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwaaH9fmzNAm for ; Wed, 14 Dec 2011 08:13:02 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 26A2521F8AF5 for ; Wed, 14 Dec 2011 08:13:02 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id pBEGD1Pk003950 for ; Wed, 14 Dec 2011 09:13:01 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 14 Dec 2011 09:13:01 -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, 14 Dec 2011 09:13:01 -0700 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Wed, 14 Dec 2011 09:12:59 -0700 Thread-Topic: Rough notes and AI list from the design team call on 12/14 Thread-Index: Acy6eyx/l3uaC4eJQP2KnLqcfi6H0w== Message-ID: <76AC5FEF83F1E64491446437EA81A61F81DE3E2CE0@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Rough notes and AI list from the design team call on 12/14 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 16:13:03 -0000 IETF DRINKS DESIGN TEAM CALL=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 12/14/2011, 10:00a-10:45a (Eastern)/8:00a-8:45a (Mountain) =20 Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Alexander Mayrhofer - Vikas Bhatia - Manjul Maharishi - Ken Cartwright - Syed Ali - Sumanth Channabasappa=20 ACTION ITEMS UPDATE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - [I-D Authors] Complete the remaining changes as illustrated (e.g., editor= ial nits, further comments) - [Alex] Assist with the completion of the Internationalization considerati= ons - [WG Chairs] Modify the WG timelines - [WG Chairs] Establish an interim meeting - [Design Team] Consider using the IETF issue tracker, if useful - [WG] Decide on the nomenclature for the WG documents Also... - [WG, Chairs] Consider Vikas as one of the authors of the I-D, given his s= ignificant contributions to the recent revisions=20 AGENDA =3D=3D=3D=3D=3D=3D 1. Discuss Taipei, and follow-up action items 2. Plan for the interim meeting 3. Others NOTES =3D=3D=3D=3D=3D 1. Discuss Taipei, and follow-up action items - Sumanth presented the draft notes; no additional comments - We extracted the action items (see above) - We had some discussions regarding the need for the IETF issue tracker > There were questions around usefulness at this time, with Alex and S= yed indicating that it may be useful > Sumanth recommended that we first collect the comments and issues an= d then make a decision on this, the design team agreed 2. Plan for the interim meeting - We discussed when we can have review comments; based on outages in Dec= ember we decided that we can have them by Jan 13th > Alex, Vikas and Syed indicated that they may have some time during t= his month and will try to present their comments > The rest of the design team will be out, and plans to have comments = in early-Jan > Based on all the discussions, we decided on the following dates: Jan 13 - all comments due on the current I-D versions; we then make = a decision on the issue tracker Jan 27 - authors to present updates Feb 1 - recommended date for the interim 3. Others + Internationalization - Alex raised the internationalization and we had some discussion arou= nd case sensitive or case insensitive usage - The inclination from the team was to keep identifiers case insensiti= ve - On the question of SIP URIs, Alex mentioned that there are probably = requirements already in place - In terms of next steps Alex will take a look at the internationaliza= tion requirements within DNS, and propose specific text + Addition of a new author - Ken recommended that, given significant recent contributions and ong= oing involvement, Vikas be considered as an author for the WG documents - WG Chairs find this reasonable and will consider this request during= the next set of updates From alexander.mayrhofer@nic.at Thu Dec 15 23:40:16 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373A221F84B9 for ; Thu, 15 Dec 2011 23:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F3D-nEK18k3 for ; Thu, 15 Dec 2011 23:40:15 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id D6E0021F84B4 for ; Thu, 15 Dec 2011 23:40:14 -0800 (PST) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Fri, 16 Dec 2011 08:40:12 +0100 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.1.355.2; Fri, 16 Dec 2011 08:40:06 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 16 Dec 2011 08:40:01 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B3672B0@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Logistics: Plan for Virtual Interim Thread-Index: Acy7xUFNSkix1bO0SKGpbSj/NeY7VA== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Cc: drinks-chairs@tools.ietf.org Subject: [drinks] Logistics: Plan for Virtual Interim X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 07:40:16 -0000 All, in the last design team call held this Wednesday, the team indicated that it would be useful to hold an Virtual Interim Meeting early next year. This meeting would be used to perform work on the remaining two documents, and get them "fit" for working group last call. We're currently looking at holding the meeting on=20 Wed, February 1st 2012, 9am - 1pm Eastern (this would also allow european participants to attend the meeting). I've set up a doodle poll to record whether people would be available or not, please indicate your availability here: http://www.doodle.com/qza66x4yxue873hg (Please only cast your vote if you're interested in attending the meeting at all ;) thanks, Alex & Sumanth From vbhatia@tnsi.com Thu Dec 29 10:56:22 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0510621F8B61 for ; Thu, 29 Dec 2011 10:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eydOnK6kZ1Ic for ; Thu, 29 Dec 2011 10:56:21 -0800 (PST) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 228DB21F8B5D for ; Thu, 29 Dec 2011 10:56:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQAAJy3/E6sEQfn/2dsb2JhbABDnAiRaYFyAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAQEEARIIh3q1WwSLLGMEiDefHQ X-IronPort-AV: E=Sophos;i="4.71,428,1320624000"; d="scan'208";a="688656" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 29 Dec 2011 18:56:09 +0000 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 29 Dec 2011 13:56:09 -0500 From: "Bhatia, Vikas" To: Dean Willis , "drinks@ietf.org" Date: Thu, 29 Dec 2011 13:56:08 -0500 Thread-Topic: [drinks] Thoughts on sppp-over-soap-06 Thread-Index: AcyfMfH/yq1wPil7SIm6BxozFAm5SAmUyv3w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [drinks] Thoughts on sppp-over-soap-06 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 18:56:22 -0000 Please see comments below. > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf > Of Dean Willis > Sent: Wednesday, November 09, 2011 5:50 PM > To: drinks@ietf.org > Subject: [drinks] Thoughts on sppp-over-soap-06 > > I really like the new approach to splitting generic and implementation > protocols. This is looking good. > > > > In 3. SOAP Features and Protocol Layering we have a sentence that > doesn't parse for me: > > Orig: > > It is characterized by setting the soapAction binding style as > _document_, the soapAction encoding style as _literal_, and then > defining the SOAP messages to simply contain a single data element > that _wraps_ that is a data structure containing all the required > input or output data elements. > > Is this the same as: > > It is characterized by setting the soapAction binding style as > _document_, the soapAction encoding style as _literal_, and then > defining the SOAP messages to simply contain a single data element > that _wraps_ a data structure containing all the required input or > output data elements. > > (I took out a "that is" that seemed superfluous, after _wraps_). [VB:] This was rectified in latest version (7) of the document. > > One general worry point is that we sometimes refer to "SPPP" behavior, > when we're talking about "SPPP over SOAP". This is evident in the > general description under section 6, which implies that the > SOAP-specific wrapping is an aspect of SPPP, whereas it's really tied > to our implementation of SPPP using SOAP. Could we call this > SPPP/SOAP? If so, a simple search-replace operation could fix section > 6, and probably most of the following text. [VB:] Valid comment. There should be some consistency when referring to SPP= P over SOAP. Like currently it is also being referred to as "SPPP SOAP mapp= ing" at one place. We can change this in the next rev of the document. > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From vbhatia@tnsi.com Fri Dec 30 11:20:50 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B4A21F84DA for ; Fri, 30 Dec 2011 11:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=-1.222, BAYES_00=-2.599, SARE_SUB_MULTI_PRN2=1.66, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCz+QWU6mYPm for ; Fri, 30 Dec 2011 11:20:49 -0800 (PST) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE9321F84BC for ; Fri, 30 Dec 2011 11:20:48 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEAAOMN/k6sEQfn/2dsb2JhbABDnBORQYFyAQEBBAEBATctBxcEAgEIEQQBAQsUCQcnCxQJCAEBBAESCId6tU0EglWIV2MEiDefHQ X-IronPort-AV: E=Sophos;i="4.71,433,1320624000"; d="scan'208";a="694124" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 30 Dec 2011 19:20:45 +0000 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 30 Dec 2011 14:20:45 -0500 From: "Bhatia, Vikas" To: Dean Willis , "drinks@ietf.org" Date: Fri, 30 Dec 2011 14:20:42 -0500 Thread-Topic: [drinks] A little more on spprov-11 request-response model and spppUpdateResponse Thread-Index: AcyfNP5DHxy3GZgbRP+afXprGI+UHgn0Qz8w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [drinks] A little more on spprov-11 request-response model and spppUpdateResponse X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 19:20:50 -0000 Please see comments inline below. > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf > Of Dean Willis > Sent: Wednesday, November 09, 2011 6:12 PM > To: drinks@ietf.org > Subject: [drinks] A little more on spprov-11 request-response model and > spppUpdateResponse > > o corInfo: corInfo is an optional parameter of type CORInfoType > that allows the registrant organization to set forth a claim to > be the carrier-of-record (see [RFC5067]). This is done by > setting the value of element of the CORInfoType > > > Previously, we assumed that a request-response model consistent with > SOAP. SOAP allows us to return a structured type that includes a lot > of information. This assumption is illustrated in section 4.2 Request > and Response Model in the spprov-11 draft: > > 4.2. Request and Response Model > > Provisioning operations in SPPP follow the request-response model, > where a client sends a request message to initiate a transaction and > the server responds with a response. Multiple subsequent request- > response exchanges MAY be performed over a single persistent > connection. > > Therefore, a transport protocol for SPPP MUST follow the request- > response model by allowing a response to be sent to the request > initiator. > > > One of the challenges in re-layering the specification is that some > potentially interesting protocol bindings (such as RESTful HTTP) use a > different response paradigm. REST, in particular, suggests that the > response code set by mapped onto the relatively small set of HTTP > responses, although some transactions (notably query or "GET" > transactions) can obviously return a large amount of structured data. > So this is particularly of concern on write/update transactions, > ("PUT", "POST", "DELETE"). > > So this means that we can't always return a structured type like the > "spppUpdateResponse". It's just something that a non-SOAP binding is > going to have to find an appropriate way to do. > > However, the current spprov-11 draft retains a few references to > "spppUpdateResponse" that still need to be cleaned out. Specifically, > I noted references in section 6.3 Route Group (right at the end) that > can probably just be deleted. > > There's also some discussion in the corInfo bullet under TNType in > section 6.2 Public Identifier. I think it's okay to just delete the > last sentence that talks about spppUpdateResponse, but this needs > some thinking about. [VB:] References to "spppUpdateResponse" were cleaned out in version 12 of = the spprov document. Version 11 was an intermediate version of the document= while the documents were being restructured to accommodate ReSTFul mapping= of the protocol/framework. > > Specifically, I'm wondering of there's actually some sort of > authorization failure that needs to be asserted if 1) the > carrier-of-record claimed in the update is inconsistent with the > previously claimed authority information, and 2) the server policy > cares about this distinction. If we need to assert such an error, how > might we assert it? > > Related question for the SOAP binding: Is just including a mismatched > corInfo in the response a strong enough assertion of this error > condition? [VB:] If carrier-of-record claim in an update request is different from the= previously claimed information then this could be a valid scenario as the = registrant is no more a carrier-of-record for that pub Id. So from that per= spective, validating carrier-of-record claim in an update request with prev= iously claimed information does not seem a valid scenario. However, as also= mentioned in the protocol document (section 6.2), if the registry does hav= e access to authority data and can cross-verify the corClaim in the request= (add or update), and if there is a mismatch with the authority data, then = whether Pub Id add/update fails is a matter of server policy. If the server= policy decides to fail it then they can respond with the appropriate Respo= nse Type ("Response Types" section in the version 12 of the spprov document= ). I hope this answers. Design Team, if I am missing some historical perspecti= ve on this please comment. > > > -- > Dean > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From vbhatia@tnsi.com Fri Dec 30 11:43:44 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A827F21F86A5 for ; Fri, 30 Dec 2011 11:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORZr1FWioCaa for ; Fri, 30 Dec 2011 11:43:40 -0800 (PST) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id F325A21F867F for ; Fri, 30 Dec 2011 11:43:39 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAAALMT/k6sEQfn/2dsb2JhbAA6CYJOmUaIKwGHFIIBgXIBAQEEJwZFFwIBCA4DBAEBCxYHBzIUCQgBAQQBEgi9UYhXglVjBIg3lzyHYQ X-IronPort-AV: E=Sophos;i="4.71,433,1320624000"; d="scan'208,217";a="694268" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 30 Dec 2011 19:43:38 +0000 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 30 Dec 2011 14:43:38 -0500 From: "Bhatia, Vikas" To: David Schwartz , "drinks@ietf.org" Date: Fri, 30 Dec 2011 14:43:36 -0500 Thread-Topic: Some comments/nits on latest SPProv doc Thread-Index: AcylPKCeXYFm9wU6TJm6VV7C43gloQh1+hnA Message-ID: References: <00DC9946-3629-43F1-BEAC-CBEEC5FC736C@xconnect.net> In-Reply-To: <00DC9946-3629-43F1-BEAC-CBEEC5FC736C@xconnect.net> 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_B4254E341B54864B92D28BC2138A9DC38F9D7ATNSMAILNAwin2kcor_" MIME-Version: 1.0 Subject: Re: [drinks] Some comments/nits on latest SPProv doc X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 19:43:44 -0000 --_000_B4254E341B54864B92D28BC2138A9DC38F9D7ATNSMAILNAwin2kcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please note the responses below prefixed with my initials. Other than the couple of nits, most of the these comments apply historicall= y to the earlier versions of the spprov document. I am giving a shot at answering all comments below. Others from the design = team, please review from a historical perspective (especially the ones suf= fixed with "Design Team?") and provide comments. Thanks, Vikas From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= David Schwartz Sent: Thursday, November 17, 2011 10:22 AM To: drinks@ietf.org Subject: [drinks] Some comments/nits on latest SPProv doc Hi guys I reviewed the SPProv doc and have a few comments. I will start with the little nits... * Throughout the doc there is reference to "Modify" operation when in reali= ty it does not exist (only ADD/DEL/GET/ACCEPT/REJECT) * Page 12 - An an organization...[VB:] Ok, needs to be fixed in next rev. * Page 30 - missing SourceIdentRegex in the schema of SourceIdentType[VB:] = Seems a valid comment. There is a "sourceIdentLabel" in the actual schem= a and then there is a "sourceIdentRegex" in the description. Design Team? * Page 38 - egrRte missing from arc diagram on page 10[VB:] Ok, can be add= ed. May be the diagram was intended to be an overview. Will add in next rev= . * 5.2.1 - the enumeration value --> not vaue[VB:] Ok, will correct the typ= o with next rev. * 5.2.2 - Is this a contradiction? --> ObjKeyType MUST contain the followin= g attribute . . . DG . . . This is an optional attribute.[VB:] No, not a c= ontradiction. This is a typo again. Should be "PubIdKeyType" instead of "Ob= jKeyType". Will correct in next rev. * 7.6 - double "." at end of sentence[VB:] Ok, will correct in next rev. Moving on to comments... 4.3 -> why isn't this a MUST? [VB:] My understanding on this is that this is more of a performance optimi= zation aspects for large datasets or constant small updates. Hence, it seem= s appropriate to be a SHOULD and not MUST. 4.8 -> why isn't this a MUST? [VB:] This could be a MUST imo. Design Team? And some questions/opinions... Destination Groups 6.1 -> I think that DG should have priority field as well. This allows to d= ifferentiate based on a a parameter other than route (e.g. cost) [VB:] Can you please elaborate on this a bit more on what is the scenario? = I thought the "priority" attribute on the RG determines the route to be use= d in situations where same DG is associated with multiple RGs. Page 40 - When DG removed - it says PIs removed -> not references by PIs (s= ee next comment about PIs) PIs Page 23 - why is a PI associated with only 1 DG? why not more? What if I ha= ve some TNRange and I want to have both "gold" and "silver" routes associat= ed with it - how would I do this without having this TNR referencing more t= han one DG? [VB:] A PIs association with its DG forms its primary key. There is a "prio= rity" attribute in the RG definition. For "gold" and "silver" routes, same = TNRange would be created in two DGs with one of the DG associated to the "= gold" route (with a higher priority) and other to the "silver" route (with = a lower priority value). 6.2 -> what happened to the URI type? Why can't an identifier be a URI (e.g= . AOR)? Why can't my gmail address be the lookup identity without requiring= "gmail.com" to me anything more than an opaque string. [VB:] An identifier could be an email address. It seems there should be a P= ub Id type than can take in something like an email address. I am not sure = of the historical perspective on why this is not there. Design Team? Page 24 -> isn't the idea of a RouteGroup to "group" route records"? Why th= en in the definition of a TN do we refer to an rrRef instead of an rgRef? T= he description does say "one or more" rrRefs which would imply to me that t= his could be a rgRef [VB:] Sorry, but two parts of this comment seem unrelated. Yes, the idea o= f RG is to associate a set of Pub Ids (DG) that share a common routing info= rmation, to the set of Route Records that form that routing information. T= N association to RG is via the DG. TN also refers to rrRef for situations w= here the routing information may be unique to a particular TN. We need to c= orrect the description however to say "zero or more" and not "one or more".= May be that caused the confusion. Page 25 - why is RNType associated with DG and not RG or RR? what is logic = of grouping RN's? I would assume that RN's have a closer relationship to RG= s than DGs Why isn't corinfo part of the base PI type [VB:] RNs are grouped into a DG for situations where many RNs share the sam= e routing information. On the corInfo element, as it currently stands, corI= nfo could be part of the base type. I had that thought myself when making = the last set of updates. May be the idea was that there could be other Pub = Id types where "corinfo" does not apply (like an email address per your ear= lier comment). Design Team? SourceID Page 30 - Why not simply a URI instead of enumeration as regex can deal wit= h parts of URI. We all know that in the end the source information will be = represented in the DNS request using a URI. [VB:] Source information match can be done via the IP where the request is = coming from (which may not be in the URI), root domain or the URI itself. I= n that sense having source identity scheme as one of "uri", "ipaddress", or= "rootDomain" seems valid. Can you elaborate further? Design Team? Page 38 - why isn't egrRte associated with RG? [VB:] It probably was just a design decision. Having egrRte associated with= a RG would mean that egrRte definition would also need to have an optional= "svcs" element to defines the type of ENUM service(s) supported by the rou= te. For situations where many ingress routes share the same egress route, r= ight now there will be an association between egress route object and all R= Rs that are part of the RG. Design Team? Page 38 - why not associated with RteRecType instead of obj? [VB:] The association egrRte with RteRec object is using the RteRec's key w= hich is common element "ObjKeyType" (even before the latest changes). That = is why this association. :D ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_B4254E341B54864B92D28BC2138A9DC38F9D7ATNSMAILNAwin2kcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please note the responses below prefixed with my initials.

 

Other than the couple of nits, most of the these comments appl= y historically to the earlier versions of the spprov document.  <= /o:p>

I am giving a shot at answering all comments below. Others fro= m the design team,  please review from a historical perspective (espec= ially the ones suffixed with “Design Team?”) and provide comments.

 

Thanks,

Vikas

 

From: drinks-b= ounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of David Schwartz
Sent: Thursday, November 17, 2011 10:22 AM
To: drinks@ietf.org
Subject: [drinks] Some comments/nits on latest SPProv doc=

 

Hi guys

 

I reviewed the SPProv doc and have a few c= omments.

 

I will start with the little nits…

 

* Throughout the doc there is reference to= "Modify" operation when in reality it does not exist (only ADD/D= EL/GET/ACCEPT/REJECT)

* Page 12 -  An an organization…= ;[VB:] Ok, needs to be fixed in next re= v.

* Page 30 - missing SourceIdentRegex in th= e schema of SourceIdentType[VB:]  Seems a valid comment.&nbs= p; There is  a “sourceIdentLabel” in the actual schema and= then there is a “sourceIdentRegex” in the  description. D= esign Team?

* Page 38 - egrRte missing from arc diagra= m on page 10[VB:]  Ok, can be added. May be t= he diagram was intended to be an overview. Will add in next rev.

* 5.2.1 - the enumeration value --> not vaue[VB:] =  Ok, will correct the typo with next rev.

* 5.2.2 - Is this a contradiction? --> = ObjKeyType MUST contain the following attribute . . . DG . . . This is an o= ptional attribute.[VB:]  No, not a contradiction. T= his is a typo again. Should be “PubIdKeyType” instead of “= ;ObjKeyType”. Will correct in next rev.

* 7.6 - double "." at end of sen= tence[VB:]  Ok, will correct in next r= ev.

 

 

Moving on to comments...=

 

4.3 -> why isn't this a MUST?

[VB:] My understanding on this is that this is more of a perfo= rmance optimization aspects for large datasets or constant small updates. H= ence, it seems appropriate to be a SHOULD and not MUST.

 

4.8 -> why isn't this a MUST?

[VB:] This could be a MUST imo. Design Team?=

 

And some questions/opinions…

 

Destination Groups

6.1 -> I think that DG should have prio= rity field as well. This allows to differentiate based on a a parameter oth= er than route (e.g. cost)

[VB:] Can you please elaborate on this a bit more on what is t= he scenario? I thought the “priority” attribute on the RG deter= mines the route to be used in situations where same DG is associated with multiple RGs.

 

Page 40 - When DG removed - it says PIs re= moved -> not references by PIs (see next comment about PIs)

 

PIs

Page 23 - why is a PI associated with only= 1 DG? why not more? What if I have some TNRange and I want to have both &q= uot;gold" and "silver" routes associated with it - how would I do this without having this TNR referencing more than one DG?

[VB:] A PIs association with its DG forms its primary key. The= re is a “priority” attribute in the RG definition. For “g= old” and “silver” routes, same TNRange would be  created in two DGs with one of the DG associated to the = 220;gold” route (with a higher priority) and other to the “silv= er” route (with a lower priority value).

 

6.2 -> what happened to the URI type? W= hy can't an identifier be a URI (e.g. AOR)? Why can't my gmail address be t= he lookup identity without requiring "gma= il.com" to me anything more than an opaque string. 

[VB:] An identifier could be an email address. It seems there = should be a Pub Id type than can take in something like an email address. I= am not sure of the historical perspective on why this is not there. Design Team?

 

Page 24 -> isn't the idea of a RouteGro= up to "group" route records"? Why then in the definition of = a TN do we refer to an rrRef instead of an rgRef? The description does say "one or more" rrRefs which would imply to me that this could be = a rgRef

[VB:] Sorry, but two parts of this comment seem unrelated.&nbs= p; Yes, the idea of RG is to associate a set of Pub Ids (DG) that share a c= ommon routing information, to the set of Route Records that form that routing information.  TN a= ssociation to RG is via the DG. TN also refers to rrRef for situations wher= e the routing information may be unique to a particular TN. We need to corr= ect the description however to say “zero or more” and not “one or more”. May be that caused the c= onfusion.

 

Page 25 - why is RNType associated with DG= and not RG or RR? what is logic of grouping RN's? I would assume that RN's= have a closer relationship to RGs than DGs

Why isn't corinfo part of the base PI type=

[VB:] RNs are grouped into a DG for situations where many RNs = share the same routing information. On the corInfo element, as it currently= stands, corInfo could be part of the base type.  I had that thought myself when making the = last set of updates. May be the idea was that there could be other Pub Id t= ypes where “corinfo” does not apply (like an email address per = your earlier comment). Design Team?

 

SourceID

Page 30 - Why not simply a URI instead of = enumeration as regex can deal with parts of URI. We all know that in the en= d the source information will be represented in the DNS request using a URI.

[VB:] Source information match can be done via the IP where th= e request is coming from (which may not be in the URI), root domain or the = URI itself. In that sense having source identity scheme as one of “uri”, “ipaddres= s”, or “rootDomain” seems valid. Can you elaborate furthe= r? Design Team?

 

Page 38 - why isn't egrRte associated with= RG?

[VB:] It probably was just a design decision. Having egrRte as= sociated with a RG would mean that egrRte definition would also need to hav= e an optional “svcs” element to defines the type of ENUM service(s) supported by the route. For= situations where many ingress routes share the same egress route, right no= w there will be an association between egress route object and all RRs &nbs= p;that are part of the RG. Design Team?

 

Page 38 - why not associated with RteRecTy= pe instead of obj?

[VB:] The association egrRte with RteRec object is using the R= teRec’s key which is common element “ObjKeyType” (even be= fore the latest changes). That is why this association.

 

:D

=  


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_B4254E341B54864B92D28BC2138A9DC38F9D7ATNSMAILNAwin2kcor_-- From sumanth@cablelabs.com Fri Dec 30 13:46:16 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D7D21F8564 for ; Fri, 30 Dec 2011 13:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04M74LZ4qoK9 for ; Fri, 30 Dec 2011 13:46:15 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1C90421F8560 for ; Fri, 30 Dec 2011 13:46:14 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id pBULkAWs010915; Fri, 30 Dec 2011 14:46:11 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Fri, 30 Dec 2011 14:46:10 -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; Fri, 30 Dec 2011 14:46:11 -0700 From: Sumanth Channabasappa To: "drinks@ietf.org" Date: Fri, 30 Dec 2011 14:46:10 -0700 Thread-Topic: Logistics: Plan for Virtual Interim Thread-Index: Acy7xUFNSkix1bO0SKGpbSj/NeY7VALdwqxA Message-ID: <76AC5FEF83F1E64491446437EA81A61F81DE3E2F16@srvxchg> References: <8BC845943058D844ABFC73D2220D46650B3672B0@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D46650B3672B0@nics-mail.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "drinks-chairs@tools.ietf.org" Subject: Re: [drinks] Logistics: Plan for Virtual Interim X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 21:46:16 -0000 Folks, Thus far we have received 5 positive responses and 0 negative responses. If= you haven't responded, please do so at your earliest.=20 Thanks! - S -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Alexander Mayrhofer Sent: Friday, December 16, 2011 12:40 AM To: drinks@ietf.org Cc: drinks-chairs@tools.ietf.org Subject: [drinks] Logistics: Plan for Virtual Interim All, in the last design team call held this Wednesday, the team indicated that i= t would be useful to hold an Virtual Interim Meeting early next year. This = meeting would be used to perform work on the remaining two documents, and g= et them "fit" for working group last call. We're currently looking at holding the meeting on=20 Wed, February 1st 2012, 9am - 1pm Eastern (this would also allow european participants to attend the meeting). I've set up a doodle poll to record whether people would be available or no= t, please indicate your availability here: http://www.doodle.com/qza66x4yxue873hg (Please only cast your vote if you're interested in attending the meeting a= t all ;) thanks, Alex & Sumanth _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks