[09:50:09] --- heikki has joined
[09:50:16] --- heikki has left
[12:30:53] --- koojana has joined
[12:35:46] --- TJ has joined
[12:47:39] --- andrewdmcgregor@jabber.psg.com has joined
[12:47:51] --- ks has joined
[12:50:13] --- shep has joined
[12:51:22] --- m_ersue has joined
[12:51:36] --- apetrescu has joined
[12:52:12] <apetrescu> sorry what's co-chair's name I forgot
[12:52:31] <koojana> http://www3.ietf.org/proceedings/07mar/agenda/monami6.txt
[12:52:45] <apetrescu> Jari Arkko presenting
[12:53:01] <apetrescu> JA: we have 3 WGs focusing on mip6 and extensions: mip6 monami6 and nemo
[12:53:24] <apetrescu> JA: next IETF timeframe (after mcoa spec to IESG) we plan to merge groups
[12:53:31] <apetrescu> JA: one place where this work happens
[12:53:50] <apetrescu> JA: _or_ outsiders. need for coordination of groups. reviewers.
[12:54:08] <apetrescu> JA: AD perspective is easier avoid groups meeting at same time
[12:54:21] <apetrescu> JA: in a couple of months. comments? nor or later
[12:54:30] <apetrescu> JA: details to be determined
[12:54:35] --- psavola has joined
[12:54:40] <apetrescu> JA: there will be details
[12:54:52] <apetrescu> JA: not a change in what's being worked on. WG items will stay.
[12:55:01] <apetrescu> questioner: name is?
[12:55:05] <apetrescu> JA: MIP6
[12:55:31] <apetrescu> JA: come talk to me or Mark.
[12:56:29] <apetrescu> Nicolas Montavont co-chairs with Thierry Ernst.
[12:56:41] <apetrescu> NM: there's a WiKi and thank Henrik
[12:56:52] <apetrescu> NM: will send address of wiki in a mail.
[12:57:09] <apetrescu> slide: wiki with active tasks
[12:57:20] <apetrescu> slide: analysis of multihoming in MIPv6
[12:57:31] <apetrescu> slide: Changes from v01
[12:58:08] <apetrescu> slide: Changes in definition of a multihomed mobile node
[12:58:36] <shep> I thought I heard Jari Arkko say something about shim6 when he was talking about merging working groups. Did I mis-hear?
[12:58:52] <apetrescu> slide: Definition Simultaneously using multiple addresses
[12:59:19] <apetrescu> slide: Definition: Simultaneously using multiple interfaces
[12:59:35] <apetrescu> slide: Section 3 Requirements to node capabilities
[13:00:55] <apetrescu> (previous questioner who asked name of new WG is Tim Shepherd I believe)
[13:01:00] <apetrescu> Hesham Soliman
[13:01:15] <apetrescu> HS: original definition was mobile nodes with multiple interfaces, why moving from that?
[13:01:20] <apetrescu> NM: ...
[13:01:26] <apetrescu> HS: but that's different
[13:01:55] <apetrescu> HS: ND uses that, assumes multi-med assumes multiple interfaces not multiple addresses... multiple definitions in multiple documents
[13:02:00] <apetrescu> MN: multiple is...
[13:02:03] <shep> My name is spelled "Shepard"
[13:02:18] <apetrescu> (I'm sorry, Tim Shepard)
[13:02:30] <apetrescu> NM: single interfaces MNs?
[13:02:40] <apetrescu> HS: seems its because we nmed it that wqay
[13:02:46] <apetrescu> Erik Nordmark
[13:02:52] <apetrescu> EN: historically
[13:02:57] <apetrescu> EN: IPv6 explicitely
[13:03:14] <apetrescu> EN: if need to talk specific cases mobile interface per mobile address... reasonable to keep as intended today
[13:03:28] <apetrescu> HS: if we need to distinguish then maybe need to distinguish
[13:03:32] --- TJ has left
[13:03:35] <apetrescu> HS: because eg in flow binding work
[13:03:36] --- TJ has joined
[13:04:04] <apetrescu> HS: in NEMO case (Recently) i have two different addresses on same link but different properties. I think if you're more specific then easier to understand scenario more
[13:04:15] <apetrescu> NM: change you prefer? Or just use term multi-addressed MN?
[13:04:35] <apetrescu> HS: not want make hard work, background, used to use multi-homed for multiple interfaces and in other documents this is so.
[13:04:40] <apetrescu> HS: up to you, not push
[13:04:44] <apetrescu> NM: we know but
[13:04:54] <apetrescu> NM: we change de def at each ver of draft
[13:05:23] <apetrescu> N<: wlecomes your reviews and cross reviews from other WG to read the
[13:05:27] --- TJ has left
[13:05:43] <apetrescu> NM: asks Ryuji Wakikawa to begin
[13:06:14] --- TJ has joined
[13:06:18] <apetrescu> slide: Multiple Care-of Address Registration
[13:06:22] <apetrescu> questioner
[13:06:27] <apetrescu> q: long hair, woman
[13:06:38] <apetrescu> q: multiple addresses multiple interface you said?
[13:06:46] <apetrescu> NM: we want to work on both multiple and single
[13:07:05] <apetrescu> q: but seems in abstract multiple ifaces/multiple address for heteroegeneous.
[13:07:15] <apetrescu> q: is multi-mode temrinal a case of multihoming or not?
[13:07:19] <apetrescu> q: right?
[13:07:21] <apetrescu> NM: yes
[13:07:41] <apetrescu> slide: comments on ML
[13:09:37] --- FDupont has joined
[13:09:50] <apetrescu> RW: suggests to put priority field out of mcoa to flows
[13:10:11] <apetrescu> NM: I prefer this in mcoa draft, because linked to mcoa, because in our draft we can have several attached to flow.
[13:10:16] <apetrescu> RW: will update this
[13:10:22] <apetrescu> Gerardo Giaretta approaching
[13:10:27] <apetrescu> HS: clarify this in draft.
[13:10:30] <apetrescu> RW: yes
[13:10:39] <apetrescu> HS: baseline uses.
[13:10:47] <apetrescu> RW: many people send questions why mcoa
[13:10:52] <apetrescu> HS: add text explain why.
[13:10:56] <apetrescu> GG agrees and leaves.
[13:11:50] <apetrescu> RW: problems with proxy ND
[13:12:06] <apetrescu> RW: avoid address duplication on home link.
[13:12:28] <apetrescu> RW: comments please/
[13:12:31] <apetrescu> questioner
[13:12:50] <apetrescu> q: I understand there's another draf submitted in mip6, solution to solve neighbour proxy discover
[13:13:01] <apetrescu> questioner: highlights draft-wakikawa-...
[13:13:25] <apetrescu> q and RW agree to advertise this draft (but they don't spell name :-(
[13:13:48] <apetrescu> slide: Updates
[13:14:03] <apetrescu> slide: Message Format
[13:15:31] <apetrescu> slide: Overwrite (O) flag
[13:18:04] <apetrescu> HS: BU by def overrides everything in BC
[13:18:23] <apetrescu> RW: in mcoa you can send multiple bindings. 3 active CoAs, and a single...
[13:18:28] <apetrescu> HS: changing the def of BU?
[13:18:36] <apetrescu> HS: new flags to 'not' override?
[13:18:41] <apetrescu> RW: if not this flags.
[13:18:53] <apetrescu> HS: if 3 CoAs and only refrresh one
[13:18:58] <apetrescu> RW: just send one BU
[13:19:01] <apetrescu> RW: no change
[13:19:06] <apetrescu> HS: what if you want to remove
[13:19:10] <apetrescu> RW: then set o flag
[13:19:11] <apetrescu> HS: ah
[13:19:33] <apetrescu> HS: if you not implementing mcoa and then send 3. then send a normal, then send one, will that replace
[13:19:35] <apetrescu> RW: yes
[13:19:39] <apetrescu> HS: both legal
[13:19:48] <apetrescu> RW: always carry BID suboption
[13:19:59] <apetrescu> RW: remove all bindings and .
[13:20:09] <apetrescu> HHenrik Levkowetz
[13:20:37] <apetrescu> HL: you can use this flag to send one BU with the flag set and will clean out existing entries- so it's a 'clear' flag
[13:20:45] <apetrescu> RW: yes, but use with multiple registrations.
[13:20:57] <apetrescu> HL: the flag still says to clear existing bindings.
[13:21:12] <apetrescu> HL: from your explanation it seems that's what you do, so that's a better name
[13:21:21] <apetrescu> EN: semantic... what if..
[13:21:33] <apetrescu> EN: if packet contains clear operation and the set succeeds.
[13:21:40] <apetrescu> EN: if it's a replace operation it fails w/o change state.
[13:21:46] <apetrescu> HL: good point
[13:21:53] <apetrescu> HS: I understand it as a replacement.
[13:22:10] <apetrescu> HL: that is interpretation further from my understanding.
[13:22:20] <apetrescu> HL: replace doesnt imply you keep other bindings
[13:22:26] <apetrescu> RW: I'm open to name this flag.
[13:22:38] <apetrescu> slide: Return Routability
[13:23:46] <apetrescu> slide: Sequence Number Handling
[13:25:31] <apetrescu> slide:slide: Next Step
[13:26:18] <apetrescu> Vijay Devarapalli presents next
[13:26:58] <apetrescu> slide: Use of IKEv2 and IPsec with Multiple CoA support
[13:27:20] --- shubranshu has joined
[13:27:36] <apetrescu> slide: Assumptions in RFC3775, 3963
[13:27:54] --- shubranshu has left
[13:29:44] <apetrescu> slide: IKEv2 security associations
[13:31:19] <apetrescu> slide: Transport Mode IPsec SAs
[13:31:43] --- shubranshu has joined
[13:33:53] <apetrescu> slide: Tunneled HoTI/HoT Messages
[13:34:16] --- shubranshu has left
[13:36:03] <apetrescu> slide: Tunneled Payload Traffic
[13:37:10] --- m_ersue has left
[13:38:15] <apetrescu> HL: small
[13:38:20] <apetrescu> question
[13:38:29] <apetrescu> HL: is this irrespective of using same SAs?
[13:38:51] <apetrescu> HS: why do you think its much harder... that's what we did before with ...
[13:39:37] <apetrescu> VD: IPsec tag does the IPsec encapsulation. SAD the tunnel endpoints are stored there.
[13:44:49] <apetrescu> presenter Umar Toseef
[13:45:02] <apetrescu> slide: Implementation of Flow Management in MIPv6 Environment
[13:45:23] <apetrescu> slide: Implementation Overview
[13:48:03] <apetrescu> slide: Processing Field
[13:48:25] <apetrescu> slide PRO Field
[13:48:41] <apetrescu> slide: Processing Field
[13:49:12] <apetrescu> slide: Specifying Src/Dest Ports wihtout Protocol
[13:51:37] <apetrescu> HS: i don't know of any port exclusively used for one transport protocol
[13:51:51] <apetrescu> HS: X reserved for same protocol for UDP and TCP - doesn't.
[13:52:03] <apetrescu> HS: you resreve a port number -then it means any
[13:52:14] <apetrescu> UT: whenver that is unaplicable
[13:52:31] <apetrescu> HS: save space if you want to apply to both transport protocols, just say once.
[13:52:35] <apetrescu> HS: is that easy?
[13:52:45] <apetrescu> UT: we can do that but we might have discussion over it.
[13:52:53] <apetrescu> slide: Priorities
[13:53:22] --- washad has joined
[13:54:29] <apetrescu> slide: duplicate Receipt of Filter Rules
[13:55:59] <apetrescu> slide: Performance Results
[13:57:41] <apetrescu> slide: Performance Results
[13:58:25] <apetrescu> slide: End
[13:58:42] <apetrescu> HS:...
[13:59:00] <apetrescu> UT: MN wants to register... register filter, sned the egg of this filter.
[13:59:08] <apetrescu> UT: Ack was lost doing.
[13:59:30] <apetrescu> HA: the BAck could have been lost, but not for one flowid.
[13:59:51] <apetrescu> UT: yes, but if it's filtered and the MN wanted to register what was done.
[14:00:02] <apetrescu> HS: if the BAck was lost it's not a filter Ack.
[14:00:10] <apetrescu> HS: BU would have to be re-transmited.
[14:00:25] <apetrescu> UT: not, because already registered the FID. Would duplicate FID error.
[14:00:37] <apetrescu> UT: FID would be rejected but binding accepted.
[14:00:57] <apetrescu> HS: ok, so state is correct on both ends, looks as everything ok, but not ok.
[14:01:11] <apetrescu> UT: beofre receiving error. Duplicate is more like a warning.
[14:01:19] <apetrescu> UT: then MN doesn't know.
[14:01:23] <apetrescu> NM: offline please.
[14:01:27] <apetrescu> Koshiro Mitsuya
[14:01:34] <apetrescu> KM: how did you play with FID?
[14:01:46] <apetrescu> KM: in draft says you can indicate ...
[14:01:54] <apetrescu> KM: how did you iimplement that feature.
[14:02:01] <apetrescu> UT: not related to this slide right?
[14:02:25] <apetrescu> UT: for moment since we have this implementation integrated with other software, that soft takes care of that FID, generates that serially.
[14:02:34] <apetrescu> UT: if we keep say that.
[14:02:47] <apetrescu> UT: there can be random numbers for this to not repeat.
[14:02:59] <apetrescu> KM: do you support the case you want to use in the CN?
[14:03:29] <apetrescu> KM: you can indicate that the MN wants to use a filter that is already installed in CN, by just sending the FID.
[14:03:40] <apetrescu> UT: yes, only flags and status fields.
[14:04:02] <apetrescu> UT: not any problems I found with this. The FID is already distribtued to HA. It just matches with this updated.
[14:04:18] <apetrescu> KM:maybe you need some state machine managed in filter rule (already exchanged).
[14:04:28] <apetrescu> Thierry Ernst: send detail to mailing list.
[14:04:34] --- FDupont has left
[14:04:42] <apetrescu> questioner
[14:05:01] <apetrescu> q: if you can't provide the network teopology of env
[14:05:03] <apetrescu> UT: UDP streams
[14:05:16] <apetrescu> q: two terminals, what
[14:05:20] <apetrescu> John Cha
[14:06:00] <apetrescu> UT: got feedback from nsplat
[14:06:10] <apetrescu> UT: share experiences
[14:06:32] <apetrescu> slide: Summary of the Discussion "Flow/binding Policies Exchange"
[14:06:36] <apetrescu> slide: Outline
[14:06:58] <apetrescu> slide: Objective in Monami6
[14:08:30] <apetrescu> slide: Operations... cont
[14:09:11] <apetrescu> slide: Objective in Monami6
[14:10:34] <apetrescu> slide: 1st solution on the plate
[14:10:42] <apetrescu> slide: 2nd solution on the plate
[14:11:21] <apetrescu> slide: 3rd solution
[14:11:47] <apetrescu> slide:int-area ML discussion
[14:12:01] <apetrescu> int-area@ietf.org
[14:12:21] <apetrescu> slide: Int-Area ML Discussion Topics
[14:12:56] <apetrescu> Vijay Devarapalli VD
[14:13:36] <apetrescu> VD: a generic solution for all these sounds good, BUT.
[14:13:53] <apetrescu> Thierry Ernst: TE
[14:13:58] --- behcet.sarikaya has joined
[14:15:39] <apetrescu> Henrik Levkowetz
[14:15:59] <apetrescu> HL: believes correct policy in this case is a 'why', what kind of policy, may differ.
[14:16:42] --- rjaksa has joined
[14:18:14] <apetrescu> Jari Arkko
[14:18:18] <apetrescu> JA: question
[14:18:38] <apetrescu> JA: 1/2 do you require that transaction only happens only during mobility transaction?
[14:18:42] <apetrescu> TE: not touched these specs
[14:18:49] <apetrescu> HS: ay time should be possible
[14:18:59] <apetrescu> VD: just send a BU whenever you want to update
[14:19:36] <apetrescu> HS: first bullet is correct, but please mention the security factors.
[14:23:16] --- washad has left
[14:24:40] <apetrescu> Koshiro Mitsuya
[14:25:09] --- andrewdmcgregor@jabber.psg.com has left
[14:25:35] <apetrescu> KM: KM: note we have implementation of my draft (1)
[14:25:36] --- shep has left: Logged out
[14:25:54] <apetrescu> KM: I think you have to stop to walk from terminal...
[14:26:01] <apetrescu> KM: maybe we have different.
[14:26:09] <apetrescu> (sorry he said 'start' not 'stop')
[14:26:23] <apetrescu> TE: if you can start this thread we'll follow up pon that.
[14:26:47] <apetrescu> KM: draft-... it's very ... solution to send filter rule. At this point we also need to think about architecture draft first.
[14:26:55] <apetrescu> TE: going back to generic discussion,
[14:27:22] <apetrescu> JA: what should be the scope of this work in this WG and the ambition level.
[14:27:52] <apetrescu> JA: important you think what you need to do. Innappropriate and inefficient to design a solution that provides a solution for all those things, it's not your task.
[14:28:11] <apetrescu> JA: apply engineering judgement, if it appears something is modular and modularize it and architecturally.
[14:28:13] --- shep has joined
[14:28:23] <apetrescu> JA: don't bind that to all that you can use later, but you can modular.
[14:28:38] <apetrescu> JA: the requirements and arch discussion.
[14:28:47] <apetrescu> JA: take years of req document
[14:28:58] <apetrescu> JA: not sure for interoperability.
[14:29:04] <apetrescu> JA: this is a fairly simply problem.
[14:29:12] <apetrescu> TE: not against of having a ...
[14:29:27] <apetrescu> JA: apply uyour judgnennt, modular parts you can make it modular.
[14:29:41] --- koojana has left
[14:29:50] <apetrescu> JA: if group feels is to best have a solution bound to mobility protocols then I'm not oppose.
[14:30:04] <apetrescu> questioner:
[14:30:05] <apetrescu> q
[14:30:09] <apetrescu> scope
[14:30:13] <apetrescu> PMIP is already considered?
[14:30:18] <apetrescu> TE: no, no Charter on that.
[14:30:29] <apetrescu> JA: general guidance, don't work on
[14:30:35] <apetrescu> previous questioner is Conny Larsson
[14:30:49] <apetrescu> JA: maybe someone else in 10years works on netlmm bindings.
[14:31:12] <apetrescu> HS: one suggestion on mailing list there seems to be a benefit of having a generic format with filter rules.
[14:31:21] <apetrescu> HS: make sure these commonalities are captured.
[14:31:28] <apetrescu> HS: specific carrier with MIP6.
[14:31:40] <apetrescu> HS: PMIP may reuse that later.
[14:32:07] <apetrescu> HS: question why rationale for INFORMAITONAL
[14:32:18] <apetrescu> TE: if you have stdstrack solution it needs more consensus
[14:32:36] <apetrescu> TE: if you look for informational you don't need... 2-3 solutions as informational are fine.
[14:32:44] <apetrescu> VD: it should be experimental
[14:32:46] <apetrescu> TE: yea
[14:32:54] <apetrescu> JA: that's one approach
[14:33:11] <apetrescu> JA: I would like to do more work, put Hesham and others in one room.
[14:33:17] <apetrescu> JA: not ready yet to go that path.
[14:33:38] <apetrescu> HS: agreed, it's just a political, put more effort into figuring out.
[14:33:51] <apetrescu> HS: not because two people disagree.
[14:34:04] <apetrescu> HS: informational is weird.
[14:34:22] <apetrescu> RW: agree with Jari, important to see how we can have modularizing thing, general solution.
[14:34:31] <apetrescu> RW: comment on solution. The reason ...
[14:34:53] <apetrescu> RW: a solution is needed in monami6 quickly, but requirement from operator are not covered.
[14:35:02] <apetrescu> RW: some operators want to put the policy on the HA.
[14:35:29] <apetrescu> RW: some of the future maybe missing. 2 different solutions. flowbinding, henrik, two different ways.
[14:35:44] <apetrescu> RW: concept is similar, why not looking at both solutions in this WG
[14:35:52] --- shep has left: Logged out
[14:35:55] <apetrescu> VD: looked at the slide, it wasn't clear to me .
[14:36:24] <apetrescu> VD: prefers make it modular: generic format (1 draft) and then we show how to do BU/BAck. Later on we can see.
[14:36:34] <apetrescu> VD: 1 shows filters in generic format.
[14:37:13] <apetrescu> HL: respond to VD: I proposed a slighlty more generic solution that wouldn't be my favourite but makes sense.
[14:37:35] <apetrescu> HL: understands MIP6-specific transport for this, and as optimizaiton I understand. But first generic solution first.
[14:37:58] <apetrescu> HL: in some cases you can't see clearly the generic until done specific: but I don't see that here happening.
[14:38:03] <apetrescu> HL: a generic language.
[14:38:11] <apetrescu> HL: propose a generic transport for this also.
[14:38:34] <apetrescu> HL: do some decomposition so we don't do all all complete monami-specific then I'd be happy.
[14:38:56] <apetrescu> HL: TE's personal preference is that something that can't be generalized? Not happy with thtat solution.
[14:39:07] <apetrescu> Vidya Narayanan
[14:39:34] <apetrescu> VN: IPv6 extension headers - that was clarified on the list, as long as ext is DO then no fragmentation, then no issue.
[14:39:47] <apetrescu> VN: ...exactly what we do with carrying BU
[14:40:01] <apetrescu> VN: any strong oppinion as mobility option or generic format, I don't have strong.
[14:40:20] <apetrescu> HS: in flow binding draft we already do that.
[14:40:32] <apetrescu> HS: the format is already, rules are separate entity from rest of .
[14:40:43] <apetrescu> HS: effectively what we have is option 2 in TE slide.
[14:40:55] <apetrescu> TE: the fact that you have it in same draft.
[14:41:05] <apetrescu> TE: could be separated draft?
[14:41:07] <apetrescu> HS: fine
[14:41:41] <apetrescu> HL: points out having a container that carry any format is very fdifferent than defining a container and a different use.
[14:42:03] <apetrescu> HL: if HS preoposes of contain a container - that doesn't give a standard, it gives something we can reuse.
[14:42:14] <apetrescu> HS: we can carry different formats but today we have one.
[14:42:15] --- rjaksa has left
[14:42:19] <apetrescu> HS: explains his draft.
[14:42:51] <apetrescu> HL: you're taking my agreement to go generic filter solution and try to say that 'oh yes we have that' - that is , well, ...not compute to me.
[14:43:10] <apetrescu> HL: filter format generic thing. and possible monami-specific container; not mixing them together.
[14:43:38] <apetrescu> JA:if we had a generic format, IP-filter-something, and carried by monami6 in MH - would that fly with both of you?
[14:43:40] <apetrescu> HS: yes
[14:43:59] <apetrescu> HL: not perfectly happy with me. because timing of sending BU and timing to update a filter.
[14:44:10] <apetrescu> HL: not use transport MH as generic MH>
[14:44:21] <apetrescu> HL: happier with less generic filter rules that HS proposed.
[14:44:45] <apetrescu> HS: clarify that regardless of carrier you may any time send filter rules.
[14:44:51] <apetrescu> HS: a message is being sent.
[14:45:01] <apetrescu> HS: not difference, it's just a packet.
[14:45:02] --- psavola has left
[14:45:28] <apetrescu> HL: separation of matters. One userland that handles the module and another that handles mobility then you still need to fancy mix BU into filter
[14:45:36] <apetrescu> HL: almost discussed this.
[14:45:54] <apetrescu> HS: the fact that we have different ids can't propose.
[14:46:08] <apetrescu> HS: secure UDP protocol, it maps the.
[14:46:18] <apetrescu> HL: you assume it needs to map UDP sec to MIP sec?
[14:46:21] <apetrescu> HS: no.
[14:46:50] <apetrescu> HS: identity needs to be crypto processed.
[14:47:00] <apetrescu> HS: UDP proposal TLS is proposed.
[14:47:03] --- behcet.sarikaya has left
[14:47:08] <apetrescu> HS: not see how easy to map that.
[14:47:31] <apetrescu> HL: youre overstating difficulties, you need secure identity that matches.
[14:47:46] <apetrescu> Vijay devarapalli
[14:48:17] <apetrescu> VD: one option of doing a modular document, part of document is generic, 2nd part defines BU/BAck.
[14:48:27] <apetrescu> HL: that was what I ...
[14:48:33] <apetrescu> HL:...
[14:48:40] <apetrescu> VN: what the generic format is based on?
[14:48:51] <apetrescu> VN: host-tor-outer? router-to-router?
[14:49:10] <apetrescu> VN: huge set
[14:49:29] <apetrescu> VN: trgetting common solution is not sure easy or common.
[14:49:36] <apetrescu> HS: not think is a problem.
[14:50:02] <apetrescu> VN: both
[14:50:08] <apetrescu> VN: NSIS.
[14:50:48] <apetrescu> HL: engineering-wise to make sense to do the most reasonable modular solution we can to the problem we understand.
[14:51:05] <apetrescu> HL: problem here doesn't include NSIS.
[14:51:15] <apetrescu> HL: will not cover router-to-router.
[14:51:25] <apetrescu> TE: we came across this in NEMO discussion.
[14:51:33] <apetrescu> HL: not saying it turns out.
[14:51:41] <apetrescu> HL: it could be turned out.
[14:52:05] <apetrescu> HS: comment on VD, happy with a document, referrencing that.
[14:52:40] <apetrescu> HS: doesnt agree with close on info.exp/stdtr
[14:52:46] <apetrescu> VN: agree with HL.
[14:53:15] <apetrescu> TE: closes discussion and comes back to JAri and then mailing list.
[14:53:20] <apetrescu> TE: thanks for attending.
[14:53:29] <apetrescu> TE: thanks to Alexandru.
[14:53:36] <apetrescu> TE: thanks to Henrik
[14:53:46] <apetrescu> TE: sees us at next IETF.
[14:53:55] <apetrescu> TE: sees us in NEMO tomorrow.
[14:54:01] --- apetrescu has left
[14:55:18] --- ks has left
[15:43:07] --- TJ has left