IETF 75 DRINKS Agenda (Stockholm, Sweden) ================================================= Data for Reachability of Inter/tra-NetworK SIP (drinks) Date: MONDAY, July 27, 2009 Time: 1520-1720 Afternoon Session II, Location: Congresshall A Chair(s): Richard Shockey Alexander Mayrhofer WG Secretary: Debbie Guyton RAI Director(s): Cullen Jennings Robert Sparks RAI Area Advisor: Cullen Jennings fluffy@cisco.com Session Agenda ============== Welcome & Agenda Bashing (5m) Notes: Active Jabber session. Alex reviewed the agenda. Alex will be Jabber scribe. Debbie reviewed the status of documents. A. Status of the Usecases Requirements Document. (25m) : DRINKS Use cases and Protocol Requirements Author(s) : S. Channabasappa Filename : draft-ietf-drinks-usecases-requirements-00.txt Pages : 22 Date : 2009-05-27 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-ietf-drinks-usecases-requirements-00.txt Notes: Sumanth discussed the draft. The plan is to be kept in sync as the protocol draft progresses. He acknowedged recent comments on the list from David Schwartz. Alex mentioned that it is pretty stable. Please provide other use cases if you see some that should be incorporated. We have also identified that some of the use cases are pretty complex. The plan is to release this milestone before the protocol document. D. Schwartz: Would like to see definitions in one place, also architecture in one place. David suggested we put these in either the requirements or protocol document. There are missing use cases. Rich said please post use cases ASAP so that we can address them. We are trying to incorporate any input received into the draft. B. New Business. (40m) Title : Session Peering Provisioning Protocol Author(s) : J. Mule, et al. Filename : draft-mule-drinks-proto-01.txt Pages : 43 Date : 2009-07-13 This document defines a protocol for provisioning session establishment data into Session Data Registries or SIP Service Provider data stores. The provisioned data may then be used by various network elements for session peering. This document focuses on the Session Peering Provisioning Protocol used by clients to provision registries. The document provides a set of guiding principles for the design of this protocol like extensibility and independent transport definitions, a basic data model that meets some of the requirements discussed in DRINKS and an early XML Schema Document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mule-drinks-proto-01.txt Notes: Jean-Francois presented. We used the Use Case and Requirements draft as the base for the protocol design team work. he asked how many had read the draft and counted about 15 people. He outlined what he would cover during the presentation. For the Current scope of the document, we took a smaller subset and focused on the provisioning protocol, the Session Peering Provisioning Protocol, in draft 01. We agreed to use a typical client-server protocol model. The goals of the first draft were to take a small set of use cases and rquirements and produce a draft and submit it to the WG and get input and comments. He said now is the best time to get input to be incorporated. He reviewed the goals listed in the presentation. Some things are not yet covered, e.g., the batch mode where a file is submited, and some other items are not yet addressed. He reviwed the key objects in the data model. He reviewed the: - protocol actors; registrant, registrar, organization (typically a peer service provider but can be others that will use the registered data) - destination group - route group Q: David Schwartz: Under registrant, you mentioned a holder. This could be "owner" or someone else who has the right to register a number? Rich stated that we have discussed a callback entity may need to be identified. Alex stated we have also not identified who is associated with the actions of each object. Brian Rosen stated that he has been involved in this exact problem. There may be a chain of resellers, and each has a policy that may affect what can go into the database. Alex asked is that related to how to address the local regulation? Brian said not regulatory, you have the notion or problem of who is allowed to do what. you might have differences in who can do what and have multiple levels of registrants. Debbie clarified on multiple registrants. Also we haven't addressed carrier of record and transit providers. Wille Wimmreuter said that it may not be the policy maker. As the identifier moves across entities, the registrant may change. Rich said that initially we need to define the roles. The question was asked is this just for VoIP or SMS also? Rich stated that we are not being specific, VoIP and other services. For interoperability, the request is that we need to also look at SMS, and a service provider ID - SPID, Rich said that we have SPIDs, and other entities, and note that we are still writing use cases, He requested that specifics here would be useful. Please send in more use cases. Jean Francois: Adding to what Rich said, please review the Use Case draft and add some. We look at a TN as a single instance and verify ownership and third parties. But that is not the case. We'll have a Destination Group and the registrar will provision. If the TN moves to another group, that new registrar will have different rules and policies and that will be applied, maybe at the Destination Group level. D. Schwartz: In terms of parameterization, for example for SMS, we need 'service'. Each serive may have only one route; whereas for IP adddesss there could be multiple ones. There may be many terminators. Multiple route groups need to be addressed. There may be different entry point depending on terminator. Jean-Francois discussed if there are different route or route providers, we have also looked at the capability to define a priority. Jean-Francois continued the presentation with some examples based on the main relationships. D. Schwartz: When you talk about originators, don't talk about a 1 to 1 relationship. These rules are sourced based for grouping of orgs. Jean-Francois said we have source based routing and we have multiple routes if and when we incorporate transit providers. He reviewed the data model. A Destination Group (DG) gathers a set of public identifiers and could include a range. As appropriate, new types can be added here. Once you have the DGs, a DG is related to one or more Route Groups. The question arises should we use the NAPTR resource record. Many are use to this. He reviewed the Org Name - these include recipients (basically peers) that use the data, registrar, and registrant. D. Schwartz: I don't see Route Group parameterized with service type - we used to have that, and it seems to have been taken out. Ken asked David to clarify and said we didn't have 'service type' there. D. Schwartz: We parameterize NAPTR records based on serivce type. Jean-Francois: voice and SMS ... given the same TN, i can resolve with one route group for voice and one for SMS. D. Schwartz suggested we look at number porting. Ken stated or have a single route group and different NAPTRs parameterized by service. Jean-Francois: The Registry has flexibility to provide routes by Service. In the ENUM query, you can't specify service, you query and get all routes and the client resolver, application on top, will select based on service. Alex: We have found multiple ways to do things. We need to make sure we are accomplishing what is needed for all use cases. Please let us know if use cases are missing. Jean-Francois discussed the layering concept. You can add a transport protocol that is independent of the message and envelop used. We are using a message approach with a request and response. We have separated the objects into data object types and then defined actions or operations for each object. This is a fairly typical approach. Section 2 of the draft includes transport protocol requirements and what we believe is needed. He reviewed the major ones listed on the viewgraph. Alex: We also found out that the distribution protocol may have different requirements, e.g., chunking of large sets of data. D. Schwartz: He had a general comment about query response model. Not all data is created equal. Why can't it be in a message notify approach? Jean-Francois said that he did raise this question and we discussed this. D. Schwartz: I might partition the data and only care about a specific set and subscribe to a specific set and not have all of it pushed to me. The server may need a mechanism to say 'hold on, don't send the data now, please wait. Ken clarified that you might want to prioritize and get data you need quickly and get other data later. Publish and subscribe and file based may not be all that is needed. Jean-Francois wrapped up and summarized. D. Schwartz: Number Portability data, sometimes it comes in once a data or every 15 minutes. I want to throttle and may not want it pushed all the time. I would rather say wait and i'll tell you when to provision to me. Jean-Francois: On the provisioning side, a client may want to push his updates immediately for the registry. Andy Newton had a question about how the transport requirements are defined. Jean-Francois says we plan to define the requirements that any transport must meet and they will be in this document. Andy: Alex mentioned chunking. Some of these concepts may already be included in given transports. Rich clarified that there may be massive updates that must be in files with specific date/timestamps. The plan is to include in the message layer. JF - in implementations we have both - we could define how to deal with it in the trasport layer and in messages. AN - you should not do at both layers - rich asked what is better - Jean-Francois said we should choose one or the other, not both. He said there are tradeoffs. If you use both, there will be interoperability issues. HTTP, BEEP does it.Looking ahead, if you are using SOAP, then go with the message layer, you will not be able to do it in "SOAP". Rich said we have not tied ourselves to SOAP - yet! Spencer Dawkins: one thing we need to address is what does the trasport layer do, so that we don't need to address those items above that layer. At the very least we will not be silent but call out in what layer something is done or specify if it can be done at both places. Jean-Francois continued with some open questions: One is should we use NAPTR records? We didn't have strong requirements against it. D Schwartz: There were 3 or so comments against it and no response. Andy: You can support NAPTR but should allow other others. Jean-Francois said we have boxes today that are ENUM servers and will recreate this info. Andy: Define what you want them to do then define how to do it. Alex: What other approaches should be used? mostly NAPTRs are used... Ken: Maybe we abstract out as attributes or route objects and let the NAPTRs be built out. But what we find is that folks should use order and preference and the ENUM standard seems to want to use the NAPTRs. Jean-Francois: We tried to make it generic... Jon Peterson: We should define what data is needed for the database and then how best to use it, it may be NAPTRs. No one has implemented order sanely or well so far. I suggest we use a single fixed value for 'order' and then use preference for flexibility. Ken: Field 'replace/donate' is another. Rich: There is confusion of which to use (orer or prefence) and this has been documented in ENUM usage documents... Jon P: Is there something we can't do that we need to do? Jean-Francois: To summarize consensus - are we ok with NAPTR and we could also use something else? D Schwartz: Why NAPTR? The fact is that we are not capturing routing essence - trunk group, address, .... you can build a NAPTR later. Ken: name = value can live in a route group and then build NAPTR later. From JABBER - look at the SED document contributed by Alex, use the data and then form the NAPTR later. Otmar said we are shifting complexity to the registry to do something magical. Manjul said a routing group protocol is not in the charter, we are specifying a protocol for routing. Jon P: What is the alternative? There will be a query and response and you will get back some elements - how would you put it together. The design making matrix used to define the data may not need to address how it is delivered. The ugliness of URIs is not enough to rule out NAPTRs. D Schwartz: Clumping it all together into the URI is what I have trouble with. I'm concerned about how the data should be stored and that is important. Not how it is distributed. ken: You build a NAPTR from several data sources - it can be built at different layers. D Schwartz: How about egress routing? What is the data model around this? It can be internal or external routing. Ken: Similar discussion for SIP redirect. Rich: we should move on. Jean-Francois: We do have other issues. One is Data Recipient Groups - We have set this to the side and not incorporated into the data model for the protocol. With a group you have more flexibility to make a route change for a bunch of entities together. We think it has some value but adds a lot of complexity. Alex asked who understands the problem. David raised his hand. It's helpful to group rather than do things again and again. He understands the complexity. Not sure it is needed in the model. ken suggested using the existing protocol, move sets for Data Recipients rather than form groups. Jean-Francoiss said that we will keep that one open for now. Other issues - for each object we have an activation date. We have deletion date. We discussed effective dates. It is open... Debbie suggested some examples. Network changes, maintenance. D Schwartz: not sure we can't do what we need with just activiation date. It does add complexity. We have other open issues. Our goal is to continue the team calls and produce another draft before the next meeting. Rich said that this document should become the vessel for the data elements and data model. Jean-Francois thinks with the next revision we can issue it. Rich is looking to see if this doc should be an official DRINKS WG doc. The Humms for yes have it. Alex summarizes - definitionns should not be in 2 places - post issues - post new Use Cases - we had a discussion about actors, provisioning should include a primary provider, we haven't addressed who is allowed to provision what object, please comment - comment about SMS and who can provision - multiple ways to parameter a route group - parameterize and relate to Use Cases - chunking problem discussion and at what layer - suggest to do at one layer - NAPTR discussion - our data model allows us to put something new there, we have NAPTRs there as they are used - egress routing - destination groups discussion Please post your suggestions to the list. C. Open discussion of the issues surrounding selection of SOAP vs RESTful as the baseline DRINKS transport protocol. (20m) Notes: Rich said we are going to have to make a decision as to what the transport should look like. We asked for input from the IESG. We invited Lisa Dusseault to one of our calls to get input. Logically we have been working with SOAP as the transport protocol, as typically the SSPs deploying this protocol would use SOAP as they are using it for provisioining today. Rich also sent a poll to the list to get some feedback on SOAP vs. the RESTful issue. The discussion with lisa took us to a fork in the road. The IETF traditionally has had issues with SOAP as a potocol. Consider BCP 5256. We do need to make some decision about this and properly document the agreement of the WG. Howver, we have the obligation to look at the current state of RESTful deployment and how we might incorporate that. Does our area director ahve any input? Cullen Jennings: I view RESTful as a design mechanism or style as to how to structure the symantics. SOAP, XML over HTTP SOAP or BEEP is out there. We could use an RCP mechanism. Andy: In general you should not use BCP 5256 as so many folks have ignored it so far. The question was asked: How many are involved with issues related to the RESTful approach? Spencer: I'm hoping we get to having a decision discussion for direction for implementation. SOAP is already used. Rich: We don't want a surprise when we specify SOAP and be told "no way on earth" can you use SOAP. Rich: The WG chairs want something that is implementable and more important implemented. Andy: IESG cannot tell the WG how to think. That doesn't seem like the IETF way. From the WG chair, we would make explicitly clear why we are dong what we are doing. AndyN: We should not go down the route of RESTful approach over other than http. Rich: I do think the design team should look at the RESTful aproach over HTTP even if we cnn't recommend it be implemented just to learn what it might provide. Ken presented his viewgraphs. A formal poll indicated we use SOAP. My experience is to get a protocol done and get it implemented. SOAP will make it happen. But we should look at a RESTful approach and see what it might do for us. In my experience use HTTP as a transport, HTTP result codes, and action codes, and URIs, and from practical experience what is implemented are hybrids of RESTful approach. But you need to do things that are not cleanly supported by these approaches. With SPPP, it will be transport independent, envelop independent... - you will see some of the REST approaches in this. But there are difficulties. Response codes and messages must move out of the protocol. The response codes are not very explicit - you can only say an operation failed and it cannot tell you what is really wrong. You cannot combine actions where you might want to. It is very difficult to use business keys. Too much info must be moved out of the protocol to the transport and envelop layers. We are going to see if we can have a goal where you might be able to implement a hybrid approach. Dean and Spencer confirmed. This was said to the mailing list, he would lean towards REST, but what he sees out there is SOAP. Ken: We will have a separate document for SOAP. If someone wants to go thru the exercise to create a document for REST, they may volunteer and do that. SOAP implementation is more likely to be implemented sooner. Andy: I'm not a big fan of SOAP, but for the application here, SOAP is appropriate. D Schwartz; We should start with SOAP, but I'm troubled by that if there are large sets of data and the number of tags. Ken: If you compare using one TN per request in SOAP vs. other protocols it may haveimplications. But not for large numbers. Jon P: If everyone agrees on transport agnosticism, you will have to do the work implied. Spencer: We need feedback on the trasport section of the draft. Cullen: I'm not sure I agree with all of the comments on REST, but for a transactional approach for actions on the database, SOAP seens to be reasonable. I hear we don't want to use REST based on the discussion. We didn't talk about SOAP. We could do XML over HTTP or SOAP over HTTP. We didn't have a discussion about that. Andy: Forget agnosticism - just go with SOAP over HTTP. Jean Francois: There is a preference to define this protocol over SOAP. There may be other implementations where a RESTful approach may be useful. Let's look at the exercise of how RESTful might be used and see if we can learn useful info. D. Discussion about WG Milestones (15m) Rich reviewed the milestones and the WG chairs will propose a new set of milestones to the IESG. Is this a reasonable time table for moving forward? Any comments? We will submit to the list for further approval. We shifted them by 1 1/2 years. We explicitly list the transport protocol as a separate document. Open Discussion / Other Business (if time permits) Notes: