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-requirements -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.txt 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.