[14:08:02] --- m_ersue has joined
[14:08:05] --- m_ersue has left
[14:15:55] --- Seung Yi has joined
[14:15:59] --- Seung Yi has left
[15:45:28] --- Seung Yi has joined
[15:58:36] --- petrescu7 has joined
[15:58:44] <petrescu7> hello?
[16:02:27] --- petrescu7 has left: Replaced by new connection
[16:02:31] --- jis has joined
[16:02:34] --- petrescu7 has joined
[16:02:48] <petrescu7> Suresh K presents WG document status slide
[16:03:32] --- doug.otis@gmail.com has joined
[16:03:46] --- hpditt has joined
[16:04:11] <petrescu7> slides:draft-ietf-dna-link-informaiton-05
[16:04:51] --- ks has joined
[16:05:19] <petrescu7> slide: sdraft-ietf-dna-link-information-05 (Changes)
[16:05:43] <petrescu7> SK: anybody interested see new text?
[16:05:47] <petrescu7> room: no answer
[16:05:57] <petrescu7> Jari Arkko: did you submit already?
[16:06:01] <petrescu7> SK: yes
[16:06:10] --- m_ersue has joined
[16:06:10] <petrescu7> JA: I'd like to see BErnard agree before forwarding
[16:06:16] <petrescu7> SK: text is here, load read.
[16:06:29] <petrescu7> slide: New Text (Influence of Bridgding)
[16:06:45] <petrescu7> JA: I'm ok with that, not a great situation to be ien.
[16:06:57] <petrescu7> JA: get some other people review that piece of text before moving forard.
[16:07:01] <petrescu7> SK: yes.
[16:07:07] <petrescu7> SK: 've put it on web site.
[16:07:17] --- behcet.sarikaya has joined
[16:07:20] <petrescu7> slide: WG document status
[16:07:29] <petrescu7> SK: any comments on link information?
[16:07:36] <petrescu7> slide: Further Steps
[16:07:45] <petrescu7> screen: blue
[16:07:54] <petrescu7> who's presenter?
[16:07:58] <petrescu7> Sati? Sathi?
[16:08:00] <petrescu7> Soti?
[16:08:10] <petrescu7> slide: Outline
[16:08:24] <petrescu7> S. NArayanan I believe.
[16:08:39] <petrescu7> slide: overview of the merge
[16:08:51] <jis> So here I sit in Boston
[16:08:58] <jis> I am listening to the audio, and this room
[16:08:58] <Seung Yi> Is this slide set available anywhere on the web?
[16:09:08] <jis> If only the slides were on-line.... life would be great
[16:09:11] <petrescu7> I don't know
[16:09:18] <petrescu7> Where are slides?
[16:09:54] --- sureshk has joined
[16:10:04] <petrescu7> Suresh where are slides?
[16:10:07] <sureshk> i will send url in a sec
[16:10:09] --- doug.otis@gmail.com has left
[16:10:29] <petrescu7> slides: Overview of the merge (contd/)
[16:10:53] <petrescu7> slides: DNA steps
[16:10:54] --- jasso1 has joined
[16:12:15] <m_ersue> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
[16:12:56] <petrescu7> jinhyeock choi samsung
[16:13:05] <petrescu7> JC: does it include reachability status?
[16:13:18] <petrescu7> JC: youy perform dna, decide on same link, destroy state REACHABLE
[16:13:31] <petrescu7> presenter: IP address i optimistic... was my understanding
[16:13:38] <petrescu7> presenter: don't have a tech answer
[16:13:54] <petrescu7> slide: processing RA
[16:15:03] <petrescu7> in that url, seach 'dna' on that page, and find "Chair slides" and "Link info".
[16:15:44] <sureshk> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
[16:16:08] <sureshk> I just uploaded the DNA solution presentation as well
[16:17:35] <petrescu7> JC: from now on, landmark option, bit no bit - will not be used.
[16:17:46] <petrescu7> presenter: ... I have other open issues
[16:17:56] <petrescu7> slide: OPen Issues
[16:18:56] <petrescu7> Erik Nordmark
[16:18:59] --- nm has joined
[16:19:00] <petrescu7> EN: wrong direction
[16:19:11] <petrescu7> EN: reason for this number, concern we rely on prefixes...
[16:19:30] <petrescu7> EN: reason to have this in, flash renumber and reassign, host moves at same time...
[16:19:47] <petrescu7> EN: cope with that, don't hold to old info forever.
[16:20:02] <petrescu7> EN: saw this prefix a while back, it might be reassignment to old link quicker than it expired.
[16:20:21] <petrescu7> EN: if we can solve 2, then we should solve 1.... timestamps of something else
[16:20:30] <petrescu7> EN: holding them to longer it would be a bad idea
[16:20:33] <petrescu7> TN Thomas Narten
[16:20:42] <petrescu7> TN: a question not supposed to ask
[16:20:55] <petrescu7> TN: I don't have a clear idea - what is the problem the group is trying to solve?
[16:21:05] <petrescu7> TN: moving, happens quickly (VoIP).
[16:21:14] <petrescu7> TN: other scenario: re-connect because away for hours.
[16:21:23] <petrescu7> TN: DNAv4 you only handle that case.
[16:21:36] <petrescu7> TN: question: is the goal to just optimize the case where you move?
[16:21:44] <petrescu7> TN: that's an ok price to pay
[16:21:57] <petrescu7> EN: problem is you never know when you dicsonnected
[16:22:04] <petrescu7> EN: reliable info when you lost conne
[16:22:23] <petrescu7> EN: can you tell when you received the last RA than the last link info you received
[16:22:38] <petrescu7> EN: even if I'm on this link but the subnet info is old.
[16:22:54] <petrescu7> EN: even if those things are long, don't rely on them.
[16:23:06] <petrescu7> EN: don't count on that info being current anymore.
[16:23:12] <petrescu7> TN: robustness is a tradeoff
[16:23:18] <petrescu7> EN: keep them up for shorter
[16:23:40] <petrescu7> TN: DNAv4 we ditn' make this choice at all, the CHDP lease is valid (DHCP sorry).
[16:23:49] <petrescu7> EN: but I thought you always send the packet in a huge pieve.
[16:23:52] <petrescu7> EN: piece
[16:23:59] <petrescu7> EN: we don't have state to say this address is ok
[16:24:04] <petrescu7> EN: is this prefix here
[16:24:11] <petrescu7> EN: more complicated we have multiple prefixes
[16:24:17] <petrescu7> EN: in v4 we only have ...
[16:24:39] <petrescu7> EN: in v6 multiple prefixes assigned and this prefix may have moved. That's a mess make this this complicated
[16:24:48] <petrescu7> EN: need of robustness mechanism to deal with corner cases.
[16:24:51] <petrescu7> James Kempf
[16:24:56] <petrescu7> JK: on number 2
[16:25:00] <petrescu7> JK: not using DHCP
[16:25:13] <petrescu7> JK: network operator may want to just advertise the router to ...
[16:25:28] <petrescu7> JK: the notion of DHCP CONFIRM may ... moved... DHCP address still valid?
[16:25:38] <petrescu7> presenter: SN S. NArayanan
[16:25:54] <petrescu7> SN: we have a proposal to solve it : mandate RA, without LN lbits.
[16:26:01] <petrescu7> JK: if DHCP it doesnt matter.
[16:26:07] <petrescu7> JK: send a cONFRIM,
[16:26:13] <petrescu7> SK: doesn't matter...
[16:26:24] <petrescu7> SN: a different case where ?
[16:26:27] <petrescu7> JK: might be
[16:26:40] <petrescu7> JK: why one would not send... DHCP.
[16:26:59] <petrescu7> JC: Choi: router doesnt' support just autoconf - it would not
[16:27:12] <petrescu7> JC: the router will not advertise at all so then DNA would not have any prefix.
[16:27:24] <petrescu7> SN: DHCP can confirm.
[16:27:42] <petrescu7> SN: in the case of links where dhcp, then there is a different way of doing DNA based on dhcp.
[16:27:51] <petrescu7> SN: stateful is a different config.
[16:27:56] <petrescu7> JC: DNA based on DHCP?>
[16:28:00] <petrescu7> SN: yes.
[16:28:06] <petrescu7> JC: simple proposal...
[16:28:27] <petrescu7> JC: this diagram will apply to any case, stateless or -ful. We don't have to define another mechanism based on DHCP.
[16:28:56] <petrescu7> SN: is that better? Move the CONFIRM to DHCP to DNA, add a line in other section where router MUST advertise? Is that?
[16:29:09] <petrescu7> SN: ask the question on mailing list
[16:29:28] <petrescu7> SN: remove any dependency on DHCP on DNA, mandate router send link addresses.
[16:29:34] <petrescu7> slide: OPen Issues
[16:29:48] <petrescu7> EN:this time, is only used in cPS protocol?
[16:29:52] <petrescu7> EN: elsewhere?
[16:30:04] <petrescu7> SN: it is used here (pointing to slide)
[16:30:09] <petrescu7> SN: non-complete
[16:30:09] --- m_ersue has left
[16:30:47] <petrescu7> EN: if as part of .16 they increase some number, you'll have RA come up and next one hasn't come up for 12h, this will be empty? If you moved you have nothing to base?
[16:30:56] <petrescu7> SN: send a landmark question...
[16:31:02] <petrescu7> SN: no landmark response in this diagram
[16:31:12] <petrescu7> SN: if you have an empty list, landmark req,...
[16:31:28] <petrescu7> SN: but if change link, complete RA, nothing to compare against, then it becomes confusing.
[16:31:39] <petrescu7> SN: maybe a situation where this is useful
[16:32:00] <petrescu7> EN: how it could work if we didn't change anything. IT seems it wouldn't work very well if welongered those lifetimes.
[16:32:12] <petrescu7> SN: we can support longer duration, because of dependecnye of ... list.
[16:32:24] <petrescu7> JC: I understand landmark must be selected from ... list.
[16:32:33] <petrescu7> SN: a good point.
[16:32:53] <petrescu7> SN: maybe text is using prefix from which you're configuring an address for, not from DNA prefuxes.
[16:33:09] <petrescu7> JC: it will be forced... possible problem that landmark is, is invalid.
[16:33:14] <petrescu7> SN: how possibily?
[16:33:23] <petrescu7> JC: ... expire prefix, but used as landmark.
[16:33:32] <petrescu7> JC: prefix lifetime is very loong usually.
[16:33:42] <petrescu7> JC: prerfix used in landmark is longer than few hours?
[16:33:45] <petrescu7> SN: I agree
[16:33:51] <petrescu7> EN: prefix is flas remembered.
[16:34:02] <petrescu7> EN: solve it? You have to have a way of not using prefix.
[16:34:09] <petrescu7> SN: keep it open.
[16:34:21] <petrescu7> EN: not relying on prefix but on... random numbers (the other solution is).
[16:34:31] <petrescu7> EN: deal with probabilities of ...
[16:35:02] <petrescu7> JC: we said that number 1 point 4 hours... 30 minutes. But something needs to be shorter for cellular operations. Every 30 minutes.
[16:35:18] <petrescu7> JC: if cellular operator don't advertise every 30min then we have problme.
[16:35:31] <petrescu7> SK: flas renumbering issues stil not solved.
[16:36:05] <petrescu7> EN: what it does do is places an operational constraint. If you need RAs every 3 hours. Then put a constraint on operator. Issue is a bit subtle.
[16:36:19] <petrescu7> SN: there's a section making recommendations on flash renumbering.
[16:36:32] <petrescu7> EN: host needs to know this number they currently don't.
[16:36:48] <petrescu7> EN: host must somehow know these numbers.
[16:36:58] <petrescu7> Hesham SOliman
[16:37:06] <petrescu7> HS: regardless agreeing increase or not but
[16:37:27] <petrescu7> HS: how do it still compatible with existing implementations?
[16:37:41] <petrescu7> HS: backward compatible found to need 50minutes
[16:37:51] <petrescu7> SN: existing hosts don't DNA
[16:38:04] <petrescu7> HS: then the scope of this issue to this work is what?
[16:38:21] <petrescu7> SN: hosts must be able to work even on links w/o DNA (that's compatibility).
[16:38:36] <petrescu7> HS: is the wimax forum is aware existing hosts will not support this?
[16:38:44] <petrescu7> SN: wimax... 30minutes check.
[16:38:50] <petrescu7> SN: number could be longer.
[16:38:56] <petrescu7> SN: 1.5 hours hardcoded.
[16:39:15] <petrescu7> HS: supposedly that will satisfy the reqs.
[16:39:29] <petrescu7> HS: would they then have to force, DNA implementation?
[16:39:31] <petrescu7> SN: yes
[16:39:40] <petrescu7> EN: I suspect this is a q for the 16ng wg.
[16:39:57] <petrescu7> EN: the router shouldnt use a number larger than 20min but host should accept a value less than 18hours.
[16:40:04] --- peetu has joined
[16:40:14] <petrescu7> EN: this wimax going this direction sending less frequently - should not cause problems.
[16:40:27] <petrescu7> EN: it's not the host rejecting
[16:40:31] <petrescu7> EN: that issue is separate.
[16:40:54] <petrescu7> SK: the q: the max then no way to communicate to host.
[16:41:09] <petrescu7> EN: that's why... simialar to other adverts,...
[16:41:33] <petrescu7> SN: you could have multiple routers on link, each having different periods ...
[16:41:36] <petrescu7> EN: ok that
[16:41:43] <petrescu7> SN: agreement on that?
[16:41:50] <petrescu7> SN: no-bit... landmark...
[16:42:28] <petrescu7> SN: the Y bit functionality can be achieved by adding a prefix in the response, without saying yes this prefix is here.
[16:43:22] <petrescu7> EN: the semantics to get a Y back isn't that... multiple RAs same landscapes
[16:43:30] <petrescu7> EN: not a confirmation that this RS is needed.
[16:43:40] <petrescu7> SN: not sure landmark response can be multicasted
[16:44:15] <petrescu7> JC: optimistic addresses then response will come in unicast. So even if we reuse without Y bit. The reply will come in unicast.
[16:44:30] <petrescu7> SN: Y bit.
[16:44:42] <petrescu7> SN: have it as explicit, advantage: we can remove a check.
[16:45:31] <petrescu7> EN: format-wise: get rid of explicit landmark option. Just send a prefix up. (and rename option). all we need is a prefix in RS. Not need to have a separate option.
[16:45:38] <petrescu7> EN: rename it, but
[16:45:48] <petrescu7> SN: would it be more complex?
[16:45:51] <petrescu7> EN: format...
[16:45:58] <petrescu7> EN: all we need is to send a prefix in RS
[16:46:09] <petrescu7> EN: so the router says we're stil lin same place
[16:46:16] <petrescu7> SK: do we gain what? Simplicitiy?
[16:46:18] <petrescu7> SN: less text
[16:46:28] <petrescu7> JC: landmark option we can not send non-prexif based.
[16:46:36] <petrescu7> JC: if we use link id option...
[16:46:52] <petrescu7> EN: therwseis, carefully renaming into LPIO
[16:47:02] <petrescu7> EN: link ids on some links are not prefixes.
[16:47:10] <petrescu7> EN: send it in an RS as well.
[16:47:18] <petrescu7> LPIO: link-identifier option
[16:47:32] <petrescu7> SN: I'm ,,,... not compressing all too much.
[16:47:56] <petrescu7> SN: it's simpler to leave it as... not this option in this direction means this, this option in that direction means that.
[16:47:57] --- jishac has joined
[16:48:12] <petrescu7> SN: removing the Y bit? Not removing the Y bit? Ok I'll go to mailing list.
[16:48:40] --- nm has left: Replaced by new connection
[16:48:42] --- nm has joined
[16:49:07] <petrescu7> TN: why do we have to have thiese things configurably??? No user ever touches these otpions. Constance, not changeable.
[16:49:13] <petrescu7> SN: they are default values.
[16:49:22] <petrescu7> TN: but text says configurable
[16:49:32] <petrescu7> EN: so we should be more conservative
[16:49:43] <petrescu7> TN: it measn cell phone, when we say configuration.
[16:49:53] <petrescu7> TN
[16:49:59] --- nm has left
[16:50:07] <petrescu7> TN: terminology
[16:50:19] <petrescu7> TN: you say something is another doc refers to an expired draft?
[16:50:22] <petrescu7> TN: fix that
[16:50:27] <petrescu7> TN: pull up those that matter
[16:50:35] <petrescu7> TN: thoise not used in the document get rid of them
[16:50:38] <petrescu7> SN: ok will do
[16:51:02] <petrescu7> slide: Open Issues
[16:51:13] <petrescu7> (cont'd)
[16:51:19] <petrescu7> (contd.)
[16:52:06] <petrescu7> EN: the analysis specifically talks bssid, but how rouboust suich recommendations are? Today nothing depends on them.
[16:52:37] <petrescu7> EN: walk far enough, find a new one, everything works the way it would expect. Recommend people look at that the DNA will fail in that case. YOu try to optimize, but it's hard to tell the downside.
[16:52:51] <petrescu7> EN: reachability probe to the router? routers have stuff...
[16:53:05] <petrescu7> EN: the optimizaiton is not biased that much
[16:53:20] <petrescu7> EN: sending an RS or not is the only q. Doesn't seem worthwhile optimize this.
[16:53:24] <petrescu7> EN: CARD?
[16:53:34] <petrescu7> EN: not trying to rpedict what that might be here.
[16:53:42] <petrescu7> EN: not do that in base protocol.
[16:53:58] <petrescu7> SN: CARD, FMIP case. Say something better than what was said right now.
[16:54:06] <petrescu7> SN: keep it and make an issue now, rather than..
[16:54:29] <petrescu7> .SN: trying to ask the q, but do something that CARD DNA, DNA does something more efficient thant hat.
[16:54:42] <petrescu7> EN: so it would be of someone else to specify this. Just keep this spec simpler.
[16:55:10] <petrescu7> slide: Open Issues (Cntd.)
[16:55:17] <petrescu7> (Contd.)
[16:56:36] <petrescu7> EN: could they remain on one list?
[16:56:54] <petrescu7> EN: this one I learn from this place. In most case you don't care where from you've learnt this.
[16:57:00] <petrescu7> EN: make things ismpler.
[16:57:08] <petrescu7> SN: different solutions which became.
[16:57:16] <petrescu7> TN: right direction is this.
[16:57:56] <petrescu7> TN: you have a link, a fundamental obj, associated to link is prefix, id... the trick is how to name the objects. BEtter off structuring on infomration on link, maybe sometimes merge infos when realize the same links.
[16:58:02] <petrescu7> SN: they gave me an idea
[16:58:16] <petrescu7> SN: the main advantage of link id list is to understand the forward compatibility idea.
[16:58:26] <petrescu7> SN: which are link ids, which arenot based on prefixes.
[16:58:51] <petrescu7> SN: there is some forward compatibility advantage, which is not prefix .
[16:59:08] <petrescu7> SN: if people think we don't have to maintain this capability, it would ismplify
[16:59:19] <petrescu7> EN: you can do maintain that instead of simple layers.
[16:59:29] <petrescu7> EN: other ones don't have to pbe prefixes.
[16:59:40] <petrescu7> EN: comapre it to what I've received to RA in the list. The details of...
[16:59:51] <petrescu7> EN: what are the effective rules.
[17:00:07] <petrescu7> SN: the advantage, you just implementation issues
[17:00:35] <petrescu7> EN: but in terms of describing in this level, I maintain the list per link, on top I add info from RAs. When I get RA from link up.
[17:00:49] <petrescu7> EN: doesn't necessarily get simpler, but gets easier to describe.
[17:01:00] <petrescu7> SN: prefixes, link ids.
[17:01:16] <petrescu7> SN: in terms of description things can be siomplifiedm, but otherwise everything stays the same.
[17:01:24] <petrescu7> SN: leave it open.
[17:01:36] <petrescu7> SK: quite a few people depend on the possiblity to include...
[17:01:48] <petrescu7> SK: bring it to list, manet and autoconf WG who are very interested.
[17:02:03] <petrescu7> slide: Open Issues (Contd.) issue 8 to 10
[17:02:46] <petrescu7> HS: merger
[17:03:06] <petrescu7> HS: discussed couple IETF ago, distinction link up when interface comes up or when change in AP. Was this reflected in draft?
[17:03:12] <petrescu7> SN: don't remember the discussion.
[17:03:16] <petrescu7> HS: a bit misleading.
[17:03:39] <petrescu7> HS: there's a difference between getting a link up when interface comes up and change an AP. It's not the same thing anyways, whatever you call it.
[17:03:51] <petrescu7> SN: from DNA's point of view it's not different.
[17:04:00] <petrescu7> HS: need to distinnguish
[17:04:06] <petrescu7> HS: to make it clear to implementers
[17:04:18] <petrescu7> JC: right now it's described as link up info in ... draft. YOu mean
[17:04:30] <petrescu7> JA: we have other document talking about link information indication.
[17:04:40] <petrescu7> JA: if concrete - yes we should talk about, if not then not.
[17:04:51] <petrescu7> HS: if you want to keep as conceptual name, but it should be dscribed.
[17:05:00] <petrescu7> JA: yes, sholuld clear in lilnk info document
[17:05:08] <petrescu7> SK: it doesn;t distinguish between these two
[17:05:23] <petrescu7> HS: whichever document describes it means we should have a distinction.
[17:05:36] <petrescu7> JC:I don't think that section
[17:05:41] <petrescu7> JC: the draft is not too short
[17:05:52] <petrescu7> JC: maybe we coan remove the erroneous prefix list this and that
[17:06:05] <petrescu7> SN: it's in the overview sections so.
[17:06:20] <petrescu7> SN: confirm on mailing list
[17:07:28] <petrescu7> JC: there's a section "Dna complications" that need to go
[17:07:36] <petrescu7> SN: I felt that is not completely useless.
[17:07:44] <petrescu7> JC: a similar section in the Goals draft
[17:07:51] <petrescu7> SN: let me look at that.
[17:08:05] <petrescu7> JC: goals and non-goals
[17:08:19] <petrescu7> slide: proposed schedule
[17:08:45] <petrescu7> SN: needs substantial comments
[17:09:27] <petrescu7> JC: what sorts of issues ready to be resolved soon?
[17:09:43] <petrescu7> SN: yes, and any new issues you may have.
[17:09:57] <petrescu7> blue sheets time
[17:10:12] <petrescu7> Jin-Hyeock Choi presenting
[17:10:24] <petrescu7> FRE document
[17:10:26] <petrescu7> INFORMATIONAL
[17:10:44] <petrescu7> FRD
[17:10:54] <petrescu7> Fast Router Discovery
[17:11:11] <petrescu7> slide: Current Status
[17:11:28] <petrescu7> there are no slides on the proccedings site I believe
[17:11:34] <petrescu7> slide: Issue list
[17:13:14] <petrescu7> slide: Tentative Solutions
[17:13:22] <petrescu7> Jari Arkko
[17:13:27] <petrescu7> JA: clarification
[17:13:33] <petrescu7> JA: moved the part to an appendix you said?
[17:13:42] <petrescu7> JA: agreed now to remove it completely
[17:13:47] <petrescu7> JC: agreed.
[17:14:27] <petrescu7> JA: but multiple mechanisms, what the testing, the lack of applicability statement that probabilye helps.
[17:14:36] <petrescu7> JA: wanted to see whether WG agrees to smaller...
[17:14:42] <petrescu7> JA: there are differences in areas
[17:14:48] <petrescu7> JA: but all this seems rather short term
[17:15:10] <petrescu7> JA: if you had a good recommendation from IETF in this space, on what people deploy, that would be great. That's not too much to ask.
[17:15:20] <petrescu7> JA: like to see redcution in number of solutions
[17:15:29] <petrescu7> JC: analyze the problem and provide solution
[17:15:32] <petrescu7> slide: Plan
[17:15:40] <petrescu7> JC: any questions?
[17:15:48] <petrescu7> SK: Thomas you raised lots of this issues, looks ok?
[17:15:52] <petrescu7> TN: hard to say
[17:16:02] <petrescu7> TN: we had offline email discussion that's not compeltely solved.
[17:16:08] <petrescu7> TN: hard to tell
[17:16:17] <petrescu7> SK: willing to work on text with Jim get
[17:16:32] <petrescu7> TN: merged document exlcuisleve until get it done, otherwise loose energy
[17:16:39] <petrescu7> TN: uncomfortable with merged document.
[17:16:51] <petrescu7> TN: don't want to spend document. I want to look at th emerged document
[17:16:57] <petrescu7> JA: point to say, I agree TN
[17:17:09] <petrescu7> JA: get the 2 document on table (link doc, protocol doc) out.
[17:17:18] <petrescu7> JA: I don't want to have multiple things on my table.
[17:17:32] <petrescu7> JA: maybe you too don't want two S
[17:17:35] <petrescu7> two WGLCS
[17:17:40] <petrescu7> Satya N.
[17:18:00] <petrescu7> SN:not looking at any other document than the merged document... same feeling you have towards ... router?
[17:18:04] <petrescu7> adjourns
[17:18:08] <petrescu7> Chair adjourns
[17:18:10] <petrescu7> end of meeting
[17:18:12] --- hpditt has left
[17:19:21] --- petrescu7 has left
[17:19:22] --- ks has left: Logged out
[17:19:59] --- jasso1 has left
[17:26:37] --- peetu has left: Logged out
[17:29:57] --- Seung Yi has left
[17:37:07] --- hpditt has joined
[17:44:38] --- jishac has left
[17:53:09] --- hpditt has left
[18:20:45] --- behcet.sarikaya has left
[18:24:28] --- sureshk has left
[18:26:05] --- hpditt has joined
[18:28:48] --- hpditt has left
[19:27:24] --- jis has left