[13:59:00] David Schwartz joins the room [15:05:28] David Schwartz joins the room [15:09:14] Dan York joins the room [15:09:22] Dan York has set the subject to: DRINKS at IETF 74 [15:33:37] dmw joins the room [15:41:56] Alex joins the room [15:57:54] otmar joins the room [15:58:52] frodek joins the room [16:02:38] pee joins the room [16:03:08] suzukisn joins the room [16:03:22] ysuzuki joins the room [16:03:25] Hi Otmar [16:03:39] eburger joins the room [16:03:40] Hi David. [16:03:46] karen.s.seo joins the room [16:03:52] Presentation of the "drinks" to Jon Peterson [16:03:55] Anyone here who doesn't listen to the audio stream? [16:03:57] (Eric Burger Scribing) [16:04:08] (Let me know if you want me to channel you) [16:04:20] Hello, is there going to be an audiocast? [16:04:23] Debbie G. talking about active contributions status [16:04:30] I take it you don't hear Debbie? [16:04:49] http://feed.verilan.com:8000/continental_1-2.m3u [16:04:59] james.michael.swan joins the room [16:05:37] Is this feed working for you? [16:05:49] yes [16:05:54] It's working for me. [16:06:06] yes, it just started working. Thank you! [16:06:19] Talking about initial set of use cases [16:07:16] Next up: Use Cases draft: draft-channabasappa-drinks-usecases-requirements-02.txt [16:07:26] David Schwartz leaves the room [16:07:46] slide 2 [16:08:02] David Schwartz joins the room [16:08:33] Slide 3 [16:09:07] Slide 4 [16:09:41] are the slides posted on the web? [16:09:57] https://datatracker.ietf.org/meeting/74/materials.html [16:10:21] Also on the agenda page:http://tools.ietf.org/wg/drinks/agenda?item=agenda74.html [16:10:52] pk joins the room [16:10:59] thanks [16:11:04] slide 6 [16:11:44] lorgr25 joins the room [16:11:45] slide 7 [16:12:06] Greg Schumacher joins the room [16:12:13] slide 8 [16:14:14] slide 9 [16:15:00] slide 10 [16:15:49] Questions? [16:15:56] Anyone? [16:16:00] spencerdawkins joins the room [16:16:13] waiting for slide 17. [16:16:17] John Elwell at mic [16:16:18] Just waiting for slide 17 [16:16:24] Otmar beet me to that [16:16:25] :-) [16:16:55] sk joins the room [16:17:00] if enterprise network wants to connect to SP, enterprise needs access to SP's registry. If that SP peers with another SP, the enterprise needs to reach through, etc., etc. [16:17:20] Uh oh... John's asking the security/privacy/circle-of-trust question. :-) [16:17:25] A: provisioning protocol does not dictate deployment model [16:17:33] This design assumes one big registry in the sky [16:17:34] eburger: agreed [16:17:45] it seems that registry to registy is missing [16:17:50] I agree with John [16:17:56] yes [16:18:01] very important [16:18:14] but this mechanims is not discussed [16:18:26] bilateral exchanges important, but not addressed [16:18:35] I know [16:18:35] :( [16:18:37] Yes, that is the question. [16:18:37] Martin: LERF/LUF [16:19:20] ray joins the room [16:20:03] Yup: you are all right: get your comments in so they can be incorporated into the document vis-a-vis registry-registry and circle-of-trust stuff [16:20:17] who is talking? [16:20:21] Arrow on slide 3 shows multiple registries [16:20:27] Ken Cartwright [16:20:30] thanks [16:21:22] Adam U: last IETF had discussion between LRG and LUF; Adam was supposed to help out DRINKS on the different; looks like it was not incorporated into document; SPEERMINT is working on it [16:21:37] A: Was thought about, but got wrapped around the axel on it so didn't make it in [16:22:21] RS: doesn't really see understanding of what LRF is [16:22:35] David Schwartz leaves the room [16:22:46] RS: Recall purpose of design team was to rough out stuff, not the final product [16:22:52] John E: Referring to diagram 3 [16:23:02] Two registries point to same service providers [16:23:20] What if different registry / SSP relationships? [16:23:32] A: ASCII art problem, not a design architecture [16:23:41] Ken speaking [16:24:01] Nice to have layering between LRF/LUF [16:25:00] Darryl Malis speaking [16:25:06] David Schwartz joins the room [16:25:27] Definitions are already published in RFC [16:26:01] Surprised not much discussion on definitions [16:26:21] Feels terms are clear, but perhaps some confusion as to what/how to implement [16:27:08] ENUM does raise ability to find LRF from LUF, but as an implementation detail [16:27:13] See RFC 4904 [16:28:04] JFM: doesn't think LRF/LUF distinction is important; we've been over this lots of times before [16:28:12] in both SPEERMINT and DRINKS [16:29:04] Seems we are discussing this ad nauseam, but we keep saying it has nothing to do with requirements [16:29:25] RS: agrees; but if people keep bringing it up must be something there [16:29:36] JFM: thinks issue will never go away [16:29:45] Hadriel: will talk about something completely different [16:29:46] (not for relaying, Eric, but this is where Skype is very useful in that it has a (banghead) emoticon ;-) [16:29:59] :-) [16:30:01] dan, indeed. [16:30:11] The XMPP guys *really* need to add that emoticon [16:30:24] HK: trunk groups are optional; only an ENUM thing [16:30:38] does TG get processed at client or server? [16:30:53] ENUM Trunk Group (TG) service type by definition done at client [16:31:37] JE: would an example be "*@example.com [mailto:*@example.com]"? [16:32:02] pee leaves the room [16:32:18] A: is the question would a wildcard be supported? [16:32:22] JE: yes [16:32:22] pee joins the room [16:33:06] Can a DG include RNs, TNs and public identities or is it just multiple TNs OR multiple PIs etc? [16:33:13] (want me to ask?) [16:33:23] please [16:33:42] I guess John asked a similar q [16:33:46] nevermind [16:33:54] k - I'll sit down [16:33:58] :) [16:34:05] I want to give you some excercise [16:34:16] O:-) [16:34:24] On to slide 11 [16:35:40] Cullen has bad eyesight... [16:35:43] On slide 12 I dont like the term COR [16:35:52] Anything in particular you don't like? [16:35:54] slide 12 [16:35:54] I wish they could make this more generic [16:36:01] like... [16:36:08] Primary provider? [16:36:15] dont know [16:36:20] COR is so telco [16:37:33] Hallway discussion: Who is allowed to provision which identifiers? Not specified yet [16:37:34] "carrier of record", right? [16:37:55] Doesn't want to think about in protocol; wants to do it as an implementation detail [16:38:01] Unless you have the mechanism to enforce [16:38:06] than you cannot use COR [16:38:08] Do not want discussion of who owns public identity [16:38:25] David: I would take that to the list (unless you have - then I will jump up) [16:38:29] slide 13 [16:38:40] no - I will take to the list [16:39:09] slide 14 [16:39:53] DRG = Default Routing Group [16:40:02] slide 15 [16:40:54] Q: Is everyone confused about use cases, or are there more? [16:41:15] (No, everyone is still asleep) [16:41:19] Is there any notion of how we identify the recipient? (are we assuming requests oringnating from an IP?) [16:41:27] (I hope not) [16:41:32] Hadriel: should be requirement of attributes per route [16:41:59] Hadriel: which is key and which is result of key lookup (FREQ9) [16:42:45] Hadirel: why are we distinguishing between TN and RN? [16:42:56] A: Because last time we split them out... [16:43:56] RN could be aggregated; can figure it out yourself. Need to identify special handling. [16:44:06] A TN could look like a RN. [16:44:15] Hadriel: So? Would you get a different result? [16:44:29] A: Routing could be different [16:44:39] Is there any routing, ownership or other semantic to PI? [16:44:52] or is PI JUST an identifier (even if it has a domain) [16:45:13] Hadriel: wants to remove multiple assignments to a single RN [16:45:22] Because client cannot know which it is [16:46:39] ENUM (or other mechanism) does not provide a way to query differently based on types [16:47:17] if you're using SIP, you can specify RNs, etc. richer set of keys is available [16:47:24] that is a slippery slide [16:47:28] yes [16:47:32] I agree with Hadriel [16:47:48] hadriel - but then you need to standardize what keys get used based on R-URIs, etc. [16:47:48] I was going to channel your ownership Q. Want me to? [16:47:55] yes - dont rely on the fact that SIP has the info [16:48:05] sure [16:48:45] eric asking david's question - is PI just an identifier even if it has a domain? does it have routing semantics, etc.? [16:49:18] alex says "just an identifier" [16:49:20] I was hoping that was the answer [16:49:52] Not only can you not 3263, but domain may be totally irrelevant, e.g., tel: URL [16:49:54] pee leaves the room [16:50:07] Ken: back to RN thing: don't want more types than you need [16:50:14] If we can meet use cases without RN, great [16:50:24] pee joins the room [16:50:40] However, looks like there are some use cases where you can do stuff like looking up RN owner in NPAC DB [16:51:08] Ken: some use cases have customers requesting all TN's associated with one RN [16:51:20] If we can get away with not having special RN type, that would be great [16:52:38] Daryl on PSTN terminology: well, get over it; most SIP use is for PSTN stuff [16:52:49] Nice to not offend people, but get real folks! [16:53:23] Nobody has introduced non-SP use cases. [16:54:51] Hadriel: question is this just for E.164 routing, or are we going to try to route SIP (email-style) URI's? [16:55:29] Hadriel: seems like there will be email-style URI's, and we will need to figure out how to route through middle domains [16:56:02] Jon P: understood scope to be non-TN-specific [16:56:10] RS: so far, 95% of use cases are. [16:56:11] slide 16 [16:56:42] NOW: SLIDE 17 [16:56:43] How do you prioritize transit providers [16:56:53] the minute you leave the realm of COR [16:57:34] There is no point in including them [16:57:39] if you cannot prioritize [16:57:47] Please provide use cases [16:57:50] if we are mimidkinbg PSTN [16:57:56] where is the COST [16:57:57] Most of the requirements assume that there is a registry, and discuss which data must be communicated with the registry. That's putting the cart before the horse. The real requirements are which data the local data repositories need and how changes are introduced into the system. Only after that exercise we know whether we need a registry for all these data exchanges. [16:58:17] --- second point: ---- [16:58:24] It seems to me like the Carriers which wrote this document are suffering from a Stockholm syndrome with respect to registries: They are being held hostage right now, and are now busy designing yet another system which prolongs this. [16:58:25] You can prioritize (Nanjul) [16:58:37] ok [16:58:38] thanks [16:59:03] Othmar: is this an issue or commentary? [16:59:06] AdamUzelac joins the room [16:59:08] please relay [16:59:54] hahah [16:59:55] pee leaves the room [16:59:59] thats funny Otmar [17:00:19] pee joins the room [17:00:22] Dan York smiles at otmar's text [17:00:50] otmar - so what alternative do you suggest? [17:01:01] 3263 [17:01:03] That was the motivation for the draft in the first place [17:01:20] read my speermint background draft. See the "vision" section [17:01:30] slide 18 [17:01:39] ok [17:01:55] otmar just wants us all to get along [17:02:00] Alexander: next steps... [17:02:00] it's an admirable goal [17:02:19] has anyone else lost audio? Otmar has lost his feed. [17:02:20] Hum on adopting this item [17:02:28] Any thoughts from the Jabber crowd [17:02:30] ? [17:02:50] Every WG needs a Court Jester who occasionally tells the king that he has no clothes [17:02:52] full consensus to adopt [17:02:56] Audio is still fine [17:03:01] I'm fine adopting the draft [17:03:11] Humm [17:03:16] I am OK [17:03:17] Dan York hums [17:03:36] David Schwartz: That's debatable, actually ("I am OK") :-) [17:03:36] Please provide more use cases to the list. [17:04:23] Sumanth will continue to be the editor [17:04:26] my windows media player hung. back now [17:04:42] Now: SED Elements (Alex) [17:04:54] Motivation Slide [17:06:18] "What's in the draft?" slide [17:07:46] "Things to consider" slide [17:08:57] "Next steps" slide [17:09:41] (I'm off for today, other business calls. Have a nice day.) [17:09:49] Thanks! [17:10:20] pee leaves the room [17:10:29] pee joins the room [17:10:36] John Elwell: "identify federating user" - John thought LRF was result of query; so it's part of the received request, not in the LRF [17:10:44] (I meant SED for the last LRF) [17:11:49] Hadriel: confused: thought draft was supposed to enumerate the data required to route a call to a peer; document actually goes way beyond that [17:12:33] Useful to have "what we need" document [17:13:09] otmar leaves the room: Disconnected [17:13:43] yes - I agree with Hadriel [17:13:45] KISS [17:13:52] leave it with a minimal set [17:14:04] otherwise - no one will ever implement the entire draft [17:14:04] RS: is cost included? [17:14:11] no [17:14:17] but priority - yes [17:14:27] use q values for all I carte [17:14:29] care [17:15:03] no [17:15:11] find that out during negotiation [17:16:46] keep it focused on routing [17:16:51] (ingress.egress) [17:17:11] type (e.g. H323 one egress, SIP another) [17:18:42] I think there is value in coming up with a minimal set [17:18:52] zoil joins the room [17:18:55] Daryl: if you put policy there, there's lots of stuff do put in [17:19:34] Daryl: could be valuable to have egress info (as David pointed out) [17:20:01] yes [17:20:18] Jon: agreeing with Hadriel [17:20:22] whooooa [17:20:34] how did that happen :) [17:21:37] yes it is [17:21:38] JP: "We should do what Hadriel says, because he is always right" [17:21:40] :) [17:22:08] Yes, we need to mark this point in the minutes so we can easily retrieve the audio from the MP3 ;-) [17:22:33] 10:20 into the recording [17:22:36] ;) [17:22:50] 1:20 (1 hour, 23 minutes, really) [17:22:53] yes [17:23:31] John E: clarifying: will include some dynamic data. Outside of scope for DRINKS? [17:23:45] Is FQDN considered dynamic or static? [17:23:49] I would venture Static [17:23:49] thanks eric - I stand (sitting really) corrected [17:24:08] Easy: it's 10:24 in the morning here. [17:24:29] How did I know that point would come up? [17:24:44] hot potato [17:25:00] Daryl, with SPEERMINT chair hat on: punting back :-) [17:25:27] How can you provision what was not defined? [17:25:31] pee leaves the room [17:25:43] John E.: suppose you want to go to destination X [17:25:54] provisioned data: go via A, if unavailable, go via B [17:25:54] pee joins the room [17:26:03] SED would come back with ONE of A or B [17:26:28] I wish I could see that... [17:26:37] Video in the future... [17:26:45] which codec? [17:26:47] :) [17:27:33] wow - what is in the food over there? [17:27:41] Puppy uppers [17:28:02] note that this meeting started with a rather large bottle of vodka! [17:28:30] Who was it that was just talking saying to get on with defining the data and skip worrying about LUF/LRF? [17:28:40] Next Up: Private use of DRINKS (RS) [17:28:49] Daryl Malas [17:28:52] karen.s.seo: that was Daryl i think [17:28:58] Thank you. [17:29:02] It was Daryl. Sorry I fell behind [17:29:26] yes [17:30:03] But I think its part of the "distribuitoin" process [17:30:04] Side comment: Jon getting DRINKS [17:30:05] http://www.facebook.com/p.php?i=766881578&k=R6FXXXWZUZ5M5CF1QG26US [http://www.facebook.com/p.php?i=766881578&k=R6FXXXWZUZ5M5CF1QG26US] [17:30:16] plesae relay [17:30:17] Hadriel: what IS a "public" use? [17:30:28] Which "it" [17:30:30] ? [17:30:43] Hadriel thought all uses were covered by protocol [17:30:45] The distribuition of data from reg to reg is part of distribution [17:30:56] I think the LDR is misdefined [17:31:20] it assumes a DNS master slave kind of architecture [17:31:32] not "private", but "bilateral" exchanges [17:32:09] nothing in the charter says bilateral is out of scope, but they aren't in the use cases now [17:32:15] "please send text" [17:32:51] hadriel says the architecture affects this (LRF or LUF function) [17:33:35] LRFs become routing protocol elements, need to prevent loops in routing protocols [17:33:40] hahah [17:34:04] alex: shouldn't preclude any use of provisioning protocol. [17:34:17] David.. I'm still in line for the mike. Let me know if you change your mind. [17:34:27] might compromise if use cases are too creative [17:34:28] no - have not changed my mind :) [17:34:53] pee leaves the room [17:34:54] daryl - how different is registry-to-registry from what's being defined today? [17:35:17] The way I see it - provisioning is kind of like a "push" [17:35:27] we are missing a "pull" or subscribe [17:35:28] assuming there's a requirement that you can identify phone numbers as specific to enterprise, or registry, or ... [17:35:50] pee joins the room [17:35:53] when it comes to reg - reg you may have push or pull [17:36:03] and both these models need to be covered [17:36:21] LDRs dont really have a mind [17:36:24] they are just local stores [17:36:29] don't think there's too much difference between these cases - just need to say so explicitly [17:36:31] does it? i thought it was always a dip (pull), not a subscription [17:36:32] registries however have a mind [17:36:41] and should be able to decide [17:37:30] jon: have always had two protocols when we move from LUF-like to LRF-like functions... [17:37:37] I can write reg to reg use case [17:38:14] eric/david: registries need both push and pull operation [17:38:43] Chairs slides: "WG status / current Milestones" slide [17:39:50] Daryl: sympathetic to date estimation [17:40:18] Daryl: more stuff to think about for reg-reg [17:40:28] Possibly break out into separate work? [17:40:38] I think its part of the original scope [17:40:42] (am checking) [17:40:58] reg-reg could look different than reg provisioning [17:41:16] thus proposes to split off so we can do SOMETHING [17:41:35] Ken: curious to see reg-reg requirements; that will drive if we need to do something different or a separate document [17:41:42] Adam U: agrees with Ken [17:41:52] pee leaves the room [17:41:55] doesn't see what is different between reg-reg and reg provisioning [17:42:21] pee joins the room [17:42:22] its not hte data [17:42:28] its the mechanism [17:42:37] that is used to find and distribute data [17:42:55] John E.: is it SED as defined by SPEERMINT what we're exchanging? [17:42:56] this will become evident in the use case I write [17:43:09] SED is for a *given* session, not generic [17:43:22] Alex: SED is *derived* from provisioned data [17:43:29] David - I can't wait to read that draft! ;) [17:43:40] (banghead) [17:44:10] pee leaves the room [17:44:45] pee000 joins the room [17:44:49] Alex: please come up with use cases and flesh out enumerated use cases [17:45:15] Alex: is design team approach the way to go forward? [17:45:51] Teams get stuff done, but very low traffic on mail list [17:47:09] Spencer: mail minutes from design team periodically to the list [17:47:55] RS: Are we ready to form another design team on protocol, when the requirements are not quite finished yet? [17:48:01] Daryl: get started [17:48:21] ray leaves the room [17:48:29] Spencer: echoing Daryl [17:49:28] Only if they focus on the concensus [17:49:37] not on the issues that have not been sorted out [17:50:30] Can the design team have the meetings on a conf bridge [17:50:37] so that others can listen in [17:51:43] Daryl: once got consensus, fast to move forward when terminology draft changed (in SPEERMINT) [17:51:48] Thinks risk is low [17:52:48] Yes, can have stuff on open bridge, but worried about unnecessary rehashing [17:52:49] not if the minutes are published BEFORE the call [17:52:57] good point. [17:53:12] what about Hadreiels stuff [17:53:12] suzukisn leaves the room [17:53:17] Alex leaves the room [17:53:32] which stuff? [17:53:37] ysuzuki leaves the room [17:53:37] And, meeting's over [17:53:37] eburger leaves the room [17:53:38] Bye! [17:53:39] Didn;t he have a routing rptocol [17:53:50] zoil leaves the room [17:53:52] that he was pushing last time for the SED? [17:53:55] Enjoy your drinks ;-) [17:53:59] whatever [17:54:02] I will take to the list [17:54:03] Eric -- Thank you. [17:54:05] thanks [17:54:09] thanks eric [17:54:10] pee000 leaves the room [17:54:13] dmw leaves the room [17:54:17] Dan York leaves the room [17:55:52] sk leaves the room [17:57:42] james.michael.swan leaves the room [17:59:42] spencerdawkins leaves the room [17:59:47] lorgr25 leaves the room [18:00:34] frodek leaves the room [18:09:29] AdamUzelac leaves the room [18:45:10] pk leaves the room: Replaced by new connection [18:45:12] pk joins the room [19:21:52] Greg Schumacher leaves the room [20:17:54] pk leaves the room: Replaced by new connection [20:17:55] pk joins the room [20:18:55] pk leaves the room [23:54:09] David Schwartz leaves the room [23:59:01] karen.s.seo leaves the room