IETF DRINKS INTERIM MEETING (81.5) ================================== Aug 31, 2011 (Wednesday); 1p-5:20p (Eastern) / 17:00 - 21:20 (UTC) Participants (in order of announcement on the bridge) ============ - Dean Willis - Syed Ali - Jeremy Barkan - Ken Cartwright - David Schwartz - Manjul Maharishi - Daryl Malas - Dan Romascanu Chairs ====== - Alex Mayrhofer - Sumanth Channabasappa Scribes ======= - Alex Mayrhofer - Syed Ali ACTION ITEMS ============ [David S., 9/2] Present a proposal to allow for extensibility in an interoperable manner. [Alex, 9/2] Propose considerations around internationalization [Chairs, 9/8] Check with the ADs (or IESG members) to see if we will need to refine the current separation of protocol and transport documents [Authors, 9/8] Incorporate comments based on the discussions at the interim [Chairs] Finalize a response to the ITU liaison statement (https://datatracker.ietf.org/liaison/518/) AGENDA ====== 0/ Welcome and Administrivia 1/ OpenSPPP Demo -- new item 2/ Review and resolve open items related to the following a) protocol draft b) transport draft 3/ Discuss and Respond to the ITU Liaison 4/ Open Discussion 5/ Next Steps 0/ Welcome and Administrivia ---------------------------- - Sumanth started the meeting and presented note well - Call for scribes resulted in volunteers from Alex and Syed - A new item was added to the Agenda -> OpenSPPP demo There were no objections to this - Discussion Jeremy: Wants to check whether some functional aspects are covered in the protocol with respect to the use cases / requirements document. specifically, the route offer logic. Sumanth: Let's discuss this during the protocol document discussion 1/ OpenSPPP Demo -- new item ----------------------------- - Dean and Jeremy provided an overview of the OpenSPPP demo - Comments were also presented by the developers + Notes - The system uses a MySQL database, implemented in Java, runs on top of Tomcat. - Dean starts from database scheme "upwards", Organization table is discussed, there is some confusion whether the Organization objects are used as rant or rar's. - Destinationgroup scheme - notes that foreign keys should be integers, rather than strings. - Dean shows adding, getting, re-adding a Destinationgroup, then trying to "get" an unknown destination group. shows that deleting an already deleted destniation group still returns success - intended? - As organizational basis, sourceforge is used to collaborate. - Dean: instructions on how to get the code, or play with the code. shows in a term window how to pull the code and compile it. Deployment would be the next step and standard tomcat container will do the job. - Dean: bug tracking tool is actively in use + Alex: question-- how complete is this implementation - (Dean) RouteGrp / RouteRec operations may not be complete. Route/NAPTR/URI handling is missing right now. - (Dean) estimates that 20% of functionality is there and about 50% of needed total code written. + Q&A - Get destination group without any key - should that return a list of all destination groups? This does currently not work, could be a bug in the implementation - Ken noted that the use of rqstObj in a successful transation may be incorrect. Dean to further look into that, and result of that would either be update of spec, or update of OpenSPP code. + Ken: Public ID handling implemented yet? - Jeremy: Vijay is handling the schema need to add the code + Ken: What about route grp offer - Jeremy: needs to be implemented + Ken: What about the services and server status commands implemented? - Jeremy: still needs to be implemented + Discussion - (Jeremy) The solution seems to use generic SOAP, but relies on the XML for functions for operations; this resulted in some overhead. (Ken) indicated examples of netconf where the usage is similar (Dean) expressed the need for separation of nouns and verbs (David) Data Model discussions - Verbs are on top of the nouns (Dean) Data Model, Operations and Binding need to be clear (Dean) In summary, the implementation as we have specified works. However, we could make it better - (Ken) Operations and data structure are defined in one document, and the envelope is defined in a separate transport document. The reason for this approach is that the verbs and nouns need to be defined in the first doc. SOAP WSDL could be written to again write the operations again (RPC), though it would be repetitive. - (Dean) Thought it is good to define verb and nouns in one document. Though it becomes restrictive because they cannot be used for other. - (Ken) Noted that going with another interface, such as, REST, brings its own restrictions. - (Jeremy) REST verbs may have more flexibility in mapping the operations to other interfaces. - (Ken) Agrees that Fieldings explained how the ops and codes can address the needs for almost all transport needs, but the decisions were made in the beginning about the SOAP approach. - (Sumanth) clarified a couple of things: REST is an architectural principle. RESTful web services is the application of these principles via the use of HTTP. (as chair) when we started the work we asked for volunteers to work on an alternative approach, including RESTful web services. However, there were no volunteers. We then took a poll on the extent of refinement. There were no strong recommendations, apart from the design team going with what we have today. - (David) verb as an api is an issue. REST or not may not be. - (Sumanth) data model discussion is open. clarified that we don't get wrapped with only two choices (REST vs SOAP) and acknowledged that there multiple choices. - (Ken) understands that to realize that vision there can be no XSD in the protocol. describe the structure and leave it the implementers to execute... (15 min break) 2/ Review and resolve open items related to the following --------------------------------------------------------- = Plan to discussing the following topics: - security considerations - data validation - internationalization - Additonally, questions raised by the OpenSPPP developers. = Sumanth (as Chair) decides we start with the open questions from the developers. a) Protocol Document (http://tools.ietf.org/wg/drinks/draft-ietf-drinks-spprov/) + Comments around the lack of separation around data model, operations and binding + (Dean) There are two options Option 1: Separate the data model, operations and binding NOW Option 2: Go ahead with the current limitations - (Alex) Let'S fix what is important to fix, and let's understand the limitation of the other data model problems. - (David) There is confusion around policy; metadata is not policy. Metadata allows you to build policy rules. As soon as you add extensions you may break interoperability since we don't have a clean mechanism to do this (e.g., cost etc.). (Ken) It is unclear what is being asked for: is it a request for new elements or a modification (David) There is no clear way to make extensions without affecting interoperability (e.g. video) (Ken) sounds like new requirement and welcomes new addition (Jeremy) interoperability is more important. (Alex) Metadata not necessarily within scope? Is the extensibility mechanism we got good enough? (David) thinks the extensibility mechanism is good enough, but we need to decide whether we want to have certain things in the core, rather than in extensions. (Sumanth) requested David to present a text proposal around this. (David) Agreed. See AI. - (Dean) The layering of the protocol; separate the data and operations and place it in one document, then map this onto SOAP or other protocols. we may find situations where the current data model doesn't work we may have to then update the data model a little down the road Alex: if something needs to be fixed in the future, let's fix now - (Dean) Approach to data - operation - binding is still an issue that we are not all on the same page. (sumanth) agrees and asks what are we trying to fix first. (Dean) layering of the protocol needs to be fixed. operations are part of the core. And this means that the operations need to be mapped again for other bindings such as CORBA, SOAP, REST etc. (ken): XSD that is defined is not tied to SOAP. It can be tied to RPC, tcp, and other flavors; it cannot be as cleanly mapped to interprocess methods/tech that want to specify operations in a particular way: REST, COBA, RMI. we can remove the generic binding from SOAP and move to the specific instance. (Dean) what will change in the protocol document? (Ken) things will be copied and reflected in the protocol document. - (Dean) suggested that perhaps we should ask the ADs or IESG members if the current split was sufficient - (Sumanth & Alex, as chairs) agreed. see action item. - (Sumanth, as chair) also wanted to take a poll to see what the participants here think. ==== Poll#1: Is the current split valid? Question is do we want to change the split between the documents, so that the "protocol" document can become more "generic"? + Option #1: Do nothing + Option #2: We do some work to make this better Alex : Unless we need to get by IESG, go with #1 (-- as a contributor) David : Unless we need to get by IESG, go with #1 Dean : Unless we need to get by IESG, go with #1 Jeremy : Wasn't present for the poll Ken : #1 is the preference; unless we need to! Syed : #1 is the preference; unless we need to! Sumanth: Unless we need to get by IESG, go with #1 (-- as a contributor) Summary: Looks like we are ok with the current I-Ds, unless we are asked to change it. ==== Poll#1: Is the current, generic usage, of SOAP acceptable? + Option #1: Leave it as-is, i.e., Generic WSDL usage + Option 2: Modify WSDL operations so that individually address the nouns and verbs Alex : #1 (-- as a contributor) David : #2 (if it is a few hours worth of work) Dean : #2 (#1 works, but #2 would make it simpler) Jeremy : Wasn't present Ken : Either works Syed : #1 Sumanth: Either works (--as a contributor) Summary: No strong consensus. Leave it as is. = We then move onto SECURITY; Sumanth (as chair) requests Syed to present. - (Syed) Suggested XML Signatures for non-repudiation (Alex) this is not widely implemented so we should be careful (Ken) What is the use of this if we already have other mechanisms for message integrity (Sumanth) agree with Ken (Syed) Explained the need for non-repudiation e.g., within Accounting where we need a mechanism to validate in the aftermath. (Sumanth) agrees that this could be a valid case; however we will need to be clear on how this would work (David) XML signatures may be a good thing. (Dean) How does a client find out whether it is supported on a server? (Jeremy) mechanics are simple, processes are much more complicated. (Jeremy) Be careful as to what you specify since there are PKI and other issues. (Alex) Make clear it's not required, because it tends to be a hassle to implement. (Sumanth) suggested that we indicate repudiation as an issue and present ways to solve them (e.g., XML signatures) Summary: Syed to clarify the security concerns and issues, and present XML signature as one of many options. - (Dean) presents the problem of policy - where does that policy information come from? Who can see, modify what, and how is that decision made.. Other protocols do "example policies", and mention what's typically done. Authentication credentials used to identify the client? Already there from authenticating the SPPP session (request)? authorization step comes in addition to authentication. (Dean, Ken, Syed, Sumanth) Multiple use cases were presented: - the case of registrar acting on behalf of another registrar is not considered. - registrants having two registrars can happen Suggested that we perhaps add the registrar field back in, to aid with authentication and authorization? (David) doesn't like the fact that the "rar" field could contain completely random stuff, because it's defined in the client. "rar" that has been authenticated vs. "rar" that has only been "noted" in a field. Summary: After much discussion we decided to re-add the registrar ID. = DATA VALIDATION - Alex presented a proposal to validate data Questions were raised around the validation of IP addresses and Ken's earlier comment regarding '+' in TNs - may not exist in non-E.164 number TNs (Jeremy) says that validation proposal from Alex is about 98% complete - discussion around IP address validation. Summary: Alex's proposal will be incorporated and further modifications will be made to IP address validation. = Internationalization - Alex to propose text and/or a discussion. 3/ Discuss and Respond to the ITU Liaison ----------------------------------------- - skipped due to time constraints - chairs will discuss privately 4/ Open Discussion ------------------ - Covered as part of #1; no time for additional discussion, please use the reflector. 5/ Next Steps ------------- - See "action items" above