From alexander.mayrhofer@nic.at Wed Apr 1 08:56:38 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 814723A6A6F for ; Wed, 1 Apr 2009 08:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] 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 vrUewpVVWeNV for ; Wed, 1 Apr 2009 08:56:37 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 51C133A6A88 for ; Wed, 1 Apr 2009 08:56:36 -0700 (PDT) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.44 ; Wed, 1 Apr 2009 17:57:35 +0200 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: Wed, 1 Apr 2009 17:57:33 +0200 Message-ID: <8BC845943058D844ABFC73D2220D4665081E48CE@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: List confirmation - adoption of draft-channabasappa-drinks-usecases-requirements-02 as WG item Thread-Index: Acmy4pG4W61Xik1GTG6wevA1oyVj0A== From: "Alexander Mayrhofer" To: "IETF DRINKS WG" X-XWALL-BCKS: auto Subject: [drinks] List confirmation - adoption of draft-channabasappa-drinks-usecases-requirements-02 as WG item 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, 01 Apr 2009 15:56:38 -0000 During the DRINKS WG meeting in San Francisco, a hum was taken on whether the WG would want to adopt http://tools.ietf.org/html/draft-channabasappa-drinks-usecases-requireme nts-02 as a WG item, covering the first DRINKS milestone ("Requirements for Session Establishment Data (SED) data exchanges."). There was strong concensus in the room that the document mentioned above should be adopted to cover that milestone.=20 This message is to confirm this concensus with the people not having been able to attend the WG meeting (or the discussion on Jabber). If you have an opinion about this issue, please indicate your answer (yes/no) to the following question back to the list Q) Should the Working Group adopt draft-channabasappa-drinks-usecases-requirements-02 as a WG item? Unless we hear strong opposition from the list over the next few days, we will consider that the WG is in concensus about adopting the document. Thanks, Alex From richard@shockey.us Thu Apr 9 12:42:26 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 9E47F3A6969 for ; Thu, 9 Apr 2009 12:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, 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 bdpupVEs-jlA for ; Thu, 9 Apr 2009 12:42:25 -0700 (PDT) Received: from outbound-mail-29.bluehost.com (outbound-mail-29.bluehost.com [69.89.17.211]) by core3.amsl.com (Postfix) with SMTP id B0C043A6802 for ; Thu, 9 Apr 2009 12:42:25 -0700 (PDT) Received: (qmail 21920 invoked by uid 0); 9 Apr 2009 18:43:14 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy2.bluehost.com with SMTP; 9 Apr 2009 18:43:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=YJyCeo8C9glB3sFLPRBUZb3ob78GmieuUsfZcaKnJLno3MSSlWrpM6YFutP2kFigI6MBJQL3Py8XOf6zsTg1Xzrwt35qnga/A12iize0XFVTA5ljAzhJsPe7VxirDVqh; 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 1Ls09t-0006CD-Ko for drinks@ietf.org; Thu, 09 Apr 2009 13:43:33 -0600 From: "Richard Shockey" To: "'IETF DRINKS WG'" Date: Thu, 9 Apr 2009 15:43:32 -0400 Message-ID: <023801c9b94b$775fe9b0$661fbd10$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm4+sDH/4G4xSU6QDyEiFPjwKePAgAHb3RAAAyRTvA= 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: [drinks] FW: New Liaison Statement, "Liaison to IETF DRINKS Group on a unique international resource for global Service Provider Identification (SPID)" 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: Thu, 09 Apr 2009 19:42:26 -0000 FYI .. I checked with Karen Mulberry on this and the issue is that ITU-T = SG2 wants to make sure that we have appropriate data fields available in = the DRINKS protocol to accommodate both national and this new proposed = international SPID. Seems a reasonable request ..the use case is certainly obvious, at least = to me.=20 -----Original Message----- From: Richard Hill(ITU-T SG 2) [mailto:tsbsg2@itu.int]=20 Sent: Thursday, April 09, 2009 4:04 AM To: statements@ietf.org Cc: richard.hill@itu.int; Mulberry, Karen Subject: New Liaison Statement, "Liaison to IETF DRINKS Group on a = unique international resource for global Service Provider Identification = (SPID)"=20 Title: Liaison to IETF DRINKS Group on a unique international resource = for global Service Provider Identification (SPID) Submission Date: 2009-04-09 URL of the IETF Web page: = https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D518=20 Please reply by 2009-11-10 From: Richard Hill(ITU-T SG 2) To: IETF/DRINKS(statements@ietf.org) Cc:=20 Reponse Contact: richard.hill@itu.int Technical Contact: karen.mulberry@neustar.biz Purpose: For action=20 Body:=20 Attachment(s): COM 2 - LS 27, Liaison to IETF/DRINKS on SPID https://datatracker.ietf.org/documents/LIAISON/file624.pdf From richard@shockey.us Thu Apr 9 13:05:07 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 358543A6CAD for ; Thu, 9 Apr 2009 13:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, SARE_MILLIONSOF=0.315] 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 zI1BidSsPRKI for ; Thu, 9 Apr 2009 13:05:05 -0700 (PDT) Received: from outbound-mail-304.bluehost.com (outbound-mail-304.bluehost.com [67.222.53.250]) by core3.amsl.com (Postfix) with SMTP id 1367C3A6C37 for ; Thu, 9 Apr 2009 13:05:05 -0700 (PDT) Received: (qmail 14721 invoked by uid 0); 9 Apr 2009 20:00:03 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 9 Apr 2009 20:00:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=WvwNOod4d8YHdnyJnNeULpE/ihM2zv5+JmwUS0JWMhYyWmbOHbGK8D9TpD9A2yB4OOMx/vYpucfDumKmzA1Luwr1odFBXKWNlFhGFiYQg2a8o008cJMxci+uOWaMj4Xn; 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 1Ls0Vn-0001KJ-5E for drinks@ietf.org; Thu, 09 Apr 2009 14:06:11 -0600 From: "Richard Shockey" To: "'IETF DRINKS WG'" Date: Thu, 9 Apr 2009 16:06:09 -0400 Message-ID: <025401c9b94e$a07af490$e170ddb0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm5Tp4TKZXvmjqXT4ikw9bQOE/ykQ== 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: [drinks] DRINKS Meeting Notes. 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: Thu, 09 Apr 2009 20:05:07 -0000 IETF 74 DRINKS WG agenda - with embedded notes ======================== Data for Reachability of Inter/tra-NetworK SIP (drinks) TUESDAY, March 24, 2009 0900-1130 Morning Session I Continental 1&2 RAI drinks Data for Reachability of Inter/tra-NetworK SIP WG Chair(s): --------- Richard Shockey Alexander Mayrhofer WG Secretary: ------------- Deborah Guyton RAI Director(s): ---------------- Jon Peterson Cullen Jennings RAI Area Advisor: ----------------- Jon Peterson Agenda: ======= 0. Welcome / Note Well / Agenda bashing (Chairs, 5m) Notes: There were no changes or additions to the agenda. 1. Document status (Deborah Guyton, 5m) Notes: Debbie reviewed active contributions. She provided a brief overview of the Requirements Design Team purpose, meeting structure and major participants and contributors working on the usecases and requirements draft. 2. DRINKS use cases / requirements (Sumanth Channabasappa, 60m) Title : DRINKS Use cases and Protocol Requirements Author(s) : S. Channabasappa Filename : draft-channabasappa-drinks-usecases-requirements-02.txt Pages : 22 Date : 2009-02-03 This document captures the use cases and associated requirements for interfaces to provision session establishment data into SIP Service Provider components that aid with session routing. Specifically, the current version of this document focuses on the provisioning of one such element, termed the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-channabasappa-drinks-usecases-requ irements -02.txt Notes: There was a request for a show of hands as to who had read the document. Approximately 15. Sumanth started with a recap of the components, the scope, terminology, and entity-relationships. He discusssed the three current use case categories. He provided a one line summary of each use case identifying each by Use Case Number. He asked for questions. John Elwell had a question - who has access to the registry? As each service provider peers with others they need to have access to the registry. How many registries will exist? Alex said the protocol should not be determining the number of registries. John asked about registry to registry interactions. Rich said that is an item on the agenda to be addressed: Registry to Registry. Martin Dolly - Here did the design team end up with LRF/LUF? Sumanth answered that we did not include that distinction in our requirements. Jabber - Dan said that it seems like one big registry in the sky. Design team said no! What is missing is registry to registry. All agreed that we need to add use cases in this area. Alex reiterated that we want the Working Group (WG) to participate and contribute input. Ken Cartwright said that the scope diagram does show registry to registry - there will be more than one. Adam Uzelac said he took an item from SPEERMINT to look at the impact of LUF/LRF but we seemed to ignore it. Sumanth said we made a concious effort to distinguish this and discussed it at length but could not make a distinction. Rich said we punted the issue because we need to get a framework or superstructure for the use cases established. The Design Team was to come up with a rough architecture. The WG needs to progress this. John referred to the scope document and wanted to see different registries with different sets of SSPs. Alex said he would clarify. Ken said we must distinguish beteween LUF/LRF. Otmar did talk about layering. Until we make this distinction, we are pressing on. Rich mentioned the ENUM contribtion on trunkgroup data. Daryl Malas was asked to summarize. Daryl said he wasn't sure how he wanted to answer the question. SPEERMINT 5486 has definitions of LUF/LRF and those definitions are complete. There seemed to be less arguments than expected. For WG SPEERMINT co-chair - the issue seemed to be solved. But that's separate. ENUM draft - For the ENUM service type defined for trunk, in general folks thought it wasn't valuable and not a valid approach. Wanted to query on a TN - in the query for LUF, you want to get LRF info - trunk group to route to. You can put 4904 parameters in a NAPTR. Jean Francois Mule - i don't think the LUF/LRF discussion is relevant. We had 4 sessions discussing it and it had no meaningful impact on requirements. In the data model we should support elements that support lookup functions. Some said we will do dynamiclookup. Some said we should include some LRF. We seem to have these discussions over and over again. Jean Francois Mule asked "what needs to be resolved"? If you have issues, send text. Hadriel Kaplan - I don't want to talk about that topic. My point is about the trunk group topic. The reasone the trunk group service made sense to me is that it is optional. With the current draft you might get these parameters back and you don't know whether you process it or pass it on. If you have a service type, If you don't process locally you just pass it on. John Elwell had a question about destination groups - e.g., *example.com. We don't say anything about SIP URI at this time. Would it be wildcarded? Alex said if you have millions and millions of identifiers, if you have to change something about the routing, we only want to change the routing behind it with a detination group. Currently it is an abstraction. Sumanth moved on to review the requirements - There are two kinds: data and functional. These are numbered in the draft. Some are more developed than others. He reviewed the list of requirements. Eric for the Jabber room - David doesn't like the term "COR" as it feels like a telco thing - maybe "primary provider". Alex - who is allowed to provision isn't specified in the protocol - it can be implementation specific. Rich - and we don't want any discussions of who 'owns' a public identity. That's a rat hole. Alex asked, is everyone confused or contemplating whether there are additional use cases to be defined? Are folks just digesting? Hadriel - there is a requirement that a provisioning protocol support an extensible list of future elements. Which is the key versus the key lookup? Look up key is TN. Also, why distinguish between a TN and an RN? Manjul - RN could be aggregated. You know that you have done a portability dip beforeyou query if you query on an RN - you need to know if you are querying for a TN or an RN. Hadriel -the database query client has to know what to query, If the database has to have a different entity type, it has to convey that to the local resolver. There is no way to do this today. Basically at the resolver, a key must be used to lookup and get a result. They both work the same way. The resolver needs to know what key it is getting. Hadriel - the real question - is there a difference in the answer - if yes, we have a problem. Jabber - David - are there any routing ownership to the Public Identify or is it just an identifier? In the protocol it is just an identifier. You can't use 3263 for it. They can't put the domain name in it. Not a sip URI. Ken cartwright - we don't want to issue new data types we don't need. But TN and RNs are different. A use case, if you know it is an RN, you can look up ownership in NPAC with confidence. If you have a TN you don't know. We have customers who explode out an rN to the TNs it represents. Alex - as Otmar noted, the use cases are affiliated with PSTN things. We would like additional use cases that are not that tightly associated with the PSTN. Darryl Malas, while we may chose to say we want to use sIP for non-TN based applications, the broadest application is PSTN replacement. Alex - it's good to know what else is out there. We need to know other uses beyond voice application. Jabber - if you want non service provider use cases, submit non service provider use cases. Hadriel is it for e164 number use case routing or non - e.g., email style (non "+ starting", non digit strings) is this the use case we are looking for? Is public identify more than a TN? Alex says it can be something else. Jon Peterson - my understanding is that it is non TN specific. But all admitted 95% of use cases are tN oriented. Sumanth - we have had discussions on transit providers. Otmar sent across good commmentsand thoughts. Questions? Other use cases and requirements? Jabber - David - how do you prioritize service providers if you don't use COR? Manjul use ENUM preference and order and SIP priority. Hadriel - definitely in favor of having it become a WG draft. Rich - This is version 00 of a working group draft. Need to have the WG progress this. Daryl this is to frame the work - not define the solution space. Good work to get this effort going on use cases and requirements. Jabber - Otmar - most requirements assume there is a registry. This is putting the cart before the horse. They need to decide what data a registry needs and then decide if they need a registry to put the data in. Alex said to reference his draft to review elements that may be aggregated versus exchanged peer to peer. Alex - now we would like to ask the WG if they accept as first WG draft. Needs broader scope from WG. Took a hum. Folks are in favor of adopting this effort as a WG document. Alex - Once this document becomes stable we can progress the work on the protocol. Asked that Sumanth still serve as the edit or the document. Sumanth said 'sure'. 3. SED Elements (Alex Mayrhofer, 20m) Title : Potential Elements of Session Establishment Data Author(s) : A. Mayrhofer Filename : draft-mayrhofer-drinks-sed-elements-00.txt Pages : 6 Date : 2009-03-04 This document provides a list of potential Session Establishment Data Elements in the Scope of SPEERMINT/DRINKS work. The list is provided to seek input from the community, and with the intent to aid in the definition ofDRINKS requirements/protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-drinks-sed-elements-00.t xt Notes: Alex presented. he thought it might be useful to identify data elements from a bottoms up approach. This is just a list of data elements that may be needed for peering. He also referenced the "Hancock" draft. If folks thinks this is a useful exercise we can expand the list and review the data. John - I thought we would be looking at a query and get back SED, do we need to know who the user is. The LRF cannot give you the user data. Hadriel- I'm confused. I thought it was the data we need to get back to route for a query. But the list goes beyond that. Not possible to go through this list - as a vendor we have over 1200 possible configurable elements. We need to come up with a list of what we do need, maybe major attributes that we need. We could extend the list in the future. Rich asked should it be the maximum number of parameters or a minimum subset. Hadriel - obviously the minimun set. Should not include constraints. Alex - we should try to get it down to the minimum set and not include items not relevent to routing. Do not list data that would be exchanged in the actual session. Manjul - you need to know about the media and codec in the peering part. Alex - my broader question is - is it useful to progress - I only have a shopping list now. Jabber - David, keep it to a simple minimal set. Eric - if you have lots of stuff, you are begging for disaster. Hadriel - of course the SBEs should know about bandwidth - in the forwarding plane, but should not be part of the registry or database. Alex how do they know about bandwidth? Hadriel today it is an SLA. Today each other does not provision each others routers or SBEs. Can not expect someone else to control your equipment. Daryl Malas - it is a little early to hash out. The registry is likely to have CNAME (ENUM working group) you can do queries without ever processing a call. You said SED talks about data for the next hop. If I'm going to route to an ingress point, I might need to know where I egress. These would be valuable and should have a framework around it and be part of this draft. Jon Peterson - has to be a distinction of static information on a registry and real time forwarding decisions. Make the distinction. Draw a line and declare before we go forward with the document. We can go forward with what Hadriel said and draw this line. Alex - would anyone who knows more about this than I do, pick up the draft and extend it or add data elements. Rich said the concensus I hear is a) this is useful to define the necessary data elements of SED, 2) minimal subset, and 3) static versus dynamic data. John Elwell - SED will include some dynamic data, but not a concern in DRINKS. We should focus on the static part. SPEERMINT should define the SED. Then the aspects of provisioning should be the charter of DRINKS. Daryl malas, speermint co-chair, i don't think we should define the SED - we define what it is but we don't define all of the attributes. We define how SSPs peer and what they need to peer. What they need and attributes to complete a negotiation is not in SPEERMINT. John Elwell, suppose you want to get to Destination X. Provisioned data may say go via A, but if A is not available go by B. SED may say go via either A or B. [Note that when folks were discussing information about LUF versus LRF, they were saying "hmm" versus "hmm", not again wanting to get into details of distinguishing each.] Daryl Malas - if we hum every time we say L*F, I might go insane. Let's figure out later if LUF or LRF. First come up with the appropriate data. Let's define what we need to do. Then define the spec around it. 4. Discussion: Private use of DRINKS protocol (Richard Shockey leads, 20m) Issues involving how provisioning Private Peering data fits into the DRINKS model. Notes: Alex - an example is between SSPs. Rich said this came up also as registry to registry in an SSP to SSP concept. The question is do we need to come up with use cases to cover this? Do we need to flesh it out or let the implementation determine this with the existing use cases? Do we have a definitive statement on that? Hadriel - statement of private versus public? Rich said bad use of terms. The current scope is SSP to SSP or registry to registry. We haven't discussed bi-lateral or pairwise use of the protocol. Hadriel said yes. Rich said nothing in charter says pairwise is out of scope. We haven't explicitly called out use cases for this. Hadriel says it depends on the architecture. Whether you discuss LUF or LRF. For LRF you need a requirement to prevent loops. You don't need to worry about this for LUF. As the connections are a mesh and not fully hierarchical. Alex - we shouldn't preclude any use of the protocol. There has been mention of enterprise PBXs. We need use cases. Daryl malas - short answer - There should be an ability to provsion registry to registry.How different is that from what is described in the use cases today? You have to able to identify a set of TNs from an enterprise - these are unique to this enterprise. If globally unique, then you are getting to what Otmar is saying - example, there are going to be global registries. For this enterprise you can query up to the LUF. Need a use case that says this can be used for registry to registry provisioning. Jon Peterson - I have no objection that this is within the scope of drinks - when we get into more detail, it may be a different protocol for registry to registry. Jabber - David said we need to cover a pull or subscription. The local stores don't have a mind, just local stores. He volunteered to write the registry to registry use case. 5. WG Status / Milestones Discussion (Alex Mayrhofer leads, 10m) Notes: Alex covered the list of milestones. Requirements 9/08; Protocol 11/08 for data providers to registry; 2/09 exchange of SED from registry to LRF databases. We need to update these. Daryl had a question for the WG to consider, there probably are some more things to consider for registry to registry - consider as separate work from provisioning into a registry. Jon mentioned that it could end up having functionality different from provisioning a registry. There should probably be a separate document for defining these use cases. And allow the current document to move forwrad. Ken said we need to understand that, let's see what the use cases are, then decide if it needs to be separate or not. Adam Uzelac - I agree with Ken, I dont see what would be different. John Elwell, the question I raised about SED data - is it truly data that is provisioned? Alex - SED is derived from the provisioned data. Alex - We had a rough idea to start a design team for the protocol itself. Now that we have adopted the use case doc as a WG item, we shoud add additional use cases. I'd like to get a feeling whether the approach for a design team for the protocol would fit as a way to go forward. My concern was that the WG discussion after our design team was low volume. I want folks working once they commit. Silence was frustrating. Ken cartwright - some feedback - the good thing about the design team was there were weekly meetings that gave progress. If we move away from this approach, we need something else to create progress checkpoints - like weekly. Spencer - keep the notes on the main mailing list. This was agreed to. Rich - are we ready to commence this as the use cases are in an advanced stage? Daryl malas - start the work as there are not major arguments against the use cases. Spencer - I echo that, it's a long time until the next IETF - late July - let's start it. Sumanth - having a design team continue working on the protocol may identify additional requirements and use cases. Let's progress it. Rich - let's form a design team for the protocol. Operate in the same manner, weekly phone calls, and minutes be published on a regular basis. The action item is for the chairs to draft up ideas to proceed. Solicit volunteers from the list. Jabber - David - need to also get concensus on registry to registry info. Eric - be careful starting too soon and say we've done so much on protocol we can't change for new use cases. Daryl Malas, we moved forward on drafts but then waited for terminology. but relatively quick to align these. The same thing can occur with minimal amount of risk. David - did ask if the design team can deliberate with a conference bridge. Alex- but need regular paricipants so we constantly don't explain earlier decisions. 6. General Discussion ... / AOB Notes: The meeting ended. Richard Shockey PSTN Mobile: +1 703.593.2683 skype: rshockey101 LinkedIn : www.linkedin.com/in/rshockey101 From richard@shockey.us Thu Apr 9 13:14:25 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 92FC63A6BC6 for ; Thu, 9 Apr 2009 13:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_05=-1.11, 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 rMnHXezfOeUY for ; Thu, 9 Apr 2009 13:14:24 -0700 (PDT) Received: from outbound-mail-151.bluehost.com (outbound-mail-151.bluehost.com [67.222.39.31]) by core3.amsl.com (Postfix) with SMTP id AFE7E3A67FF for ; Thu, 9 Apr 2009 13:14:24 -0700 (PDT) Received: (qmail 17179 invoked by uid 0); 9 Apr 2009 20:11:43 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 9 Apr 2009 20:11:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=OoEsmSf0+RkWVm1O47vDd3Utd/lzogdraufoUFS6HFJNZZ04xfPS9Dlsez93Xe51xEvAxp2K3OLxaHTudx7flaTWC3QYBJq/aVn9ro2GcTTC9pQbJ/d+Ezv8MFOlfnJL; 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 1Ls0eq-0001WW-HU for drinks@ietf.org; Thu, 09 Apr 2009 14:15:32 -0600 From: "Richard Shockey" To: "'IETF DRINKS WG'" Date: Thu, 9 Apr 2009 16:15:30 -0400 Message-ID: <025801c9b94f$ef15d470$cd417d50$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm5T+2PH6O3k/NjSMmXOJ2AcV1EsA== 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: [drinks] Confirmation of WG Consensus on adoption usecases 02 as WG item. 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: Thu, 09 Apr 2009 20:14:25 -0000 I just want to get WG consensus on the hum that we took in SF that the following document is a WG document and formally replaces the original DRINKS requirements document. Silence is considered consent. I'll post a note in a few days opening the discussion on creating a DRINKS Protocol Design team as we discussed in SF. We need to continue to refine the use cases and requirements but we also need to start protocol design in parallel. Sound right? DRINKS use cases / requirements (Sumanth Channabasappa, 60m) Title : DRINKS Use cases and Protocol Requirements Author(s) : S. Channabasappa Filename : draft-channabasappa-drinks-usecases-requirements-02.txt Pages : 22 Date : 2009-02-03 This document captures the use cases and associated requirements for interfaces to provision session establishment data into SIP Service Provider components that aid with session routing. Specifically, the current version of this document focuses on the provisioning of one such element, termed the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-channabasappa-drinks-usecases-requ irements-02.txt Richard Shockey PSTN Mobile: +1 703.593.2683 skype: rshockey101 LinkedIn : www.linkedin.com/in/rshockey101 From trutkowski@netmagic.com Mon Apr 20 07:49:10 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 7519528C2A7 for ; Mon, 20 Apr 2009 07:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_40=-0.185] 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 AmQ+UmvfuaYb for ; Mon, 20 Apr 2009 07:49:09 -0700 (PDT) Received: from vms173009pub.verizon.net (vms173009pub.verizon.net [206.46.173.9]) by core3.amsl.com (Postfix) with ESMTP id BBBCB28C296 for ; Mon, 20 Apr 2009 07:49:09 -0700 (PDT) Received: from [192.168.1.3] ([72.86.34.21]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KIE0084TMJ1J5EB@vms173009.mailsrvcs.net> for drinks@ietf.org; Mon, 20 Apr 2009 09:49:53 -0500 (CDT) Message-id: <49EC8B8D.9030600@netmagic.com> Date: Mon, 20 Apr 2009 10:49:49 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-version: 1.0 To: drinks@ietf.org Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Subject: [drinks] FW: New Liaison Statement, "Liaison to IETF DRINKS Group on a unique international resource for global Service Provider Identification (SPID)" X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 14:49:10 -0000 Hi Richard, Over the past 18 months, there have been multiple efforts in different forums (including ITU-T forums) addressing the subject of a unique global service provider identity (a/k/a SPID). ITU-T Study Group 17 (security) abandoned the effort and focussed instead on service provider identity *trust* using EVcerts combined with Enterprise OIDs. This action was a recognition that multiple standards bodies and the industry have chosen IANA Enterprise OIDs as the means of choice of implementing a unique global service provider *identifier.* There are now something approaching 40,000 of them registered. It also recognizes that the reality that the EVcert has been recognized by multiple standards bodies, including the IETF, ITU-T, ETSI, Liberty Alliance, etc, as the basis for high-trust, open, *identity* among service providers and users. Reading through the DRINKS material, it's not apparent that you are doing anything that deviates from the Enterprise OID/EVcert consensus. Is that accurate? What at most may be needed might be a means for pointing or binding Enterprise OIDs to the plethora of provider identifiers that exist, including those associated with the DRINKS work. best, tony -- Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 From richard@shockey.us Mon Apr 20 07:55:20 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 184693A6C95 for ; Mon, 20 Apr 2009 07:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, 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 CesGquzDOaVm for ; Mon, 20 Apr 2009 07:55:19 -0700 (PDT) Received: from outbound-mail-160.bluehost.com (outbound-mail-160.bluehost.com [67.222.39.40]) by core3.amsl.com (Postfix) with SMTP id 34CAF3A6C6F for ; Mon, 20 Apr 2009 07:55:19 -0700 (PDT) Received: (qmail 13392 invoked by uid 0); 20 Apr 2009 14:52:26 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 20 Apr 2009 14:52: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:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=dNdnI9d6X/cJJUhoLWaz0knmO5Pb2ZJA3VnCBwkmHDTp2gH7rAWnV8s7YkoGINj16G6xSb2ZaaBqtAfiVJMu1SqjfirCc0xstPvwr1hQ6HS+E9DkGXEvM6g+elPOXghY; 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 1LvuvC-0004N7-6s for drinks@ietf.org; Mon, 20 Apr 2009 08:56:34 -0600 From: "Richard Shockey" To: "'IETF DRINKS WG'" References: <025801c9b94f$ef15d470$cd417d50$@us> In-Reply-To: <025801c9b94f$ef15d470$cd417d50$@us> Date: Mon, 20 Apr 2009 10:56:19 -0400 Message-ID: <018f01c9c1c8$2ac2cfc0$80486f40$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm5T+2PH6O3k/NjSMmXOJ2AcV1EsAIeB5aw 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] Confirmation of WG Consensus on adoption usecases 02 as WG item. 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: Mon, 20 Apr 2009 14:55:20 -0000 I'm assuming silence is consent and the document is question is a WG document. > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On > Behalf Of Richard Shockey > Sent: Thursday, April 09, 2009 4:16 PM > To: 'IETF DRINKS WG' > Subject: [drinks] Confirmation of WG Consensus on adoption usecases 02 > as WG item. > > I just want to get WG consensus on the hum that we took in SF that the > following document is a WG document and formally replaces the original > DRINKS requirements document. Silence is considered consent. > > I'll post a note in a few days opening the discussion on creating a > DRINKS > Protocol Design team as we discussed in SF. > > We need to continue to refine the use cases and requirements but we > also > need to start protocol design in parallel. > > Sound right? > > > DRINKS use cases / requirements (Sumanth Channabasappa, 60m) > > Title : DRINKS Use cases and Protocol Requirements > Author(s) : S. Channabasappa > Filename : draft-channabasappa-drinks-usecases-requirements- > 02.txt > Pages : 22 > Date : 2009-02-03 > > This document captures the use cases and associated > requirements for > interfaces to provision session establishment data into SIP > Service > Provider > components that aid with session routing. Specifically, the > current > version > of this document focuses on the provisioning of one such > element, > termed the > registry. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-channabasappa-drinks- > usecases-requ > irements-02.txt > > Richard Shockey > PSTN Mobile: +1 703.593.2683 > > skype: rshockey101 > > LinkedIn : www.linkedin.com/in/rshockey101 > > > > > > > > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks From trutkowski@netmagic.com Mon Apr 20 11:17:27 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 9037A3A6E23 for ; Mon, 20 Apr 2009 11:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599] 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 TVINch72uBez for ; Mon, 20 Apr 2009 11:17:26 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by core3.amsl.com (Postfix) with ESMTP id 50E053A6FB3 for ; Mon, 20 Apr 2009 11:17:26 -0700 (PDT) Received: from [192.168.1.3] ([72.86.34.21]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KIE002UUW65CG3N@vms173005.mailsrvcs.net> for drinks@ietf.org; Mon, 20 Apr 2009 13:18:13 -0500 (CDT) Message-id: <49ECBC5D.20009@netmagic.com> Date: Mon, 20 Apr 2009 14:18:05 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-version: 1.0 To: Richard Shockey References: <025801c9b94f$ef15d470$cd417d50$@us> <018f01c9c1c8$2ac2cfc0$80486f40$@us> In-reply-to: <018f01c9c1c8$2ac2cfc0$80486f40$@us> Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Cc: 'IETF DRINKS WG' , Richard Brackney , Mike Hird Subject: Re: [drinks] Confirmation of WG Consensus on adoption usecases 02 as WG item. X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 18:17:27 -0000 Hi Rich, > I'm assuming silence is consent and the document is question is a WG > document. > > Public Identity: A generic term that refers to a telephone number > (TN), an email address, or other identity as deemed appropriate, > such as a globally routable URI of a user address (e.g., > mailto:john.doe@example.net). The use of "public identity" in this draft creates a new term that seems both unnecessary and out of sync with the concepts being followed in the Identity Management community. It is not clear why the term "public" is needed, and can give rise to substantial confusion. Additionally, what is defined in the draft is customarily known as an "identifier," rather than an identity. The potential confusion arises, for example, in Use Case #6 where reference is make to taking a public identity "out of service," as well as Freq 4, where reference is made to a "carrier of record for a public identity." >From the context of this work, you might want to consider alternatively a term like "signalling endpoint identifier" or "call routing identifier." Hope this is useful. I've copied both some of the folks involved with international identity management terminology and specifications. best --tony -- Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 From richard@shockey.us Mon Apr 20 11:55:29 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 2A32F3A69D3 for ; Mon, 20 Apr 2009 11:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, 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 6A6nplAXFkxf for ; Mon, 20 Apr 2009 11:55:28 -0700 (PDT) Received: from outbound-mail-115.bluehost.com (outbound-mail-115.bluehost.com [69.89.24.5]) by core3.amsl.com (Postfix) with SMTP id 449B63A6E0C for ; Mon, 20 Apr 2009 11:55:28 -0700 (PDT) Received: (qmail 10333 invoked by uid 0); 20 Apr 2009 18:56:43 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy3.bluehost.com with SMTP; 20 Apr 2009 18:56:43 -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:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=E8Ix+ZXMSbDJuxH5zBXk2xJaG1GhbrzJDJcCUNZZwbfTgvLLEZmOkbe5Gic8beGnmEpZ6Zf6bdFpi11W73T9cFE3jxPg6RdgFgmluodP/pgGLP7ic547ERU21ZemwgzE; 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 1Lvyfa-0001Me-MP; Mon, 20 Apr 2009 12:56:42 -0600 From: "Richard Shockey" To: , References: <49EC8B8D.9030600@netmagic.com> In-Reply-To: <49EC8B8D.9030600@netmagic.com> Date: Mon, 20 Apr 2009 14:56:27 -0400 Message-ID: <021401c9c1e9$b663e2f0$232ba8d0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnBx1g/wSL2v9AgQ9OyqVUs/kuNCgAIawLw 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] FW: New Liaison Statement, "Liaison to IETF DRINKS Group on a unique international resource for global Service Provider Identification (SPID)" 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: Mon, 20 Apr 2009 18:55:29 -0000 Hi Tony .. nice to see you active :-) In line. > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On > Behalf Of Tony Rutkowski > Sent: Monday, April 20, 2009 10:50 AM > To: drinks@ietf.org > Subject: [drinks] FW: New Liaison Statement, "Liaison to IETF DRINKS > Group on a unique international resource for global Service Provider > Identification (SPID)" > > Hi Richard, > > Over the past 18 months, there have been multiple efforts in different > forums (including ITU-T forums) addressing the subject of a unique > global service provider identity (a/k/a SPID). ITU-T Study Group 17 > (security) abandoned the effort and focussed instead on service > provider identity *trust* using EVcerts combined with Enterprise OIDs. > > This action was a recognition that multiple standards bodies and the > industry have chosen IANA Enterprise OIDs as the means of choice of > implementing > a unique global service provider *identifier.* There are now > something> approaching > 40,000 of them registered. It also recognizes that the reality that > the EVcert has been recognized by multiple standards bodies, including the IETF, > ITU-T, ETSI, Liberty Alliance, etc, as the basis for high-trust, open, > *identity* among service providers and users. > > Reading through the DRINKS material, it's not apparent that you are > doing anything that deviates from the Enterprise OID/EVcert consensus. That is correct the way I read the liaison statement was that the DRINKS Protocol ( what ever that is) should accommodate the GSPID concept in its data model the way it would any normal national SPID or ALT-SPID etc Is > that > accurate? What at most may be needed might be a means for pointing or > binding Enterprise OIDs to the plethora of provider identifiers that exist, > including those associated with the DRINKS work. We have not seen a use case for the Enterprise OID's and if you would like to provide one that would be appreciated, in any event the goal of the DRINKS WG is to be extensible for all forms of existing and future data requirements. > > best, > tony > > -- > Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 > 703.999.8270 > > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks From trutkowski@netmagic.com Mon Apr 20 13:11:35 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 AEF933A6ACF for ; Mon, 20 Apr 2009 13:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599] 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 pFETlPvVhs9B for ; Mon, 20 Apr 2009 13:11:35 -0700 (PDT) Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) by core3.amsl.com (Postfix) with ESMTP id 0C91D3A63EC for ; Mon, 20 Apr 2009 13:11:34 -0700 (PDT) Received: from [192.168.1.3] ([72.86.34.21]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KIF00A241GNCJ8U@vms173007.mailsrvcs.net> for drinks@ietf.org; Mon, 20 Apr 2009 15:12:28 -0500 (CDT) Message-id: <49ECD727.3060805@netmagic.com> Date: Mon, 20 Apr 2009 16:12:23 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-version: 1.0 To: Richard Shockey References: <49EC8B8D.9030600@netmagic.com> <021401c9c1e9$b663e2f0$232ba8d0$@us> In-reply-to: <021401c9c1e9$b663e2f0$232ba8d0$@us> Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Cc: drinks@ietf.org Subject: Re: [drinks] FW: New Liaison Statement, "Liaison to IETF DRINKS Group on a unique international resource for global Service Provider Identification (SPID)" X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 20:11:35 -0000 Hi Rich, > Protocol ( what ever that is) should accommodate the GSPID concept in its > data model the way it would any normal national SPID or ALT-SPID etc > Helpful. It appeared from the SG2 material that DRINKS was spinning up some kind of new SPID. There is today no such thing as a singularity denominated as a SPID. To there extent that a prevailing global service provider identifier has emerged, it appears to be the Enterprise OIDs. So, harmony exists in the world, and there is no need to invent another identifier. best, tony -- Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 From richard@shockey.us Mon Apr 20 13:11:56 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 EF8993A63EC for ; Mon, 20 Apr 2009 13:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_50=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 k5vCs-JZy8cS for ; Mon, 20 Apr 2009 13:11:56 -0700 (PDT) Received: from outbound-mail-03.bluehost.com (outbound-mail-03.bluehost.com [69.89.21.13]) by core3.amsl.com (Postfix) with SMTP id 406413A6E18 for ; Mon, 20 Apr 2009 13:11:56 -0700 (PDT) Received: (qmail 18096 invoked by uid 0); 20 Apr 2009 19:11:46 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy1.bluehost.com with SMTP; 20 Apr 2009 19:11:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=h57ZD+3GnomPt239uNcVEezMO1pBnjiJpmdlCNPVZxdw0QxyAXUU5ZRRqEYQLI2GqzS+rpSlYTR0q5n/CYdkwhdOE+5OKF8PIlI3faWyMilzFtnAoXvooYWuLWyoKcE6; 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 1Lvzrb-0003hB-VP; Mon, 20 Apr 2009 14:13:12 -0600 From: "Richard Shockey" To: Date: Mon, 20 Apr 2009 16:12:56 -0400 Message-ID: <024501c9c1f4$65b98d90$312ca8b0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnB9GTWfaWMYBk6R3utHSgnQ+XdJQ== 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} Cc: drinks-req-team@mlist.labs.nic.at Subject: [drinks] Moving forward from SF. 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: Mon, 20 Apr 2009 20:11:57 -0000 I'd like to propose a quick conference call for the Use Case / Requirements design team on next Tuesday April 28 for one hour at either 10 or 11 AM ( preferences ). For this call other members of the DRINKS WG are invited to participate as well. The design team is not going to run indefinitely but needs full input from everyone concerned. The purpose of the call is to review comments and suggestions from SF so that the document authors can continue to revise the document. In addition we agreed in SF to create a parallel Design Team on the actual protocol specification as well. I'd like to use this opportunity to call for volunteers for this effort. The plan would be to have ongoing and regular conference calls by a limited number of people to outline and begin to draft the protocol specification based on the preliminary work of the Use Case / Requirements design team. The chairs will entertain volunteers for the protocol design team. Richard Shockey PSTN Mobile: +1 703.593.2683 skype: rshockey101 LinkedIn : www.linkedin.com/in/rshockey101 From ppfautz@att.com Mon Apr 20 13:25:16 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 60CF73A6951 for ; Mon, 20 Apr 2009 13:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 hj0yq+WIK16H for ; Mon, 20 Apr 2009 13:25:15 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id EC47F3A6E39 for ; Mon, 20 Apr 2009 13:25:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-7.tower-161.messagelabs.com!1240259185!15798163!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 31832 invoked from network); 20 Apr 2009 20:26:25 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-7.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Apr 2009 20:26:25 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3KKQOKt003634; Mon, 20 Apr 2009 16:26:25 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3KKQMkU003609; Mon, 20 Apr 2009 16:26:22 -0400 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: Mon, 20 Apr 2009 16:26:21 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B015660FE@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <49ECD727.3060805@netmagic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] FW: New Liaison Statement, "Liaison to IETF DRINKS Group on a unique international resource for global Service Provider Identification (SPID)" Thread-Index: AcnB9GhUELlC2DOxQGivx3fFCZqwtQAAM2Ag References: <49EC8B8D.9030600@netmagic.com><021401c9c1e9$b663e2f0$232ba8d0$@us> <49ECD727.3060805@netmagic.com> From: "PFAUTZ, PENN L, ATTCORP" To: , "Richard Shockey" Cc: drinks@ietf.org Subject: Re: [drinks] FW: New Liaison Statement, "Liaison to IETF DRINKS Group on a unique international resource for global Service Provider Identification (SPID)" 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: Mon, 20 Apr 2009 20:25:16 -0000 Just want to be sure we're all on the same page - It seems to me that drinks uses a service provider identifier only internally for keeping track of which entities own which data objects or may access them. I would guess that using some previously defined set of IDs (maybe OIDs for instance) would be advantageous but I don't see drinks doing anything with SPID externally. Am I missing something?=20 Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Monday, April 20, 2009 4:12 PM To: Richard Shockey Cc: drinks@ietf.org Subject: Re: [drinks] FW: New Liaison Statement, "Liaison to IETF DRINKS Group on a unique international resource for global Service Provider Identification (SPID)" Hi Rich, > Protocol ( what ever that is) should accommodate the GSPID concept in its > data model the way it would any normal national SPID or ALT-SPID etc > =20 Helpful. It appeared from the SG2 material that DRINKS was spinning up some kind of new SPID.=20 There is today no such thing as a singularity denominated as a SPID. To there extent that a prevailing global service provider identifier has emerged, it appears to be the Enterprise OIDs. So, harmony exists in the world, and there is no need to invent another identifier. best, tony --=20 Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From kcartwright@verisign.com Mon Apr 20 14:44:14 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 C06D928C158 for ; Mon, 20 Apr 2009 14:44:14 -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=[BAYES_00=-2.599, 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 xgedAP-ZzRm0 for ; Mon, 20 Apr 2009 14:44:13 -0700 (PDT) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id D1E2D3A6E40 for ; Mon, 20 Apr 2009 14:44:13 -0700 (PDT) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n3KLICCh001566; Mon, 20 Apr 2009 14:18:52 -0700 Received: from oly1wnexcb02.vcorp.ad.vrsn.com ([10.55.13.57]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 14:45:08 -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); Mon, 20 Apr 2009 14:45:07 -0700 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: Mon, 20 Apr 2009 14:45:06 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] FW: New Liaison Statement, "Liaison to IETF DRINKS Group on a unique international resourcefor global Service Provider Identification (SPID)" Thread-Index: AcnB9GhUELlC2DOxQGivx3fFCZqwtQAAM2AgAAI63SA= References: <49EC8B8D.9030600@netmagic.com><021401c9c1e9$b663e2f0$232ba8d0$@us><49ECD727.3060805@netmagic.com> <35FE871E2B085542A35726420E29DA6B015660FE@gaalpa1msgusr7a.ugd.att.com> From: "Cartwright, Kenneth" To: "PFAUTZ, PENN L, ATTCORP" , , "Richard Shockey" X-OriginalArrivalTime: 20 Apr 2009 21:45:07.0666 (UTC) FILETIME=[45AF9320:01C9C201] Cc: drinks@ietf.org Subject: Re: [drinks] FW: New Liaison Statement, "Liaison to IETF DRINKS Group on a unique international resourcefor global Service Provider Identification (SPID)" 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: Mon, 20 Apr 2009 21:44:14 -0000 I'd tend to agree with that. The drinks work is ongoing, so nothing has been fully fleshed out, but maybe the following is helpful... 1) The implementations of a provisioning protocol need to track the business entity that is responsible for a given object that has been or is being provisioned. A business entity identifier is necessary to accomplish this. =20 2) The provisioning protocol also needs to expose the ability to establish "peering relationships" between business entities. A business entity ID is also necessary to accomplish this. 3) Given that this ID needs to be unique to the widest extent practical, using the IDs from the IANA "Private Enterprise Number (PEN)" as a basis for the ID is definitely a viable (and maybe the best) optional. And if it turns out that this value also morphs into a the "global SPID", then all the better. 4) This identifier could be called an "Enterprise ID", or an "Organization ID", or a GSPID (if we get so bold), or a "Data Recipient ID". Although I think this latter term is too limiting because it ties *one specific* role (Data Recipient) a business entity can fulfill into the name of the data element. Ken -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L, ATTCORP Sent: Monday, April 20, 2009 4:26 PM To: trutkowski@netmagic.com; Richard Shockey Cc: drinks@ietf.org Subject: Re: [drinks] FW: New Liaison Statement,"Liaison to IETF DRINKS Group on a unique international resourcefor global Service Provider Identification (SPID)" Just want to be sure we're all on the same page - It seems to me that drinks uses a service provider identifier only internally for keeping track of which entities own which data objects or may access them. I would guess that using some previously defined set of IDs (maybe OIDs for instance) would be advantageous but I don't see drinks doing anything with SPID externally. Am I missing something?=20 Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Monday, April 20, 2009 4:12 PM To: Richard Shockey Cc: drinks@ietf.org Subject: Re: [drinks] FW: New Liaison Statement, "Liaison to IETF DRINKS Group on a unique international resource for global Service Provider Identification (SPID)" Hi Rich, > Protocol ( what ever that is) should accommodate the GSPID concept in its > data model the way it would any normal national SPID or ALT-SPID etc > =20 Helpful. It appeared from the SG2 material that DRINKS was spinning up some kind of new SPID.=20 There is today no such thing as a singularity denominated as a SPID. To there extent that a prevailing global service provider identifier has emerged, it appears to be the Enterprise OIDs. So, harmony exists in the world, and there is no need to invent another identifier. best, tony -- Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From kcartwright@verisign.com Mon Apr 20 15:04:17 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 B455228C189 for ; Mon, 20 Apr 2009 15:04:17 -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=[BAYES_00=-2.599, 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 Ubg06CRpDBw2 for ; Mon, 20 Apr 2009 15:04:12 -0700 (PDT) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id CF6493A6AF1 for ; Mon, 20 Apr 2009 15:04:12 -0700 (PDT) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n3KM5S3Q005749; Mon, 20 Apr 2009 15:05:28 -0700 Received: from oly1wnexcb01.vcorp.ad.vrsn.com ([10.55.13.56]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 15:05:28 -0700 Received: from OLY1WNEXCB04.vcorp.ad.vrsn.com ([10.55.13.59]) by oly1wnexcb01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 15:05:28 -0700 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: Mon, 20 Apr 2009 15:05:26 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] Confirmation of WG Consensus on adoption usecases 02 as WG item. Thread-Index: AcnB5HNxgkMV+3oxS5yyIhGM6IzKhAAHNaIQ References: <025801c9b94f$ef15d470$cd417d50$@us><018f01c9c1c8$2ac2cfc0$80486f40$@us> <49ECBC5D.20009@netmagic.com> From: "Cartwright, Kenneth" To: , "Richard Shockey" X-OriginalArrivalTime: 20 Apr 2009 22:05:28.0086 (UTC) FILETIME=[1D1CE360:01C9C204] Cc: IETF DRINKS WG , Richard Brackney , Mike Hird Subject: Re: [drinks] Confirmation of WG Consensus on adoption usecases 02 as WG item. 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: Mon, 20 Apr 2009 22:04:17 -0000 Hi Tony, Thanks for the feedback. In think the term Public Identity was chosen, in part, because of its familiarity from a similar concept in 3GPP, "Public User Identity", and its nice contrast with the sister term "Private User Identity". In general, the word "Public" means that "this is the identity you tell people to use to contact you". This contrasts with the word "Private" in "Private User Identity", which means "this is the identity you (or the underlying system) can use to authenticate yourself". There was much discussion about other terms that contained "endpoint" and variations. But none seemed to fit quite as well, while also not stepping on other terms. More specifically, the term "end point" was discussed and thought to refer too often to a physical device that may be somewhere in the call routing flow (not necessarily the end device the user was using), as apposed to the logical identity of a "person". And the term "call routing identifier" could refer to any logical or physical entity involved in the call routing or even to the entire call routing flow of a given call. Ken -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Monday, April 20, 2009 2:18 PM To: Richard Shockey Cc: 'IETF DRINKS WG'; Richard Brackney; Mike Hird Subject: Re: [drinks] Confirmation of WG Consensus on adoption usecases 02 as WG item. Hi Rich, > I'm assuming silence is consent and the document is question is a WG=20 > document. > =20 > Public Identity: A generic term that refers to a telephone number > (TN), an email address, or other identity as deemed appropriate, > such as a globally routable URI of a user address (e.g., > mailto:john.doe@example.net). The use of "public identity" in this draft creates a new term that seems both unnecessary and out of sync with the concepts being followed in the Identity Management community. It is not clear why the term "public" is needed, and can give rise to substantial confusion. Additionally, what is defined in the draft is customarily known as an "identifier," rather than an identity.=20 The potential confusion arises, for example, in Use Case #6 where reference is make to taking a public identity "out of service," as well as Freq 4, where reference is made to a "carrier of record for a public identity."=20 >From the context of this work, you might want to consider alternatively a term like "signalling endpoint identifier" or "call routing identifier." Hope this is useful. I've copied both some of the folks involved with international identity management terminology and specifications. best --tony -- Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From trutkowski@netmagic.com Mon Apr 20 17:43:24 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 694A73A6A0B for ; Mon, 20 Apr 2009 17:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599] 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 R2N-vQDh0kmL for ; Mon, 20 Apr 2009 17:43:23 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by core3.amsl.com (Postfix) with ESMTP id EADC33A6900 for ; Mon, 20 Apr 2009 17:43:22 -0700 (PDT) Received: from [192.168.1.3] ([72.86.34.21]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KIF00E0QE23DAV6@vms173017.mailsrvcs.net> for drinks@ietf.org; Mon, 20 Apr 2009 19:44:28 -0500 (CDT) Message-id: <49ED16EB.7050705@netmagic.com> Date: Mon, 20 Apr 2009 20:44:27 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-version: 1.0 To: "Cartwright, Kenneth" References: <025801c9b94f$ef15d470$cd417d50$@us><018f01c9c1c8$2ac2cfc0$80486f40$@us> <49ECBC5D.20009@netmagic.com> In-reply-to: Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Cc: IETF DRINKS WG , Mike Hird , Richard Brackney , Richard Shockey Subject: Re: [drinks] Confirmation of WG Consensus on adoption usecases 02 as WG item. X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 00:43:24 -0000 Hi Ken, > In think the term Public Identity was chosen, in part, because of its > familiarity from a similar concept in 3GPP, "Public User Identity", and > its nice contrast with the sister term "Private User Identity". In > general, the word "Public" means that "this is the identity you tell > people to use to contact you". This contrasts with the word "Private" > in "Private User Identity", which means "this is the identity you (or > the underlying system) can use to authenticate yourself". > In fact, "public" implies in communications law an implementation pursuant to a regulatory requirement. The use of the term "Public User Identity" in 3GPP standards is done to meet those requirements - that notably include government to user, and user to government messaging requirements. As used in those standards, it implies additional proofing that makes the string an *identity* rather than an *identifier.* You can see the extensive use of the term in this context by using ETSI's TEDDI term discovery service at: http://webapp.etsi.org/Teddi/ In the DRINKS draft, you've taken the 3GPP/ETSI term and redefined it quite differently - in fact as you note - as an open-ended generic identifier for any kind of SIP purpose, devoid of any proofing. The approach here potentially creates security vulnerabilities that deserve mention. If you're really wedded to the term and notion, you should either include some sense of proofing other that mere self-asserted "routability," or else use the term "identifier." If you want to check the significance of the use of these concepts and terms, you can reference ITU-T Rec. X.1250 (Baseline capabilities for enhanced global identity management trust and interoperability). --tony (X.1250 editor) From kcartwright@verisign.com Tue Apr 21 08:06: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 CF05B3A6842 for ; Tue, 21 Apr 2009 08:06:12 -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=[BAYES_00=-2.599, 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 PbcVp06Snf7y for ; Tue, 21 Apr 2009 08:06:11 -0700 (PDT) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 98D7B3A6910 for ; Tue, 21 Apr 2009 08:05:38 -0700 (PDT) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n3LF6YD0004114; Tue, 21 Apr 2009 08:06:54 -0700 Received: from oly1wnexcb01.vcorp.ad.vrsn.com ([10.55.13.56]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 08:06:46 -0700 Received: from OLY1WNEXCB04.vcorp.ad.vrsn.com ([10.55.13.59]) by oly1wnexcb01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 08:06:46 -0700 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: Tue, 21 Apr 2009 08:06:45 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] Confirmation of WG Consensus on adoption usecases 02 as WG item. Thread-Index: AcnCGle+gD2M9WXeTSSagaIJxfEonwAcXB4Q References: <025801c9b94f$ef15d470$cd417d50$@us><018f01c9c1c8$2ac2cfc0$80486f40$@us> <49ECBC5D.20009@netmagic.com> <49ED16EB.7050705@netmagic.com> From: "Cartwright, Kenneth" To: X-OriginalArrivalTime: 21 Apr 2009 15:06:46.0534 (UTC) FILETIME=[C9EA0260:01C9C292] Cc: IETF DRINKS WG , Mike Hird , Richard Brackney , Richard Shockey Subject: Re: [drinks] Confirmation of WG Consensus on adoption usecases 02 as WG item. 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: Tue, 21 Apr 2009 15:06:12 -0000 Hi Tony, Thanks for this background on the legal connotation that can underlie the word "public". In think this is certainly worth considering as the drinks work moves forward and may have important implications for the drinks use cases and requirements. However, I think you've taken some liberties with what I said. I did not say that we've "taken the 3GPP/ETSI term and redefined it quite differently". We've definitely not even *attempted* to re-define the 3GPP term, we've not even quite used the same term, much less attempted to redefine it. Nor did I say that we've defined it "as an open-ended generic identifier for any kind of SIP purpose, devoid of any proofing". I'm not sure what you mean by "any kind of purpose". I certainly would not suggest such a definition for our use of the term "Public Identity" in the use case document. Now the idea of proofing is certainly an important one. And as the drinks requirements work moves forward it will be important to clarify the role that proofing should play. And I'm certainly not apposed to the use of a term different from "Public Identity". Lastly, in addition to the legal connotation behind the word "public" that you explain, here is a quote from two of the designers of 3GPP as co-authors of the book "The 3G IP Multimedia Subsystem" from Wiley: "3.5.1 Public User Identities In the IMS there is also a deterministic way to identify users. An IMS user is allocated with one or more Public User Identities. The home operator is responsible for allocating these Public User Identities to each IMS subscriber. A Public User Identity is a SIP URI [snip] or a Tel URI [snip]. Public User Identities are used as contact information on business cards." So I do not see how my informal statement, "this is the identity you tell people to use to contact you", conflicts with the above. And just to be clear, drinks is certainly not attempting to create the 3GPP IMS. Also from "The 3G IP Multimedia Subsystem": "3.5.2 Private User Identities Each IMS subscriber is assigned a Private User Identity. [snip] Unlike Public User Identities, Private User Identities are not used for routing SIP requests; instead, they are used for subscription identification and authentication purposes." Ken -----Original Message----- From: Tony Rutkowski [mailto:trutkowski@netmagic.com]=20 Sent: Monday, April 20, 2009 8:44 PM To: Cartwright, Kenneth Cc: Richard Shockey; IETF DRINKS WG; Richard Brackney; Mike Hird Subject: Re: [drinks] Confirmation of WG Consensus on adoption usecases 02 as WG item. Hi Ken, > In think the term Public Identity was chosen, in part, because of its=20 > familiarity from a similar concept in 3GPP, "Public User Identity",=20 > and its nice contrast with the sister term "Private User Identity". =20 > In general, the word "Public" means that "this is the identity you=20 > tell people to use to contact you". This contrasts with the word "Private" > in "Private User Identity", which means "this is the identity you (or=20 > the underlying system) can use to authenticate yourself". > =20 In fact, "public" implies in communications law an implementation pursuant to a regulatory requirement. The use of the term "Public User Identity" in 3GPP standards is done to meet those requirements - that notably include government to user, and user to government messaging requirements. As used in those standards, it implies additional proofing that makes the string an *identity* rather than an *identifier.* You can see the extensive use of the term in this context by using ETSI's TEDDI term discovery service at:=20 http://webapp.etsi.org/Teddi/ In the DRINKS draft, you've taken the 3GPP/ETSI term and redefined it quite differently - in fact as you note - as an open-ended generic identifier for any kind of SIP purpose, devoid of any proofing. The approach here potentially creates security vulnerabilities that deserve mention. If you're really wedded to the term and notion, you should either include some sense of proofing other that mere self-asserted "routability," or else use the term "identifier." If you want to check the significance of the use of these concepts and terms, you can reference ITU-T Rec. X.1250 (Baseline capabilities for enhanced global identity management trust and interoperability). --tony (X.1250 editor) From trutkowski@netmagic.com Tue Apr 21 08:23:43 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 218A128C1E7 for ; Tue, 21 Apr 2009 08:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599] 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 9piA5ouRJKyO for ; Tue, 21 Apr 2009 08:23:42 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by core3.amsl.com (Postfix) with ESMTP id 6896828C1DC for ; Tue, 21 Apr 2009 08:23:42 -0700 (PDT) Received: from [192.168.1.3] ([72.86.34.21]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KIG003Y0ITI2UCH@vms173005.mailsrvcs.net> for drinks@ietf.org; Tue, 21 Apr 2009 10:24:58 -0500 (CDT) Message-id: <49EDE546.4060008@netmagic.com> Date: Tue, 21 Apr 2009 11:24:54 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-version: 1.0 To: "Cartwright, Kenneth" References: <025801c9b94f$ef15d470$cd417d50$@us><018f01c9c1c8$2ac2cfc0$80486f40$@us> <49ECBC5D.20009@netmagic.com> <49ED16EB.7050705@netmagic.com> In-reply-to: Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Cc: IETF DRINKS WG , Mike Hird , Richard Brackney , Richard Shockey Subject: Re: [drinks] Confirmation of WG Consensus on adoption usecases 02 as WG item. X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 15:23:43 -0000 Hi Ken, When I used the term "you," it was meant in the plural. Sorry for the confusion. I should have said "DRINKS." Hopefully the discussion has been useful. It is one that is occurring in an enormous number of Identity Management and related venues worldwide. The choice of some variant of "identifier" as Mike Hird notes, would be a good one for the reasons he provided, and help DRINKS harmonization within the prevailing ontology. best, tony -- Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 From mmaharishi@verisign.com Tue Apr 21 10:09:54 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 A34D43A69CF for ; Tue, 21 Apr 2009 10:09:54 -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=[BAYES_00=-2.599, 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 Kcr4akMqcta9 for ; Tue, 21 Apr 2009 10:09:53 -0700 (PDT) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id AB3E03A697F for ; Tue, 21 Apr 2009 10:09:53 -0700 (PDT) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n3LHB9sw009894; Tue, 21 Apr 2009 10:11:09 -0700 Received: from oly1wnexcb01.vcorp.ad.vrsn.com ([10.55.13.56]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 10:11:09 -0700 Received: from OLY1WNEXCB04.vcorp.ad.vrsn.com ([10.55.13.59]) by oly1wnexcb01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 10:11:08 -0700 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: Tue, 21 Apr 2009 10:11:08 -0700 Message-ID: <7E039AD2FAAF284B81A3A601E11D0BC8518C1F@OLY1WNEXCB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] Moving forward from SF. Thread-Index: AcnB9GTWfaWMYBk6R3utHSgnQ+XdJQAr6vwA References: <024501c9c1f4$65b98d90$312ca8b0$@us> From: "Maharishi, Manjul" To: "Richard Shockey" , X-OriginalArrivalTime: 21 Apr 2009 17:11:08.0988 (UTC) FILETIME=[29E21FC0:01C9C2A4] Cc: drinks-req-team@mlist.labs.nic.at Subject: Re: [drinks] Moving forward from SF. 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: Tue, 21 Apr 2009 17:09:54 -0000 Hi Rich, 10 Eastern for 4/28 works better for me.=20 Thanks. Manjul Maharishi=20 -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, April 20, 2009 4:13 PM To: drinks@ietf.org Cc: drinks-req-team@mlist.labs.nic.at Subject: [drinks] Moving forward from SF. I'd like to propose a quick conference call for the Use Case / Requirements design team on next Tuesday April 28 for one hour at either 10 or 11 AM ( preferences ). For this call other members of the DRINKS WG are invited to participate as well. The design team is not going to run indefinitely but needs full input from everyone concerned. The purpose of the call is to review comments and suggestions from SF so that the document authors can continue to revise the document. In addition we agreed in SF to create a parallel Design Team on the actual protocol specification as well. I'd like to use this opportunity to call for volunteers for this effort. The plan would be to have ongoing and regular conference calls by a limited number of people to outline and begin to draft the protocol specification based on the preliminary work of the Use Case / Requirements design team.=20 The chairs will entertain volunteers for the protocol design team. Richard Shockey PSTN Mobile: +1 703.593.2683 skype: rshockey101=20 LinkedIn : www.linkedin.com/in/rshockey101 _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From kcartwright@verisign.com Tue Apr 21 10:16:25 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 B5FF13A6AC8 for ; Tue, 21 Apr 2009 10:16:25 -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.000, BAYES_00=-2.599, 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 dfeiz77PEBqg for ; Tue, 21 Apr 2009 10:16:24 -0700 (PDT) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id 918AB3A6C3A for ; Tue, 21 Apr 2009 10:16:23 -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 n3LGoK9m007105; Tue, 21 Apr 2009 09:51:01 -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); Tue, 21 Apr 2009 10:17:10 -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); Tue, 21 Apr 2009 10:17:10 -0700 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: Tue, 21 Apr 2009 10:17:09 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] Moving forward from SF. Thread-Index: AcnB9GTWfaWMYBk6R3utHSgnQ+XdJQAr6vwAAAA6q8A= References: <024501c9c1f4$65b98d90$312ca8b0$@us> <7E039AD2FAAF284B81A3A601E11D0BC8518C1F@OLY1WNEXCB04.vcorp.ad.vrsn.com> From: "Cartwright, Kenneth" To: "Maharishi, Manjul" , "Richard Shockey" , X-OriginalArrivalTime: 21 Apr 2009 17:17:10.0126 (UTC) FILETIME=[012368E0:01C9C2A5] Cc: drinks-req-team@mlist.labs.nic.at Subject: Re: [drinks] Moving forward from SF. 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: Tue, 21 Apr 2009 17:16:25 -0000 I'm fine with that as well.=20 -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Maharishi, Manjul Sent: Tuesday, April 21, 2009 1:11 PM To: Richard Shockey; drinks@ietf.org Cc: drinks-req-team@mlist.labs.nic.at Subject: Re: [drinks] Moving forward from SF. Hi Rich, 10 Eastern for 4/28 works better for me.=20 Thanks. Manjul Maharishi=20 -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, April 20, 2009 4:13 PM To: drinks@ietf.org Cc: drinks-req-team@mlist.labs.nic.at Subject: [drinks] Moving forward from SF. I'd like to propose a quick conference call for the Use Case / Requirements design team on next Tuesday April 28 for one hour at either 10 or 11 AM ( preferences ). For this call other members of the DRINKS WG are invited to participate as well. The design team is not going to run indefinitely but needs full input from everyone concerned. The purpose of the call is to review comments and suggestions from SF so that the document authors can continue to revise the document. In addition we agreed in SF to create a parallel Design Team on the actual protocol specification as well. I'd like to use this opportunity to call for volunteers for this effort. The plan would be to have ongoing and regular conference calls by a limited number of people to outline and begin to draft the protocol specification based on the preliminary work of the Use Case / Requirements design team.=20 The chairs will entertain volunteers for the protocol design team. Richard Shockey PSTN Mobile: +1 703.593.2683 skype: rshockey101=20 LinkedIn : www.linkedin.com/in/rshockey101 _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From richard@shockey.us Tue Apr 21 10:18:45 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 5A9BE3A6832 for ; Tue, 21 Apr 2009 10:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.472 X-Spam-Level: X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_50=0.001, GB_I_INVITATION=-2, 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 v1yaxuzcqFgY for ; Tue, 21 Apr 2009 10:18:43 -0700 (PDT) Received: from outbound-mail-307.bluehost.com (outbound-mail-307.bluehost.com [67.222.53.253]) by core3.amsl.com (Postfix) with SMTP id BE8093A67B1 for ; Tue, 21 Apr 2009 10:18:43 -0700 (PDT) Received: (qmail 2626 invoked by uid 0); 21 Apr 2009 17:13:26 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 21 Apr 2009 17:13:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:thread-index:Content-Language:X-Identified-User; b=JsPON9XTLuiLH+qcw9fe9RCh05wCNrfZxgS0lBEOwAGbgnt3dhsh3yn/3/u9pMdYIRNuFpv1gJY9JHckuOvitP6EOgeZAKHgjQTg6/xC3lLhZTEbJGhnE/JNNTm227gt; 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 1LwJdX-0003Au-H1; Tue, 21 Apr 2009 11:20:00 -0600 From: "Richard Shockey" To: Date: Tue, 21 Apr 2009 13:19:42 -0400 Message-ID: <017701c9c2a5$5cf5ba10$16e12e30$@us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0178_01C9C283.D5E41A10" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcnCpEVOIsIIxAKySuy73cbWdh0NfwAAPFiA 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} Cc: drinks-req-team@mlist.labs.nic.at Subject: [drinks] FW: Conference Call Confirmation DRINKS 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: Tue, 21 Apr 2009 17:18:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0178_01C9C283.D5E41A10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0179_01C9C283.D5E41A10" ------=_NextPart_001_0179_01C9C283.D5E41A10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I had more folks request 11 than 10 am if it is a problem I can easily = reschedule. =20 From: reservations@conferencemgr.com = [mailto:reservations@conferencemgr.com]=20 Sent: Tuesday, April 21, 2009 1:12 PM To: Richard Shockey Subject: Conference Call Confirmation =20 Your Conference Is Confirmed = =20 Richard Shockey, the conference call you scheduled has been confirmed. = Any invitations you elected to send to the Participants have been mailed. = How do I change = or cancel this conference? =20 =20 Conference Details =20 =20 =09 Scheduled Conference Date: Tuesday, April 28, 2009 Scheduled Start Time: 11:00 AM Eastern Daylight Time Scheduled End Time: 11:25 AM Eastern Daylight Time Scheduled # of Participants: 30 Type of Conference: Standard Dial-in Number: 1-712-580-8025 (Midwest)=20 Participant Access Code: 654087 Organizer Access Code: *129592 (you must include the leading star key) Conference Controls: Conversation Mode (all Participants can be heard) Entry Chimes - Enabled Exit Chimes - Enabled =20 Note: The Organizer Access Code is only necessary for use of enhanced = conference controls. Otherwise, you can just use the Participant Access = Code.=20 E-mail Invitations: 0 Sent Subject: =09 Comments/Agenda: =09 Invitation Recipients: =09 =20 Conference Booked by Richard Shockey on Tuesday, April 21, 2009 at 01:11 = PM Eastern Daylight Time Conference Touch-Tone Quick Reference Touch-tone Controls = = 5, 7, 9 and # are available only to the conference Organizer =E2=80=A0 Conference Muting Modes: Conversation Mode, Q&A Mode, = Presentation Mode =E2=80=A1 Chimes settings: Entry on/Exit on, Entry on/Exit off, Entry = off/Exit on, Entry off/Exit off See you there! =20 ------=_NextPart_001_0179_01C9C283.D5E41A10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Conference Confirmation

I had more folks request 11 than 10 am if it is a problem = I can easily reschedule.

 

From: reservations@conferencemgr.com [mailto:reservations@conferencemgr.com]
Sent: Tuesday, April 21, 2009 1:12 PM
To: Richard Shockey
Subject: Conference Call Confirmation

 

3D"Your

Richard S= hockey, the conference call you scheduled has been confirmed.  Any invitations you
elected to send to the Participants have been = mailed.

How do I change or cancel this = conference?

=

 

Conference Details

=

 

Scheduled Conference Date:

Tuesday, April 28, 2009

Scheduled Start Time:

11:00 AM Eastern Daylight Time

Scheduled End Time:

11:25 AM Eastern Daylight Time

Scheduled # of Participants:

30<= /span>

Type of Conference:

Standard<= /o:p>

Dial-in Number:

1-712-580-8025=  (Midwest)

Participant Access Code:

654087

Organizer Access Code:

*129592 (you must = include the leading star key)

Conference Controls:

Conversation Mode (all Participants can be heard)
Entry Chimes - Enabled
Exit Chimes - Enabled

Note: The Organizer Access Code is only necessary for use of enhanced conference controls.  Otherwise, you can just use the Participant Access Code.

E-mail Invitations:

0 Sent

Subject:<= /o:p>

Comments/Agend= a:

Invitation Recipients:

 

Conference Booked by Richard Shockey on Tuesday, April 21, 2009 at 01:11 PM Eastern Daylight Time

Conference Touch-Tone Quick = Reference

3D"Touch-tone

5, 7, 9 = and # are available only to the conference Organizer

=E2=80=A0 Conference Muting Modes: Conversation Mode, Q&A Mode, Presentation = Mode

=E2=80=A1 Chimes settings: Entry on/Exit on, Entry on/Exit off, Entry off/Exit = on, Entry off/Exit off

See you there!

 

------=_NextPart_001_0179_01C9C283.D5E41A10-- ------=_NextPart_000_0178_01C9C283.D5E41A10 Content-Type: text/x-vCalendar; name="Calendar Item.vcs" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Calendar Item.vcs" BEGIN:VCALENDAR PRODID:-//Global Conference Partners//Conference Call Event//EN VERSION:1.0 BEGIN:VEVENT DTSTART:20090428T150000Z DTEND:20090428T152500Z LOCATION;ENCODING=3DQUOTED-PRINTABLE:FreeConference.com Conference = Bridge 1-712-580-8025 UID:acde9668-85b1-4c7f-9cfc-c4e8033d1cc2 CATEGORIES;ENCODING=3DQUOTED-PRINTABLE:Conference SUMMARY;ENCODING=3DQUOTED-PRINTABLE:Conference Call DESCRIPTION:Please Call Dial-in Number: 1-712-580-8025 (Midwest)\n\n = Your Organizer Access Code is: *129592.\n\n (The Participant Access Code = is: 654087.)\n\n For details, click here: = http://www.freeconference.com\n\n Comments/Agenda:\n\n \n PRIORITY:3 END:VEVENT END:VCALENDAR ------=_NextPart_000_0178_01C9C283.D5E41A10-- From dguyton@telcordia.com Tue Apr 28 15:11:16 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 1CA403A67E1 for ; Tue, 28 Apr 2009 15:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, 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 cVExy4IvFpB6 for ; Tue, 28 Apr 2009 15:11:14 -0700 (PDT) Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by core3.amsl.com (Postfix) with ESMTP id B7DB63A70D7 for ; Tue, 28 Apr 2009 15:10:46 -0700 (PDT) Received: from pya-dte-ieg01.dte.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1rrc.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id n3SMC707023260 for ; Tue, 28 Apr 2009 18:12:07 -0400 (EDT) X-AuditID: 80601415-00000d340000055c-fb-49f77f330a02 Received: from pya-dte-exhb1.dte.telcordia.com ([128.96.20.11]) by pya-dte-ieg01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 18:12:03 -0400 Received: from rrc-dte-exmb2.dte.telcordia.com ([128.96.180.27]) by pya-dte-exhb1.dte.telcordia.com ([128.96.20.11]) with mapi; Tue, 28 Apr 2009 18:12:03 -0400 From: "Guyton, Deborah A" To: "drinks@ietf.org" Date: Tue, 28 Apr 2009 18:12:03 -0400 Thread-Topic: Notes for DRINKS WG next steps Conference Call held April 28, 2009 Thread-Index: AcnCpEVOIsIIxAKySuy73cbWdh0NfwAAPFiAAWnwJSA= Message-ID: In-Reply-To: <017701c9c2a5$5cf5ba10$16e12e30$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_AE85DAD2723E724EAB2A704148DE15AC27E6870FDDrrcdteexmb2dt_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "drinks-req-team@mlist.labs.nic.at" Subject: [drinks] Notes for DRINKS WG next steps Conference Call held April 28, 2009 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: Tue, 28 Apr 2009 22:11:16 -0000 --_004_AE85DAD2723E724EAB2A704148DE15AC27E6870FDDrrcdteexmb2dt_ Content-Type: multipart/alternative; boundary="_000_AE85DAD2723E724EAB2A704148DE15AC27E6870FDDrrcdteexmb2dt_" --_000_AE85DAD2723E724EAB2A704148DE15AC27E6870FDDrrcdteexmb2dt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To all DRINKS WG members, Attached are the notes for the DRINKS WG call held today, April 28, 2009 to= discuss: 1) next steps for the WG draft document on use cases and requirements= for provisioning a Registry 2) getting a team of volunteers to draft a document and protocol for = the Registry interface Debbie Guyton, DRINKS WG Secretary --_000_AE85DAD2723E724EAB2A704148DE15AC27E6870FDDrrcdteexmb2dt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Conference Confirmation

To all DRINKS WG members,

Attached are the notes for the DRINKS = WG call held today, April 28, 2009 to discuss:

1)      = next steps for the WG draft document on use c= ases and requirements for provisioning a Registry

2)      = getting a team of volunteers to draft a docum= ent and protocol for the Registry interface

 

Debbie Guyton,

DRINKS WG Secretary<= /font>

 

 

--_000_AE85DAD2723E724EAB2A704148DE15AC27E6870FDDrrcdteexmb2dt_-- --_004_AE85DAD2723E724EAB2A704148DE15AC27E6870FDDrrcdteexmb2dt_ Content-Type: text/plain; name="DRINKS WG call 28Apr2009.txt" Content-Description: DRINKS WG call 28Apr2009.txt Content-Disposition: attachment; filename="DRINKS WG call 28Apr2009.txt"; size=2901; creation-date="Tue, 28 Apr 2009 17:26:08 GMT"; modification-date="Tue, 28 Apr 2009 18:00:36 GMT" Content-Transfer-Encoding: base64 RFJJTktTIFdHIENhbGwNCg0KQXByaWwgMjgsIDIwMDkNCg0KQ2FsbCBub3RlcyBmcm9tIERlYmJp ZSBHdXl0b24sIFdvcmtpbmcgR3JvdXAgU2VjcmV0YXJ5DQoNCkF0dGVuZGVlczoNCg0KUmljaGFy ZCBTY2hvY2tleSAtIERSSU5LUyBXRyBjby1jaGFpcg0KUGVubiBQZmF1dHoNCkRlYmJpZSBHdXl0 b24NCktlbiBDYXJ0d3JpZ2h0DQpTdW1hbnRoIENoYW5uYWJhc2FwcGENClNwZW5jZXIgRGF3a2lu cw0KSmVhbi1GcmFuY29pcyBNdWxlDQpNYW5qdWwgTWFoYXJpc2hpDQpEb3VnIFJpbmFsbGkNCg0K QWdlbmRhIFRvcGljcw0KDQpQZXIgUmljaGFyZCBTY2hvY2tleSwgdGhlIGZvbGxvd2luZyB0d28g aXRlbXMgd2lsbCBiZSBkaXNjdXNzZWQgb24gdGhpcyBjYWxsOg0KMS4gVXNlIENhc2UgYW5kIFJl cXVpcmVtZW50cyBXRyBkb2N1bWVudCAtIG5leHQgc3RlcHMgdG8gbW92ZSBpdCBmb3J3YXJkDQoy LiBGb3JtIGEgcGFyYWxsZWwgZWZmb3J0IGFzIGEgd29ya2luZyBjb21taXR0ZWUgdG8gZHJhZnQg YSBwcm90b2NvbCBkb2N1bWVudCBhbmQgYSBjYWxsIGZvciB2b2x1bnRlZXJzDQoNCkRpc2N1c3Np b24gb2YgVG9waWMgMQ0KDQpSaWNoYXJkIGFza2VkIFN1bWFudGggdG8gcmV2aWV3IHdoZXJlIHdl IGFyZSBhdCB3aXRoIHJlc3BlY3QgdG8gdGhlIFVzZSBDYXNlIGFuZCBSZXF1aXJlbWVudHMgV0cg ZG9jdW1lbnQuIFN1bWFudGggc3VtbWFyaXplZCB0aGF0IHBlb3BsZSwgaW4gZ2VuZXJhbCwgaGFk IG5vIG9iamVjdGlvbnMgdG8gdGhlIFdHIGRvY3VtZW50OyBob3dldmVyLCB0aGVyZSB3ZXJlIHNv bWUgY29tbWVudHMgb246DQogMSkgdGVybWlub2xvZ3kgYWx0ZXJuYXRpdmUgc3VnZ2VzdGlvbnMN CiAyKSBhZGRpdGlvbmFsIHVzZSBjYXNlcyB0byBjb25zaWRlci4NCkFsdGhvdWdoIHRoZXJlIGFy ZSBtdWx0aXBsZSB3YXlzIHRvIHByb2NlZWQsIGhlIHN1Z2dlc3RlZCB0aGF0IHdlIHVwZGF0ZSB0 aGUgY3VycmVudCBkcmFmdCBkb2N1bWVudCB3aXRoIHRoZSBXb3JraW5nIEdyb3VwIHRlcm1pbm9s b2d5IGFuZCB0aGVuIHdvcmsgb24gdGhlIGFkZGl0aW9uYWwgdXNlIGNhc2VzIGlkZW50aWZpZWQg aW4gc29tZSBvZiB0aGUgZW1haWwgZXhjaGFuZ2VzLiBTdW1hbnRoIHRob3VnaHQgdGhhdCBoZSBj b3VsZCBtYWtlIHNvbWUgb2YgdGhlIG1pbm9yIGVkaXRvcmlhbCBjaGFuZ2VzIGFuZCBhbGlnbiB0 aGUgdGVybWlub2xvZ3kgaW4gdGhlIG5leHQgY291cGxlIG9mIHdlZWtzLg0KDQpSaWNoYXJkIHNh aWQgdGhhdCBoZSB3YW50ZWQgYSBXRyBkcmFmdCBkb25lIHNvb24gdG8gbWFrZSB0aGlzIHRoZSBv ZmZpY2lhbCBkb2N1bWVudCBmb3IgdGhlIFdHIGFuZCBnZXQgaXQgaW50byB0aGUgSUVURiBhcmNo aXZlcyBjb3JyZWN0bHkuDQoNClJpY2hhcmQgYWxzbyBzaGFyZWQgdGhhdCB0aGUgUkFJIGhhZCBi ZWVuIHJlb3JnYW5pemVkLiBDdWxsZW4gSmVubmluZ3Mgd2lsbCBiZSB0aGUgUkFJIGRpcmVjdG9y IGZvciBEUklOS1MsIGFsc28gU1BFRVJNSU5UIGFuZCBFTlVNLCBhbmQgaXMgZ2VuZXJhbGx5IHN1 cHBvcnRpdmUgb2Ygd2hhdCB3ZSBhcmUgZG9pbmcuDQoNCkRpc2N1c3Npb24gb2YgVG9waWMgMg0K DQpSaWNoYXJkIHNhaWQgdGhhdCB0aGVyZSBuZWVkcyB0byBiZSBhIHByb3RvY29sIGRvY3VtZW50 IG93bmVyLiBKZWFuLUZyYW5jb2lzIE11bGUgaW1tZWRpYXRlbHkgdm9sdW50ZWVyZWQuICBNYW5q dWwgYW5kIERlYmJpZSBhbHNvIHZvbHVudGVlcmVkLiBSaWNoYXJkIHJlcXVlc3RlZCB0aGF0IGVh Y2ggdm9sdW50ZWVyIGZvcm1hbGx5IHZvbHVudGVlciBieSBzZW5kaW5nIGFuIGVtYWlsIHRvIHRo ZSBEUklOS1MgY28tY2hhaXJzLCBSaWNoYXJkIFNob2NrZXkgYW5kIEFsZXhhbmRlciBNYXlyaG9m ZXIsIGFuZCB0aGUgV0cgU2VjcmV0YXJ5LCBEZWJiaWUgR3V5dG9uLg0KDQpSaWNoYXJkIHNhaWQg dGhhdCBoZSBhbmQgQWxleCB3b3VsZCBiZSB0YWxraW5nIG9mZmxpbmUgdG8gZGlzY3VzcyBwbGFu bmluZyBmb3IgU3RvY2tob2xtLiBIZSB3YXMgaG9waW5nIHRoYXQgYSBkcmFmdCBjb3VsZCBiZSBh dmFpbGFibGUgZm9yIHRoYXQgbWVldGluZy4NCg0KSGUgc2FpZCB0aGF0IHRoZXJlIHdhcyBhIGNv bnNlbnN1cyBpbiBhIHBhc3QgV0cgbWVldGluZyB0aGF0IHRoZSBwcm90b2NvbCBiZSBTT0FQL1hN TC4gSGUgYXNrZWQgaWYgdGhhdCB3YXMgc3RpbGwgZXZlcnlvbmUncyB1bmRlcnN0YW5kaW5nLiBU aGVyZSB3YXMgYWdyZWVtZW50Lg0KDQpDT05TRU5TVVM6IFdlIHdpbGwgdXNlIFNPQVAvWE1MLg0K DQpKZWFuLUZyYW5jb2lzIHNhaWQgdGhhdCBoZSB3b3VsZCBtb2RlcmF0ZSBhIHNldCBvZiBjYWxs cyB0aGF0IHdvdWxkIGZvY3VzIG9uIGRldmVsb3BtZW50IG9mIGEgZHJhZnQgZG9jdW1lbnQgYW5k IHByb3RvY29sIGJlZm9yZSBTdG9ja2hvbG0uIFJpY2hhcmQgc3VnZ2VzdGVkIHdlIHN0YXJ0IG5l eHQgd2Vlay4gSXQgd2FzIHN1Z2dlc3RlZCB0aGF0IHRvIG1ha2UgZ29vZCBwcm9ncmVzcyB3ZSBz aG91bGQgaWRlbnRpZnkgYW55IGlzc3VlcyBlYXJseSBvbiBpbiB0aGUgZGlzY3Vzc2lvbnMuICBU aGVyZSB3YXMgYWdyZWVtZW50IG9uIHRoaXMgcGxhbi4NCg0KSmVhbi1GcmFuY29pcyB3aWxsIGJl IHNldHRpbmcgdXAgYSBEb29kbGUgd2l0aCBzb21lIHN1Z2dlc3RlZCBiZXN0IHRpbWVzIHRvIGhh dmUgdGhlIGNhbGxzIGFuZCBmb2xrcyBjYW4gY2hvb3NlIHRob3NlIGJlc3QgZm9yIHRoZW0uDQoN CkFzIHJlcXVlc3RlZCBhdCB0aGUgRFJJTktTIFdHIG1lZXRpbmcsIHRoZSBub3RlcyBvZiB0aGlz IGNhbGwgYW5kIGFsbCBjYWxscyB3aWxsIGJlIGRpc3RyaWJ1dGVkIGJ5IERlYmJpZSB0byB0aGUg ZnVsbCBEUklOS1MgV0cgZW1haWwgbGlzdC4NCg0KVGhlIGNhbGwgZW5kZWQuDQoNCg0K --_004_AE85DAD2723E724EAB2A704148DE15AC27E6870FDDrrcdteexmb2dt_--