============================ IETF 79, Beijing, China Wednesday, November 10, 2010 0900-1130 Morning Session I ============================ ============== DRINKS session ============== ** The "Note Well" statement was projected and described by the chair. ** Agenda (http://www.ietf.org/proceedings/79/agenda/drinks.txt) MEETING DETAILS =============== IETF 79 - Beijing, China DATE : WEDNESDAY, November 10, 2010 TIME : 0900 - 1130 (Morning Session I) PLACE: Valley Ballroom B Personnel ========= 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/ AGENDA ====== 0/ Welcome and Administrivia (5 mts) - Note well - Blue Sheets - Scribes - Agenda bashing 1/ WG status review (5 mts, WG chairs) 2/ Use cases document - status, open issues (15 mts, Design Team) Link : http://tools.ietf.org/wg/drinks/draft-ietf-drinks-usecases-requirements/ 3/ Protocol document - status, open issues, discussion (45 mts, Document Authors) Link : http://tools.ietf.org/wg/drinks/draft-ietf-drinks-spprov/ 4/ Proposed Next steps (10 mts) 5/ Open Mic (10 mts) MEETING NOTES ======= ===== Note takers: Dale Worley and Alex Mayrhofer (brief edits by Sumanth) 0/ Welcome and Administrivia - Chair (Sumanth Channabasappa) introduces self, opens the meeting - Shows note well, calls for scribe volunteers > Dale W. and Alex M. volunteer for notes; Jean-Francois M. volunteers as the Jabber scribe ================= 1/ WG status review - Presenter: Sumanth (as chair) - See: http://www.ietf.org/proceedings/79/slides/drinks-0.pdf + Topics covered * WG since Maastricht... * Interim Meeting Meeting * Design team calls * Updates to WG Docs ================= 2/ Use cases document - status, open issues - Presenter: Sumanth (as document editor) - See: http://www.ietf.org/proceedings/79/slides/drinks-1.pdf + Updates - I-D was revised once (-04), based on comments by reviewers. Sumanth presented the most important changes to the document. The main topics are reproduced below: ** Direct relationship from PI to SED Record -- Yay or Nay? - [Sumanth] This was dicussed at the interim, where we decided to keep it. >> Sumanth asked for comments from the room - none. >> Based on the absence of comments, this will be retained as-is. ** Selective Peering -- at what Level? [Ken Cartwright]: Selective peering is done on a Route Group basis (given the way the question is worded based on Data Recipients). ** Number Portability - [Sumanth] indicated that Otmar had raised a comment saying that this is a "bad idea", and sought comments from the participants. - [Ken Cartwright]: This use case is one of the few left from the number portability use cases. It was decided to use the generic protocol features to implement number portability. - [Sohel Khan]: We need a way to aggregate TNs and RNs as a way to [support this use case]. - [Ken Cartwright]: We do have a use case for provisioning based on RNs. >> Sohel Khan and Ken Cartwright chat at the mike about what is in the protocol (the ability to "provision PIs" using RN, to use loose language).] >> Ken Cartwright clarified that what Sohel Khan asked about is about SPID-based routing. To do that, you can associate a URItype RouteRec with a SPID and associate that RouteRec with a destination group. >> JFM commented that "association" is maybe misleading, "provision a link" is what is meant. ** Registrar and Registrant [Sumanth]: Since these are not used in the use cases, we removed them from the draft? Is this OK? [Ken Cartwright]: Agrees. >> Chair observes only comment is favorable, so we'll go ahead with it. ** SED record or Route Record? [Sumanth] asked as to whether we should normalize this in the protocol document. - [Ken Cartwright]: I don't have a hard opinion one way or another other than to say the protocol document says Route Record inside its XML data structures, so changing the term would take some effort. I think the reason we did this is that "SED Record" is more generic, but as we got into the protocol, the SED Record became something living inside a route group, so we named it "Route Record" to make that tie clearer. - [Jean-François Mule]: Currently we can use a Route Record to express most of what you'd want to do with a SED Record. If we make this clarification, I don't think it would be useful to replace Route Record with SED Record everywhere. - [Sumanth, as Chair]: Is there really a difference? If there is not, we have to clarify it. - [Ken Cartwright]: I would vote for adding a clarification but I'd like to avoid the abundant changes, in my opinion unnecessary, work of changing the name everywhere. - [Alex Mayrhofer via Jabber]: We might get into trouble in the IESG reviewing process because the terminology is confusing. - [Sumanth, as Chair]: Let's add a clarification. ** Status and Next Steps - [Sumanth, as Chair]: Is this document really done? WGLC ends 22 Nov 2010. Please send comments to mailing list. When asked, about 5 people in the room indicated that they have read the doc, and outside of people who have already reviewed it, no else plans to review it further. ================= 3/ Protocol document - status, open issues, discussion - Presenter: Ken Cartwright (on behalf of the authors) - See: http://www.ietf.org/proceedings/79/slides/drinks-2.pdf - I-D: draft‐ietf‐drinks‐spprov‐03 [Ken] indicated that the authors think that they are close to completing this document. He also acknowledged his co-authors and their contributions (e.g., Syed's contributions to the examples). ** Support for Open Numbering Plans - [Jean-François Mule] You're going to go through a series of examples that do not have anything to do with open numbering plans? - [Ken Cartwright] That's right. - [Jean-François Mule] I think it would be important to have it reviewed in regard to open numbering plans. There are a number of potential vendors that have potential implementations of prefix-based routing. It would be good to sync up and I'd like to collect some names. - [Sumanth, as Chair]: How many people here need support for open numbering plans? <<< no responses >>> - [Jon Peterson] Although I'm not personally engaged in this, I continuously hear that this is a requirement in various contexts. - [Ken Cartwright] I think it was an oversight to not support open numbering plans in the original proposals. - [Sumanth, as Chair] We will need to solicit feedback on the mailing list to get input . - [Alex, via Jabber] Austria and Germany has it definitely, that makes at least ~120 million TNs. (Note: This was not relayed until later.) ** Examples -- Add Dest Grp [Jean-François Mule] The protocol should be agnostic to any namespace used to name registrants. So the XML schema only specifies a string. We would like any thoughts about this. [Jean-François Mule] We exchanged some e-mails with Penn [Pfautz]. He intends to present some ideas about a global SPID identifier. But I would like to note that the protocol is independent of the SPID identifier, so we should progress the protocol, as it is separate from the SPID identifier discussion. [Sumanth, as Chair] Agree that we should progress the protocol document independently of the SPID discussion. [Alex Mayrhofer via Jabber] Agree. Unless we have defined an identifier space here that fits 100%, we need to be generic. [Sumanth, as Chair]: How many people have read this version of this document? <> [Sumanth, as Chair] How many people intend to red it? <> [Sumanth, as Chair] I know Jon [Peterson] is planning on reviewing it, and Hadriel [Kaplan] is planning on reading it. I know of a few other people who are interested in this document (e.g., Manjul Maharishi, Otmar Lendl). ** Deferred Items [Sumanth, as Chair]: For the deferred items, we should start a new I-D effort. ** Quick digression into the status of the transport document <> ================= 4/ Proposed Next steps Sumanth (as Chair) talked about the "next steps" - we're slightly behind on the use cases milestone, protocol and transport document should be done december 2010, so we need to be pretty quick.. ================= 5/ Open Mic - [Sohel Khan] I want to ensure we keep the technology open. We have to include some data model so that we can add features in the future. For example, we may want to add fields so we can include subscriber names in the provisioning requests, so that we don't have to query the provider to obtain caller id information. - [Ken Cartwright] The need for extensibility is a good point, I think we have it covered in the data model by an extensibility data element of type "any" in all objects. We need to validate our assertion that this makes it easy to extend. Getting extension data elements standardized is a different and harder problem. - [Sohel Khan] Would like to have existing data items to support extensibility. - [Ken Cartwright] I understand the use cases -- organizations are constantly adding new items to responses to resolution requests. A standardized provisioning mechanism for those items is not in scope here. - [Jean-François Mule] We're defining a protocol that is extensible already. I would hate to have an opaque TLV [type-length-value] type to cover arbitrary data. If Sohel has a specific need we should discuss the use cases and design appropriate data items. - [Alex Mayrhofer via Jabber] We should be careful to not go beyond the scope of the effort. Caller name is one of those. - [Sumanth, as Chair] We either need to start by considering the use cases for new data items, or the effort would be out of scope.