IETF 72 DRINKS WG Notes 07/31/2008 15:10-16:10 hr Notes of the meeting are provided by the new Working Group Secretary, Debbie Guyton, followed by the official agenda. NOTES Rich Shockey welcomed everyone, reviewed the agenda and reminded everyone that the meeting is only one hour. The discussion of requirements documents included four draft presentations. 1 - Consolidated Provisioning Problem Statement was presented by David Schwartz. - David Schwartz indicated that this is a draft out of a BOF and not meant to put down real requirements until we discuss them. - Jean Francois Mule said this document has not been changed except for the name and this should not be done. Rich Shockey apologized, meant to be a place holder. Issue closed. - We will focus on provisioning into the Registry. David requests we focus on using the same terminology. - David reviewed the LUF and LRF definitions and mapped the contribution drafts to these. He discussed Registry data requirements in terms of key data. He felt one area that was covered somewhat but not sufficiently is transit providers. In Europe traffic is not routed symmetrically between service providers. This area of transit needs to be addressed. He was happy to see the use of the effective date concept in Debbie Guyton's contribution. - He said there was too much focus on NAPTR - maybe we should focus on the data that goes into a NAPTR. - He reviewed the logical operations on Registry Data. He reviewed other Registry attributes. One, Validity, he cross referenced that it is also discussed in Debbie's contribution. He said we need the media type. - He confirmed that the protocol requirements are in scope. Need security. Need XML. Have used SOAP but heavy and may not need it. Would like to debate, maybe REST, maybe not. - He discussed next steps - agree on terms, consolidate requirements, need a use-case doc and an architecture doc. - Jean Francois Mule stated that the Registry Data requirements are absolutely centered around telephony. Would it be ok to have user addresses, user domain ? that is used in the ESPP. - Rich Shockey said absolutely. This is prefix centric and in a portability environment you need to route on the full e.164 string. - Jean Francois Mule stated that there are use cases in earlier documents. - Hadriel Kaplan stated that we can't be limited to prefixes. The data in the ESPP proposal is too specific to NAPTRs - could be more generic to routing information. On later slides, there is talk about the need for separate documents (next steps) however for terminology, SPEERMINT has already defined terminology. - The Co-chairs asked that discussion be held to the end of presentations as time is short. - Martin Dolly agreed with Jean Francois that we think beyond PSTN. - From the Jabber room, Otmar Lendl stated that full e.164 numbers are a special case of a prefix. - Rich Shockey said that we could discuss later if we need special documents. 2 - Provisioning Protocol Requirements for ENUM-SIP Addressing Servers was presented by Jean Francois Mule. Jean Francois stated that the updates being presented were from all the authors. They would be on one slide as he then wanted to shift gears and review all the drafts. - Updates: Since the meeting in Philadelphia, they have cleaned up the terminology, removed North American terms and used those globally applicable. - Per Slide 4 he discussed how we can make progress. Start with basic data elements. In UML terminology we have agreement on some classes: - TNs, ranges, blocks - Grouping those: Destination Group/Tag - Validity concept - what's valid - 'Ownership' - provisioned or on behalf of others - Martin Dolly stated we should go beyond the PSTN. Do we have individual route records or ranges? Individual route records are more of an internet model rather than use ranges. - There was discussion on what should be included on top of the domain, use 3263 and go beyond and look at how to provision SIP servers using NAPTR records or decompose them. Need discussions. - The proposal is to define a data model to allow these to be provisioned as optional. An example is what has been done in the ESPP for reference. - Martin stated to be careful to not have too much 'presence' in the network. - Jean Francois stated there are differences in the provisioning protocols. There are two types: - Registry to Registry - Registry to cache - He sited an example from Debbie's draft of validity. This is used in the Registry. We should only push valid numbers from the Registry to cache. - He stated another example is the telephone number type and that may only be needed in the Registry. - The question was asked: How do we want to define the requirements? A super set then cut for each interface type? Or define two sets. - David Schwartz stated that it's really the same data; the view in the cache should be in the Registry. But there may be additional data in the cache. So may not be the same data. - Ken Cartwright suggested that we need an architecture and use cases first, then we can decide on data. - Rich Shockey reminded everyone that the first document is the requirements document. - Ken suggested one data model where we identify the differences in the two sets. - David Schwartz stated that a registry to cache is a little different, like a master to slave. A cache has a more current picture and can overwrite. He is not convinced one data model will work. - It was stated that we need to determine protocol operations. - Jean Francois stated that frankly we disagree on which of the ESPP requirements have been agreed on. It is an example view. It may be a base for information. - David stated that a port out is fundamentally different than a delete. Need to take care of accounting. 3. Key Data for a Registry Provisioning Interface was presented by Debbie Guyton. Alex Mayrhofer took notes while Debbie was presenting and they are included here. - Jean Francois Mule said that there is a validation document RFC 4725. - Rich Shockey said we are not re-inventing the wheel, is there validation for other, non-TN data? yes. - David Schwartz asked if validation of ownership of a number? - Jean Francois Mule said that validation may be optional, for example when the party provisioning the number (and associated data) can be different from the assignee of the number. - Rich Shockey stated that "ownership" of a number is a dangerous concept and we should not use it. 4. Location Routing Function Requirements was presented by Hadriel Kaplan. - Hadriel Kaplan stated that the draft is very specifically on the Location Routing Function. He listed 3 examples ? for 1 and 2 LUF is needed to determinate the terminating SSP. 3 is different. - He continued. So assume we have solved the LUF. How does the SSP-A get there to SSP-E. They may not have a relationship. They are not peers or in the same federation. Today the answer is simple - send to PSTN. Another problem - the SSPs are really big - easily over 100 SBEs each with frequent topology changes. SSPs will not provide their internal topological relationships. Some providers hold on to the request and get to the fartherest SBE as possible, others move the request off at the closest SBE. Usually related to cost. - He continued. Email URIs should be considered as real. Do Service Providers need to route these? They will continue to go thru the SSP path. - He continued. To solve this we need dynamic location routing protocol. It's not part of ESPP but want to use a similar syntax. But first work should be on requirements. Read my draft. - From the Jabber room and Alex Mayrhofer, the dynamic location routing protocol should be in SPEERMINT. Or we need to decide if it is in the charter and fix the charter if necessary. - David Schwartz said from LRF, it is in the scope of DRINKS. - Jon Petersen stated that in discussion around the charter, on the part of the in the charter states that the initial scope is those provisioned with the ENUM protocol. He made sure it was there. This is a different direction and there might be good work areas here. - Then ENUM is not a query response protocol so Hadriel Kaplan says LRF provisioning cannot be resolved in this group. - Jon Petersen clarified by asking what should be done first. - Hadriel says this should not be the first thing we solve. We need bite size pieces first. But we should keep it in mind as it might impact the data model. - Rich Shockey stated: Consensus - it is in ultimate scope but not a WG item at this time. We should steer clear of layer 3 routing. -Jean Francois Mule stated that he likes the draft. What are the objects, data attributes to put in the provisioning framework, so when we get an LRF protocol, we can pull the correct elements? His understanding was that the provisioning part is in scope. - Daryl Malas said that LUF and LRF are somewhat confused; LUF is not a required step. If you do a query and get a specific address use DNS routing on last step. Rich Shockey stated that the co-chairs are going to appoint authors for the requirements document. There will be a single requirements document going forward. General discussion of Consolidation of Requirments Documents in order to fulfill Goals and Milestones item #1. - There was a question of terminology. Some are different than what came out of SPEERMINT. If we are calling for modifications, need to add to terminology in SPEERMINT. After the discussion in 2 BOFs, no one signed up for use cases and architecture, it should be done in SPEERMINT. Or a use case should be provided as part of a requirement. - Jean Francois Mule agreed. Don't do use cases and architecture. Do a simple example and then a requirement. - From Jabber room: A question of one requirements document for each of LUF and LRF or one overall? - Rich Shockey said only one overall requirements document. - Jean Francois Mule requested that we progress a basic bare bones protocol draft in parallel with the requirements document development. - Rich Shockey agreed. Let's fast track both.