[06:57:35] fdupont joins the room [06:59:47] fdupont leaves the room: Computer went to sleep [07:34:59] fdupont joins the room [07:34:59] fdupont leaves the room [11:37:52] telemaco.melia joins the room [11:39:43] telemaco.melia leaves the room [12:03:07] arjen joins the room [12:04:20] chanwah.ng joins the room [12:07:54] Brian Haberman joins the room [12:09:43] Brian Haberman leaves the room [12:10:37] john.zhao joins the room [12:11:49] hirocomb joins the room [12:12:35] washad joins the room [12:14:56] nsko joins the room [12:17:52] hirocomb leaves the room: Replaced by new connection [12:18:07] hirocomb joins the room [12:18:27] cjbernardos joins the room [12:18:30] jronan joins the room [12:19:19] hirocomb leaves the room: Replaced by new connection [12:20:02] hirocomb joins the room [12:20:12] Suresh presenting residual threat [12:21:02] Jari: the defense is to cut it off [12:21:18] hirocomb leaves the room: Replaced by new connection [12:21:37] sure but when? [12:21:38] hirocomb joins the room [12:22:38] hirocomb leaves the room: Replaced by new connection [12:24:10] yoshfuji joins the room [12:24:26] yoshfuji leaves the room [12:24:48] hirocomb joins the room [12:25:35] Hannes: prob I have is many of the MIP6 features are not deployed. Nice to see real deployment scenario. [12:25:44] teco joins the room [12:27:53] momose joins the room [12:34:11] momose leaves the room [12:35:21] Peny joins the room [12:36:46] hirocomb leaves the room: Replaced by new connection [12:37:05] hirocomb joins the room [12:42:17] TAN-DEVELOPER1 joins the room [12:42:52] TAN-DEVELOPER1 leaves the room [12:43:34] intvelt joins the room [12:43:52] bnsmith joins the room [12:44:28] To people on this room: You guys know that there is no jabber scribe, right? I may here and there try to type something, but it will helpful if you listen to the AV streaming. [12:46:52] Hi.. I've not done it before.. but if it helps.. I can try and be a scribe.. [12:47:03] rfc3775bis issues [12:47:10] Charlie Perkins [12:47:35] http://www3.ietf.org/proceedings/08jul/slides/mext-2.ppt [12:48:05] First comment on the previous concerns MIPv6 concerns. [12:48:14] Maybe add them to 3775bis [12:48:41] slide 3 [12:49:29] Elena joins the room [12:49:39] Discussing the Issue tracker and how to use it [12:49:58] if anyone has any ideas on how to make it work better, contact Charlie [12:50:04] Slide 4 [12:50:12] Issue 1: [12:51:12] Any responses to this proposal? [12:51:31] Can everyone see the slides? [12:52:16] hirocomb leaves the room: Replaced by new connection [12:52:23] hirocomb joins the room [12:52:51] arjen leaves the room: Replaced by new connection [12:52:51] arjen joins the room [12:53:13] Issue isn't solved.. Yari ?? will look into it [12:58:13] Take it back for discussion to the list. [12:58:37] hirocomb leaves the room: Replaced by new connection [12:58:38] Slide 5 [12:59:11] Suggestion: Now that we have RFC 5026, expunge DHAAD [12:59:29] Charlie put some text to the list [12:59:44] issue appeared to be resolved [12:59:52] jean michel Combes wasn't so sure. [12:59:59] Anyone read the proposal? [13:00:06] opinions? [13:00:18] didn't get the speakers name [13:00:25] possible security issues with this mechanism [13:00:42] charlie: correct, but case hasn't been sufficiently made [13:01:19] from floor, question how many had read the draft. [13:01:39] -00 version of 3775bis is available [13:01:53] -01 was to do some textual updates [13:02:05] -02 charlie is hoping to have out within a week or two of this meeting [13:02:14] washad leaves the room: Computer went to sleep [13:02:15] try and get as many issues closed as pssible [13:02:29] Issue 4 slide 6 [13:02:37] Problem: site-local addresses have been deprecated, but rfc3775bis still makes reference to them [13:02:45] Proposal: just make the simple changes for PS, unless ULAs also become deprecated [13:03:00] not everyone in favour of using ULA's [13:03:12] some opinion that ULA's do still have value [13:03:26] Elena leaves the room [13:03:32] Yari: ULA's not being deprecated, folks can have opinions on their use or not [13:04:07] in reality its about progress: Site locals got removed, does spec work with ULA's [13:04:27] Proposal is Site Locals to be changed to become ULA's [13:05:01] George: no though process required.. change site locals to ula's.. if we want to consider it in depth.. do we really need any non globally routed addresses? [13:05:18] Chair: [13:05:30] do we have any new input to say this is not a good idea? [13:05:37] hirocomb joins the room [13:05:46] Yari: [13:06:11] how useful in a global scale? [13:06:28] Charlie's suggestion go with it as is... and we can propose to remove them later. [13:06:48] Lydia?: Simplest thing would be just to remove Site locals. [13:06:56] Vidya [13:07:05] and Yari -> Jari [13:07:07] Vydia... acttually I'm wrong.. [13:07:49] nope.. I was right initially.. Simplest thing would be just to remove Site locals. [13:07:54] Ta for the names. [13:08:24] Chairs: Whats the solution? [13:08:44] Floor: People agreed before to swap site locals for ULA's [13:08:59] Jari: WG should look at the text again. [13:09:16] Charlie: Will post after the meeting [13:09:45] Suresh?: Thinks the text is ok... [13:10:00] Slide 7: [13:10:09] Problem: IPv4 address in encapsulating header can never match the source address (IPv6 CoA) of BU [13:10:18] Proposal 1: Require an IPv4 mapped IPv6 address in the BU header Proposal 2: view DSMIPv6 as a document updating the behavior specified in rfc3375bis, punt [13:10:27] Proposal 2 seems to have better support (?) [13:11:06] Floor: didn't get the name [13:11:12] doesn't think the issue was worded properly. [13:11:15] Hesham [13:11:31] issue is that RFC4877 introduced/added new format for BU for 3775 [13:11:37] either say now that both are ok [13:11:44] or... [13:11:55] missed it. [13:12:59] jpc joins the room [13:13:14] Vjay: [13:13:18] general comment on slides. [13:13:50] he was of hte understanding that a lot of these issues were already closed on the list. [13:14:02] Charlie: procedural issue.. [13:14:27] Chair: folks seem to be more vocal at meetings.. and a good place to allow folks to speak up and give feedback. [13:14:47] Slide8 [13:14:54] Observation: after RFC 3775 was published, the IETF has subsequently published RFC 5014 to enable a mobile application to use the care-of address as a source address [13:14:59] Proposal: cite RFC 5014 as informational [13:15:24] Some discussion re how to get IKE and MIPv6 to play well together. [13:15:30] IKEv2 [13:15:32] sri [13:15:52] no questions [13:15:59] Slide 9 [13:16:05] Problem: signaling for RO can fail if mobile node and correspondent node move simultaneously [13:16:07] hirocomb leaves the room: Replaced by new connection [13:16:12] question raised again on the list [13:16:39] you can get into a situation were all retries are used.. real time traffic suffering [13:16:44] no consensus identified [13:16:55] Proposal: fall back to reverse tunneling – but, when? [13:17:22] When? Right away, after 1 try, after MAX_RETRIES or in paralell with reverse tunneling [13:17:33] Floor: [13:17:39] didn't get name [13:17:50] thought there was an interesting discussion on the list. [13:18:21] nsko leaves the room [13:18:24] nsko joins the room [13:19:00] these 4 options... problem still exists... MN may not have registered with HA (could be wrong).. [13:19:33] has papers written though it would be good to bring it back to IETF [13:19:46] though/thought [13:19:56] leaving this one open [13:20:03] Slide 10 [13:20:08] Problem: does MN expunge home agent address when its lifetime expires? Does this on whether the HA address was statically configured? [13:20:17] Question: is there a default value for the HA address lifetime? [13:20:22] what should the MN now do? [13:20:42] maybe lifetime comes from DHAAD [13:21:20] what happens when lifetime of the HA address is about to expire. [13:21:29] Floor: [13:21:37] Ryuji [13:21:53] When MN optains HA address from DNS/DHAAD, no homeagent lifetime available... so is the HA lifetime necessary [13:22:04] not sure if the information is really neceassary for MN side. [13:22:35] Charlie: X asked the question what the default value should be [13:22:51] Should be brought up on the list [13:23:39] Chair: Wrap it up.. take it to the mailing list. [13:24:05] Floor: [13:24:08] Hesham: [13:24:29] Unless everey mechanism is mandated to provide lifetime, which is impossible.. [13:24:41] then do a BU, which if it fails.. [13:24:43] start again [13:24:45] Chair: out of time [13:24:59] Floor: Whats Decision now? [13:25:02] Chair: [13:25:04] Take it to the list [13:25:07] Chairs: [13:25:39] http://tools.ietf.org/wg/mext/ [13:25:50] everyhign is in the issue tracker. [13:26:10] start a thread on the list if you have an issue. [13:26:42] hirocomb joins the room [13:27:17] hmm can't find slidesent [13:27:19] slideset [13:28:29] http://www3.ietf.org/proceedings/08jul/slides/mext-8.ppt [13:28:52] Slide 5 [13:28:59] Charlie Perkins at the mike [13:29:07] Charles [13:29:43] asked several times on the list for examples of signalling that would not fit in this format [13:29:51] no one ever could answer it. [13:30:01] No justification for imposing this on future messages [13:30:23] Elena joins the room [13:30:43] previous mechanisms were domain specific area (authentication) for example. [13:31:41] Sri is presenting [13:32:03] Sri is Arguing his case [13:32:04] washad joins the room [13:33:16] Charlie, if every conceivable message can fit into this scheme.. and if its that generic.. then it belongs in RFC3775bis or some other RFC [13:33:31] Floor: [13:34:24] Have we gone slightly off topic? [13:35:17] Point: no API interface plus further issues to describe how to protect the messages in this draft [13:35:18] ? [13:36:00] Sri: Use the same mechanisms to protect these as other Mobility Header Types [13:37:03] some discussion.. that I'm not quite able to follow. [13:38:13] Question... how to decide whether to use Generic message or now header type [13:38:21] sri: on a case by case basis [13:38:43] Floor: worried that anyone could define any new message type for any purpose [13:40:13] Another Floor: Very important for the WG to define the scope and limitation for the Generic Signally Message Format: [13:40:48] Chair: Proposing to change agenda [13:40:59] Floor: Not entirely happy with it [13:41:06] Chair: Running out it time.. [13:41:17] either finish discussion now.. and move to Binding revocation [13:41:36] or do Binding Revocation purposes [13:41:42] Sri: To close [13:41:50] if any of the draft is out of scope.. [13:41:54] talk to us. [13:43:34] summarizing discussion form the list... [13:44:24] looking at slides [13:44:25] http://www3.ietf.org/proceedings/08jul/slides/mext-7.ppt [13:45:05] Slide 14 [13:45:22] sorry.. couldnt' keep up there [13:45:44] co chair: maybe we need 3 MH types [13:46:05] Ahmad: Doesn't see need for generic message type [13:49:03] Julien: Point.. we have different ways of defining scope [13:49:19] Counterpoint: if its so generic.. its almost meaningless [13:49:54] hirocomb leaves the room [13:49:55] We need to ascertain the scope.. and its obvious there isn't consensus [13:50:17] Peny leaves the room: Replaced by new connection [13:50:39] Suresh: if we end up with wide scope generic messages, we need to need to decide if its to be mandated or not... [13:50:49] Ahmad: [13:52:06] Should Binding Revocation use Generic Message or not? [13:52:54] Guidance from Mobility Directorate Binding Revocation should use Generic Mechanism [13:53:21] Missed Marcelo's point [13:53:30] Sri: Can't answer the question "what is the scope" [13:53:45] Julien: [13:53:59] Jari: [13:54:15] john.zhao leaves the room: Computer went to sleep [13:54:16] Background to Mobility Directorate [13:54:41] Julien: Discussion closed [13:55:16] Ahmed: SHould have consensus call [13:55:19] Question [13:55:33] Should Binding revocation be based on Generic Signalling Message [13:56:02] ? [13:56:10] washad leaves the room [13:56:39] Marcelo.. seems to be a 'no' [13:56:54] New slides [13:57:10] http://www3.ietf.org/proceedings/08jul/slides/mext-6.ppt [13:58:32] sorry. not that link [13:58:50] http://www3.ietf.org/proceedings/08jul/slides/mext-10.ppt [13:59:01] arjen leaves the room [13:59:18] Slide 5 [13:59:52] Slide 6 [14:00:17] Scenarios [14:00:18] various [14:00:26] Slide 7 [14:01:04] intvelt leaves the room [14:03:10] Julien: please send comments to the list. http://www3.ietf.org/proceedings/08jul/slides/mext-6.ppt Slide 3 [14:03:29] Slide 4 [14:03:57] Slide 5 [14:04:18] cjbernardos leaves the room [14:04:40] Slide 6 [14:04:58] telemaco.melia joins the room [14:05:38] Question is: Should this be a WG item ? [14:05:50] Julien: Folks should read the new version of the draft and comment [14:06:05] We would like to ask for adoption at some stage in the future [14:06:08] We're done [14:06:16] End of session [14:06:27] Not bad for the first time scribe :) [14:06:27] Elena leaves the room [14:06:49] jeez.. [14:06:52] telemaco.melia leaves the room [14:07:05] is there a scribe howto? [14:07:17] :lol: [14:07:33] needs caffine [14:08:06] nsko leaves the room: Computer went to sleep [14:08:11] chanwah.ng leaves the room [14:08:13] jronan leaves the room [14:17:44] teco leaves the room: Replaced by new connection [14:27:47] jronan joins the room [14:29:01] jpc leaves the room [14:33:42] nsko joins the room [14:34:46] nsko leaves the room [16:03:21] jronan leaves the room [16:57:55] jpc joins the room [19:10:35] jpc leaves the room