[10:00:37] --- apetrescu has joined
[10:00:41] --- apetrescu has left
[10:00:53] --- jeremiah has joined
[10:01:05] --- alexpetrescu has joined
[10:02:03] --- sivaram7 has joined
[10:03:17] <alexpetrescu> slides are at http://www3.ietf.org/proceedings/07jul/slides/ search for 'netlmm'
[10:03:29] <alexpetrescu> slide: Liaison Statement from 3gpp2
[10:03:41] <alexpetrescu> Vidya Narayanan is VN and Jonne Soininen is JS
[10:03:59] <alexpetrescu> Sri Gundavelli going to present is SG
[10:04:22] <alexpetrescu> slide: Proxy Mobile IPv6
[10:05:38] <alexpetrescu> slide: Between Prague (Rev-oo) and Chicago (Rev-01)
[10:05:56] <alexpetrescu> slide: Changes from -00 Version
[10:06:05] --- jeremiah has left
[10:08:58] --- sivaram7 has left
[10:09:18] --- behcet.sarikaya has joined
[10:11:29] <alexpetrescu> (test)
[10:12:00] <alexpetrescu> slide: Issue #149: IPv4 Related Text
[10:12:40] <alexpetrescu> slide: Issue #150: LMA Failover
[10:13:33] <alexpetrescu> slide: Issue# 153: Addressing Models
[10:14:39] <alexpetrescu> slide: Issue# 154 and 158: Mandatory and Optional fields in the Policy Store
[10:14:47] --- sureshk has joined
[10:16:31] <alexpetrescu> slide: Issue# 156: MAG Actions when PBU is rejected by the LMA
[10:17:27] <alexpetrescu> slide: Issue# 157: Editorial Issues
[10:17:40] --- uli.m has joined
[10:17:47] <alexpetrescu> slide: Issue# 160: Time Stamp vs Sequence Number
[10:20:10] <alexpetrescu> Christian Vogt is CV
[10:20:44] <alexpetrescu> CV: another approach is to let th eold MAG send the reg message and when the new reg message happens to pass the old reg message then the LMA could apply some... this could be faster than sending two bu
[10:20:52] <alexpetrescu> SG: there are known mechanisms...
[10:21:28] <alexpetrescu> SG: look at the different sgr pictures; in L3 we can do that, but still quite high 3s, the mobile moves but MAG detexts and does registration, MAG can not handle that quickly; if you have that then you should
[10:21:35] <alexpetrescu> SG: but absent that you need another way.
[10:21:39] <alexpetrescu> Ahmad Muhanna is AM
[10:21:50] <alexpetrescu> AM: we agreed with the radius with the two mechanisms right?
[10:21:51] <alexpetrescu> SG: no
[10:22:13] <alexpetrescu> AM:so we agree timestamps absent then MN can use in the case of fast handovers. ctx also.
[10:22:29] <alexpetrescu> SG: if there are ctx mechanisms then, if there are mechanisms to sync that.
[10:22:38] <alexpetrescu> JS: I think the document has both of them.
[10:22:53] <alexpetrescu> slide: Issue# 161: NETLMM scope.
[10:23:22] <alexpetrescu> sliGeorge Tsirtsis is GT
[10:23:45] <alexpetrescu> GT: one thing missing in the dst domain is the question whether... if you justify with SAs then that includes miles, that is different technologies.
[10:24:09] <alexpetrescu> GT: if you limit the definition of domain to SAs then you can have a set of 'minds'(?) then use different access technologies...
[10:24:21] <alexpetrescu> GT: means you can apply PMIP to this case too.
[10:24:37] <alexpetrescu> SG: we did not touch generally inter-access.
[10:24:42] <alexpetrescu> Raj Patil is RP
[10:25:08] <alexpetrescu> RP: PMIP6 domain is comprising a set of SAs, but in this document we don't reference that a MAG is associated with a specific access tech.
[10:25:12] <alexpetrescu> RP:...
[10:25:26] <alexpetrescu> RP: don't think in this scope we should worry about MAG specific to a specific access tech.
[10:25:31] <alexpetrescu> GT: don't drag into this.
[10:25:47] <alexpetrescu> GT: when the MAGs have diffeerent techs then you need some suport in the mobile make that work.
[10:25:54] <alexpetrescu> GT: mobile doesnt hide the interfaces from this.
[10:26:04] <alexpetrescu> GT: you may have a problem, that should be recognized.
[10:26:11] <alexpetrescu> GT: if only talk SAs then not clear.
[10:26:27] <alexpetrescu> RP: I see what you say, but this is more an implementaiton aspect, how the mobile handles handovers.
[10:26:34] <alexpetrescu> RP: this is mobile implementation spec.
[10:26:46] <alexpetrescu> GT: if you don't say anything then this part says MN doesnt say anything special.
[10:26:57] <alexpetrescu> VN: base protocol we have requirement not to modify the MN.
[10:27:09] <alexpetrescu> GT: how does it square with the fact that in this case the MN is modified.
[10:27:15] <alexpetrescu> VN: yes, document should clarify.
[10:27:28] <alexpetrescu> CV: this could lead to MN end up with same address on both interfaces.
[10:27:40] <alexpetrescu> CV: that might be an issue you refer to.
[10:27:54] <alexpetrescu> SG: the MN is using mutliple interfaces, we dont deal.
[10:28:00] <alexpetrescu> Vijay Devarapalli is VD:
[10:28:35] <alexpetrescu> VD: if the domain PMIPv6 contains multiple access techs then we may say in the doc the MN may end up with same interface and MN may use a technique to avoid that.
[10:28:41] <alexpetrescu> SG: we can state that
[10:28:45] <alexpetrescu> VD: this can happen today.
[10:28:52] <alexpetrescu> VD: wifi and ...
[10:29:00] <alexpetrescu> VN: in many OS some turn down because.
[10:29:07] <alexpetrescu> VN: solutions are always... full?
[10:29:23] <alexpetrescu> SG: the host perspective needs to be more explorative: can it handle same prefix adv?
[10:29:27] <alexpetrescu> Ryuji Wakikawa is RW
[10:29:50] <alexpetrescu> RW: dont think mobile will get same address on different interfaces because LMA will reject the PBU that...
[10:30:04] <alexpetrescu> RW: theres no case where the MN has same address with the kind of PMIP.
[10:30:15] <alexpetrescu> RW: you have to extend the PMIP to register the CoA.
[10:30:29] <alexpetrescu> SG: push the address config on same interface, requires some signalling, how do you drop?
[10:30:38] <alexpetrescu> JS: cuts after HEsham
[10:30:42] <alexpetrescu> Hesham Soliman is HS
[10:31:09] <alexpetrescu> CV: this problem with duplicated IP address is not pmip specific, if you have bridged access technologies.
[10:31:39] --- montavont has joined
[10:39:01] --- alexpetrescu has left: Replaced by new connection
[10:39:16] --- alexpetrescu has joined
[10:39:32] <alexpetrescu> HS and JS commented on whether the duplicate address is intentional or accidental and concluded to continue the discussion on the maiing list.
[10:39:43] <alexpetrescu> VD: I thought we concluded LMA manages the space for home prefix, the allocation comes from LMA. Don't think there is ... MAG manages prefix. LMA manages prefix all time.
[10:39:54] <alexpetrescu> SG: sure. we discussed this on the list, the q was. Should the MAG extend the prefix returned? if ok with that then
[10:47:24] <alexpetrescu> VD: wihere get it from? SG: Not specify, policy. VD: should be managed from LMA not from AAA. SG: should take this to. One commendt. SG: address management can be delegated to other entities. VD: there are... SG: look into this issue. AM: there is another issue close I agree, profiled code, home network prefix. SG: optional. AM: optional means will be there. SG: yes. AM: contraditiocntion to handling it only by HA. SG: actually. VD: we had one more discussion on the MIP6 discussion on bootstrapping and we condluded it comes from HA not from any other entities outside.
[10:48:22] <alexpetrescu> VN donùt think ze cqn get... having a MUST is fine. MUST use is a very implementation. A MUST is mandatory to implement (2119). VN: we stds track if we do this, we have been asked more preferences... VN: best not to consider it as part of base protocol. Alper Yegin is AY AY: 4285 AY: if we go to that later, we should not shut the door to that. AY: MUST use means MUST implement? MUST use means MUST use not MUST implement VN: having the MUST use in 3775 didnt stop from publishing. VN: don't see that as a particular AY: how come that language did not stop 4285 from being used. VN: look at 2119 HS: 2119 doesnt say ... usage. HS: 2119 does not say is not the only one. HS: why we? MUST use or MUST implement never was an issue. HS: we don't bring... we talk support not usage. AY: if you read the text it says MUST use. Jim Bound is JB JB: we build specs for engineers, then we say if you do an implementation and conformant to IETF. What goes on market, GM and DoD? That's a suggestion, we dont anything MUST, not our business. We do specs for engineers. This MUST or means MUST do this means you cant go there. Jari Arkko is JA JA: we don't have that protocol police, the intent of the spec means must do that. Must support this, you should use, it's up to the WG, my personal oppinion in this case 'MUST support' is appropriate. JS: over time. important to discuss these issues. JA:searching for source of noise. RP: AY's concern, in this document there should be a default option. what is used in different deployments. At the moment there's only one option and doesn't close the door for other means. Implementing? then only way is IPsec. Suresh Krishnan, is SK. SK: proposed solution on something doesnt work. 0 lifetime on a DoS attack, keeps using prefix. This solution will not work, something else. Ajoy Singh is AS AS: we should not make it MUST use. It's ok to specify IPsec as one option. VN: JA said we don't ever , this is for default mechanism. JS: comment on readabaility, editorial work will be nice. JS: we aim with this with out-of-standards group, being more careful than normal with IETF specs will be useful SG: yes absolutely.
[10:48:41] <alexpetrescu> RW presenting
[10:48:54] <alexpetrescu> slide: IPv4 Support for Proxy Mobile IPv6
[10:49:11] <alexpetrescu> slide: Overview
[10:49:19] <sureshk> SK: I was talking about Issue #156
[10:49:51] <sureshk> when a vaid lifetime of 0 is received for a prefix than an MN is using
[10:50:07] <sureshk> it simply resets the lifetime to 2 hours (and not 0)
[10:50:35] <alexpetrescu> slide: IPv4 Home Address Mobility Support
[10:51:03] <alexpetrescu> slide: IPv4 HoA assignment from LMA
[10:51:07] --- jeremiah has joined
[10:54:18] <alexpetrescu> slide: IPv4 HoA assignment from DHCP-server
[10:55:43] <alexpetrescu> slide: PBU/PBA formats
[10:56:01] <alexpetrescu> GT: with the relay option the only for DHCP server to be able to allocate to mobile it should know which LMA
[10:56:05] <alexpetrescu> GT: how handle
[10:56:17] <alexpetrescu> RW: right... if dhcp server colocated with LMA then...
[10:56:31] <alexpetrescu> VD: how's argument, colocate dhcp server didnt make a mag a dhcp relay
[10:56:35] <alexpetrescu> VD: inter-domain
[10:56:49] <alexpetrescu> -VD: keep the IPv4 address from LMA to MAG from proxy bu to proxy back
[10:57:20] <alexpetrescu> VD: if still... then use a dhcp server, mag stores info on the dhcp server, look at bootstrapping doc, AR gets the Hoaddress, stores it on the dhcp server, comes back. Do similar.
[10:57:33] <alexpetrescu> VD: use dhcp server in the network, still makes the mag a dhcp relay.
[10:57:46] <alexpetrescu> SG: dhcp resigns then we dont have to specify that
[10:57:48] <alexpetrescu> VD: bad idea
[10:57:53] <alexpetrescu> SG: deployment is that
[10:57:59] <alexpetrescu> SG: where is n the domain.
[10:58:13] <alexpetrescu> SG: the use of dhcp is not only for address allocation is for other ...
[10:58:20] <alexpetrescu> SG: then PMIP signalling we need to push other options too.
[10:58:23] <alexpetrescu> Kuntal Chowdhury
[10:58:30] <alexpetrescu> KC : uses for 2 different cases.
[10:58:42] <alexpetrescu> KS: this case where dhcp server is outside and dhcp relay in the mag.?
[10:58:53] <alexpetrescu> KC: this is not something you get on the market (relay on mag0
[10:59:06] <alexpetrescu> KC: when PBA comes back with an error case, relay has no way to contact the server.
[10:59:13] <alexpetrescu> KC: that locks the situation,
[10:59:21] <alexpetrescu> KC: that was discussed long ago in other place.s
[10:59:43] <alexpetrescu> KC: dhcp relay has to gate the dhcp responses from the server and then issue the PBU which is not a relay behaviour today so we have to document.
[10:59:59] <alexpetrescu> KC: co-locating, the way to solve that is with private address... so eht mn always contacts the same server.
[11:00:06] <alexpetrescu> RW: same IP address to MAG?
[11:00:09] <alexpetrescu> KC: yes...
[11:00:30] <alexpetrescu> KC: mag has a dhcp server fucntion, in offer there should be a dhcp server address, that should be fixed to a given address, constantn
[11:00:41] <alexpetrescu> KC: wherever the mobile goes, wall mags could trigger.
[11:00:54] <alexpetrescu> RW: this is feasible to assign such address to all functions , it sounds like anycast.
[11:01:00] <alexpetrescu> RW: not know we should mandate?
[11:01:11] <alexpetrescu> SG: link is ptp link, we should solve it with virtual addresses.
[11:01:20] <alexpetrescu> SG: intercept that with dhcp packets, responds in any case.
[11:01:38] <alexpetrescu> RW: ptp , mag always intercepts dhcp messages, I don't know reasonable enough, I'm fine, MAG has to process packets.
[11:01:46] <alexpetrescu> JS: cross line after CV
[11:01:58] <alexpetrescu> KC: quick, this scenario has a number of issues that are not documented now.
[11:01:59] <alexpetrescu> RW: ok
[11:02:27] <alexpetrescu> VD:we do want to restrict where we place the dhcp server, we want of them, wpreferable to have, the only mechanism to get the LMA address is pbu/.pback
[11:02:50] <alexpetrescu> VD: if other configurations DNS server, MIP extensions, Homenetwork specific cnfing parameters.
[11:02:55] <alexpetrescu> Kent Leung is KL
[11:03:29] <alexpetrescu> KL:not details documented in tdraft help, make some assmptions on dhcp messaging, but not clear by looking on slide on whether the dhcp exchange happenms completely.
[11:03:35] <alexpetrescu> KL: there are details.
[11:03:46] <alexpetrescu> RW: MAG should send the pbu after the request, and... figure is not clear.
[11:03:52] <alexpetrescu> KL: a sequence thing, offline.
[11:04:24] <alexpetrescu> KL:dhcp separator or colocated with lma, not sure should this specified? should be known, some kind of interface between dhcp server and lma. if there colocated then.
[11:05:01] <alexpetrescu> CV: dhcp messages crossing admin domains, why don't you solve that with other approach, rebinding state, dhcp relay case, when mn crosses domain then all dhcp servers can force the mn in rebinding state.
[11:05:12] <alexpetrescu> CV: the two cases can be combined depending on deployment case.
[11:05:34] <alexpetrescu> RW: where we place the server, ... avoid VD's case, but not think we cna just like ... scenarios from scenarios.
[11:05:43] <alexpetrescu> CV: not specific scenarios, but these options.
[11:05:52] <alexpetrescu> JS: KC necessary?
[11:05:54] <alexpetrescu> KC: gives up.
[11:05:58] <alexpetrescu> JS: takes issues to list.
[11:06:11] <alexpetrescu> slide: IPv4 Transport Support
[11:07:22] <alexpetrescu> JS: dhcp relay issue bring to list.
[11:08:11] <alexpetrescu> Julien Laganier is JL going to present
[11:08:26] <alexpetrescu> slide: NetLMM MN-AR Interface
[11:08:29] <alexpetrescu> slide: Status
[11:09:07] <alexpetrescu> slide: Address Collisions
[11:10:20] <alexpetrescu> slide: Address Collisions
[11:11:31] <alexpetrescu> SG: on a ptp link, when link comes up, the iid negotiation, ptp you see the collision.
[11:11:37] --- Melinda has joined
[11:56:21] --- LOGGING STARTED
[11:59:33] --- apetrescu has joined
[11:59:50] --- ldondeti has joined
[12:00:14] <apetrescu> Some notes on netlmm WG meeting 24 July 2007, Chicago. Beginning of meeting is on jabber. Then jabber became jittering and I alternated between jabber noting and local noting. Some duplicates may exist. Alex Petrescu. ... VD: wihere get it from? SG: Not specify, policy. VD: should be managed from LMA not from AAA. SG: should take this to. One commendt. SG: address management can be delegated to other entities. VD: there are... SG: look into this issue. AM: there is another issue close I agree, profiled code, home network prefix. SG: optional. AM: optional means will be there. SG: yes. AM: contraditiocntion to handling it only by HA. SG: actually. VD: we had one more discussion on the MIP6 discussion on bootstrapping and we condluded it comes from HA not from any other entities outside. VN donùt think ze cqn get... having a MUST is fine. MUST use is a very implementation. A MUST is mandatory to implement (2119). VN: we stds track if we do this, we have been asked more preferences... VN: best not to consider it as part of base protocol. Alper Yegin is AY AY: 4285 AY: if we go to that later, we should not shut the door to that. AY: MUST use means MUST implement? MUST use means MUST use not MUST implement VN: having the MUST use in 3775 didnt stop from publishing. VN: don't see that as a particular AY: how come that language did not stop 4285 from being used. VN: look at 2119 HS: 2119 doesnt say ... usage. HS: 2119 does not say is not the only one. HS: why we? MUST use or MUST implement never was an issue. HS: we don't bring... we talk support not usage. AY: if you read the text it says MUST use. Jim Bound is JB JB: we build specs for engineers, then we say if you do an implementation and conformant to IETF. What goes on market, GM and DoD? That's a suggestion, we dont anything MUST, not our business. We do specs for engineers. This MUST or means MUST do this means you cant go there. Jari Arkko is JA JA: we don't have that protocol police, the intent of the spec means must do that. Must support this, you should use, it's up to the WG, my personal oppinion in this case 'MUST support' is appropriate. JS: over time. important to discuss these issues. JA:searching for source of noise. RP: AY's concern, in this document there should be a default option. what is used in different deployments. At the moment there's only one option and doesn't close the door for other means. Implementing? then only way is IPsec. Suresh Krishnan, is SK. SK: proposed solution on something doesnt work. 0 lifetime on a DoS attack, keeps using prefix. This solution will not work, something else. Ajoy Singh is AS AS: we should not make it MUST use. It's ok to specify IPsec as one option. VN: JA said we don't ever , this is for default mechanism. JS: comment on readabaility, editorial work will be nice. JS: we aim with this with out-of-standards group, being more careful than normal with IETF specs will be useful SG: yes absolutely. ------------ SG: what are the others? JS: multiple possibilities. SG: address collision that potentially other than ppp (not an issue), with others we stated there can be a collision possiliity. SG: link-local address of other nodes, that solution appeared feasible. JL: what about the other solution... selecting? SG: fine JL: include it in oyour draft SG: fine JL: discuss the issue with send, what I've deone is provisioning the certs to router to advertise the prefix, that's a typical case to advertise... JL: if both these things then we can do send. SG: send is just a trust handler, is the mag allowed to advertise that prefix? configuration this issue. What's the need to specifiy this in this doc. JL: home network prefix, home domain delivers a certificates, domain gets the prefix. SG: out of that, a provisioning issue, how in the end is some trust entity to allow that prefix is authroized, bioils to dad. JL: ok say provisioning, but if prcactically this is not possible to make it then it's ... maybe you can then deploy send tehre. SG: ok we can discuss. VN: couple of ways we can address these issues, one is we could potentially pick a reserved iid mn refrains from use that iid. other way we can prefered secpficiefd algorithm. VN: were these two possibilie options? SG: there's no unique reserved set of ids. absent that document we don't want to write anything. JL: a reserved iid then. In send the iid comes from the public key, you can't reserve it. VN: true. JA: did you mean VN there's something you should change in MN? VN: good point. KC: mentions that for most ptp links this wont happen because ppp and the one using gtp, the AR assigns the ... this should not happen in most cases. In WiMax MAC address is used. All sorts of cases I know of this should not happen. HS: ptp links dont have mac addresses (not all). Do we agree this is very rare? hong-knong1 hong-kong2 HS: theoretically, even if MN uses a MAC address we assume there is a small probability. In your solution there is also a very rare probability that the MN will change its ... address. JL: if changes it then DAD. 28 then MAG can run learn and put it to profile. HS: MAG uses same ll address for all mns. so will have to run dad too. ------------------- JA: which field of eap you intend to ? JL: out of scope JL: you say you must auth the MN, either with SeND or VIP, how you do it it doesnt matter. JA: the details matter, it has to be possible. JA: how that is possible? VN: I had this comment for the base document itself. In EAP if you use a method with id privacy. Relying on EAP... if we say there's net access control mandatory prior to. then. Wifi open example and netlmm. JS: interesting to consider. ------------------------------- CV: comment on putting those new entries in the policy store, also referes to the mobiles' address, basically changes to rather static repository to now dynamic repository and that has consequences on messaging. Keep in mind there needs to be signalling involved. ------------------------------ VN: observes 15-20min overtime. VN: will cut couple of minutes from each presentation. VD presents. ------------------------------ JS: didn't force anything but encouraged to. ----------------------------------- AY: right to say it's not a protocol issue for netlmm, may be a protocol issue for radius, we don't know that yet. Some AR needs to know whether a MN is using a PMIPv6 or MIPv6. VD: what needs to know is IPv6. AY: agree. GT: scenarios Bs how two MNs use two different mechanisms under same MAG, how they communicate with each other? One with MIP6 one with DHCP. VD: traffic goes to HA GT: that's one solution. Jouni Korhonen is JK JK: first idea of proxy mip, say which mobility is or not. RP: why does the AR advertises both prefixes? MAG can provide lots of addresses, indicate that is also a MAG. VD: that would be the MN to understand the extensions. MNs not modified. Not feasible at all if the ... is used. RP: that implies the MN understands. VD: flag wouldnt understand any way, right RP: agrees. Greg Daley is GD GD: why does the HA/LMA why it has to be the home network? Localized mobility management. A device outside the domain, then why you go back to that particular, unreasonable to have both as visited domains, and mobile goes to, you'd have to bridge every path. VD: if you have... that's not lma. VD: mobile ip tunnel on top of. GD: weak extension VD: your pmip tunnel makjes is a ptp link, makes it look as on the home link. why this scenario is a separate discussion. VD: this scenario is considered for depliyment by some sdos. GD: essentially nothing to do VD: no, lots of issues with it. GD: bu wouldn't arrive. VD: binding cache,... Ashutosh Dutta is AD AD: if interdomain mobility, one domain you're using pmip VD: not, something wont change, that's mip6, right? --------------------------------- AS: are you going to support all 3 options? VD: this is informational document, if somebody considering this handoff interwogkin scenario then.. AS: good presentation, I'd note that... crfc per-mn SAs... JS: take offline sorry about that. --------------------------- Ahmad Muhanna presenting is AM AM: asks the group about adopting draft-muhanna-netlmm-grekey as WG item. JS: not in Charter, we wait for rechartering as soon as the base come out, I'd like to wait for it come out. AM: thank you. ---------------------------- Frank Xia is presenting MN Agnostic Fast Handover... Frank Xia is FX <pasted all to here>
[12:00:26] <apetrescu> slide: Main Steps for Predictive Mode
[12:01:03] --- ldondeti has left
[12:01:09] --- lixia has joined
[12:01:10] --- vidya has joined
[12:01:29] <vidya> Alex, issues with jabber?
[12:01:35] <apetrescu> yes
[12:01:45] <vidya> ok, np.. looks like it is working now
[12:01:53] <apetrescu> it lost all notes from beginning of meeting.
[12:02:04] <vidya> hmm.. I do see it in the log
[12:02:13] <apetrescu> I dont...
[12:02:36] <vidya> http://www3.ietf.org/meetings/ietf-logs/netlmm/2007-07-24.html
[12:03:04] <apetrescu> JS: not asking question about item
[12:03:09] <apetrescu> JS: waiting for rechartering
[12:03:14] <apetrescu> Hitoshi Fuku,,,
[12:03:37] <apetrescu> HF: about ctx, about predictive mode, in reactive mode you use pbu-pback... so why not using diferent headers for ctx.
[12:03:42] --- lixia has left
[12:03:45] <apetrescu> FX: basic idea is to reuse the messages
[12:04:03] <apetrescu> FX: reuse the fmip6 messaging
[12:04:17] <apetrescu> HF: 4068 doesnt disallow hi/hack in reactive mode, they can.
[12:04:21] <apetrescu> FX: yes, they can.
[12:04:24] <apetrescu> JS: cuts down.
[12:05:06] <apetrescu> Sanjin Jeon is SJ is presenting
[12:05:16] <apetrescu> slide: Route Optimization Support for PMIP6
[12:05:24] <apetrescu> slide: Objective
[12:05:38] <apetrescu> slide: RO scenarios in PMIP6
[12:06:54] <apetrescu> slide: RO across MAGs and within an LMA
[12:07:05] <apetrescu> slide: RO across LMAs
[12:07:32] <apetrescu> slide: Issues and discussion
[12:09:07] <apetrescu> Behcet Sarikaya is BS
[12:09:11] <apetrescu> slide: Next steps
[12:09:27] <apetrescu> SJ: add to charter? design team for our solution?
[12:09:51] <apetrescu> JS: on next steps, no new wg items, this we not form any official dt; but if interested please contact authors.
[12:10:16] <apetrescu> BS: we had a draft on pmip6 RO presented in Prague, that has been quite discussed on netlmm, first presented in mipshoop.
[12:10:44] <apetrescu> BS: SJ's draft uses same exactly scenarios w/o mentioning our draft, I've told them many times, he refuses to do this, this unethical, such practice sshould not do it.
[12:11:07] <apetrescu> VN: more than one draft, suggest that all authors discuss offline, but as of now this wont be an official wg item.
[12:11:18] <apetrescu> JS: this are indifividaul drafts, work it out by yourselves.
[12:11:50] <apetrescu> Marco Liebsch is ML is going to present
[12:12:03] <apetrescu> JS: one presentation on RO you asked, we don't have time for two.
[12:12:33] <apetrescu> Jslide: Route Optimization for Proxy MIPv6
[12:12:50] <apetrescu> VN: slot requested was one draft... (discussing with Marco privately)
[12:12:53] <apetrescu> slide: Background
[12:13:11] --- behcet.sarikaya has joined
[12:13:30] <apetrescu> slide: Some thoughts...
[12:14:07] --- jeremiah has joined
[12:15:02] <apetrescu> slide: Some ideas...
[12:16:23] <apetrescu> slide: Protocol Modes and Interfaces
[12:16:39] <apetrescu> slide: More extensions
[12:17:35] <apetrescu> JS: our mistake was that, continue on ctx.
[12:17:52] <apetrescu> slide: Context Transfore for MIPv6
[12:18:50] <apetrescu> slide: Example: Reactive Context Transfer
[12:19:22] <apetrescu> JS: time for one q
[12:19:37] <apetrescu> BS: you were presenting one draft, looks as two drafts? ctx and ro?
[12:19:59] <apetrescu> BS: is a message because in one draft you recommend use previous rfc, in another draft you recommend a new protocol
[12:20:03] <apetrescu> ML: this two different
[12:20:11] <apetrescu> JS: author asked for a slot for both drafts
[12:20:28] <apetrescu> BS: all Im saying authors ahve not consisiting drafts. in case of RO several drafts are saying let's use.
[12:20:34] <apetrescu> BS: in case of ctx you're saying...
[12:20:38] <apetrescu> VN: stop discussion here.
[12:20:46] <apetrescu> VN: confusion on topics being related on unrelated.
[12:20:57] <apetrescu> CV: two different topics two different drafts
[12:21:00] <apetrescu> Michael Combes is MC
[12:21:28] <apetrescu> MC: actual version pof pmip6 draft in this draft it says HoTI messages should be dropped, I dont understand why, the consequences are that RO should not be possible.
[12:21:36] <apetrescu> JS: no answer to this.
[12:21:43] <apetrescu> MC: this is important point to solve.
[12:21:50] <apetrescu> JS: not a WG item at the moment, bring it to the list.
[12:22:02] <apetrescu> JS: we're out of time for you, next time ask for a slot earlier.
[12:22:11] <apetrescu> SK: asked earlier but didn't get time through.
[12:22:19] <apetrescu> JS: way forward, straightforward:
[12:22:21] --- vidya has left
[12:22:23] <apetrescu> JS: no slides
[12:22:47] <apetrescu> JS: get the authors of WG drafts documents to get an aextra round quickly, ready for our timelime, here, slide: WG status
[12:22:57] <apetrescu> JS: ready for LC
[12:23:22] <apetrescu> JS: activity on mailing list, how ready the docs are , asked by other SDOs, tight scehdule, hope the editors revisions quickyly
[12:23:40] <apetrescu> JS: we approach a timeline where we go towards rechartering where we go these things done.
[12:23:47] <apetrescu> JS: comments on next steps?
[12:23:56] <apetrescu> JS: straightforward for you guys as well, good to here.
[12:24:09] <apetrescu> JS: closing the meeting, thanks everybody for participating hopes to see next time.
[12:24:28] --- apetrescu has left
[12:26:06] --- behcet.sarikaya has left
[12:35:16] --- jeremiah has left
[16:13:02] --- admin has joined