DRINKS WG meeting - FRIDAY, Nov 18, 2011, 1120-1210pm ===================================================== WG Chairs: - Alexander Mayrhofer - Sumanth Channabasappa Area Directors: - Gonzalo Camarillo - Robert Sparks Mailing List - Address: drinks@ietf.org - To Subscribe: https://www.ietf.org/mailman/listinfo/drinks - Archive: http://www.ietf.org/mail-archive/web/drinks/ Jabber Chat: - Room Address: xmpp:drinks@jabber.ietf.org - Logs: http://jabber.ietf.org/logs/drinks/ Summary of AIs: -------------- - [I-D Authors] Complete the remaining changes as illustrated (e.g., editorial nits, further comments) - [Alex] Assist with the completion of the Internationalization considerations - [WG Chairs] Modify the WG timelines - [WG Chairs] Establish an interim meeting - [Design Team] Consider using the IETF issue tracker, if useful - [WG] Decide on the nomenclature for the WG documents 1) Welcome and Administrivia (Presenter: Alex) - Alex presented the Note Well, and the agenda - Scribes were identified: Sumanth (note taker and Jabber scribe) - Alex presented the Note Well and administrivia 2) WG status review (Presenter: Alex) Link: http://www.ietf.org/proceedings/82/slides/drinks-0.ppt - No changes to the scope of the work - The use cases document is at a late stage within the IESG, pending one comment around security considerations - We reworked the protocol and transport documents, based on discussions at the interim meeting - We also responded to a liaison statement from the ITU regarding the Global SPID, where we asked them to follow the work going on in DISPATCH 3) Discussions at the Interim and current action items (Presenter: Sumanth) Link: http://www.ietf.org/proceedings/82/slides/drinks-1.ppt - The last interim meeting was held on Aug 31, 2011 - We saw a demo of OpenSPPP (demonstrating running code), and we discussed the protocol and transport I-Ds - However there was a recommendation to change the document split between the protocol and transport docs to make it even more generic to support additional mechanisms, such as RESTful Web Services. - We then discussed what this split would look like and recommended the following: > Protocol document to contain object definitions; and the normative requirements around operations, response codes and object identity > Concrete representations of operations, responses and object identity to go into the transport document - The latest updates reflect these changes - The chairs asked if there were any objections to this split, and proceeding as indicated? > No objections were noted from the room; 4) Protocol document (Presenter: Syed; on behalf of the authors) Link to presentation: http://www.ietf.org/proceedings/82/slides/drinks-2.pptx Link to I-D: http://tools.ietf.org/id/draft-ietf-drinks-spprov/ - Syed presented an overview of the all the changes that have been made, primarily to accommodate the change in the split as discussed in agenda item #3 - In addition, he indicated the additional topics that are still TBD, most notably support for internationalization > There was quite a bit of discussion around this; Pete Resnick attended as an expert advisor > See email from Alex on 11/17 (http://www.ietf.org/mail-archive/web/drinks/current/msg01070.html) > Discussions at the meeting revolved around whether we want to make the identifiers case sensitive or case insensitive = Ken, Alex and Dean indicated that case insensitive would be preferred = Pete explained some potential issues/surprises around this (e.g., if we type ASCII on a Japanese Keyboard, then it may not be ASCII). = If you normalize (something like NFC), and you have a particular encoding (likely/hopefully UTF-8), then you can do octet-by-octet comparison and do reasonably well, but there are still edge cases where users would be "surprised" that certain things don't match. = Different scenarios provide different surprises. You can also use NFKC > In summary, there was no decision on this. Alex will follow-up with the WG to make a recommendation 5) Transport document (Presenter: Syed; on behalf of Ken) Link to presentation: http://www.ietf.org/proceedings/82/slides/drinks-3.pptx Link to I-D: http://tools.ietf.org/id/draft-ietf-drinks-sppp-over-soap/ - The presentation contained a summary of the changes that have been made, based on the change in direction - No specific concerns were noted 6) Proposed next steps (Presenters: Chairs) Link: http://www.ietf.org/proceedings/82/slides/drinks-4.ppt - Three main items were discussed - 1) Nomenclature to reflect the split > “SPP Framework” instead of “SPP Protocol”? > “SPP Protocol over SOAP” instead of “SPPP over SOAP over HTTP”? = There was general agreement - 2) I-D completion timelines > The WG chairs proposed a revised completion timeline, Jan for protocol and Feb for transport > There was a recommendation to move them by a month (Ken, Dean) > The WG chairs will reflect this change - 3) Interim meeting > The chairs proposed a virtual interim in the January timeframe > The WG was OK with this; chairs to follow-up 7) Open Mic Time - Sumanth (as the use cases I-D editor) asked for feedback around security considerations; specifically to say: OLD: " A provisioning protocol or interface that implements the described use cases MUST therefore provide data confidentiality, and MUST ensure message integrity for the provisioning flow. Authentication and authorization of the provisioning entities are REQUIRED features of the protocol and interfaces." NEW: " A provisioning framework or protocol that implements the described use cases MUST therefore provide data confidentiality and message integrity. Such frameworks and protocols MUST specify mechanisms to authenticate and authorize any entity that provisions data into the registry, i.e., that the entity is who it says it is, and is allowed to use the provisioning interface. The determination of whether such an entity is authorized to provision specific data elements (e.g., a certain public identifier or TN Range) - while REQUIRED - may be left to local policy." > There were no objections to this - Syed proposed that we use the IETF issue tracker > Alex indicated that this works well, and we can decide to use it, if we all agree.