[12:02:02] --- LOGGING STARTED
[12:59:38] --- momose has joined
[12:59:40] --- nm has joined
[13:01:03] --- gorryf has joined
[13:01:12] --- petrescu7 has joined
[13:02:05] --- dudi has joined
[13:02:37] --- dthaler has joined
[13:03:13] <petrescu7> Soohong Daniel PArk SDP
[13:03:44] <petrescu7> slide: agenda 1/2
[13:03:56] --- admcd has joined
[13:04:04] <petrescu7> anybody knows where the slides are on the ietf site? anywhere else?
[13:04:49] <admcd> Most slides are available at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66
[13:04:58] --- shep has joined
[13:05:41] <dthaler> agenda slides: http://www3.ietf.org/proceedings/06jul/slides/16ng-7.ppt
[13:05:46] <petrescu7> Sang Eon Kim, Max Riegel, Eun Kyoung Paik, Frank Xia will present during the meeting.
[13:06:37] <petrescu7> slide: WG Report
[13:06:57] --- loughney has joined
[13:07:36] <petrescu7> slide: 16ng Interim
[13:08:17] <dthaler> do people want the mid-sept interim meeting to be in seattle, seoul, or germany?
[13:08:24] <petrescu7> how about washington?
[13:08:42] <petrescu7> germany, korea? hands raised.
[13:08:53] --- rjaksa has joined
[13:09:08] <rjaksa> what was the count?
[13:09:17] <dthaler> couldn't tell
[13:09:20] <dthaler> anyone else?
[13:09:32] <petrescu7> no public count, by myself same counts for all options, like 2-3 hands for each city.
[13:09:51] <petrescu7> Max Rieger presents "relationship to IEEE802.16 & WiMAX"
[13:10:04] <petrescu7> slide: IEEE 802.16: One standard fits all
[13:10:06] <dthaler> slides at: http://www3.ietf.org/proceedings/06jul/slides/16ng-9.ppt
[13:10:56] <dthaler> (also, it's spelled Riegel)
[13:11:13] <petrescu7> slide: wimax and ieee 802.16
[13:11:17] <petrescu7> sorry Riegel
[13:11:46] --- psavola has joined
[13:12:10] <petrescu7> slide: preferred convergence sublayers
[13:12:18] --- bonninjm@jabber.org has joined
[13:12:35] --- gorryf has left
[13:13:48] <petrescu7> Junghoon Jee presenting. IP over 802.16...
[13:13:53] <petrescu7> slide: Terminology
[13:13:58] --- psavola has left
[13:13:59] <dthaler> slides at: http://www3.ietf.org/proceedings/06jul/slides/16ng-10.ppt
[13:14:13] --- fparent@jabber.org has joined
[13:15:07] <petrescu7> slide: Terminology (@)
[13:15:12] <petrescu7> sorry Terminology (2)
[13:15:23] --- Will Ivancic has joined
[13:15:40] --- weddy has joined
[13:16:38] <petrescu7> slide: 16ng problem statement
[13:16:50] <petrescu7> lights off, on again
[13:17:01] --- Bob has joined
[13:17:37] --- psavola has joined
[13:17:37] --- miyahiro@jabber.org has joined
[13:20:38] <petrescu7> slide: 16ng Problem Statement (2)
[13:21:50] <petrescu7> slide: 16ng Goals
[13:23:09] <petrescu7> slide: 16ng Goals (2)
[13:23:56] --- shep has left
[13:24:13] <petrescu7> slide: 16ngNetwork Models (last slide)
[13:24:28] --- patchvonbraun has joined
[13:25:05] --- patchvonbraun has left
[13:26:32] <petrescu7> bahncgahshere?
[13:26:50] <petrescu7> as for the goal 6, do you think we need multiple convergence layer or convergence layer selection solution?
[13:26:52] <petrescu7> no
[13:27:10] <petrescu7> JJ: for deciding wchich cs, which terminal, this klind of negotiation is already defined in...
[13:27:31] <petrescu7> JJ: we don't need any new function in the 16ng wg, just clarify how to do achieve this aspect in this document. no need of new...
[13:27:41] <petrescu7> sugest to remove this... was confusion.
[13:28:06] <petrescu7> 2nd point: subnet model, but is this right time to discuss subnet model today? I remember discussion about this on the mailing list, I think you said...
[13:28:32] <petrescu7> the model included this kind of cfunctionality, but the Ethernet actually should be more clearly in two acases: 1) wimax wibro, 2nd case regular model.
[13:28:58] <petrescu7> questioner: we can have three possibl esubnet models here, : wimax/wibro, etherne,t, 3rd 3gpp.
[13:29:43] <petrescu7> JJ: thanksf or comment. I'd like to multiple... in IP respect here and IP gateways... how the IP subnet prefix is distributed - that's key point.
[13:30:17] <petrescu7> JJ: we can think about two models, stations share ... or not. When the prefix is shared we can think about IP ... In case of Ethernet shares we add prefix to the Base Station.
[13:30:56] <petrescu7> JJ: your comment is valuable and very related to that but currently I don't have a strong oppinion on that. If you wanted to add the BS archi issues, how do you refer in the three model?
[13:31:12] <petrescu7> questioner: clarigyin let me, I'm just asking the current status of scope of 16ng. I feel I'd like to
[13:31:17] --- esa has joined
[13:31:28] <petrescu7> to cover the three possible scenarios on 16 link, just asking the currnet scope of the WG.
[13:31:39] --- stevebret has joined
[13:31:46] <petrescu7> questioner: 2nd comment, that kind of model is for this draft or the deployment scenario draft?
[13:32:00] <petrescu7> JJ: our draft has these kinds of issues, it's one of ... should be included in this document.
[13:32:03] --- patchvonbraun has joined
[13:32:15] <petrescu7> JJ: if any subnet model is missing then...
[13:32:42] <petrescu7> questioner2 from Lucent: that's architecture you plan to study, includes the keys where the router is co-located to BS?
[13:33:25] <petrescu7> JJ: yes, it's related to BS archi issues, just add information text about that in this draft. Whether BS for Access Router is combined or not, should be considerede, but first consider how to IP subnet, then to think about how to deploy whether combined or not.
[13:33:43] <petrescu7> questioner2: if it's not done early, then very hard to get security solutions.
[13:34:13] <petrescu7> q2: because you mentioned 3gpp models, it's important to deal .
[13:34:29] <petrescu7> q2: it is important to address the physical... security issues.
[13:34:35] <petrescu7> Dave Thaler, DT
[13:35:16] <petrescu7> DT: relate, fixed world and mobile worlds, is this slide (16ng Network Models) fitting in which models? Ethernet CS? Mobile world is IP*CS.
[13:35:35] <petrescu7> DT: fixed vs wireless seems more pertinent? Is this the intent? Or some other intent.
[13:35:44] <petrescu7> (Dave, if I missed something sorry)
[13:36:17] <petrescu7> JJ: goal here is to find out... following the line you try to ... one is to be done through 16ng to provide the ... model.
[13:36:31] --- esa has left
[13:37:01] <petrescu7> DT: your intent here is that in the fixed world was Ethernet, then subnet model is applicable in the world, while in the mobility world, you have either choice between two.
[13:37:07] <petrescu7> Behcet Sarykaya BS
[13:37:31] <petrescu7> BS: this slide (16ng Netw2ork Models), very relevant to the IPv6 subteam in the WiMaxforum.
[13:37:59] <petrescu7> BS: current thinking is... We have to establish a working relationship 16ng IPv6 subteam.
[13:38:37] <petrescu7> BS: common numbers. I mentioned I don't think anything is applicable. WiMAx Forum is ready to except, really one is going to be released. Decisions have been made, wimax can not take... (here?).
[13:39:05] <petrescu7> Chair: IPv6 point...
[13:39:05] --- weddy has left
[13:39:07] --- esa has joined
[13:39:32] <petrescu7> Questioner2: on slide 16ng Goals (2)
[13:39:48] <petrescu7> questioner3 sorry.
[13:40:13] <petrescu7> questioner3: let the message and procedure to find a negotiation and several... please check the problem full 6.
[13:40:15] <petrescu7> JJ:
[13:40:31] <petrescu7> questioner4: wifi forum is not internationally recognized.
[13:40:42] <petrescu7> questioner4: it's a marketing organization.
[13:40:52] <petrescu7> questioner4 is lead in capwap I believe or so.
[13:41:03] <petrescu7> Pat Calhoun?
[13:41:26] <dthaler> i think so yes
[13:41:29] <petrescu7> Co-chair: if in favour this doc becomes a WG item raise hand.
[13:41:34] <petrescu7> many hands up
[13:41:40] <petrescu7> Co-chair: if not raise your hand
[13:41:45] <petrescu7> room: no hand I saw.
[13:42:00] <petrescu7> Co-chair: decision was to...
[13:42:40] <petrescu7> presenter is who?
[13:42:50] <momose> Jinhyock Choi
[13:43:07] <petrescu7> JC presents
[13:43:12] <dthaler> slides at: http://www3.ietf.org/proceedings/06jul/slides/16ng-11.ppt
[13:43:25] <petrescu7> slide: IPv6 over 802.16's IPv6 Convergence Sublayer
[13:43:29] <petrescu7> slide: Agenda
[13:43:47] <petrescu7> slide: Introduction
[13:44:40] <petrescu7> slide: WiMax Network Architecture
[13:45:29] <petrescu7> slide: Problems
[13:46:04] <petrescu7> DT: are you assuming a specific subnet model?
[13:46:07] <petrescu7> JC: yes
[13:46:16] <petrescu7> DT: statements are only true in the Ethernet model.
[13:46:38] --- ldondeti has joined
[13:47:05] <petrescu7> slide: Approaches
[13:49:01] <petrescu7> slide: Proposed Solution
[13:50:19] <petrescu7> slide: Proposed Solution (a different one)
[13:51:24] <petrescu7> slide: Router Discovery (RS/RA Exchange)
[13:52:12] <petrescu7> slide: Router Discovery (RS/RA Exchange)
[13:52:57] <petrescu7> slide: Neighbor Discovery Procedures
[13:54:28] <petrescu7> slide: Neighbour Discovery Procedures
[13:55:03] <petrescu7> slide: Address Autoconfiguration
[13:55:34] <petrescu7> slide: Relay DAD
[13:56:28] --- nm has left
[13:56:52] <petrescu7> slide: Relay DAD Procedure
[13:57:06] <petrescu7> slide: Relay DAD Procedure
[13:57:18] --- ldondeti has left
[13:57:47] <petrescu7> slide: WiMAX IPv6 Status
[13:58:08] <petrescu7> slide: Way Forward
[13:58:35] <petrescu7> DT: one and half qs.
[13:59:01] <petrescu7> DT: you're responding out of the cache populated from DAD, so router has a list of addresses thinks existed. That's not true. may be packet loss...
[13:59:13] <petrescu7> DT: you don't have a complete solution there.
[13:59:27] <petrescu7> DT: question: what do you do about app layer multicast and broadcast.
[13:59:48] <petrescu7> DT: app sends packet to explicit IPv6 mcast address... intended to go to other ms'es, what does the ARs do?
[13:59:53] <petrescu7> JC: inside the link?
[14:00:04] --- nm has joined
[14:00:10] <petrescu7> DT: you kept it inside a link, didn't mention the other ones, the inteliigiceht switcihing?
[14:00:24] <petrescu7> DT: right now does not support any multicast (other than NS).
[14:00:30] <petrescu7> JC: ns is delivered for mcast.
[14:00:39] <petrescu7> DT: any protocol above ND that uses mcast will not work.
[14:01:12] <petrescu7> questioner5: current document is stable and good shape for wimax, it is not for general ipcs solution. My thought could be that IETF doc should have broader view.
[14:01:40] <petrescu7> q5: wimax is about current deployment. 16ng should cover replacments solutions (like dsl, 3gpp), if time permits... this draft should wait for input... if not
[14:01:54] <petrescu7> this should be separated into wimax spec documents, or rfc 3...
[14:01:59] <petrescu7> or the general solution doc.
[14:02:20] <petrescu7> JC: wimax is clearly visible and take/extract there from wibro, gather. General solution would be nice...
[14:02:24] <petrescu7> questioner 6 (rand?)
[14:02:44] <petrescu7> q6: you're confusion is handoff between bs and as, is a pro-ms... three possibilities...
[14:02:48] <dthaler> (on my DAD point up a ways, the point is there are multiple reasons it's not sufficient... packet loss, anycast addresses, MS configures DAD attempts to 0, someone does the bad optimization of just doing dad on LL and not global, etc etc)
[14:02:55] <petrescu7> JC: ISP is the tunnel BS and ASN and should be managed at least per MS
[14:02:58] <petrescu7> q6: why
[14:03:20] <petrescu7> q6: tentative option
[14:03:36] <petrescu7> JC: ok , RS carries tentnative option, but it's not mandatory to put...
[14:03:57] <petrescu7> q6: I want to say your condition that the tunnel BS-AS gw, this is another very necessary.
[14:04:06] <petrescu7> JC: in wimax gerrytunnel is at least per MS.
[14:04:15] <petrescu7> q6: wimax should be.
[14:04:26] <petrescu7> JC: not trying to slay "every dragon" :-)
[14:04:40] <petrescu7> questioner7: udlr as a way to manage the tunnel?
[14:04:50] <petrescu7> q7: has multicast and broadcast for upstream.
[14:05:04] <petrescu7> JC: bs should relay packet to upside.
[14:05:16] <petrescu7> q7: not the IETF way to do work we like in IETF.
[14:05:30] <petrescu7> JC: manage thousahns of moboiile stations, multicast not efficienmt.
[14:06:27] <petrescu7> DT: udlr - primary scenario was for satelite networks. The mc happens by sending unicast in... ther you don't need any. HEre yuo need some intelligent learning like in ND or MLD. The equivalent solution here would be unicast downstream and selectible ... downlstreamn.
[14:06:37] <petrescu7> JC: IPv6 can work on a non-multicast downlink.
[14:06:49] <petrescu7> q7: then you break mc apps where mc flows. Something to think about.
[14:07:05] <petrescu7> BS (Behcet): we discussed this over the list. Just to bring it to the meeting.
[14:07:12] <petrescu7> BS: originates in 6lowpan.
[14:07:22] <petrescu7> BS: involves another MS nothing to do with that comm.
[14:07:40] <petrescu7> BS: involvement of another MS all of a sudden has the dormant mode problem.
[14:07:46] <dthaler> UDLR = unicast upstream over a tunnel to the router, and broadcast/multicast downstream from router to hosts
[14:07:53] <petrescu7> BS: idea: counter DAD (?)
[14:08:33] <petrescu7> JC: IPv6 host operations should be modified according to this, that's why we choose relay DAD, although not pretty.
[14:08:55] <petrescu7> Co-chair: we need more comment and feedback discussion. We'll trigger the discussion on the mailing list.
[14:09:25] <petrescu7> blue screen :-)
[14:09:40] <dthaler> btw, UDLR = http://www.ietf.org/rfc/rfc3077.txt
[14:09:53] <petrescu7> thanks
[14:10:50] <petrescu7> anybody in this chat room not in the real physical room?
[14:11:03] <stevebret> yes
[14:11:32] <petrescu7> the computer used to display crashed and it takes some time install a new computer.
[14:11:41] --- patchvonbraun has left
[14:12:01] <dthaler> slides for next presentation are at: http://www3.ietf.org/proceedings/06jul/slides/16ng-12.ppt
[14:13:49] <petrescu7> Max Riegel presents "Transmission of IP packets over..."
[14:13:54] <petrescu7> slide: Introduction
[14:15:07] <petrescu7> slide: IP works fine over Ethernet
[14:15:46] <petrescu7> slide: IP works fine over Ethernet over IEEE802.16
[14:16:50] <petrescu7> slide: The IEEE802.16 Link Model
[14:17:34] <petrescu7> speaker is sometimes interrupted by funny chat window showing on the screen.
[14:17:55] <petrescu7> They;d better display this chat room along with the slides :-)
[14:18:08] <petrescu7> slide: Convergence Sublayer Classification and Encapsulation
[14:19:40] <petrescu7> slide: Bridged Ethernet link model for IEEE802.16
[14:20:48] <petrescu7> slide: Enhanced Ethernet link model for IEEE802.16
[14:21:40] <petrescu7> slide: Layered Approach
[14:23:21] --- admcd has left: Replaced by new connection
[14:23:36] --- nov has joined
[14:23:43] <petrescu7> slide: conclusion
[14:24:33] <petrescu7> MR: talking about becoming WG item, and when.
[14:26:01] <petrescu7> DT: overall looks good.
[14:26:10] <petrescu7> DT: you do actually support mc, because it's classic.
[14:26:15] <petrescu7> MR: beneath it's always...
[14:26:22] <petrescu7> DT: mc at mac layer.
[14:26:40] <petrescu7> MR: cash that can be used on behalf of hosts to keep entryies...
[14:26:46] <petrescu7> sorry that was DT
[14:26:57] <petrescu7> DT: what if you receive NS for something not in the cache.
[14:27:10] <petrescu7> MR: for this ND it's forwarded (w/ waisting ressources).
[14:27:17] <petrescu7> MR: the emulation beneath.
[14:27:22] <petrescu7> DT: an optimization then
[14:27:24] <petrescu7> MR: tyes.
[14:27:35] <petrescu7> questioner (previous riaised too):
[14:27:39] <petrescu7> (stupid q?)
[14:27:46] <dthaler> Gorry Fairhurst (spelling?)
[14:27:57] <petrescu7> q: multicast upstream is it broadcasted downstream to the other people?
[14:28:07] <petrescu7> MR: yes
[14:28:16] <petrescu7> q: do you get a copy yourself? Or a way to avoid that?
[14:28:26] <petrescu7> MR: filtering rules prevent yoursrelf getting a copy.
[14:28:32] <petrescu7> q: how do you filteR?
[14:28:53] <petrescu7> MR: the rule is that if a packet is coming oout of a upstream conn is not going down same way.
[14:28:56] <petrescu7> q is GF.
[14:29:02] <petrescu7> DT talks to GF>
[14:29:16] <dthaler> q was: do ND packets have a source address; answer: yes
[14:29:54] <petrescu7> Sang-Eon Kim presents IP Deployment over WiBro
[14:29:55] <dthaler> (except for DAD checks)
[14:30:04] <petrescu7> slide: WiBro Specification
[14:30:19] <dthaler> slides at: http://www3.ietf.org/proceedings/06jul/slides/16ng-13.ppt
[14:31:13] <petrescu7> speed is 60kmph not 6kmph I believe.
[14:31:46] <petrescu7> slide: WiBro Architecture
[14:33:01] <petrescu7> slide: IP over WiBro
[14:33:56] <petrescu7> slide: IPv4/IPv6 Bearer
[14:34:36] <petrescu7> slide: Protocol Stack at U
[14:35:25] <petrescu7> slide: Technical Issues
[14:37:10] <petrescu7> slide: Technical Issues
[14:37:46] <petrescu7> John Loughney is JL
[14:38:32] <petrescu7> JL: TCP? Are you definining a nerw RTO algorithm? There are some others in the transport areas, used in a different wireless deployments... not sure why WiMax would be different than wcdma, ...
[14:38:40] <petrescu7> SEK: no proposed algorithm.
[14:38:52] <petrescu7> SEK: diff CDMA wibro. CDMA is packet based network.
[14:39:02] <petrescu7> SEK: wibro is the packet based network.
[14:39:16] <petrescu7> JL: why, again would you need something different?
[14:39:21] --- miaofy has joined
[14:39:34] <petrescu7> JL: if you still lokking for .. please look at pilc WG, after producing RFC of TCP over wireless.
[14:39:44] <petrescu7> SEK: I'll adopt your comment.
[14:39:55] <petrescu7> questioner9: diameter not being... on IPv6 - not true.
[14:40:08] <petrescu7> SEK: I don't want all kinds of technical issues in this WG.
[14:40:16] <petrescu7> Gabriel Montengro GM
[14:40:34] <petrescu7> GM: this is wibro, not wimax. This WG w ill look at this when...
[14:40:48] <petrescu7> DT: wibro
[14:40:54] <petrescu7> MR: wibro was on my presentation.
[14:41:33] <petrescu7> GM is Gabriel Montenegro is co-chair.
[14:41:36] <petrescu7> SDP is co-chair.
[14:42:00] <petrescu7> Max Riegel presents IEEE802.16 fixed/nomadic IP deployment
[14:42:09] <petrescu7> slide: ETH and IP support of IEEE802.16
[14:42:22] <dthaler> wibro is a subset of mobile wimax (per slide 3 of http://www3.ietf.org/proceedings/06jul/slides/16ng-9.ppt)
[14:43:02] <dthaler> now up: http://www3.ietf.org/proceedings/06jul/slides/16ng-14.ppt
[14:43:22] <petrescu7> slide: deployment of IEEE802.16 for wireless DSL
[14:44:15] <petrescu7> slide: IEEE802.16e for fixed/nomadic deployments
[14:45:13] <petrescu7> slide: IEEE802.16e Fixed/Nomadic Network
[14:46:43] <petrescu7> DT: 16e... spanning both fixed and mobile.
[14:47:06] <petrescu7> DT: earlier presentation, fixed is ethernet cs, mobile is ip*cs, while here you say different.
[14:47:24] <petrescu7> MR: interest is for people doing fixed/nomadic deployment. Load balancing.
[14:47:31] <petrescu7> MR, DT: lower left.
[14:47:42] <dthaler> not the mobile side of the taxonomy
[14:48:04] <petrescu7> Eun Kyoung Paik EKP presents TTA IPv6 PG: IPv6 over WiBro Report
[14:48:15] <petrescu7> slide: Contributors
[14:48:21] <dthaler> slides at: http://www3.ietf.org/proceedings/06jul/slides/16ng-15.ppt
[14:48:25] <petrescu7> slide: What is WiBro?
[14:49:00] <petrescu7> slide: TTA IPv6 PG WiBro6
[14:49:45] <petrescu7> slide: Standard Phase1 Contents
[14:50:28] <petrescu7> slide: Current State
[14:50:48] <petrescu7> islide: What is needed from IETF?
[14:51:19] <petrescu7> slide: questions
[14:53:41] <petrescu7> Frank Xia presenting DAD Optimizatio nusing END (Enhanced NEighbour Disocvery)
[14:53:43] <dthaler> slides at: http://www3.ietf.org/proceedings/06jul/slides/16ng-16.ppt
[14:53:52] <petrescu7> slide: Relay DAD
[14:54:21] <petrescu7> slide: Relay DAD
[14:54:56] <petrescu7> attenuator needed :-)
[14:55:49] <petrescu7> slide: Enhanced Neighbour Disocvery (END)
[14:56:00] <petrescu7> SDP changin mike position
[14:58:23] <petrescu7> slide: Main Implementation Details
[14:58:36] <petrescu7> slide: Main Implementation Details
[14:58:42] <petrescu7> slide: Next Step
[14:59:02] <petrescu7> Suresh Krishnan SK
[14:59:07] <petrescu7> SK: bit is used by the ha option.
[14:59:12] <petrescu7> SK: all the bits of RA are gone.
[14:59:32] <petrescu7> SK talk to Bob Hinden, there are are two bits by DNA
[14:59:50] <petrescu7> SK: prefix information option used not in the intended way, maybe a better optiopn.
[15:00:00] <petrescu7> FX: was not a standard so yes.
[15:00:09] <petrescu7> FX: one worry of DNA, last bit resereved.
[15:00:22] <petrescu7> SK: six bits are gone, only two bits left.
[15:00:30] <petrescu7> SK: you take that so.
[15:00:32] <petrescu7> FX: ok.
[15:01:16] <petrescu7> DT: the problem is the time it takes to get an address? You didn't say specifically which CSs you intend. If Ethernet CS then normal DAD should apply. So not in the context of IPv6 CS. In there I give same feedback
[15:01:44] <petrescu7> the notion of an Authoritative cache, does not exist. Where do you get that from? Can't be given by DAD, because at least 4 reasons.
[15:01:49] <petrescu7> FX: yes
[15:02:22] <petrescu7> DT: don't think Authroitcative cache exists in IPv6.
[15:02:28] --- bonninjm@jabber.org has left: Logged out
[15:02:30] <petrescu7> BS: if there is an end then...
[15:02:40] <petrescu7> BS: about optimistic DAD.
[15:03:10] <petrescu7> DT: I interpret what you said that if I look in my cache and I find no entry then I can send this P bit (as opposed to immediate negative reply).
[15:03:13] <petrescu7> FX: yes
[15:03:22] <petrescu7> DT: so I understand you correctly so my comments are correct.
[15:03:28] <petrescu7> FX: dominate state.
[15:03:39] <petrescu7> FX: state "all send". Negative reply to MS implies.
[15:03:48] <petrescu7> DT: no inherent problem to respond out of the cache.
[15:04:01] <petrescu7> DT: I don't see any problem in this env to respond with a NA from the cache.
[15:04:16] <petrescu7> DT: not currently safe in the current IPv6 arch.
[15:04:22] <petrescu7> SDP: tnx for attention.
[15:04:25] <petrescu7> GM: bluesheets.
[15:04:28] <petrescu7> adjourned.
[15:04:29] --- fparent@jabber.org has left
[15:04:35] --- petrescu7 has left
[15:04:38] --- esa has left
[15:04:40] --- miyahiro@jabber.org has left
[15:04:40] --- Will Ivancic has left: Computer went to sleep
[15:04:49] --- Bob has left: Logged out
[15:04:51] --- stevebret has left
[15:04:52] --- miaofy has left
[15:04:56] --- nov has left
[15:06:22] --- loughney has left
[15:08:33] --- momose has left
[15:10:01] --- psavola has left
[15:12:03] --- dudi has left: Replaced by new connection
[15:21:56] --- nm has left
[15:22:28] --- rjaksa has left
[15:39:45] --- dthaler has left
[15:41:39] --- dthaler has joined
[15:43:33] --- petrescu7 has joined
[15:43:40] --- dthaler has left
[15:51:43] --- petrescu7 has left: Replaced by new connection