IETF
dmm@jabber.ietf.org
Wednesday, November 12, 2014< ^ >
Room Configuration
Room Occupants

GMT+0
[18:59:34] Meetecho joins the room
[19:06:21] 410fd10042cc10d3 joins the room
[19:06:47] 410fd10042cc10d3 leaves the room
[19:07:19] Alex Petrescu joins the room
[19:07:59] <Alex Petrescu> meeting chaired by Jouni Korhonen (JK) and Dapeng Liu (DL)
[19:09:57] <Alex Petrescu> Alper Yegin is AY presents
[19:10:22] <Alex Petrescu> AY announces: SIPTO accepted as study item in Release 13 3GPP SA2
[19:10:37] <Alex Petrescu> AY: SA2 busy with many items
[19:10:48] <Alex Petrescu> AY: prioritization discussion in plenary
[19:11:02] <Alex Petrescu> AY: make sure you support C-SIPTO
[19:11:07] <Alex Petrescu> C-SIPTO is?
[19:11:12] <Alex Petrescu> AY: presented at last IETF
[19:11:13] safa almalki joins the room
[19:11:17] <Alex Petrescu> C - coordinated SIPTO
[19:12:05] <Alex Petrescu> slide 3
[19:12:51] <Alex Petrescu> slide 4
[19:13:34] <Alex Petrescu> (the slidesets are at https://datatracker.ietf.org/meeting/91/materials.html#dmm )
[19:15:36] <Alex Petrescu> Sri Gundavelli i sSG
[19:15:43] <Alex Petrescu> SG: terminology,
[19:15:58] <Alex Petrescu> SG: what if two apps are using this 'sustained' address?  to which app?
[19:16:10] <Alex Petrescu> AY: if 2 flows use it, release only both terminated.
[19:16:19] <Alex Petrescu> SG: goal was to reflect IP address properties?
[19:16:24] <Alex Petrescu> SG: color address?
[19:16:39] <Alex Petrescu> SG: tie to app? the property of address changes depending on app lifetime
[19:16:45] <Alex Petrescu> AY: no, not changing by app
[19:16:58] <Alex Petrescu> AY: attribute belongs to IP address
[19:17:15] <Alex Petrescu> SG: give IP address to terminal, no app, then what is the property of the IP addresS?
[19:17:20] <Alex Petrescu> AY: depends on the system
[19:17:28] <Alex Petrescu> SG: understrant the intent
[19:17:35] <Alex Petrescu> SG: somehow the temrinology needs work
[19:17:46] <Alex Petrescu> AY: term sustained not comfortable, if better fine
[19:17:52] <Alex Petrescu> Danny Moses is DM
[19:18:02] <Alex Petrescu> DM: these types of addresses are services provided by network
[19:18:14] <Alex Petrescu> DM: when an app starts, it could require such an address
[19:18:35] <Alex Petrescu> DM: but if server needs an address...
[19:18:52] <Alex Petrescu> SG: stable means...
[19:19:04] <Alex Petrescu> DM: th emeaning is the type of service we receive from the network.
[19:19:08] <Alex Petrescu> Charles Perkins is CP
[19:20:00] <Alex Petrescu> CP: if several apps use same sustained address, t1, t2, if addresses are different per app then theiyre shortlived, but better have a single address for both apps.
[19:20:08] <Alex Petrescu> AY: not disappear per flow
[19:20:17] <Alex Petrescu> CP: apps can not know
[19:20:37] <Alex Petrescu> AY: all the app say is that it needs a sustained address...
[19:20:54] <Alex Petrescu> CP: should keep in mind this.
[19:21:08] <Alex Petrescu> SG: examples of apps using different types of addresses?
[19:21:30] <Alex Petrescu> slide 5
[19:23:01] <Alex Petrescu> slide 6
[19:24:37] <Alex Petrescu> SG: extensions to 5014 ?
[19:24:41] <Alex Petrescu> SG: generalized?
[19:25:05] <Alex Petrescu> slide 7
[19:27:18] <Alex Petrescu> Brian Haberman
[19:27:42] <Alex Petrescu> BH: people are going to say - you want all the apps to know whether or not they operate on a mobile node?
[19:27:55] <Alex Petrescu> BH: every app needs to source address select that?
[19:27:58] <Alex Petrescu> AY:...
[19:28:06] <Alex Petrescu> BH: the apps folks will say that.
[19:28:13] metricamerica joins the room
[19:28:18] <Alex Petrescu> DM: if you want optimization for extra servers you should know about this
[19:28:28] <Alex Petrescu> DM: if no extra service, then apps should not necessairly know
[19:29:00] <Alex Petrescu> CP: the apps need to know?  but th emobile will just offer fixed addresses for all apps?
[19:29:05] <Alex Petrescu> AY: yes, for those who ask
[19:29:24] metricamerica leaves the room
[19:29:34] <Alex Petrescu> slide 8
[19:32:42] <Alex Petrescu> Fred Templin on use cases for prefixes and planes and moving networks
[19:32:54] <Alex Petrescu> Satoru Matsushima i sSM
[19:32:58] <Alex Petrescu> SM : support for prefixes
[19:33:15] <Alex Petrescu> AY: the apps dont speak in terms of prefix terms
[19:33:43] <Alex Petrescu> SG: always give prefixes to terminals
[19:33:50] <Alex Petrescu> AY: DHCP gives address
[19:34:09] <Alex Petrescu> SG: in mobility architectures, address allocation scheme in 3GPP
[19:34:14] <Alex Petrescu> AY: in WiFi architectures?
[19:34:36] <Alex Petrescu> SG: ask an address, nothing changes, property of prefix
[19:34:46] <Alex Petrescu> AY: more of an issue of item 2 and 3.
[19:35:07] <Alex Petrescu> AY: ...
[19:35:20] <Alex Petrescu> SG: in the backend, the address is from prefix, ...
[19:35:33] <Alex Petrescu> SG: even for a given address, the address is on a given iface.
[19:35:39] <Alex Petrescu> SG: for delegated prefix is for inside
[19:35:53] <Alex Petrescu> SG: agrees aith alex's question...
[19:36:02] <Alex Petrescu> Chair: you run out of time
[19:36:31] <Alex Petrescu> slide 9
[19:36:49] <Alex Petrescu> slide 10
[19:37:42] <Alex Petrescu> slide 11
[19:38:07] <Alex Petrescu> Dapeng Liu
[19:38:21] <Alex Petrescu> DL: if mobility support by app, how does the termoinal registration know that?
[19:38:24] <Alex Petrescu> AY: need to discuss that
[19:38:35] <Alex Petrescu> DP: how many docs of this work team want to have output?
[19:38:48] <Alex Petrescu> AY: seems for item 1 1 doc, item 2 and 3 may be 1 or more
[19:38:57] <Alex Petrescu> AY: four or five
[19:39:01] <Alex Petrescu> Serge Manning is SM
[19:39:15] <Alex Petrescu> SM: boils down to the address type the mobile node asks for.
[19:39:37] <Alex Petrescu> AY: ...
[19:39:45] <Alex Petrescu> DL: please discuss on email list
[19:40:01] <Alex Petrescu> H. Anthony Chan presents (HAC)
[19:40:06] <Alex Petrescu> Page 2
[19:42:12] <Alex Petrescu> Page 3
[19:45:01] <Alex Petrescu> SG: summarize - general mobility anchor functionality... some mobility anchor
[19:45:19] <Alex Petrescu> SG: confused about Internet routers...
[19:45:27] <Alex Petrescu> Sharon Barkai is SB
[19:45:33] <Alex Petrescu> SB: anchor is a record of context
[19:45:43] <Alex Petrescu> SB: there is the record and the record coming to the data
[19:45:53] <Alex Petrescu> HAC: th ebinding?
[19:46:03] <Alex Petrescu> SB: yes
[19:47:36] <Alex Petrescu> SG: enhanced anchor functionality
[19:47:40] <Alex Petrescu> SG: what is enhanced?
[19:47:48] <Alex Petrescu> SG: there are std functions already used...
[19:47:56] <Alex Petrescu> HAC: look for...
[19:47:58] <Alex Petrescu> Page 5
[19:48:33] <Alex Petrescu> SB: ( 2 ) assummes a correlation of where it is
[19:48:41] <Alex Petrescu> SB: update routes not sufficient
[19:48:50] <Alex Petrescu> HAC: proposal to use BGP update upstream
[19:49:27] <Alex Petrescu> SB: need to show up where it is possible, not everywhere
[19:49:48] <Alex Petrescu> AY: could be helpful
[19:50:00] <Alex Petrescu> AY: depends on deployment
[19:50:10] <Alex Petrescu> JK: need host routes at some point.
[19:50:27] <Alex Petrescu> SG: clarify I may, you talk anchor functionality
[19:50:37] <Alex Petrescu> SG: in anchor based model there is no host route
[19:50:57] <Alex Petrescu> SG: ...
[19:51:02] <Alex Petrescu> HAC: the anchor may move
[19:51:08] <Alex Petrescu> SG: move the anchor then ther ei shost route
[19:51:28] <Alex Petrescu> SB: anchor is a record, then the anchor moves...
[19:51:30] <Alex Petrescu> Page 6
[19:52:26] <Alex Petrescu> SG: align slides with the other work items: control plane anchor and dat aplane anchor.
[19:52:38] <Alex Petrescu> SG: use it consistent with that area.
[19:52:50] <Alex Petrescu> HAC: we can separate - anchoring can be separate or combined.
[19:53:00] <Alex Petrescu> HAC: needs to allow for legacy systems.
[19:53:09] <Alex Petrescu> SG: in legacy system it is a consolidated box
[19:53:17] <Alex Petrescu> SG: keep it as a function
[19:53:27] <Alex Petrescu> HAC: we have not separate
[19:53:33] <Alex Petrescu> Marco Liebsch i sML
[19:54:12] <Alex Petrescu> ML: key of enhanced anchroring is to separate... not to necessarily select an anchor which is topologically correct anchor
[19:54:27] <Alex Petrescu> HAC: emal list
[19:54:43] <Alex Petrescu> HAC: deployment, which network, and so on.
[19:54:48] <Alex Petrescu> Dapeng Liu
[19:54:57] <Alex Petrescu> DL: people have different ideas about what is anchroing
[19:55:05] <Alex Petrescu> DL: anchoring and control plane anchroing
[19:55:22] <Alex Petrescu> DL: maybe in this table please add definitiion of anchor, and desrbie discuss what is anchroing for you
[19:55:31] <Alex Petrescu> HAC: only one teleconf we had, so we have to continue
[19:56:00] <Alex Petrescu> SB: problems with virtualzed EPS, the anchors are not well defined and tightly coupled... SGW, MME...
[19:56:14] <Alex Petrescu> SB: the enhancemenet is the separation, record, instnatiate dynamically
[19:56:29] <Alex Petrescu> SB: keep htat consistent not separate awareness.  distribute mobility.
[19:56:42] <Alex Petrescu> SB: chicken and egg peroble
[19:57:00] <Alex Petrescu> SB: separating  between control element and data element will allow you to ...
[19:57:10] <Alex Petrescu> HAC: use the email list discuss on DMM.
[19:57:26] <Alex Petrescu> Marco Liebsch presents
[19:57:42] <Alex Petrescu> Forwarding Path and signalling management
[19:58:00] <Alex Petrescu> Slide: WI as per charter description
[19:58:09] <Alex Petrescu> Slide: Brief status update
[19:58:24] sureshk joins the room
[19:59:14] <Alex Petrescu> Slide: General objectives of this WI
[20:02:06] <Alex Petrescu> Slide: Illustration of WI scope
[20:04:29] <Alex Petrescu> John Kappallimil i sJK
[20:04:44] <Alex Petrescu> JK: controller is a mobility controller? not a generic separation data-control?
[20:04:57] <Alex Petrescu> JK: because a daptalapnbe node and an openflow controller
[20:05:03] <Alex Petrescu> JK: I suppose you mean...
[20:05:12] <Alex Petrescu> ML: the openflow switches?
[20:05:17] <Alex Petrescu> JK: thats not in the scope?
[20:05:29] <Alex Petrescu> ML: openflow is not in scope, we describe a general way
[20:05:40] <Alex Petrescu> AY: interface between different types of controllers out of scope?
[20:05:57] <Alex Petrescu> AY: shouldnt it say controller of differenty tpe?
[20:06:23] <Alex Petrescu> ML: controllers of same type, then we should use synchronization, and the protocol of sync is ¨PMIP
[20:06:37] <Alex Petrescu> AY: interface between controllers ois out of sccope
[20:06:43] <Alex Petrescu> Satoru Matsushima
[20:07:05] <Alex Petrescu> SM: other means of controller is the controller of data plane, it could be different - the controller is about the mobility mgmt system
[20:07:16] <Alex Petrescu> SM: the controller for data plane is BGP, or openflow controller...
[20:07:28] <Alex Petrescu> ML: different levels of abstractions you mean?
[20:07:32] <Alex Petrescu> Serge Manning is SM
[20:07:40] <Alex Petrescu> SM: controller i snot impacting these kinds of transport nodes?
[20:07:59] <Alex Petrescu> SM: is the controller impacting the transport nodes?
[20:08:06] <Alex Petrescu> dany Moses: it impacts th emobility
[20:08:34] <Alex Petrescu> X (China accent): two separate entities?  second - i sthe option node mandatory?
[20:09:00] <Alex Petrescu> Sharon Barkai/ clrificaiton of ADPA,
[20:09:15] <Alex Petrescu> ML: NDPA for certain types of flows
[20:09:32] <Alex Petrescu> AY: definition of DPA?
[20:09:42] <Alex Petrescu> DPA is Data Plan Anchor
[20:09:50] <Alex Petrescu> AY: traffic flow must traverse the DPA?
[20:10:02] <Alex Petrescu> AY: all DPAs intercept traffic and forward to mobile
[20:10:11] <Alex Petrescu> AY: you can have multiple DPAs
[20:10:14] <Alex Petrescu> AY: for flows
[20:10:28] <Alex Petrescu> AY: each DPA intercepts trffic for flow?
[20:10:33] <Alex Petrescu> ML: solution is that?
[20:10:42] <Alex Petrescu> AY: single DPA per flow?  you could have several
[20:11:01] <Alex Petrescu> SG: dataplane anchor that ... node of... anchor entry-exit poit
[20:11:22] Catherine Dibble joins the room
[20:11:23] <Alex Petrescu> Slide: Exemplary deployment case - separated D-Plane Anchor and Access Node
[20:11:50] Catherine Dibble leaves the room
[20:11:58] <Alex Petrescu> Slide "pmip example"
[20:12:50] <Alex Petrescu> slide " Identified catefories"
[20:16:32] <Alex Petrescu> Slide "Next Steps"
[20:18:34] <Alex Petrescu> SB: in addition to queries id, please use publish subscribe
[20:18:48] <Alex Petrescu> SB: when querying smth, use pub-sub
[20:19:01] <Alex Petrescu> John 5JK)
[20:19:21] <Alex Petrescu> JK: big functions, charging, do you look at how to do that?
[20:19:27] <Alex Petrescu> JK: traffic detection functions
[20:19:35] <Alex Petrescu> JK: DPI(?)
[20:19:35] Joe Crowe joins the room
[20:19:45] <Alex Petrescu> JK: hiybrid way of handling
[20:19:59] <Alex Petrescu> JK: DPA and X should also be able to handle this
[20:20:03] <Alex Petrescu> SM: for mobility?
[20:20:11] <Alex Petrescu> JK: not necessarily, but whats in the gateway
[20:20:23] <Alex Petrescu> ML: we should go for that fromm the very beginning
[20:20:40] <Alex Petrescu> ML: offline
[20:20:52] <Alex Petrescu> SG: good idea to include some generic services
[20:21:03] <Alex Petrescu> SG: draw a line btw provisioning and ...
[20:21:09] <Alex Petrescu> SG: installing a runtime subscribe
[20:21:15] <Alex Petrescu> Satoru Matsushima
[20:21:31] <Alex Petrescu> SM: slide, controller is the mobility management
[20:21:38] <Alex Petrescu> slide "next steps"
[20:21:46] Joe Crowe leaves the room
[20:22:02] <Alex Petrescu> SM: what does it mean in th epicture the X?
[20:22:20] <Alex Petrescu> SM: is it the borderline, or inside the controller that could be dvicded by th emobility mgmt side and...
[20:22:27] <Alex Petrescu> the orange border line exists in th emobile mgmt inside
[20:22:50] <Alex Petrescu> ML: IP tunnel configuration? thats the tunnel
[20:22:54] <Alex Petrescu> SM: on the slide
[20:23:26] <Alex Petrescu> SM: the slide is "Matchinf a Proy Mobile IP architecture"
[20:23:39] <Alex Petrescu> discussion on this slide, with respect to the orang eline as an interface
[20:23:57] <Alex Petrescu> placement of the orange line
[20:24:08] <Alex Petrescu> AY: what are those two pieces?
[20:24:28] <Alex Petrescu> SM: standard like pmip or 3GPP dont have the separate part of data plane controller
[20:24:37] <Alex Petrescu> SM: we want to try to separate decouple
[20:25:03] <Alex Petrescu> ML: we shoul dbe making assumptions that there is s plit.
[20:25:12] <Alex Petrescu> ML: control plane is configured in the dmmm-e
[20:25:46] <Alex Petrescu> SM: when we see the orange border line as interface, what we try to figure out for control, like BGP
[20:25:58] <Alex Petrescu> SM: but if you say command or API, then it could be different.
[20:26:07] <Alex Petrescu> ML: commands or attribute specific descirptions
[20:26:26] <Alex Petrescu> ML: specify the API function, have the atributes described in an argument list
[20:26:47] <Alex Petrescu> ML: a different way to describe it, w/o a formal description language.
[20:26:50] <Alex Petrescu> Serge Manning
[20:27:03] <Alex Petrescu> SM: the blue lines are depending of kind of thing: qos, or other things
[20:27:16] <Alex Petrescu> SM: remember we talk mobility management, dont think of boxes as a gateway.
[20:27:35] <Alex Petrescu> SM: this is only the mobility management controller, not the controller of 3GPP
[20:27:47] <Alex Petrescu> John Kaippallmallil
[20:27:56] <Alex Petrescu> JK: these functions are stateful
[20:28:05] <Alex Petrescu> Jouni Korhonen: next in the agenda is Sri
[20:28:11] <Alex Petrescu> Dapeng Liu comments
[20:28:26] <Alex Petrescu> DL: your WT should sync with Antony's
[20:28:32] <Alex Petrescu> ML/ the definition of DPA?
[20:28:38] <Alex Petrescu> DL: yes, that should be aligned.
[20:28:50] <Alex Petrescu> Sri Gundavelli i sSGO presents
[20:28:51] <Alex Petrescu> SG
[20:28:58] <Alex Petrescu> Slide "Scope of the Work Item"
[20:31:00] <Alex Petrescu> Slide "Brief status update"
[20:31:31] <Alex Petrescu> slide "DMM - Functional Elements"
[20:33:44] <Alex Petrescu> Slide "Functional Architecture with Home and Access Sistinction"
[20:34:01] <Alex Petrescu> Sharon Barkai
[20:34:25] <Alex Petrescu> SB: sinc eyou do xxx searching - the function here is the anchor and do you need access node functionality?  Does the access node functionality there to scale out?
[20:34:34] <Alex Petrescu> SB: better way to scale out like cluseters?
[20:35:05] <Alex Petrescu> SG: yes, but if you look at anchors are located near tier-1 operators; theyre not always closer to radio network
[20:35:16] <Alex Petrescu> SG: its a flat archi, people can do it, but start point is this
[20:35:25] <Alex Petrescu> AY: you also miss the client based MIP
[20:35:30] <Alex Petrescu> AY: not.
[20:35:45] <Alex Petrescu> AY: mobile node should be put in this context as well.
[20:37:34] <Alex Petrescu> SG: nothing to do it
[20:37:40] <Alex Petrescu> AY: need a colorful box there
[20:37:45] <Alex Petrescu> SG: alright, I will add it
[20:38:05] <Alex Petrescu> SG: should apply to any protocol architecture
[20:38:32] <Alex Petrescu> slide "Converged Ho,e and Access Control Plane Functions"
[20:39:49] <Alex Petrescu> Slide back " Functional Architecture with Home and Access Distinction"
[20:40:02] <Alex Petrescu> ML: slide "Converged Ho,e..."
[20:40:19] <Alex Petrescu> ML: control and data plane interfaces only between...
[20:40:26] <Alex Petrescu> ML: here we should not differentiate
[20:40:38] <Alex Petrescu> ML: cover all scenarios, w/o caring about specific planes
[20:40:41] <Alex Petrescu> SG: yes.
[20:41:21] <Alex Petrescu> slide "Home-DPA/Access-DPN Collocation"
[20:43:29] <Alex Petrescu> slide "Converged Ho,e and Access Data Plane Functions"
[20:44:55] <Alex Petrescu> slide "Next Steps"
[20:45:20] <Alex Petrescu> John JK
[20:45:29] <Alex Petrescu> JK: slide "Home-dPA..."
[20:45:38] <Alex Petrescu> JK: will the home-dpa move or anchored?
[20:45:45] <Alex Petrescu> SG: by default the session is anchored
[20:45:59] <Alex Petrescu> SG: is it fixed? no its not fixed, relocate the session
[20:46:31] <Alex Petrescu> AY: differentiate from the WT2 and 3 discussions on anchroing, and cpdp?
[20:46:37] <Alex Petrescu> AY : demarcation?
[20:46:46] <Alex Petrescu> SG: WT3 is strictly about interfaces
[20:47:22] <Alex Petrescu> AY: interface should include this discussion, or this discussion here to drive that discussion
[20:47:24] <Alex Petrescu> AY: related they are
[20:47:32] <Alex Petrescu> AY: anchroing - same discussion
[20:47:42] <Alex Petrescu> AY: what does it mean announced anchors
[20:47:52] <Alex Petrescu> SG: from the presentation it is about how to publish host routes
[20:48:03] <Alex Petrescu> SG: I will follow with Anthony
[20:48:24] <Alex Petrescu> (china accent)/ how this got involved in the mobilityi management?
[20:48:40] <Alex Petrescu> SG: slide "functional architecture with Home and Access Distinction"
[20:49:22] <Alex Petrescu> SG: explanatin on slide
[20:49:46] <Alex Petrescu> SG: allocated the session, session parameters, set up tunnelling, forwarding, activate interfaces (Marco's) netconf yang
[20:49:59] <Alex Petrescu> SG: tunnel comes up, route comes up, hit the anchor, gets tunnelled.
[20:50:20] <Alex Petrescu> SG: signalling at this layer, userplane is here.
[20:50:29] <Alex Petrescu> (China accent): outward interfacE?
[20:50:34] <Alex Petrescu> SG: not outward interface
[20:50:41] <Alex Petrescu> Serge Manning: sessions?
[20:50:49] <Alex Petrescu> SM: mobility session we have in Mobile IP
[20:50:59] <Alex Petrescu> SM: but here we have per-flow basis
[20:51:07] <Alex Petrescu> SG: agreed.
[20:51:18] <Alex Petrescu> SM: different set of policies or control stuff
[20:51:31] <Alex Petrescu> Fred Templi presents "AERO"
[20:51:37] <Alex Petrescu> start on chart number 12
[20:51:56] <Alex Petrescu> slide "AERO Advanced Topics"
[20:52:13] <Alex Petrescu> chart "AERO Overviez"
[20:53:13] <Alex Petrescu> Chart "AERO Overviez"
[20:53:47] <Alex Petrescu> Chart "ARO IPv6 ND"
[20:54:38] <Alex Petrescu> Chart "AERO for intra-network mobility"
[20:55:25] <Alex Petrescu> Chart "AERO Internet-Wide Mobility"
[20:56:35] <Alex Petrescu> Chart "Proxy AERO"
[20:57:36] <Alex Petrescu> Chart "AERO Capabiloity Discovery"
[20:58:29] <Alex Petrescu> Chart "AERO Control/Forwarding Plane Separation"
[21:06:46] <Alex Petrescu> Charles Perkins - privacy considerations for DMM
[21:07:00] <Alex Petrescu> slide "Privacy considerations for DMM"
[21:07:05] <Alex Petrescu> slide "Overview"
[21:08:46] <Alex Petrescu> slide "Need for the draft"
[21:10:41] <Alex Petrescu> slide "DMM design phase"
[21:11:13] <Alex Petrescu> slide "Known privacy considerations"
[21:13:04] <Alex Petrescu> slide "Some solution approaches"
[21:13:09] sureshk joins the room
[21:16:17] <Alex Petrescu> slide "Next Steps"
[21:17:12] <Alex Petrescu> Juan-Carlos Zuniga
[21:17:18] <Alex Petrescu> JCZ: thanks
[21:17:29] <Alex Petrescu> JCZ: 802 at IEEE is coordinating with IETF
[21:17:46] <Alex Petrescu> JCZ: no issues for the momement with the MAC address rdm
[21:18:03] <Alex Petrescu> JCZ: I am in IAB privsec program, awareness of privacy issues
[21:18:16] <Alex Petrescu> JCZ: mitigations should we consider ideally now
[21:18:31] <Alex Petrescu> JCZ: discussion lead to encourage this for all future work in developping protocols, this is in line
[21:18:41] <Alex Petrescu> JCZ: you will hear more from the statements at IAB
[21:19:00] <Alex Petrescu> JCZ: in security issues  we should consider with privacy issues
[21:19:09] <Alex Petrescu> CP: in DMM we consider this
[21:19:21] <Alex Petrescu> SB: in ost models is the anchor as key function
[21:19:33] <Alex Petrescu> SB: possibly to track you down , makes privacy difficult
[21:19:40] <Alex Petrescu> SB: control and forwarding of the anchors
[21:19:59] <Alex Petrescu> SB: there is les sinformation known, randmized identifity is a powerful combination.
[21:20:09] <Alex Petrescu> CP: in the group we discusse
[21:20:19] <Alex Petrescu> dDapeng Liu: be short on next one
[21:20:29] <Alex Petrescu> Charles Perkins presents MNIDs
[21:20:32] <Alex Petrescu> slide "Overviez"
[21:20:41] <Alex Petrescu> slide "Recent changes"
[21:21:14] <Alex Petrescu> slide "Issues rised"
[21:22:11] <Alex Petrescu> slide "Next Steps"
[21:22:37] <Alex Petrescu> Dapeng Liu is DP
[21:23:02] <Alex Petrescu> DP: suggest we can find soemone to review the doc, and if continue discussion on list, if enough interest we can try to discuss it whether to adopt this document.
[21:23:07] <Alex Petrescu> Sri Gundavelli presents
[21:23:39] <Alex Petrescu> slide "multi-homing support for residential gateways"
[21:24:01] <Alex Petrescu> slide "hybrid access requiremenets"
[21:24:56] <Alex Petrescu> slide "Multipath with Policy-based Routing"
[21:25:35] sureshk leaves the room
[21:26:59] <Alex Petrescu> slide "IP Flow Policy"
[21:27:34] <Alex Petrescu> slide "Multipath with Policy Routing"
[21:27:40] satoru joins the room
[21:28:14] satoru leaves the room
[21:28:52] <Alex Petrescu> Jouni Korhonen
[21:29:03] <Alex Petrescu> JK: thi sis the maintenance part of DM WG
[21:29:14] <Alex Petrescu> JK: any interest in this group?
[21:29:20] <Alex Petrescu> Suresh Krishnan
[21:29:32] <Alex Petrescu> SK: form what I kno, hybrid access is the fixed operators
[21:29:38] <Alex Petrescu> SK: lma -flawed?
[21:29:57] <Alex Petrescu> SK: both fixed and wireless acess owned by an operator? the operators I know have fixed
[21:30:13] <Alex Petrescu> SK: hybrid access augment DSL capacity? there may be ...
[21:30:19] <Alex Petrescu> Carlos Bernardos CB
[21:30:24] <Alex Petrescu> CB: progress in this WG?
[21:30:31] <Alex Petrescu> CB: need additional discussio, read draft
[21:30:45] <Alex Petrescu> Behcet Sarikaya
[21:30:57] <Alex Petrescu> BS: this will be discussed this afternoon in thie MIf WG
[21:31:03] <Alex Petrescu> SG: nothing to do with MIF.
[21:31:21] <Alex Petrescu> JK: lots of hands for who read this drafT?
[21:32:27] <Alex Petrescu> JK: work on this
[21:34:37] safa almalki leaves the room
[21:39:39] Meetecho leaves the room
[21:49:27] Alex Petrescu joins the room
[21:49:35] Alex Petrescu leaves the room
[22:02:06] Alex Petrescu leaves the room
[22:07:06] sureshk leaves the room
[22:07:14] sureshk joins the room
[22:58:05] sureshk leaves the room
[23:00:28] Alex Petrescu joins the room
[23:12:36] Alex Petrescu leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!