[15:50:07] --- behcet.sarikaya has joined
[16:01:28] --- vidya has joined
[16:03:02] --- Gerardo has joined
[16:03:48] --- rjaksa has joined
[16:05:27] <Gerardo> a vancouver
[16:05:45] <Gerardo> in vancouver -- Gerardo and Vijay as minute taker
[16:06:35] <Gerardo> Suresh will be the jabber scribe
[16:08:36] --- xiaohunhun has joined
[16:09:42] --- sureshk has joined
[16:09:56] <sureshk> sri is going to present the base draft
[16:10:21] --- washad has joined
[16:10:46] <sureshk> sri is going to speak into the microphone now
[16:11:06] <vidya> thanks, Suresh for the jabber scribe :)
[16:11:11] <sureshk> no probs
[16:11:39] <washad> Good Luck Vidya! :)
[16:11:51] <sureshk> mainly editorial comments in last call
[16:11:56] <vidya> thanks!
[16:12:06] <sureshk> new version of draft soon to progress to iesg
[16:12:17] --- intvelt has joined
[16:12:18] --- apetrescu has joined
[16:13:48] <sureshk> sri thinks the document has been well reviewed in earlier revisions (as he calls discussed to death)
[16:13:57] <apetrescu> slide: LC Comments
[16:13:57] <sureshk> and hence the small number of last call comments
[16:15:25] <sureshk> sri is discussing whether Src address of PBU must be the dest address of PBA
[16:15:43] <sureshk> sri does not really want to restrict this (for unspecified reasons)
[16:16:00] <sureshk> but looks like he will change it in the draft from SHOULD->MUST
[16:17:25] --- ldondeti has joined
[16:17:39] <rjaksa> presentation in http://www3.ietf.org/proceedings/07dec/slides/netlmm-12.pdf
[16:18:09] <vidya> I just reordered all the presentations in the order of actual agenda
[16:18:18] <sureshk> slide 4
[16:18:24] <sureshk> slide 5
[16:18:29] <apetrescu> slide: LC Comments - Policy Profile
[16:19:13] <sureshk> sri is talking about how the MAG gets the operational parameters
[16:19:35] <sureshk> one way is a AAA profile
[16:19:39] <sureshk> one of them is a CLI
[16:19:54] --- tskj has joined
[16:19:58] <sureshk> Sri feels that how the MAG gets them is not important
[16:20:01] <apetrescu> Gerardo Giaretta speaking
[16:20:09] <apetrescu> GG: not all protocols need this profile (MIP6 eg)
[16:20:10] <sureshk> just that it does
[16:20:47] <sureshk> Gerardo does not want the policy profile to be a dump for unsolved problems
[16:20:47] <apetrescu> GG: worried, in the draft: every time there's an issue then ok it's in the policy profile. Should be very clear that a lot amount of work is needed.
[16:20:53] <apetrescu> GG: best way to do that is to remove all policy profile, sounds as interoducing new entity but you don't.
[16:21:12] <apetrescu> GG: draft assumes MAG has this config information, and the way this config is delivered to MAG is out of scope.
[16:21:17] <apetrescu> GG: we don't need ...
[16:21:22] <apetrescu> SG (Sri Gundavelli)
[16:21:37] <apetrescu> SG: if we chnge the assumption, then policy profile is a groupd of parameters but system needs them.
[16:21:47] <apetrescu> SG :what level of detail we need? You said we need to be exact
[16:22:02] <apetrescu> SG: it can dynamically generate it, or obtain, it.... thinking what of the clarifications are needed?
[16:22:20] <apetrescu> GG: every time I read policy profile, this is leading to some solution... solution not before recharteringh.
[16:22:24] <apetrescu> GG: you create an assumption
[16:22:29] <apetrescu> GG: ... assumme.
[16:22:37] <apetrescu> GG: don't need say anything else.
[16:22:37] <apetrescu> SG:
[16:22:38] <apetrescu> ok
[16:22:40] <sureshk> GG wants to list the parameters that are needed
[16:22:40] <apetrescu> Ahmad Muhanna
[16:22:49] <sureshk> Ahmad disagrees with GG
[16:22:52] <apetrescu> AM: I disagree with GG, every time on list we have a problem
[16:23:08] <apetrescu> AM: this was dscussed before we achieved consensus. IF every time we open that again
[16:23:14] <apetrescu> AM: GG doesnt agree with the context.
[16:23:27] <apetrescu> AM: GG wants you to remove policy profile and wants you to write it differently
[16:23:35] <apetrescu> AM: thre was however consensus shouldn't remore
[16:23:38] <apetrescu> Hesham SOliman
[16:23:45] <apetrescu> HS: to solve it - say it's configurabe
[16:23:58] <apetrescu> SG: it says it can generate or part of context transfer...
[16:24:00] <apetrescu> SG: clearly not a proble
[16:24:07] <apetrescu> SG: I agree not a progress.
[16:24:17] <sureshk> next slide
[16:24:19] <apetrescu> slide: LC comments - Multi-hming Section
[16:24:22] <sureshk> multihoming
[16:25:13] <sureshk> right now issue handling is seperated into sections
[16:25:24] <sureshk> that are different from the general processing rules
[16:25:33] <sureshk> eg. timestamps, multihoming
[16:25:43] <sureshk> some people prefer a linear flow
[16:25:47] <sureshk> comments welcome
[16:26:03] <apetrescu> AM: I support the way the draft ios written. There are some peolple who don't want support
[16:26:05] <vidya> we need to do what is right.. the text needs to be readable, but, the changes need to be reflected whereever needed
[16:26:08] <apetrescu> room:...
[16:26:15] <apetrescu> AM: multihoming was introduced after 06
[16:26:28] <sureshk> ahmad thinks some people do not wish to implement multihoming
[16:26:36] <apetrescu> AM: it was IMHO as long as it is coherent, it still gives you a logical. Not the feeling that out of the bule.
[16:26:39] <apetrescu> AM: spreaded over is much easier
[16:26:49] <apetrescu> AM: structure of the doc could have been changed than what it is now.
[16:27:00] <apetrescu> SG: not an intention, we changed the rulse.
[16:27:09] <sureshk> sri does not think multihoming is optional
[16:27:14] <apetrescu> AM: saying that any rfc ietf produces there's some suppliers some statement of compliance
[16:27:14] <vidya> actually, this issue was about supporting multihomed hosts in the netlmm domain
[16:27:20] <apetrescu> AM: this funcitonality not supported
[16:27:27] <apetrescu> AM: doesnt mean anything
[16:27:29] <apetrescu> JS Jonne Soininen
[16:27:36] <apetrescu> JS: not discuss now about complaince now.
[16:27:43] <apetrescu> George Tsirtsis
[16:27:53] <apetrescu> GT: multihoming is not an optional part of spec, it's a must
[16:28:12] <vidya> fundamentally, there are changes to what is included in the PBU/PBA and it is not dependent on whether a host is multihomed or not
[16:28:13] <apetrescu> GT: point is this comment made is that for an implementation point of virew it would be good to have one place where you implement BU
[16:28:22] <apetrescu> GT: spreading across document is harder
[16:28:30] <apetrescu> GT: when reviewing the doc, I had a million comments
[16:28:31] <sureshk> yes
[16:28:51] <sureshk> after reading the MH section he deleted a few of them
[16:28:55] <apetrescu> GT: in the ... sections because not included the multihimoning, then I went back and remove the comments... Not make sense. IT's a structural issue.
[16:29:00] <apetrescu> SG: you clearly changed rules
[16:29:08] <sureshk> GG thinks this is editorial
[16:29:11] <apetrescu> GG: not a technical issue, its editorial, structure of document.
[16:29:27] <sureshk> he thinks the doc is not readable
[16:29:30] <apetrescu> GG: patch for multihoming support. Now it's very difficult to read, you need to go back and forth
[16:29:36] <sureshk> we need to go back and forth multiple times
[16:29:44] <apetrescu> GG: more difficulet to understand all options all ... use of options.
[16:29:49] <apetrescu> GG: split in different options.
[16:29:58] <apetrescu> GG: for timestamp it's easier, four bullets it's ok.
[16:30:07] <apetrescu> GG: for multihoming it impacts everything.
[16:30:12] <apetrescu> GG: not technical, it's editorial.
[16:30:16] <apetrescu> JS: 5min late
[16:30:30] <apetrescu> JS: sorry for these people who'll get less time for their presentations.
[16:30:48] <apetrescu> slide: LC Comments - Use of MN-Id
[16:31:12] <sureshk> Alper thins MNID should not be used in all signaling messages
[16:31:40] <sureshk> why not use HNP as key
[16:31:53] <sureshk> jari wanted a consistent identity all the time
[16:32:00] <apetrescu> Alper YEgin is AY
[16:32:02] <sureshk> so we are going to stick with mnid
[16:32:08] <apetrescu> AY: we shall have something in the signalling to id the mn
[16:32:24] <apetrescu> AY: if we can assign the hnp before the prefix signalling takes place we can always use the hnp as id
[16:32:30] <apetrescu> AY: why... inband with pmip
[16:32:45] <apetrescu> SG: in a proxy model we ... arguates, we need to have some access id
[16:32:50] <apetrescu> SG: using an address to id
[16:32:57] <apetrescu> SG: it should be seen
[16:33:03] <apetrescu> SG: makes sense in the proxy model.
[16:33:07] <apetrescu> SG: keep this, IMHO
[16:33:11] <apetrescu> AY: we need to discuss this more
[16:33:22] <apetrescu> AY: that mn=id is not a statid id that we could rely on
[16:33:22] --- intvelt has left
[16:33:33] <apetrescu> SG: easier requirement, 4285.... why I want to understand
[16:33:59] <apetrescu> AY: first came with 4285 rfc, but then we went to multihoming, introduced comlexity, for the spec as well as for deloyment
[16:34:12] <apetrescu> AY: inband prefix assignment - get rid of it and thus all complexities go away.
[16:34:18] <apetrescu> YA: asking about
[16:34:19] <apetrescu> Jari Arkkko is JA
[16:34:31] <apetrescu> JA: is there a problem? something breaks if we do this?
[16:34:43] <sureshk> it is uncertain
[16:34:46] <vidya> I think this discussion was on the list and the complexities don't go away by getting rid of inband address assignment
[16:34:50] <apetrescu> AY: as a complexity I see, not sure... uncertainty about what mn-id is, another new subid
[16:35:01] <apetrescu> AY:if a way there is to get rid of all complexity
[16:35:06] <apetrescu> JA: so not a problem right?
[16:35:09] <apetrescu> AY:...
[16:35:12] <apetrescu> Vijay Devarapalli is VD
[16:35:26] <apetrescu> VD: write a draft how you don't do prefix... inband. So people will understand.
[16:35:26] <sureshk> wants alper to write a draft
[16:35:37] <apetrescu> AY: why do you want to do prefix assignment inband?
[16:35:41] <apetrescu> AY: that is open question
[16:35:42] <sureshk> describing how to do oob assignment of hnp
[16:35:48] <apetrescu> VY: because the sequence is so and so
[16:35:51] <rjaksa> microphone
[16:35:54] <apetrescu> AY: how does it know how to
[16:36:02] <apetrescu> GG: it's in the policy profile
[16:36:15] <apetrescu> GT: problem is that protocol uses a lot of external profile.
[16:36:29] <apetrescu> GT: a lot of params that are not inherent in the protocol.
[16:36:29] <sureshk> MAG uses a ot of external parameters
[16:36:42] <apetrescu> GT: mn-id doesn't belong to the protocol itself has to come from somewhere else
[16:36:54] <apetrescu> GT: not ahvae I an immediate oppinion on inband discussion
[16:37:01] <sureshk> PMIP is not a standlone protocol
[16:37:03] <apetrescu> GT: have to combine with other systems
[16:37:20] <apetrescu> AY: if MAG knows which LMA to send to then how does it not know the...
[16:37:28] <sureshk> HNP
[16:37:29] <apetrescu> AY: somehow MAG gets MN-specific information
[16:37:34] <apetrescu> SG: we not say that, we say as hint
[16:37:44] <apetrescu> SG: in the presence of that should we rely on mn-id
[16:37:54] <apetrescu> SG: entity that is authorized as prefix of lma
[16:38:00] <apetrescu> SG: in dhcp you also suggest a hint
[16:38:15] <apetrescu> AY: not talking about relaxing nbut about getting rid of mn-id
[16:38:17] <apetrescu> SG: oh no
[16:38:26] <sureshk> concluded
[16:38:26] <apetrescu> AY: that's the comment and that's the issue
[16:38:30] <apetrescu> slide: Thank You
[16:38:39] <apetrescu> SG: hopefully this is my last presentation on this draft
[16:39:01] <sureshk> GT: 5 new params added to protcol for supporting multihoming
[16:39:03] <apetrescu> GT: main comment: multihoming discussion resulted in 5 parameters - some of them have 2 values, some them more - look at these 5 parameters
[16:39:16] <sureshk> we need to look at all of them to decide what prefix to alloc
[16:39:17] <apetrescu> GT: in the draft all the combinations need to be described, otherwise wouldn't know what to do.
[16:39:29] <sureshk> draft missing some combinations
[16:39:33] <apetrescu> SG: when id and at are both present... mailing list
[16:40:08] <apetrescu> JS: at the cost of other presentations we have to WG presentations first
[16:40:09] <sureshk> we are running late
[16:40:14] <apetrescu> Ryuji Wakikawa going to present
[16:40:30] <apetrescu> slides at http://www3.ietf.org/proceedings/07dec/slides/netlmm-1.pdf
[16:40:43] <apetrescu> slides: Updates
[16:41:48] <apetrescu> slide: Various DHCP Configurations
[16:43:12] --- badra has joined
[16:43:37] <apetrescu> HS: all these cases are that can be used?
[16:43:45] <apetrescu> RW: the first two scenarios are implemented, last one in appendix
[16:44:00] <apetrescu> HS: the one on boottom left doesn't seem to be working
[16:44:10] <apetrescu> HS: how does the LMA know to inject routes?
[16:44:16] <apetrescu> HS: worse specific routes?
[16:44:26] <apetrescu> HS: host-specific routes for v4 addresses?
[16:44:26] --- ldondeti has left: Replaced by new connection
[16:44:32] <sureshk> host specific routes
[16:44:51] <apetrescu> slide:DHCP-S is located at MAG
[16:45:57] --- tskj has left
[16:46:21] --- badra has left
[16:48:48] <apetrescu> slide: DHCP-S is located at LMa
[16:51:33] <sureshk> soliciing comments on this document
[16:51:35] <apetrescu> sJS: no comments, thank you
[16:51:45] <apetrescu> JS: rapidfire presentations
[16:51:57] <apetrescu> JS: PMIPv6-MIPv6 Interactions
[16:52:19] <apetrescu> slides at http://www3.ietf.org/proceedings/07dec/slides/netlmm-3.pdf
[16:52:25] <apetrescu> Gerardo Giaretta presenting, is GG
[16:52:32] <apetrescu> slide: Status
[16:52:47] <apetrescu> slide: Scnario A
[16:53:47] <apetrescu> slide: Scenario B
[16:55:24] <sureshk> due to major changes in the base draft
[16:55:41] <apetrescu> Raj Patil is RP
[16:55:44] <sureshk> there might be a need to revisit this scenario wrt multihoming
[16:55:46] <apetrescu> RP: on this AR doing dual role
[16:56:01] <apetrescu> RP: this router is capable of supporting a prefix from an LMA vs a topologically correct prefix
[16:56:07] <apetrescu> RP: otherwise MN doesn't know
[16:56:28] <apetrescu> GG: for intra-tech case where we consider system-level problems, then I agree with you inorder. for some reqs, some proto work if needed
[16:56:31] <apetrescu> slide: Scenairo C
[16:58:24] --- tskj has joined
[16:58:42] <sureshk> jari is not convinced about the need for B and C
[16:59:20] <sureshk> GG mentions 3GPP using scenario C
[16:59:24] --- apetrescu has left
[17:00:25] --- apetrescu has joined
[17:00:44] <apetrescu> HS: completely agree, always I've had a problem with this scenario, I've asked but no answer
[17:00:51] <apetrescu> GG: basically that is the only reason
[17:01:02] <apetrescu> GG: if we don't care then we don't care
[17:01:06] <apetrescu> VD: responding to JA
[17:01:21] <apetrescu> VD: what I've seen is people are doing scenario C, when they do that then it's better for us
[17:01:27] <apetrescu> VD: if somebody needs such a solution
[17:01:37] <apetrescu> VD: documenting that is a good step rather than doing on their own
[17:01:43] <apetrescu> JA: that if, I don't mind that
[17:01:52] <apetrescu> GG: that's why we split the draft
[17:01:59] <apetrescu> slide: Open Issues (cont'd)
[17:03:30] <apetrescu> Ahmad Muhanna going to present GRE Key... slides at http://www3.ietf.org/proceedings/07dec/slides/netlmm-0.pdf
[17:03:37] <apetrescu> slide: GRE Key Option - Overview
[17:04:24] <apetrescu> slide: Use CAses
[17:05:25] <apetrescu> Hui Deng is HD
[17:05:35] <apetrescu> HD: GRE tunnel ? security /
[17:05:42] <apetrescu> HD: IKE negotiation guarantees
[17:05:47] <apetrescu> HD: any security guarantee?
[17:05:57] <apetrescu> SG: no, the key is intended for flow separation
[17:06:04] <apetrescu> GT: how do you secure the GRE tunnel?
[17:06:13] <apetrescu> SG: you can apply any ... security on that
[17:06:21] <apetrescu> HD: tunnel inside the GRE tunnel
[17:06:28] <apetrescu> SG: the tunnel mode, the ESP on top of that
[17:06:35] <apetrescu> SG: you secure the whole packet
[17:06:45] <apetrescu> JS: you can run also the packets that are run on top of the tunnel
[17:06:59] <apetrescu> HD: laze to tunnel, we wrote a draft for ike negotiation for gre tunnel
[17:07:33] <apetrescu> Christian Vogt is CV slides are at http://www3.ietf.org/proceedings/07dec/slides/netlmm-13.pdf
[17:07:39] <apetrescu> slide: Plenty Room for Optimization
[17:08:54] <apetrescu> slide: Joint Efforts
[17:09:51] <apetrescu> draft-jeong-netlmm-pmipv6-roreq-01
[17:10:25] <apetrescu> SG: prefix is anchored on LMA, how much scope do you see for RO?
[17:10:42] <apetrescu> CV: depends on the actual proposal - if there's support on two mags to communicate directyl then direct route?
[17:10:48] <apetrescu> SG: the MAG would do the RO right?
[17:10:49] <apetrescu> CV: yes
[17:10:56] <apetrescu> CV: optimization in diferent network entities
[17:10:58] <apetrescu> SG: ol
[17:11:02] <apetrescu> SG: ok
[17:11:14] <apetrescu> CV: asks the room to read the doc and send comments on the mailing list
[17:11:36] <apetrescu> HS: comment, consequence of having things we talked about before, global mobility, ...
[17:11:45] <apetrescu> HS: if we start doing RO on top of RO, proxy RO?
[17:12:07] <apetrescu> HS: something to keep in mind, small assumptions we don't seem to be able to stop on base spec then - proxy global ro? keep in mind\
[17:12:12] <apetrescu> CV: to be kept in mind.
[17:12:25] <apetrescu> CV: to not want to proxy for...
[17:12:30] <apetrescu> CV: correspondent host to talk to a proxy
[17:12:37] <apetrescu> CV: not want to talk proxy on both sides
[17:12:46] <apetrescu> HS: really doesn't matter, you still proxuy
[17:12:52] <apetrescu> JS: cuts the line, minutes over.
[17:13:11] <apetrescu> Mohana Jeyatharan going to present PS for multiple interfaces
[17:13:23] <apetrescu> slides at http://www3.ietf.org/proceedings/07dec/slides/netlmm-5.pdf
[17:13:32] <apetrescu> slide: Problem Statement - Single Prefix
[17:14:52] <apetrescu> slide: Monami6 node in various Roaming Scenarios
[17:16:59] <apetrescu> JS: 1 minute for qs
[17:17:32] <apetrescu> John Zhao is JZ present s on PMIP and NEMO scenario - Problem Statement
[17:17:35] <apetrescu> slide: Scenarios
[17:17:49] <apetrescu> slides are at http://www3.ietf.org/proceedings/07dec/slides/netlmm-7.pdf
[17:19:53] <apetrescu> slide: Problems and requirements
[17:21:51] <apetrescu> test
[17:22:43] --- ldondeti has joined
[17:23:23] <apetrescu> slide: Next
[17:23:53] <apetrescu> JS: 2 more presentations before discussion on rechartering, we can not come back
[17:24:06] <apetrescu> Vijay Devarapally presents Multiple Interface Support with PMIPv6
[17:24:32] <apetrescu> slides are at http://www3.ietf.org/proceedings/07dec/slides/netlmm-4.pdf
[17:24:43] <apetrescu> slide: Multiple Interface Support in PMIPv6
[17:25:52] <apetrescu> slide: Multiple Interface Scenarios
[17:28:02] <vidya> there seem to be audio problems.. audio at my end suddenly stopped
[17:28:09] <vidya> anyone else having the same issue?
[17:28:23] <rjaksa> audio is still ok for me
[17:28:39] <apetrescu> JS: thanks vijay , almost on time
[17:28:43] <apetrescu> JS: inter-tech handover
[17:29:04] <apetrescu> MArco Liebsch going to present slides at http://www3.ietf.org/proceedings/07dec/slides/netlmm-9.pdf
[17:29:19] <vidya> got it back now!
[17:29:20] <apetrescu> slide: Inter-Technology Handover - Problem Space
[17:30:40] <apetrescu> slide: Preliminary Binding as Solution
[17:31:16] --- badra has joined
[17:31:53] <apetrescu> JS: comments now?
[17:32:03] <apetrescu> VD: why is this specific to inter-access ho not regular ho?
[17:32:12] <apetrescu> ML: here one of the ifaces is configured already
[17:32:33] <apetrescu> ML: home network on one net... mt doesn't need to reconfigure an interface, but if you activate a new iface then this attaches to network.
[17:32:37] <apetrescu> ML: might take time
[17:32:40] <apetrescu> VD: why
[17:32:44] <apetrescu> ML: why/
[17:32:47] <apetrescu> VD: yeah
[17:32:56] <apetrescu> SG: implementations handle this differently
[17:33:02] <apetrescu> SG: move the configurations to other interfaces
[17:33:07] <apetrescu> SG: example is the virtual interfaces
[17:33:14] <apetrescu> SG: how use case is to justify.
[17:33:23] <apetrescu> SG: in case of virtual interfacers, is this required?
[17:33:28] <apetrescu> SG: where is the latency seen?
[17:33:46] <apetrescu> ML: virtual is implementation specific, this is physical interfaces, taking into account that an new hnp is recieved...
[17:33:49] <apetrescu> ML: takes time
[17:33:55] <apetrescu> ML: so many packets...
[17:34:17] <apetrescu> ML: nd requests, dad tests is described in the draft, only one potential problem, might be ther problems.
[17:34:22] <apetrescu> JS: stops here. late.
[17:34:30] <apetrescu> JS: rechartering discussion
[17:34:36] --- badra has left
[17:34:42] <apetrescu> JS: sorry for everybody whose presentation was not in at this time.
[17:35:06] <apetrescu> JS: presentations are online [at https://datatracker.ietf.org/meeting/70/materials.html#wg-netlmm]
[17:35:12] <apetrescu> slide: Recharter Discussion
[17:35:34] <apetrescu> [recharter discussion slides are at http://www3.ietf.org/proceedings/07dec/slides/netlmm-11.pdf]
[17:35:53] <apetrescu> slide: Recharter Discussion: Before rechartering
[17:36:26] <apetrescu> JS: main question: do we need to recharter? or can we just stop work
[17:36:35] <apetrescu> JS: so many presentations
[17:36:49] <apetrescu> JS: seems we need for this WG, need for work seems interest to further work
[17:36:59] <apetrescu> JS: Chairs think we would propose recharter
[17:37:15] <apetrescu> JS: AD agrees with us I think but we never know...
[17:37:22] <apetrescu> JA:... I think there's interest
[17:37:29] <apetrescu> JS: doesn't mean we do everything put up here
[17:37:41] <apetrescu> JA: take care what maeks sense
[17:37:46] <apetrescu> JA: this ltittle think
[17:37:53] <apetrescu> JS: there are issues to be done
[17:38:15] <apetrescu> JS: not now the content
[17:38:22] <apetrescu> ...
[17:38:27] --- badra has joined
[17:38:56] --- badra has left
[17:39:30] <apetrescu> JS: work for one year and then we look forward
[17:39:54] <apetrescu> HS: first bullet is the principal
[17:39:57] <apetrescu> JS: yes
[17:40:00] <apetrescu> JS: wait
[17:40:04] <apetrescu> HS: comment
[17:40:19] <apetrescu> HS: hard to , of course..
[17:40:30] <apetrescu> HS: hard to discuss rechartering w/o knowing the new topics
[17:40:42] <apetrescu> HS: rather discuss what topics would we include in charter and naturally ...
[17:40:53] <apetrescu> HS: no sense or say we naturally we need to recharter
[17:40:58] <apetrescu> HS: rather discuss topics
[17:41:09] <apetrescu> JS: no abstract decision on rechartering, kick off.
[17:41:22] <apetrescu> JS: what is the work needsto be done.
[17:41:32] <apetrescu> JS: constantly under discussion.
[17:41:44] <apetrescu> slide: Principles from current charter (Food for thought)
[17:42:27] <apetrescu> slide: Explicitly out-of-scope in current charter (Food for thought)
[17:42:32] <apetrescu> HS: no IPv4 transport
[17:42:36] <apetrescu> JS: scope
[17:42:42] <apetrescu> JS: reading this differently
[17:42:52] <apetrescu> JS:...
[17:43:32] <apetrescu> GG: previois slide was about principles, next slide is what is out of scope.
[17:43:46] <apetrescu> GG: one could implement something lije this with the current principles
[17:43:57] <apetrescu> HS: do you want to discuss now? orj ust listing
[17:44:03] <apetrescu> JS: listing for memory.
[17:44:12] <apetrescu> JS...
[17:44:23] <apetrescu> JS: more aggressive reminder of what's here, rechatering as a channllling set
[17:44:27] <apetrescu> JS: work needed?
[17:44:33] <apetrescu> JS: not discussed aanymore then.
[17:44:39] <apetrescu> HS: comment on princpiles slide
[17:44:45] <apetrescu> JS: rules I agree
[17:44:49] <apetrescu> HS was that not JS
[17:45:00] <apetrescu> HS: seconnd bullet unless we decide...
[17:45:10] <apetrescu> HS: current protocol does in theory do global mobility management
[17:45:19] <apetrescu> HS: that's global mobility management
[17:45:23] <apetrescu> HS: have we?
[17:45:30] <apetrescu> SG: comment on principles
[17:45:52] <apetrescu> SG: a year ago idea was that mobile not involved, but we took that to such an extreme, we should relax that, the most misinterpreted statement.
[17:45:56] <apetrescu> Jim Bound is JB
[17:46:10] <apetrescu> JB: work I hope it never happens.
[17:46:15] <apetrescu> JB: is a freaking joke
[17:46:29] <apetrescu> JB: keeping things about things that dont involve tunnels
[17:46:57] <rjaksa> interesting comment...
[17:47:00] <apetrescu> JB: work on netlmm that every node has a mip6 implementation, a total pure endtoend mip6 deployment model, what's missing from IETF?
[17:47:16] <apetrescu> JB: I hope you don't want to go further on _proxy_ mip6
[17:47:18] <apetrescu> JS: go to mext
[17:47:26] <apetrescu> JB: I'll wait to see if that's true, not convinced.
[17:47:33] <apetrescu> RP
[17:47:48] <apetrescu> RP: principles, are you asking whether those are debatable whether these are rechartering discussion?
[17:48:04] <apetrescu> RP: no changes to the mn? Is this open to the mn? Could we consider changes to mn are allowed
[17:48:06] <apetrescu> JS: yes
[17:48:16] <apetrescu> JS: if recharter then reqreite new charter
[17:48:21] <vidya> that's a discussion to be had
[17:48:26] <apetrescu> JS: discussion if we decide to go that or not
[17:48:40] <apetrescu> JS: principles are up to discussion
[17:48:51] <apetrescu> RP: make sure we not holding as be some of sacred not violated
[17:48:56] <apetrescu> JS: have to be debate at this point
[17:49:10] <apetrescu> GG: not mix what are the primciples and what was considered as scope at beginning
[17:49:17] <apetrescu> GG: netlmm charter has this principle...
[17:49:39] <apetrescu> GG: this is clearl what netlmm is, if we go to change mobile node, if we change to global mobility, name of WG is local
[17:49:43] <apetrescu> GG: stick to principle
[17:49:54] <apetrescu> GG: to respond to HS< we didn't violate anything
[17:49:55] <apetrescu> HS: we did
[17:50:02] <apetrescu> HS: this whole group is a violation
[17:50:07] <apetrescu> GG: ... not a wg draft
[17:50:20] <apetrescu> HS: it's not your draft, in the protocol you can't stop something...
[17:50:31] <apetrescu> GG: if we specify that in ietf... or not... different
[17:50:46] <apetrescu> HS: couple comments, agree with GG, although on name. I agree on rest of comments
[17:51:00] <apetrescu> HS: there were reasons for not changing the mn, same reasons still apply.
[17:51:11] <apetrescu> HS: "now this is too old let's change"
[17:51:17] <apetrescu> HS: this xy z changed
[17:51:24] <apetrescu> HS: this is not what's happeinning
[17:51:28] <apetrescu> George Tsirtis
[17:51:45] <apetrescu> GT: first principle in this group is to adhere to its own principles, it has a bad record in doing that
[17:52:09] <apetrescu> GT: when people chartered netlmm everybody assummed local means single tech, but later we said local its not necessary, now doing inter=-tech
[17:52:19] <apetrescu> GT: denial state of the fact that is still in one domain
[17:52:28] <apetrescu> GT: all protocols custeomres are doing global mobility
[17:52:37] <apetrescu> GT: argue I'd, if ...
[17:53:02] <apetrescu> GT: then talk about whole mobility subdomain, if they said so at beginning, then they wouldn't be chartered. Need guidance from IAB
[17:53:10] <apetrescu> GT: not see where IAB thinks this should go
[17:53:16] <apetrescu> GT: like to hear oppinion on this.
[17:53:29] <apetrescu> JA: to q host changes? some of the reasons of req on no host changes
[17:53:36] <apetrescu> JA: the way this tech is deployed...
[17:53:50] <apetrescu> JA: those whostss actually have to work, those whosts need to not change
[17:54:11] <apetrescu> JA: doesn't preclude the optimization of this, modified host can behave better, multihmoing, inter-access handover.
[17:54:27] <apetrescu> JS: couple of minutes
[17:54:34] <apetrescu> JS: close the line hs is the last one to speak
[17:54:58] <apetrescu> GG: if we read the current pmipv6 draft there are some things that are operational reqs that are left for study, these are actually left
[17:55:05] <apetrescu> GG: there's actually a need if you want to deploy
[17:55:15] <apetrescu> GG: what we should do is to prioritize the work that is needed
[17:55:41] <apetrescu> GG: instead of adding new funcitonality, always new functionality, beyond the principles we agreed, should do a line of what we need to do before we deploy this protocol
[17:55:49] <apetrescu> (before we develop new)
[17:55:57] <apetrescu> VD: agree with JA, ...
[17:56:19] <apetrescu> VD: charter needs tob e aupdated to mean that we refer to the fact that it doesnt have to do any mobility
[17:56:33] <apetrescu> VD: those kinds of ... should be allowed by the new charter text
[17:56:40] --- Gerardo has left: Replaced by new connection.
[17:56:40] --- Gerardo has joined
[17:56:50] <apetrescu> VD: no changes to the host? shouldnt mean no changes to the mobie
[17:57:04] <apetrescu> VD: fact that we ... pmipv6 has been used for inter-acc tech?
[17:57:12] <apetrescu> VD: huge... misson wide
[17:57:17] <apetrescu> VD: should not prevent that
[17:57:46] <apetrescu> HS: that was one of ther easons for not changing hosts, another reason wast...
[17:58:00] <apetrescu> HS: reason stated at the time for having netlmm, overheads, not apply to the multihoming case.
[17:58:11] <apetrescu> HS: encroaching over something already exists.
[17:58:17] <apetrescu> JS: thanks a lot
[17:58:29] <apetrescu> JS: hoe to continue discussion... how to recharter.
[17:58:37] <apetrescu> JS: first of that if ywe look at next steps
[17:58:40] <apetrescu> slide: Next Steps
[17:59:15] --- sureshk has left
[17:59:31] <apetrescu> VD: pmipv6 and mip6 interactions, when we took it out of the base spec, you chairs said, make wg doc asap that's what you said
[17:59:41] <apetrescu> VD: we need to document how to.... as important as...
[17:59:49] <apetrescu> VD: my understanding it was not supposed, months ago.
[17:59:56] <apetrescu> JS: I will back to you.
[18:00:00] --- tskj has left
[18:00:01] <apetrescu> JS: thanks, adjourned.
[18:00:07] --- apetrescu has left
[18:00:12] --- behcet.sarikaya has left
[18:00:15] --- vidya has left
[18:00:26] --- simoneruffino has joined
[18:01:58] --- simoneruffino has left
[18:02:54] --- rjaksa has left
[18:04:45] --- xiaohunhun has left
[18:08:52] --- washad has left
[18:08:54] --- ldondeti has left
[18:09:23] --- Gerardo has left: Disconnected.
[18:22:11] --- tskj has joined
[18:24:03] --- tskj has left