[20:30:44] --- jasso1 has joined
[20:30:51] --- jasso1 has left
[20:32:52] --- bnsmith has joined
[20:39:16] --- jasso1 has joined
[20:39:22] --- jasso1 has left
[20:43:00] --- TJ has joined
[20:43:22] --- tskj has joined
[20:44:14] --- jasso1 has joined
[20:44:29] --- ryuji.wakikawa@gmail.com has joined
[20:48:38] --- ks has joined
[20:49:10] --- telemaco has joined
[20:49:20] --- vidya has joined
[20:53:00] --- behcet.sarikaya has joined
[20:54:04] --- bob@jabber.postel.org has joined
[20:54:22] --- bob@jabber.postel.org has left
[20:54:47] --- Bob has joined
[21:02:55] <vidya> is this jabber room active?
[21:04:21] --- Tsubasa has joined
[21:04:58] --- ryuji.wakikawa@gmail.com has left
[21:05:16] --- Tsubasa has left
[21:05:45] --- ryuji.wakikawa@gmail.com has joined
[21:09:15] <TJ> no
[21:09:56] --- ryuji.wakikawa@gmail.com has left: Logged out
[21:10:06] --- keyajima has joined
[21:10:40] --- keyajima has left
[21:13:02] --- telemaco has left
[21:13:03] <vidya> apparently :)
[21:14:06] --- petrescu7 has joined
[21:14:12] <petrescu7> hey all
[21:14:39] <petrescu7> anybody on this jabber room not in the meeting room? Like people in Canada, Japan or Laponia?
[21:14:40] <vidya> hey!! scribe already :P
[21:14:46] <vidya> yes
[21:14:58] <vidya> I'm in HOKEY and would like to see some scribes here
[21:15:20] <petrescu7> I'm in mip6 I'd like to see hokey :-)
[21:15:32] <vidya> ah!
[21:15:35] <petrescu7> HEsham Soliman presenting nemo-dsmpiv6 stuff
[21:16:11] <petrescu7> slide: Dynamic detection of NAT in the HA's domain
[21:16:29] <vidya> Thanks for scribing, Alex
[21:17:12] <petrescu7> it;s my passion
[21:17:28] <petrescu7> George Tsirtsis
[21:17:54] <petrescu7> GT: the other point about this was that in some deployment scenarios (manet) this is very unlikely to be...
[21:18:02] <petrescu7> GT: this is really for home networks...
[21:18:12] <petrescu7> GT: it was concern about how real is this in practice.
[21:18:24] <petrescu7> GT: a lot of stuff in spec that what seems to be
[21:18:29] <petrescu7> Vijay Devarapalli
[21:18:36] <petrescu7> HS: worht mentioning thanks
[21:18:59] <petrescu7> VD: we don't need this mechanisms. But, when you have a HA, you have a NAT, you must make sure HA is reachable through NAT>
[21:19:07] <petrescu7> VD:...
[21:19:11] <petrescu7> HS: yes, we should say that.
[21:19:23] <petrescu7> Ryuji Wakikawa
[21:19:31] <petrescu7> RW: do we support Dynamic ha dis or not
[21:19:34] <petrescu7> DHAAD
[21:19:39] <petrescu7> RW: not really...
[21:19:45] <petrescu7> HS: the situation is not dynamic
[21:20:04] <petrescu7> HS: consensus is on ... whoever raises the issue should get consensus for
[21:20:10] <petrescu7> HS: 3 for, 4 against
[21:20:20] <petrescu7> HS: should we reject issue?
[21:20:23] <petrescu7> JA Jari Arkko
[21:20:31] <petrescu7> JA: looks unnecessary (HA behind NAT)
[21:20:38] <petrescu7> JA: not sure you should worry about that
[21:20:44] <petrescu7> JA: complicaitons.
[21:20:50] <petrescu7> HS: draft is ...
[21:20:53] <petrescu7> Raj Patil
[21:21:01] <petrescu7> RP: not having expressed oppinion in past
[21:21:13] <petrescu7> RP: trying to do dynamic discovery is much more complex
[21:21:20] <petrescu7> RP: not need to do it with dynamic detection
[21:21:27] <petrescu7> RP: any consensus on that?
[21:21:34] <petrescu7> HS: no consensus to add...
[21:21:40] <petrescu7> HS: there';s no consensus on that
[21:21:59] <petrescu7> HS: the logic we followed: if no consensus then not add it
[21:22:08] <petrescu7> RP: we do that for a year, so we should now...
[21:22:20] <petrescu7> slide: Issue 73: Use of mapped addresses
[21:22:21] <TJ> alex: there is no hokey jabber room set up.
[21:22:31] <TJ> i am just bouncing back and forth.
[21:22:36] <petrescu7> how comes, it's a WG
[21:22:42] <vidya> cool!!
[21:22:53] <petrescu7> slide: Outstanding issues
[21:23:05] <TJ> I was just in mip6 and told that I am the jabber scribe.. oops
[21:23:09] <TJ> at least alex is doing it
[21:23:24] <petrescu7> TJ sorry if I interfere - you let me know!
[21:23:33] <vidya> funny.. I told Raj that you aren't going to be there
[21:23:48] <petrescu7> slide: Issue 73: Use of mapped address
[21:23:50] <vidya> Alex, you are doing a great job! ;)
[21:23:51] --- sureshk has joined
[21:24:04] <petrescu7> then post that slide url please
[21:24:10] <TJ> too bad both groups are at the same time, many people would be interested in both..
[21:24:25] <vidya> yep
[21:24:28] <sureshk> some dt members object to the use of map addresses
[21:24:35] <petrescu7> yes
[21:24:39] <vidya> what is a map address?
[21:24:52] <sureshk> mapped addresses
[21:24:56] <petrescu7> mapped address
[21:24:59] <sureshk> ipv4 coa in ipv6 format
[21:25:01] <petrescu7> like ::1.1.1.1
[21:25:03] <vidya> oh that
[21:25:09] <petrescu7> Vijay Devarapalli
[21:25:26] <petrescu7> VD: who contributed to what issue, it's not clear in the DT issues
[21:25:30] <petrescu7> VD: we had a section
[21:25:36] <petrescu7> HS: additional addresses
[21:25:38] <sureshk> wants to add the design team member names in the draft
[21:25:40] <petrescu7> HS: additional authors
[21:26:02] <petrescu7> slide: Issues resolved
[21:26:03] <sureshk> hesham will add it after the abstract
[21:26:09] <petrescu7> HS finished presentation!
[21:26:19] <petrescu7> AAA goals for MIP6
[21:26:21] <petrescu7> going on
[21:26:25] <petrescu7> completed LC
[21:26:32] <petrescu7> request from radext for another week
[21:26:42] <petrescu7> forgot this guy's name
[21:26:50] <petrescu7> Gerardo Giaretta
[21:26:56] <petrescu7> slide: ID status
[21:27:34] <petrescu7> slide: Goals review
[21:28:18] <petrescu7> slide: Goals review (cont'd)
[21:28:55] <petrescu7> slides are at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 and then search for 'mip6'
[21:29:23] <sureshk> slide:open issues
[21:30:02] <petrescu7> Vidya your room sounds noisy!
[21:30:12] <petrescu7> Hesham Soliman approaching
[21:30:29] <petrescu7> HS: wasn't that a few years ago, move to goals instead of reqs
[21:30:44] <petrescu7> GG: not any problem to talk of reqs instead of goals
[21:30:53] <petrescu7> HS: if goals and use MUST and SHOULD then still
[21:30:58] <petrescu7> GG: no problem
[21:31:00] <sureshk> he thinks it is difficult to compare competing proposals if we have normative language
[21:31:02] <petrescu7> this guy's name?
[21:31:06] <sureshk> hannes
[21:31:10] <sureshk> tschofenig
[21:31:16] <petrescu7> hannes tshcoeffenig?
[21:31:34] <petrescu7> HT: you should allow... but the protocol must define such, in such case you can't use
[21:31:52] <petrescu7> slide: RFC 4285 support
[21:32:32] <vidya> I don't think we should do any 4285 support now
[21:32:47] <petrescu7> 4285 title like what?
[21:33:27] <vidya> no need to specifically address any RFC4285 stuff in AAA-HA goals
[21:33:33] <petrescu7> HS: to be clear, are you want to refer to 4285 in reqs or in the MN-HA interface?
[21:33:41] --- Bob has left: Logged out
[21:33:50] <petrescu7> GG: if you use 4285... this is impact between...
[21:34:05] <petrescu7> G: should we include a req for these mobile operations in this doc of aaa reqs or not?
[21:34:16] <petrescu7> GG: doc supposes IPsec is to be used between MN and HA
[21:34:18] <vidya> no, in my opinion
[21:34:20] <petrescu7> GG: any interest?
[21:34:25] <petrescu7> why vidya
[21:34:26] <vidya> assuming IPsec is enough
[21:34:34] <petrescu7> I can relay message mon mike if you want
[21:34:39] <vidya> yes, please :)
[21:34:43] <vidya> thanks
[21:34:48] <petrescu7> yes, but I need a 'why'
[21:35:03] <petrescu7> HS: HA interface, in case
[21:35:11] <petrescu7> GG: we use BU
[21:35:30] <petrescu7> HS: a way model where BU is sent with a key, auth verifying it, as opposed to... verifies
[21:35:36] <petrescu7> HS: not want the req to be exact.
[21:35:37] <vidya> why? MIP6 inherently relies on IPsec as per the proposed standard
[21:35:43] <petrescu7> GG: ok
[21:35:48] <petrescu7> I go up and speak
[21:36:17] <TJ> (see the IESG note at the top of 4285)
[21:36:30] <petrescu7> sayus what
[21:36:46] <vidya> essentially says "don't use this protocol" :)
[21:36:55] <petrescu7> aaa?
[21:36:56] <TJ> This RFC is not a candidate for any level of Internet Standard. RFC 3775 and 3776 define Mobile IPv6 and its security mechanism. This document presents an alternate security mechanism for Mobile IPv6 used in 3GPP2 networks. The security properties of this mechanism have not been reviewed in the IETF. Conducting this review proved difficult because the standards-track security mechanism for Mobile IPv6 is tightly integrated into the protocol; extensions to Mobile IPv6 and the core documents make assumptions about the properties of the security model without explicitly stating what assumptions are being made.
[21:37:02] <sureshk> Raj Patil: wants to know why current requirements are not enough even if we need to support 4285
[21:37:16] <vidya> we don't know that, but no need to spend time to look at that now
[21:37:45] <vidya> if we decide we need that later, we can talk about it
[21:38:04] <vidya> we cannot have PS documents dealing with RFC4285 stuff
[21:38:31] <sureshk> alex relaying vidya's question
[21:39:25] <sureshk> GG: does not want to revisit the document 6 months from now
[21:39:58] <vidya> well, this document should progress on its own
[21:40:00] <petrescu7> Kuntal Chowdhury
[21:40:09] <TJ> also: Section 1.1 of this document provides an applicability statement for this RFC. The IESG recommends against the usage of this specification outside of environments that meet the conditions of that applicability statement. In addition the IESG recommends those considering deploying or implementing this specification conduct a sufficient security review to meet the conditions of the environments in which this RFC will be used.
[21:40:09] <petrescu7> KC: this is _used_
[21:40:31] <petrescu7> HS: impact of adding or not adding it
[21:40:42] <petrescu7> RP: dime wg already doing this
[21:40:47] <vidya> if we later feel we need support for RFC4285, perhaps that should be an informational document with the same kind of applicability statement as 4285
[21:41:31] <petrescu7> HT: we have to charter item we have to progress on it
[21:41:37] <petrescu7> HT: this is an open issue
[21:41:51] <petrescu7> GG: currently the draft is based on these requirements
[21:41:56] <petrescu7> GG: 4285 is not on this draft
[21:42:50] <petrescu7> JA: doesn;t mind if solution is studied, modelized to be added later
[21:42:57] <petrescu7> JA: putting it there right now seems too much
[21:43:05] <petrescu7> RP: I know that 4285 had this note from IESG
[21:43:16] <petrescu7> RP: with respect to tdevelopping reqs I don't see any issue with that
[21:43:32] <petrescu7> RP: IESG will probably have an issue if the solution comes out of the dime WG how the reqs are met
[21:43:41] <petrescu7> RP: I don't think there's an issue to that
[21:43:52] <petrescu7> JA: I told what happens previousl on similar case
[21:44:00] <petrescu7> JA: expecting same thing to happen again
[21:44:06] <petrescu7> GG: consensus?
[21:44:09] <petrescu7> laughs
[21:44:17] <petrescu7> Vijay Devarapalli
[21:44:30] <petrescu7> RP: I can ask in this room, if IESG has issues I raise it
[21:44:37] <vidya> if there is a vote, count me for no RFC4285 support in this draft
[21:44:40] <petrescu7> VD: related question, bootstrapping
[21:44:47] <petrescu7> laughs
[21:45:06] <petrescu7> JA: not even clear to me where user 4285 wants to be.
[21:45:08] <vidya> I vote the same for bootstrapping also :)
[21:45:08] <petrescu7> RP: I agree
[21:45:11] <petrescu7> RP: polli
[21:45:21] <petrescu7> RP: current AAA goals doc should include reqs from 4285?
[21:45:27] <vidya> Alex, raise a hand for me to say "no"
[21:45:28] <vidya> :)
[21:45:43] <petrescu7> RP: how many?
[21:45:57] <petrescu7> RP: how many think we should not include any further requirements in this dcoment?
[21:46:03] <vidya> thanks for helping me proxy :)
[21:46:19] <sureshk> 14 yes 5 no
[21:46:29] <petrescu7> Kuntal says I shouldn't proxy, he gets nervous
[21:46:31] <sureshk> consensus to be confirmed on ml
[21:46:54] <sureshk> that was rough consensus to ADD the requirement
[21:46:56] <vidya> huh? does Kuntal understands how jabber works? ;)
[21:47:12] <petrescu7> Ryuji Wakikawa presents Home Agent Reliability protocol
[21:47:14] <petrescu7> slide: Status
[21:51:02] <petrescu7> Kent Leung approaching
[21:51:14] <petrescu7> KL: wondering consdier work of ???
[21:51:18] <petrescu7> KL: context transfer
[21:51:26] <petrescu7> KL: considered at all?
[21:51:43] <petrescu7> RW: we havent' point the solution space, we have to check the solution space yet.
[21:51:47] <petrescu7> KL: from the reqs
[21:51:51] <petrescu7> KL: auth option
[21:51:56] <petrescu7> KL: private perspective?
[21:52:00] <petrescu7> KL: will this cover?
[21:52:08] <petrescu7> KL: that may be easier problem to solve than this thing
[21:52:11] <petrescu7> Jari Arkko
[21:52:17] <petrescu7> JA: worried about IPsec state transfer problems
[21:52:20] <petrescu7> JA: quite hard
[21:52:30] <petrescu7> RW: that's why we say minimal set of state
[21:52:39] <petrescu7> RW: each implementation has minimal sets of state
[21:52:42] <petrescu7> JA: somehow now
[21:53:07] <petrescu7> VD: for minimum state setup there are many options (hot standby, or transferring state so MN knows this reg to this HA...)
[21:53:19] <petrescu7> VD: you can do various numbers of transfers
[21:53:25] <petrescu7> VD: nothing
[21:53:40] <petrescu7> JA: multiple HA - how do they look like to MN? different ip address?
[21:53:49] <petrescu7> RW: single, or multiple home address
[21:54:00] <petrescu7> JA: something based on reestablishing the ss might be easier
[21:54:14] <petrescu7> RW: our assumption is like we try to provide solution which MN is really aware of the stage
[21:54:21] <petrescu7> RW: this prevents the assumption
[21:54:23] <petrescu7> Hannes HT
[21:54:28] <petrescu7> HT: I share JA ideas
[21:54:32] <petrescu7> HT: told them about this?
[21:54:38] <petrescu7> HT: to security ADs
[21:54:41] <petrescu7> HT: should do
[21:54:42] <petrescu7> RW: no
[21:54:51] <petrescu7> HT: may spend years to go thrash bin at the end
[21:54:57] <petrescu7> HS: what's minimal list?
[21:55:05] <petrescu7> RW: state IPsec and IKE
[21:55:13] <petrescu7> RW: implementations have states in each node
[21:55:21] <petrescu7> HS: what would not be transferred?
[21:55:41] <petrescu7> HS: but that's everything in this group (SA)
[21:55:47] <petrescu7> KC: we looked at ...
[21:55:55] <petrescu7> KC: IPsec sync between devices
[21:56:01] <petrescu7> KC: people already do that
[21:56:25] <petrescu7> KC: if go to other approach (one is mobile has to recreate the binding in ipsec tunnel with new HA - huge number of sessions affected, bring down network)
[21:56:30] <petrescu7> KC: difficult in one way
[21:56:35] <petrescu7> KC: keep the IPsec option
[21:56:43] <petrescu7> KC: not need to define any specific message
[21:56:49] <petrescu7> RW: ok thanks
[21:57:15] --- jasso1 has left
[21:57:19] <petrescu7> Vijay Devarapalli on Experimenal and Vendor Specific messages
[21:57:42] <petrescu7> slide: Experimental messages
[21:58:23] <petrescu7> slide: Vendor Specific Messages
[21:58:38] --- TJ has left
[21:59:00] <petrescu7> slide: Vendor-specific Mobility Option
[21:59:35] <petrescu7> RP: Charter has mentioned we should , include these work items
[21:59:47] <petrescu7> RP: when we revised we had that currently in the charter itself
[21:59:54] <petrescu7> RP: I think we should adopt that
[22:00:00] <petrescu7> RP: we should basically aaccept them
[22:00:05] <petrescu7> RP: but let me ask the q anyways
[22:00:25] <petrescu7> KC: if the mobile sends, and ha gets it, and ha doesn't support it, what happens
[22:00:37] <petrescu7> VD: any mobility option by definition is ignorable 3775
[22:00:49] <petrescu7> VD: but you can process the snbus.
[22:01:09] <petrescu7> RP: Jari given that this is in Charter, should we still poll the room?
[22:01:15] <petrescu7> JA: have you asked about that?
[22:01:22] <petrescu7> RP: we had this discussion in the past
[22:01:33] <petrescu7> JA: if you don't have any opther alternatives, if people object...
[22:01:45] <petrescu7> RP: we go ahead and accept this as WG items
[22:01:53] <petrescu7> RP: if serious objections please send to mailing list
[22:02:10] <petrescu7> KC: if the mobile sent it and ha didn't understand it, how does the mobile know ha ignored it
[22:02:26] <petrescu7> VD: in nemo cases, what we did we had a flag in back
[22:02:35] <petrescu7> VD: so the ha tells the mn it processed
[22:02:48] <petrescu7> HS: you have to design it properly, skippable
[22:03:01] <petrescu7> KC: if the HA doesn't understand it then HA sets a bit?
[22:03:08] <petrescu7> VD: no no, if it understands it sets
[22:03:37] <petrescu7> Hannes Tschoefenig on irtf mobopts
[22:03:46] <petrescu7> actually no
[22:03:57] <petrescu7> on MIPv6 Firewall Traversal Design Considerations
[22:04:04] <petrescu7> slide: RFC 4487
[22:04:38] <petrescu7> slide: Scenario (1/2)
[22:05:22] <petrescu7> slide: Scenario (2/2)
[22:05:40] <petrescu7> slide: Selected Problem
[22:06:11] <petrescu7> slide: Design Considerations
[22:07:51] <petrescu7> Vijay Devarapalli, HEsham Soliman approaching
[22:08:00] <petrescu7> VD: 3rd bullet point
[22:08:13] <petrescu7> VD: as long as everything is done in MH, and fw is available on MH, then you're fine
[22:08:16] <petrescu7> HT: what's fine?
[22:08:20] <petrescu7> VD: what do you need?
[22:08:24] <petrescu7> VD: authorization
[22:08:28] <petrescu7> HT: the 3rd point?
[22:08:38] <petrescu7> HT: in some proposals fw contacts to install filters
[22:08:47] <petrescu7> HT: as the mobile moves, the filters should be updated
[22:08:53] <petrescu7> HT: q on initial state setup
[22:08:57] <petrescu7> HT: or state update
[22:09:07] <petrescu7> VD: what's cg hashing and pk hashing
[22:09:23] <petrescu7> HT: some proposals use security techniques with neutlrzliased auth step
[22:09:45] <petrescu7> HT: next slide: State-of-the-Art papers using this and that... in HIP context you have signalling message, they read the packets
[22:09:54] <petrescu7> HT: if they modify state you must make sure that...
[22:10:06] <petrescu7> HT: esentially I changed Jari's state at firewall
[22:10:17] <petrescu7> HT: allows simply an arbitrary person changes state
[22:10:44] <petrescu7> HT: if you don't like thes proposals (keep fw agnostic) fw detection procedures... in that it's simpler
[22:10:52] <petrescu7> HT: if fw is more complicated another proposal
[22:11:08] <petrescu7> HT: a solution changing RR check is another solution (CN behind the fw) route all messages through HA
[22:11:29] <petrescu7> HT: another proposal to have a protocol between the MN and the MN... is this allowe dto send traffic between this and the MN
[22:11:36] <petrescu7> HT: figure out authroization or not
[22:11:56] <petrescu7> HS: I don't see this as a problem specific to... every protocol has its firewall solution...
[22:12:17] <petrescu7> HS: if somenone doens't allow mobility messages through fw then ... otherwise doesn't work mip6 through fw.
[22:12:26] <petrescu7> HS: seems to be a generic problem for all firewalls.
[22:12:32] <petrescu7> HS: routing header make sure
[22:12:37] --- behcet.sarikaya has left
[22:12:40] <petrescu7> HS: understood this protocol authenticates e2e
[22:12:51] <petrescu7> HT: just an example
[22:12:54] <petrescu7> room: use it
[22:13:05] <petrescu7> HT: not talking about favoirng a particular solution
[22:13:13] <petrescu7> HT: dependes on what time, what design guidelines
[22:13:19] <petrescu7> HS: understand, q is what is the trust
[22:13:31] <petrescu7> HT: the problem statemenet document specifically focuses on mip6
[22:13:56] <petrescu7> HS: I read it, I udnerstand, you picked up some headers... when it comes to solution it definetely protect to us alone
[22:14:02] <petrescu7> HS: there are other procoslcs
[22:14:05] --- behcet.sarikaya has joined
[22:14:19] <petrescu7> HT: there might be a problem with firewalls but rather use general solution?
[22:14:20] <petrescu7> HS: yes
[22:14:23] <petrescu7> HT: that's fine
[22:14:34] <petrescu7> slide: State-of-the-Heart
[22:14:39] <petrescu7> sorry of the Art
[22:15:43] <petrescu7> slide: Next Steps
[22:16:01] <petrescu7> HT: it's obviously not quite clear, not easy to figure out which solution to work on...
[22:16:10] <petrescu7> HT: propose to work on the scope and investigate details in group
[22:16:11] --- TJ has joined
[22:16:39] <petrescu7> RP: current charter does mention, we did a problem statement doc, what we have as a milestone to have a document descrivinbg ow mip6 would work in presence of fws
[22:17:05] <petrescu7> RP: would make sense for mip6 wg to look at if there's a generic solution, or anything specific to be done
[22:17:10] <petrescu7> RP: protocol to be used
[22:17:18] <petrescu7> RP: whatever can be used to solve the firewall problem
[22:17:36] <petrescu7> HS: makes sense if there's anything specific to MIP6 to put in reqs, but I don't think we need to do a new protocol
[22:17:52] <petrescu7> HT: really yes, if you have something, some message flows, then that would be easy and good to see.
[22:18:00] <petrescu7> HT: not advocating building something from scratch
[22:18:08] <petrescu7> HS: there might still be cases where...
[22:18:18] <petrescu7> HT: administrative problem where... you have proble,... that';s live
[22:18:21] <petrescu7> Jean-Michel Combes
[22:18:28] <petrescu7> JMC: don't understand what we want to do
[22:18:40] <petrescu7> JMC: manfacturer says to me is MIP^ aware, I dont' care
[22:18:47] <petrescu7> JMC: routing header or source header
[22:18:54] <petrescu7> HT: have you read the rfc for the ps?
[22:19:05] <petrescu7> HT: that was work starting here
[22:19:10] <petrescu7> HT: there is a protocol issue to it
[22:19:15] <petrescu7> HT: there are some issues
[22:19:23] <petrescu7> HT: of course you can say I don't believe them
[22:19:29] <petrescu7> HT: ICE tutorial, SPC
[22:19:32] --- katsu has joined
[22:19:39] <petrescu7> HT: architecture thinking
[22:19:52] <petrescu7> JMC: where are the interoperability issues
[22:20:04] <petrescu7> HT: we can probably discuss the problem statement document again
[22:20:20] <petrescu7> HS: the problem is that the ps document was coming down well there is a new protocol we should...
[22:20:23] <petrescu7> HT: not true
[22:20:28] <petrescu7> HT: different scenarios
[22:20:34] <petrescu7> HS: stateful
[22:20:43] --- sureshk has left
[22:20:45] <petrescu7> HT: packet out packet in
[22:20:48] <petrescu7> HT: then problem
[22:20:52] <petrescu7> HS: that's how works
[22:20:57] <petrescu7> HS: roll the CN and tell?
[22:21:14] <petrescu7> HT: look at voip how works, they didn't say nat is there so no...
[22:21:32] <petrescu7> HS: NAT are there for reasons out of our control, whereas fw is there for administrative
[22:21:41] <petrescu7> HS: different from NAT
[22:22:06] <petrescu7> name?
[22:22:09] <petrescu7> Checkpoint
[22:22:31] --- TJ has left
[22:22:36] <petrescu7> Although I sympathise with the notion with protocol to control fws that didn't work in the past, so we do need mip6 specific solution
[22:22:51] <petrescu7> I don't think we should go back and repeat the exercise an overall fw control protocol yet again
[22:23:10] <petrescu7> The idea that an fw can just identify the mip messages and just let them pass that just that doesn't make sense.
[22:23:27] <petrescu7> IT's same as saying as this is voip and then we let it through.
[22:23:31] <petrescu7> The fw is there for a reason
[22:23:41] <petrescu7> HS: why they failed (generic apparoach)?
[22:23:52] <petrescu7> talking about mipshop
[22:23:58] <petrescu7> HT: depends on the usage
[22:24:18] <petrescu7> RP: can't ignore the problem, let's look at this draft, in deploymentn environments
[22:24:34] <petrescu7> RP: ps rfc, there will be problems arised, nsis discussions
[22:24:57] <petrescu7> RP: fw needs to be made aware of specific parameters... these are parameters we should look at in more detail
[22:25:08] <petrescu7> RP: several people set of slides
[22:25:15] <petrescu7> RP: include from perspective of fws work
[22:25:23] <petrescu7> RP: we'll look on mailing list
[22:26:13] <petrescu7> Proxy MIP6
[22:26:19] <petrescu7> tadada
[22:26:30] <petrescu7> Gopal Dommety presents
[22:26:45] <petrescu7> GD: ask co-authors of two proposals present their work.
[22:26:54] <petrescu7> GD: more of a discussion rather than my oppinions.
[22:27:04] <petrescu7> slude: Why Proxy operation of MIP6?
[22:27:45] <petrescu7> slide: Scope of PMIP6
[22:28:27] <petrescu7> slide: What PMIP6 is NOT
[22:28:57] <petrescu7> James Kempf
[22:29:04] <petrescu7> JK: those two are contradictory
[22:29:13] <petrescu7> GD: there's a space in the middle
[22:29:20] <petrescu7> JK: firewall on the border router?
[22:29:27] <petrescu7> GD: micro-mobility, GTP replacement
[22:29:33] <petrescu7> JK: radio access networks?
[22:29:42] <petrescu7> JK: between core and radio an
[22:29:53] <petrescu7> JK: that's what it is, localized mobility management is
[22:29:59] <petrescu7> GD: that's what PMIP is not
[22:30:04] <petrescu7> JK: it isnt in the RAN
[22:30:16] <petrescu7> RP: doesn't solve the mobility problem of terminal moving across access points
[22:30:21] <petrescu7> JK: in the AR?
[22:30:23] <petrescu7> RP: yes
[22:30:31] <petrescu7> JK: documents we've submitted to IESG
[22:30:41] <petrescu7> JA: problem, it's using different words for same thing
[22:30:49] <petrescu7> JA: I understand same as netlmm is trying to do
[22:30:56] <petrescu7> JK: last bullet is the most important
[22:31:01] <petrescu7> JA: mailing list on netlmm
[22:31:12] <petrescu7> JK: pretty solid netlmm consensus of ...
[22:31:18] <petrescu7> HS: political correct?
[22:31:20] <petrescu7> GD: confused
[22:31:25] <petrescu7> HS: nothing in between
[22:31:30] <petrescu7> GD: explained offline
[22:31:44] <petrescu7> VD: leaving to 2nd bullet. the 1st we don't care
[22:31:51] <petrescu7> VD: can we use it but don't call it
[22:31:56] <petrescu7> VD: 2nd bullet most important
[22:32:10] <petrescu7> KC: we should define how this should work, how this should be helpful
[22:32:15] <petrescu7> KC: scope?
[22:32:21] <petrescu7> KC: interaciotn gateways mobility?
[22:32:28] <petrescu7> KC: restrict this work to only one app
[22:32:33] <petrescu7> RP: previous slide:
[22:32:47] <petrescu7> RP: client in host, move it to network, that's lall we do
[22:32:59] <petrescu7> RP: doesn't necessarily solve the localized mobility problem , you could make do that
[22:33:11] --- ryuji.wakikawa@gmail.com has joined
[22:33:15] <petrescu7> JK: because mobile node must be agile with the access neteorkw
[22:33:40] <petrescu7> JK: if I"m a big cell carrier I don't care because my terminals always in network, but this is IETF because some terminals aren't goping to
[22:33:45] <petrescu7> JK: if we do this
[22:33:55] <petrescu7> JK: groups of carriers to set up beusiness mobility
[22:34:04] <petrescu7> JK: still good to have lots of ceompetition
[22:34:09] <petrescu7> JK: IETF shouldn't get into
[22:34:18] <petrescu7> JK: IETF neutrality in business models
[22:34:24] <petrescu7> Samit Chakrabarti
[22:34:32] <petrescu7> SC: clarification for WG
[22:34:48] <petrescu7> SC: clarify by the second bullet? across adimisntrative domains? ISPs? ANs?
[22:35:02] <petrescu7> GD: differnt operators that want have not any agreements
[22:35:10] <petrescu7> GD: they could have agereements too
[22:35:20] <petrescu7> RP: moving from enterprise domain to wide area operator
[22:35:30] <petrescu7> RP: enterprise is own admin domain
[22:35:39] <petrescu7> GD: req comes from security requirement
[22:35:53] <petrescu7> KC: if the mobile across boundary, we don't have to require
[22:35:58] <petrescu7> KC: in every handset
[22:36:05] <petrescu7> KC: number of ways for mobiles
[22:36:09] <petrescu7> KC: IPsec to PDG
[22:36:20] <petrescu7> KC: don't have to require
[22:36:25] --- keyajima has joined
[22:36:27] <petrescu7> GD: anybody can do any
[22:36:35] <petrescu7> GD: you can't tell anybody can't do
[22:36:40] <petrescu7> GD: you can always state that work
[22:36:50] <petrescu7> GD: nobody put a gun to your head don't do it
[22:36:55] <petrescu7> HS: absloutely not
[22:37:06] <petrescu7> HS: limited to what we can do with security, mobility
[22:37:10] <petrescu7> GD: ;should give a context
[22:37:17] <petrescu7> GD: protocol abuse (is that GS?)
[22:37:23] <petrescu7> GD said protocol abuse?
[22:37:27] <petrescu7> or HS?
[22:37:34] <petrescu7> slide: Present status
[22:37:37] <behcet.sarikaya> JK said it
[22:38:01] <petrescu7> VD: proxy mip, no disclosure yet
[22:38:10] <petrescu7> VD: I personally contacted different persons
[22:38:13] <petrescu7> VD: if there are
[22:38:18] <petrescu7> GD: Jari told
[22:38:31] <petrescu7> JA: go to IETF site you'll find, but I wouldn't alarm people about that
[22:38:38] <petrescu7> JA: in this space lots of IPRs anyways
[22:38:48] <petrescu7> JA: despite what protocols are called they're kind of similar
[22:38:55] <petrescu7> JK: we should leave the IPR for now
[22:38:58] <petrescu7> JK: get technical
[22:39:03] <petrescu7> JA: just warning there is warning
[22:39:10] <petrescu7> HS: if you would decide
[22:39:27] <petrescu7> HS: last two IETF - no global mobility with proxy
[22:39:40] <petrescu7> HS: I don't see - if it's not global...
[22:39:49] <petrescu7> JA:we had this dicussion
[22:40:01] <petrescu7> JA: personally we have the feeling the same problem in this proposal.
[22:40:10] <petrescu7> JA: I'd like to have a decision in this meeting now
[22:40:18] <petrescu7> JA: this will happen in the netlmm WG.
[22:40:29] <petrescu7> JA: this discussion here in this WG as a first step towards that
[22:40:34] <petrescu7> JA: raise some hands
[22:40:38] <petrescu7> JA: final decision
[22:40:47] <petrescu7> JA: decision regarding where and what?
[22:40:52] <petrescu7> JA: we have chartered work
[22:40:58] <petrescu7> JA: what kind of solution
[22:41:09] <petrescu7> JA: netlmm decision solution or pmip solution or both?
[22:41:13] <petrescu7> HS: fine, ut
[22:41:14] <petrescu7> but
[22:41:22] <petrescu7> HS: two proopposals similar
[22:41:35] <petrescu7> HS: let's discuss
[22:41:55] <petrescu7> RP: earlier slides, what the scope of this work
[22:42:07] <petrescu7> RP: just an incremental feature to the 3775/6 spec
[22:42:19] <petrescu7> RP: not all localized mobility problem
[22:42:46] <petrescu7> RP: point here, if we have MIP6, drive for creating an addon feature to enable mobility support
[22:43:02] <petrescu7> JA: we are addressing more or less the same thing, the solution is, but that's not a big difference
[22:43:12] <petrescu7> GD: there may be slight differences in reqs
[22:43:27] <petrescu7> GD: someone may say they want to re-use what they have, versus asking for network-based
[22:43:35] <petrescu7> JA: that's a req people put fwd, yes
[22:43:41] <petrescu7> JK: we talked to 3gpp2
[22:43:49] <petrescu7> jk: desire is driven by 3GPP2
[22:44:05] <petrescu7> JK: pp2 people looked at our proposal and said this is exactly what they need
[22:44:17] <petrescu7> JA: not talk of where this work happens
[22:44:23] <petrescu7> JA: wht we should be doing
[22:44:32] <petrescu7> JA: are the solutions really same, different?
[22:44:42] <petrescu7> Vidya NArayanan
[22:44:52] <petrescu7> VN: I agree with ...
[22:44:57] <petrescu7> VN: same problem being solved
[22:45:02] <petrescu7> VN: netlmm goals draft
[22:45:07] <petrescu7> VN: has reuse
[22:45:19] <petrescu7> VN: I don't think it's an entiere mismatch netlmm is solving
[22:45:45] <petrescu7> GD: difference between reuse of existing protocols and reuse of ...
[22:45:50] <petrescu7> VN: recall discussion on goals
[22:45:54] <petrescu7> goals netlmm
[22:46:03] <petrescu7> VN: discussion started out on we should reuse mip6
[22:46:18] <petrescu7> VN: reuse of existing protocols in more generic fashion, that's a good goal to have
[22:46:23] <petrescu7> VN: talk about that reqs
[22:46:50] <petrescu7> PEritz Feder Lucent
[22:46:58] <petrescu7> puzzeld by discussion,
[22:47:05] <petrescu7> PF: using pmip4 and pmip6
[22:47:15] <petrescu7> PF: we want to have the capability of client defined, and proxy
[22:47:23] <petrescu7> PF: pushing mip into the network
[22:47:32] <petrescu7> PF: netlmm pushing ha in network
[22:47:38] <petrescu7> PF: if wimax decided not to use
[22:47:49] <petrescu7> PF: please help us to do pmip
[22:48:05] <petrescu7> PF: we need to push the client away from Microsoft
[22:48:18] <petrescu7> PF: not ntellmm but mobile ip the way you know it
[22:48:29] <petrescu7> JA: have some changes are needed
[22:48:48] <petrescu7> HS: difference between two protocols: hope we can endup with one
[22:48:55] <petrescu7> HS: what the distinction is
[22:49:04] <petrescu7> KL: featuers are different
[22:49:11] <petrescu7> KL: agree with general sentiment
[22:49:20] <petrescu7> KL: some features in netlmm protocol could be adapted to pmip
[22:49:29] <petrescu7> JA: some things you have to, others are optional
[22:49:33] <petrescu7> KL: reliability
[22:49:37] <petrescu7> KL: some other things...
[22:49:51] <petrescu7> KL: I agree proposed earlier, go back to netlmm, complications of reusable protocols
[22:50:01] <petrescu7> KL: what I hear 3gpp2, very specific of what needs
[22:50:10] <petrescu7> KL: in that context that has to be..?
[22:50:20] <petrescu7> VD: two protocols aren't different, they;re same
[22:50:31] <petrescu7> VD:...
[22:50:40] <petrescu7> VD: MN-AR interface we can definitely reuse that
[22:50:47] <petrescu7> VD: standardize both
[22:50:53] <petrescu7> VD: every ... seems to be messy
[22:51:05] <petrescu7> Ahmud Mohanna
[22:51:15] <petrescu7> AM: one protocol
[22:51:22] <petrescu7> AM: just one protocol rather than two
[22:51:27] --- behcet.sarikaya has left
[22:51:27] <petrescu7> AM: then why not three
[22:51:40] <petrescu7> AM: all protocols have same problems, all have reqs
[22:51:47] <petrescu7> AM: many people need MIP6, PMIP6
[22:52:00] <petrescu7> AM: whatever IETF wwants. No I support MIP
[22:52:15] <petrescu7> KC: we define PMIP, and this is the the WG where PMIP is personal
[22:52:23] <petrescu7> KC: the reuse mip6 protocol
[22:52:34] <petrescu7> JA: I want to ask one question
[22:52:51] <petrescu7> JA: room feels one solution (a little bit of ego, own spec) vs two specs?
[22:53:27] <petrescu7> JA: and then two solutions in this space?
[22:53:40] <petrescu7> JA: pretty clear, consensus in this room is clear
[22:53:51] <petrescu7> GT: you raised your hand twice?
[22:53:55] <petrescu7> JA: just as an example
[22:54:00] --- ryuji.wakikawa@gmail.com has left: Logged out
[22:54:07] <petrescu7> JA: decision will be made in the netlmm meeting
[22:54:19] <petrescu7> Seems to be adjourned guys.
[22:54:19] --- ks has left: Logged out
[22:54:33] --- petrescu7 has left
[22:55:12] --- keyajima has left
[22:56:04] --- katsu has left
[22:56:29] --- vidya has left
[23:00:27] --- tskj has left