Okay, I can actually see people now. And you can see me, that's usually half the problem. Okay, so I'm Margaret Kiyose, and as a lot of people know, I worked for a tier one carrier for a long time. And now I work for a vendor. So my goal is to actually go through some of it's always position of what we wanna see going forward, and then some of it's actually my personal opinion. But this talk actually was done in combination with a lot of people back in headquarters. A gentleman named Kailao, and another gentleman named Feng Hongwei. So they actually helped me create this. So that's actually, I think a talk we all feel comfortable with. Oh, how come it's not showing anything? Okay, why is it not showing anything? It worked before. You know, all I did was get out of screen mode for some reason. Okay. Okay. All right, so three areas. I wanna go through a network framework that we spend a lot of time actually back in headquarters to make sure we all agree. And we're on the same level. And then I wanna introduce the concept of identity and policy. Actually it was something that came up in a conversation with a certain vendor, another vendor. And within Huawei I wanted to sort of give you a feel for where we are. And just I think some areas, I'm actually sort of new to identity that areas of trends that are happening in the identity space that I think is that may impact the FIDO community pretty heavily if we're not watching. So this slide basically goes over, you know, it's very simple, right? I mean, people have seen this in a lot of variant ways where FIDO fits in. And FIDO's more on the data plane area, right? Over here. But there's all these other layers that interwork with it that are critical.  So, I mean, I assume, since I haven't been involved in FIDO for a while, I assume everyone realizes that a lot of these pieces all interwork together with FIDO and that you can't do FIDO in its own little world. The interface with the rest of the ecosystem is pretty critical, because in the end data plane by itself is not sufficient, right? It's necessary, but not sufficient. So all these other pieces are necessary. So it is similar like the controller was not sufficient and you needed a data plane, right? In between the two, you're further along, but even then it's not really sufficient, especially when you start getting to virtualization. So management orchestration become pretty critical, okay? But I assume this is not controversial. So this is probably the key thing from a Huawei point of view of areas that we think need to stay open, if I call it that, or standardized in some sense. And how we do it, you know, it's in one place and maybe needs to evolve. So the one thing which is one of the reasons why the FIDO community got created is to come over the common, I call it the common overlay strategy for any type of environment, whether it's a virtualization, containers, bare metal, it shouldn't matter. And that's what the ones here stand for. I'm trying to show one here, the orchestrator, the different orchestrator and the one here, quote the different hypervisors or container environments so you can support multiple applications at the same time. But the key thing is we would like to have one overlay. This might be blasphemy because we're in open stack, but I don't think if you're a real network person in the middle of all the different networking, I don't know if we wanna go down the path that neutron has gone down. And the OVS and the OVDBs, I know they're changing, but they all started out in Ethernet, right? Layer two. And on the carrier side, Ethernet was just one out of many protocols that were used. And so you have a lot of Layer three protocols or services as well as like MPLS based services and you know, things of all. And I've been in the industry for almost 40 years. Actually I think this is gonna be my 40th year in the industry. And I started out in networking with async and bi-sync. So I have seen every single flavor of protocols ever thought of and when Ethernet finally came, I said, okay, I hope we're done. We don't have to do anymore. And then of course, no, that keeps evolving. So my only point is the network industry evolves has to be flexible for whatever the new applications are. And so because of that, we need, if you use OpenStack, we're in the OpenStack conference, if you get into the OpenStack neutron space, we need an environment that's actually flexible for all the different, you know, evolutions and so forth. So I see one of the Chris's cane. I don't know if you guys saw, there's a Chris talk and there's all these Chris's. Okay, so I'm sorry, I'm diverting. So, and I only probably have like 15 minutes. Okay, so that's the first space. The second is we need a common API for the data forwarding plane. Combination of, if I'm going the wrong way, there's really two types of control planes. There's a control forwarding plane and there's like a management plane. And right now, fine, today the control forwarding plane might be BGP, but as it evolves. And then management plane, okay, could be Yang, Ma might be Honeycomb helping and so forth. But even that might, will probably evolve. But the key thing is we wanna make sure these are open so that as we innovate in the forwarding plane and evolve, right, we gotta obviously interface well with our control planes, whether it's the management forwarding plane, which is more model driven or the, did I say management forwarding? I mean management plane and then the control forwarding plane, which is more around the routing, you know, and all the stitching and so forth and setting up paths and so forth. So that's pretty critical. The third area is a common API when you start getting to applications.  And whatever applications we create, we wanna make sure there's a common interface so that the data plane can take advantage of it. So as you can tell, I'm sort of taking things apart and I'm trying to show areas where we need to have commonalities open interfaces on. And on Huawei's side, we're very serious about it because our view is we need to do a lot more mixing and matching with a lot of evolution in these little, in these little, in these different modules in their own right and then we gotta make sure everything's more plug and play. I don't know if you've been familiar with all the OP NFV and the things that got involved with that. I'm really into this modularity and this plug and play, which of course is in a bigger sense, but even at this level, we have the same thing of a plug and play and there's different functional pieces, I would call it, that are actually important and that innovation happens in its own little ecosystem, but they all have to work together to really have a holistic system that works. And that's what this is trying to show for three on these two spaces. And then, let's see, four is down on the hardware level. So we have dbdk, we have odb, we have whatever might evolve going forward. But the key thing is we want choice and have a lot of different choices of hardware. On the carrier side, we wanted choice because the vision was you could, you might be able to classify anything that, well, when I was in the AT&T, anywhere AT&T existed. And so that included a hut, a cell tower and things like that. And the vision, I mean, not to insult anyone, but the vision is that one chip vendor can actually be best and brief for all those sizes, if I call it that, is probably a little bit to Nirvana. That's another session that's tomorrow. But, and so the vision was you could have a choice of all these different chips as they evolve, as they get optimized for whatever the different environments. And we don't want to keep reinventing the environment. We don't want to keep reinventing data plane. We don't want to keep reinventing this whole thing to make this work. So that's the whole vision of the DBDKs and the ODPs of the world. So currently today, you know, you've got the DBDK that has now been included or the ARM, Lanera folks are now participating more in DBDK. But I actually talked to Bob Monk on the other day, because I've been, as people know, I've been sort of out of this area for a while. I just wanted to get a sense of where were we? In fact, I joked around that I was gone for like six months or eight months and progress has not changed as drastically as I had hoped. Because the discussion we had yesterday or last week was the same discussion I had two years ago with him. And the point is, the vision is to have DBDK to be more of the generic interface for both, for all the different chips. And in the ARM space, the ODP is still probably a little bit better. It supports things like event handlers, which I think DBDK still is challenged on for whatever reason. And the performance, my understanding is on the ODP ARM side is still better than the DBDK side that interfaces the ARM. So I think it's really critical that the industry really works, I don't know if I call it fixed, but really tries to converge and get whatever the interface we have from the floating plane down to the different chips to make sure that we really do, we can use the best and breed other chips and we don't disadvantage one set of chips for another set of chips based on the interfaces. And I get the impression it's not a technical issue, really. It's still a community issue of really trying to work it for real. And then the different biases of why certain implementations are important and why they're not. I actually, my view is, forget about complaining about this implementation is better than the other, like is event needed or not. It's like if that set of chips need an event, just do it. Get it over with and get on with life instead of arguing. So that's part of the concerns I have at times. We try to optimize a little bit too much to the point that we really do disadvantage a different section of the industry. So that still needs to get worked. But I think it's critical for us because we do not want to have, I mean not, we're already going down that path. We have a VP over DBDK, we have a VP over ODP. And I think it's sort of wasteful energy if we don't converge. But if we have technical reasons to have it separate than fine, that's reality. But it's not clear, there are technical reasons for that still. And then finally, like I said, the identity is becoming more and more of a discussion and interest that's going on in the ecosystem and the policies that support it. And so now the issue is from a vital point of view, how does that fit in? Okay, so that's actually, I don't know, how many minutes do I have? Is there a clock anywhere? When am I supposed to be done? 9.30? Okay, 15 minutes. Okay, so I just go through parts of this a little bit more in depth. So this slide shows how a data plan can be in a lot of different scenarios. And of course we'd like FIDO to be that, the data plan. And so it just shows, right? You have a VM, so you have a FIDO here, you have container, you have a FIDO here. You have multiple VMs environment, so you want data plan forwarding, so you put it here. You might even have a smartNIC, right? With its own ecosystem. You know, as we went to, I joke around, as we went to NFE space, putting everything in a Linux environment, VMs and so forth, and all of a sudden you have these smartNICs coming and saying, hey, we can be our own little world too. So now we're going back into hardware, except hopefully easier, flexible hardware. And so there, you know, you might start needing data plan here because you're pulling in certain applications actually down here. It's getting pulled from up here to down here because throughput performance has become so critical and they're finding going through the whole operating system stack and so forth is not as efficient. And that there are certain applications, I would call it, that actually, whoops, that actually need a smartNIC and in the environment that it supports. So if we have that, then we would like a phyto in here. And then of course you have devices, same thing here. Okay, so I think this is sort of self-explanatory. Right? No questions? Okay, I feel like I'm talking, just talking, okay. So the other areas, you know, user space actually is critical. We want to move more and more of the data plan out of the kernel into the user because of the goal of, you know, high IO, high throughput, low latency. And the kernel wasn't quite meant to just focus on the space. So this is going through concepts of sockets, right? And I feel like I'm going back to decades ago when I knew Unix and so forth, but POSIX APIs and the key thing here is actually trying to have a stack pull. So it's more of, you know, shared memory and so forth, the moving things back and forth versus copying, right? Anytime you copy, that's a death, kiss of death from a latency and from a throughput point of view. So if we can move more and more memories and so forth and shared memories and pointers and so forth, that's probably the more efficient way. But the goal is to have a more unified compatible socket interface. Well, like I said, get out of the kernel stack and basically put more of the SLAs that are going to be required of us more and more as the industry starts moving toward, you know, VR, AR, right, types of things. You know, we're beyond video, right? Everyone's done data, video, right? Video's quote solved, which of course is not, but I mean, it's definitely further along and the next new applications I would say that's going to focus or stress performance or have more stringent performance requirements and higher throughput is actually the VR, AR space. So that's something we need to be sure we're ready for. Okay. Model driven of course is a big thing. In fact, we actually had all these other slides about going through all the ITS and so forth, but I think it's pretty obvious. At least for me, it's pretty obvious that model driven is the way to go, is the way to go. And in certain aspects, you know, Yang modeling of course is in the networking industry is an area where the industry has, you know, centered around and so forth. The problem is just like everything, there are a lot of models. There's a lot of SDOs, open source organizations that are all over the place actually in the spacing overlapping. And so we can have actually conflicting or non-compatible Yang models. And you can see there are Yang models in all these different layers, right? You have from customer service requests there are models being created there from an orchestration point of view there's models being driven here. And of course from a networking controller down to the forwarding plane, there are definitely different models, whether they're management, telemetry, types of models. And so the key thing is we need to continue to of course encourage in all these different models having standards models, but the biggest thing is we really need to have them more coordinated. So this is my personal opinion. So, AT&T with Google started this thing called open config. And the vision actually there was actually to have a central repository for all the different Yang models, period. And to then have tools to support Yang modeling are creating some Yang. So you have like Kevin DeSous's AT&T's Yang config tool, whatever, I don't even know what they call it, IDE. I don't even know what they call it anymore. Actually it's an own app now. They put in the design and creation part, but anyhow it's also in the open config. So that was like one proposal. And then maybe from there you can do all your reconciliations and all your tools and you have it in one place. So the key thing is you don't like stop all the creation of Yang models in the different open source SDOs. The real suggestion is can we at least have one repository of it. And then so at least as you're working in one arena you start seeing the tools and take advantage of maybe the tools that another arena might have created. You might even see of course all the other different Yang models that are creating the other SDOs and capitalize on and build upon and so forth. But I don't think we're, I think the industry has pretty much adopted that modeling is the way to go for faster creation, more flexibility on different pieces, whether it's services, all the way down to configuring elements. And now the issue is can we organize a little bit more efficiently through one organization, whatever that is. Okay. All right, so identity. So I said identity is an area that Huawei is actually getting more and more into. And in fact the industry is starting to get more into. It's like the next bleeding edge. And what is identity? Basically it's the who and the what of an element. So it's not tied to a physicality really per se. I mean it can be, but it's really tied to let's say a user, maybe with a combination of something physical, the combination of the user with the physical device is the identity of that quote person. Like I am an identity market on an iPad, which is a different identity of market on a cell phone. So those are unique identities versus just market as an identity. But even though let's say you have market as an identity, there are certain types of characteristics that I might want from my network and my services that doesn't matter whether I'm an iPad or I'm on a cell phone or whatever. And then there might be more details of what I might need if I'm on a mobile phone, which is different from if I'm on an iPad and things like that. And that's different from an identifier, right? An identifier is basically, that's usually tied to a physicality, a wire. And so the two combined are necessary I think to actually go into the space. Now why is identity important? Now on a carrier point of view, it's pretty obvious why it's important. When you have network failures, major network failures, it's actually pretty critical to know what customer you've impacted. And when you get onto cellular, right? When you have failures, it's important to understand what users, which might be actual cell phone number and so forth that's impacted, especially if let's say it's the president of the United States, right? You might want to know that instantaneously, right? So it's really useful to respond to customers for fault analysis, recovery, and just even trending SLAs to provide to that customer. This is an old term that was done in AT&T proactive predictive preventative. Basically having self fault isolation and recovery. And based on a customer, you might do it differently than another customer for whatever reason. But one of the values of identity is actually all the data collection that you get. If you collect a lot of data on your networks, whether it's the data plan, the control plan, and you tie it to a specific identity, there's a lot of great analytics you can do there for revenue generation. And that's actually the main reason I think why identity is important is the monetary things you can do with it once you identify traffic or control plan types of things for a specific customer. Because you can think about it, you can generalize it. You can say things like, okay, maybe for the automotive industry. Once you know the identities relate to the automotive industry. You know, these are trends that we want to do. Or you want to do it from, I don't know, all cellular traffic and so forth.  So different markets, different platforms. Just a lot of different ways once you have the data and you've tied it to identity that you can actually analyze your heart's delight, actually, depending on what you're trying to do, okay? So where would you, if that's the vision to get into faster customer response for analysis and so forth, you know, big data analytics for revenue growth or even other analysis, you know, capacity, whatever, you know, all the life cycle of an environment. Where do you put it? So is it in a control plane? Is it in the data plane? Is it in both? And wherever it is, you know, that first framework slide I showed, that should impact FIDO, right? Especially if it's in the data plane. Then we have to work on, you know, how do you put it into the data plane? But if it's in the control plane, or it's the control plane with the data plane pieces, then all that has to get worked out. And I'm not telling you what the answer is. I'm just saying, if it needs to be in all these spaces, we just, as an organization, we just gotta make sure we have an interface that is open so that we can evolve and support and actually ride this next wave of, I would call it applications that are tied to identity. Is it centralized or is it distributed? Usually within, you know, your own domain, corporate domain, you can sometimes get away with centralization, but sometimes, of course, for scale, you need distributed, right? So it's probably gonna be a combination of both. I can't imagine it's all one or the other, even though the industry keeps trying to push one or the other, we're always finding cases where sometimes we need centralized and sometimes we need distributed. And so the same thing's gonna happen here. And then the key thing is, do you tie the ID, the identifier to the IP, or do you actually place the IP with the identifier? So there's actually a slide by the folks who are heavily into content, identifying things by content. And this is really more of their bias. And I thought it was fascinating when I saw it. So this is the progression. I mean, it starts a little bit in a world that wasn't quite captured in the industry, but you start with the open flow, you have IPSDN types of concepts. Then the next thing you start getting to virtualization, so you now have SDN and NFE together. And then now you start getting to identity, which is now trying to map the identity to content, right? And then the identity to IP. So you're now trying to get the network to be closely more tied to content. Well, there's a movement, whether it's successful is a different issue, is replacing IP and actually just replace it with these identifiers, which are tied to content. So I think a drastic that is, can you imagine if IP goes away and you really replace it with an identity instead? I mean, think about it. Our equipment has to change. So it's like a fascinating, I actually like this. I can see how IP can be dated and this is the way to go. Because I think when we started having our cell phones and all these different apps, it changed the network industry pretty drastically that people more and more relate to specific apps and relate to themselves and so forth. And so now the question is, is IP dated? And is content actually the better way of really looking at the world? And then the question is, do you go down, even down to the router and switch layer, instead of doing IP address and you do it based on content? And what does that really mean to what we do here? So I think it's a fascinating area and I'm hoping this organization is more open to the discussion. You know, I'm gonna make another snide remark because I've been around so long, but when SDN NFE started, I was in the MEF, I was involved in the MEF, and I got a lot of grief, a lot of grief about this was a bunch of crap. And I mean, the whole organization was in an uproar. Just went into the uproar and I kept arguing. I said, guys, you guys are thinking about today and the issue is you have to look at the future and sort of ignore reality and think of the future potential of why this is important and what it's trying to solve. I mean, whether the details of whatever's happening today, because at that time it's open-floor, right? Whether that's a valid or not, that's not the point.  And then look at where we are now, right? I mean, I got so much grief that I actually moved out of the MEF because this is the area I wanted to go into, the SDN NFE world and of course the rest is history and where we are now. And I actually think this is another area that's like that. It's another pivotal moment that can actually, that can actually influence the industry pretty tremendously. Now the issue is how do you do it? So in Huawei, there's definitely a faction that's more focused on mapping the identity to the IP address. So there's this whole thing called ideas. They proposed it or we proposed it with some other companies. I don't know if we've listed all the companies here, but you can go to the ITF. And you know, in Chicago, a few months ago, this was proposed and we want to form, I guess it's called a working group under ITF or whatever, to basically try to start fleshing the ideas out, fleshing how do you get content tied to the IP world? And then of course, provide the different types of services necessary when you get into content areas. So I know at a simple level as a former carrier, I can actually appreciate the value of content and the identity, the whole value of it, better than even the IP stack. Now the issue is how do you do it?  I don't know what the answer is on that, but I just think it's an area that we really should look at more and more. Okay, and then policy, what do you mean by policy? I mean, a lot of people know what policy is, right? Set of conditions, which basically allow you to designate who is authorized to access certain resources. You know, what are the circumstances in which they can use those resources and you know, how can they use those resources? So this is basically a contract, right? Between the end user and the provider of a service is how I view policy. And then it shows here it could cover everything, you know, performance, usage, availability, cost, security, and so forth. But once you get into identity, policy becomes even more critical, right? Because you have different policies, like I was saying before, you might have policy for market in general for all the different equipment she's on and then you might have a more specific policy for the cell phone versus the policy for the iPad versus the policy for the television or the policy for even market in a car, right? So just think about how I can imagine myself going from, you know, there's me and then I'm in a car. So there's that type of networking that I might require versus all these other elements. And so you can actually then tie that all together. And then again, we're all of the, again, just like everything, right? We have policy being worked everywhere. So again, we have the challenge of trying to get everything converged. So we just got to make sure as we get into identity, right? The identity and the policy parts work together and we have to make sure in the final path that we have a more standard way of interfacing externally or externally in the final space. And then finally, my community one, let's work together. So basically on these five points I showed in the very first set of slides, common overlay, common API to the VPP for management control, forwarding planes, creating a common application interface for as we evolve to identity and policies, common API. So if we can get DPTK and ODP to converge better but to also still be able to support the diverse set of virtualized environments versus different chips, the NICS, the NPUs, the FPGA and of course work on applications like identity and policy, which I think is the next wave. And that's it. Okay, thank you. I guess no time for questions. Thank you, Margaret. I think we can take a question or two. Oh. Hi, Margaret, nice to see you here. So what do you summarize as content metadata driven policy enforcement on top of traffic flows, right? Through FDIO. If you, recently, not recently, but still recently, AT&T published the network 3.0 in Digo inside which implicitly referring this topology. So I don't remember, I don't represent AT&T, but okay. I know you're not, but that's the thing, right? NFE SDN driven by domain 2.0 and now we are going network 3.0 AT&T is kind of a little bit driving. Well the network 3.0, if I understand it correctly, is going after data analytics, right? Other metadata and so forth. Secure access to data through multi-party with the federation, which is pretty much implying this requirement and implementation of what you have presented to us in my humble opinion. Oh, okay, wow. Well, I mean, I always thought that the whole reason for all this stuff, SDN, NFE, even fight on self-worth is in the end, you wanna collect data. I mean, networking people have always had to collect data for survival, right? The network goes down, you have to know what to, you have to know where, who it's impacting and where it is and how to recover. So data, big data, data people have been doing forever. They didn't just call it, they didn't call it big data. And then this whole AI and data analytics come out. I mean, network people have had to do that. Or at least the carers had to do it because they had to survive. You had to keep everything up and running. So now we have the big buzzwords. Okay, fine, great. My only, I mean, maybe it looks so similar, but in the end, that's because in the end, this has always been the name of the game, right?  The heavy lifting is actually collecting the data, sorting the data, analyzing the data and figuring out what to do with that data and automating it because you can't get enough people to keep up with all the crap that happens when the network goes down and all the people that get impacted. So yeah, so if you look at H&T's, you know, domain two, domain three, or network three, whatever. So yeah, it's going to the networking, I mean, the data analytics, because in the end, that it was the end game, no matter what. It's just now a big buzzword now because the Googles and so forth of the world made it such a big deal. But actually the networking people have been doing it forever. So this is just trying to say content is becoming more and more critical because it's getting so intertwined to networking, right? It's not this separate stack. It's very much for the network to be responsive to it. And because things are so dynamic, you're being forced to it more and more. And so why? Do you want to call that three dot, oh, I don't know. I just can see that that's the next area to get into. Okay? All right, great. Thanks. I'm sure I don't fall off my chair.


Hey everybody, Dr. O here. In this video I want to talk about Griffith's experiment from a man named Frederick Griffith, I believe he was British. So this would have been done in 1928, but actually he had been working for at least a decade to try to understand bacterial pneumonia, specifically the microorganism streptococcus pneumonia. And this ties back into the Spanish flu pandemic of 1918 that killed 30 to 50 million human beings, 600,000 Americans in one flu season. So they understood that many of the people that died from that flu actually weren't dying from the flu virus. They were dying from secondary bacterial infections like this organism here. So that's why he spent a decade working on this. But so obviously that's important. And there's never been a flu pandemic like that since the advent of antibiotics. So that's that's great. But this is also super important because it was the first evidence we have of a type of horizontal gene transfer called bacterial transformation that we'll get into. And also this, this is what pointed us down the path that led us to understanding what DNA was and understanding how DNA works as hereditary materials. So very powerful experiment. This just as important in genetics as it is here in microbiology. But let's go ahead and jump in. So first you'll see a couple of terms here, rough strains and heat, smooth strains, sorry. What we're looking at here is what he would have called the rough strain would be a non-pathogenic non-virulent strain of streptococcus pneumonia that didn't have a capsule around it. The smooth strain was a virulent, very deadly strain of streptococcus pneumonia that had a capsule around it. So hopefully you remember from a few chapters back that the capsule helps an organism evade phagocytosis. So the encapsulated forms of this bacteria, streptococcus pneumonia, still kill 1.4 to 1.5 million human beings a year. So this is a very serious deal. So he was testing the two different strains. Let's go from the left all the way down the line and then we'll see what was actually happening versus what he thought was happening or at least what was in play. So first we have just the control.  So that's no shock there. Experiment number one, if you take the deadly pathogenic strain of streptococcus pneumonia that does have a capsule and you kill it with heat and then give it to this mouse, it also lives. What you really did here is you gave it a vaccine, right? Heat killed organisms are one type of vaccination. So this organism has now been exposed to this, this mouse has been exposed to this organism has developed immunity against it. So really experiment one is an example of a vaccine.  So this is just shocking, right? Because, but the key here is what actually came out of this dead mouse was living encapsulated pathogenic strains of this organism and that's really what's important here.  So what actually happened here was, so he knew that something, some sort of material was transferred from the dead organism to the living organism. So what really did happen here is an example of bacterial transformation. So transformation is when an organism that's capable of this, not all are, some are between 40 and 80 species of organisms probably are, they're able to take up what's called naked DNA from their environment. So let me go ahead and show you a quick image here. So that, what is that, fuchsia, a circle at the top would be just a piece of naked DNA. So as that heat killed, pathogenic strain of streptococcus pneumonia died and fell apart, chunks of its DNA were swimming in the environment, swimming in that syringe. And the cell here would be a living non-pathogenic strain of streptococcus pneumonia, but it took up that DNA, added it to its own genome and then used it. So this, so the purplish organism here was able to pick up the ability to grow a capsule and it happened inside that mouse, that organism became a pathogen and then killed that mouse. They were able to extract it or take it from that dead mouse from experiment two and transfer it into another mouse. And as you can see here, we now have living encapsulated pathogenic strains of streptococcus pneumonia. So huge deal. This was in the late 1920s. They didn't know what DNA was. They didn't know how this material was being transferred, but very, very important. So we'll cover bacterial transformation in a separate video, but that's why Frederick Griffith and his experiments were so important. All right. You have a wonderful day. Be blessed.


What is DAV's POW-MIA Committee? And what do you do? Well, we, as the committee, we try to stay on top of current events within the POW-MIA issue. And when important things arise that may need action, we would report that to our national leadership. And we also, being a veteran service organization, we work hand in hand with the DPAA. And what that is is the Defense Department's POW-MIA Accounting Agency. And we have a seat at their table. They have quarterly teleconferences and family events and updates. And we're staying on top of all of that. And again, when necessary, our committee can write a resolution to be brought before the body. If it's, of course, something important that pertains to the POW-MIA issue. Our organization has passed resolutions that we are to support the DPAA and the Secretary of Defense in their endeavor to complete the fullest possible accounting of our missing. And so we're the responsible party for the DAV to accomplish those things. Totally understand. But that's great that we have this, by the way. And it seems to me that the US stands alone in its willingness and ability to track down our soldiers, sailors, airmen, and Marines who are still missing off the battlefield. But how does the Defense POW-MIA Accounting Agency, or DPAA, how do they do it exactly? Well, the DPAA, they have investigation teams, research teams. We have partners all over the world. And we send, sometimes they join us in a joint field activity and in our recoveries. And we have, we still have use eyewitnesses that were in the field, perhaps when, if there was a plane crash or a plane went down and eyewitnesses that were there to see it, then we use, we have all the historical data that is necessary to go to the people that know where we can get the correct information. That sounds like a very scientific process. And not only scientific, you're also talking about historical. With the science part, there are two laboratories in the United States that support this mission. Is that correct? That's correct. We have our main lab is in Pearl Harbor, a Hickam Air Force Base. And we have another lab at Offit Air Force Base in Nebraska. And thanks to the DAV, I was able to tour the Pearl Harbor lab. I had a tour guides of Johnny Webb and the director of the DPA, Fern Sumter Windbush. And while I was there, I had a great tour. I had the, I saw the tables after tables of remains in various stages of identification. And I was also able to meet with a couple forensic anthropologists and they answered all my questions I had at the time. And a very impressive operation, what they're doing. Sounds like a very interesting moment that not a lot of Americans get the opportunity to do. How successful has the US been this year with trying to track down and identify the remains of our fallen troops? Well, last year of the 2019, they had their greatest year ever. They had, they were able to identify 217 remains. Now this year with the COVID-19, unfortunately, they've only accomplished 94 remains so far this year. 62 of those were from World War II, 31 from Korea, the Korean War and one from the Vietnam War. And unfortunately, they only have about two and a half months left remaining in this year to get their numbers up. But the way things are looking is there isn't gonna be too much more activity. In March of this past year, if we go into the, how has COVID affected the DPA's operation? In operation, in March of this year, when everything hit, they postponed or canceled all joint field operations. They brought all of their teams home. Thankfully, they're all home and safe. And no DPA employee has come up with the tested positive for the COVID. So whatever they're doing, they're doing it the right way. But unfortunately, they're only gonna have 94 identifications up to this point this year. Well, I'm certain glad that they're staying safe, but it must be very disappointing for these families who are still waiting for their loved ones to come home to hear that operations are kind of slowed down in the age of the COVID-19 pandemic. Now, I understand the DPA goes through great lengths to make proper identifications and to make families whole to give them information about their loved one. But wasn't there recently a misidentification? Yes, they use all kinds of scientific means to make a positive identification. And believe me, they are very positive when they make an identification. But unfortunately, they found out this past year that there was a Korean soldier that was misidentified and sent home to his family. And as soon as the DPA realized that a mistaken ID had happened, they immediately contacted the Army Casualty Office. They contacted the family. They started an internal assessment of their processes and how could this happen? And they've taken corrective actions and they've even brought in a separate team of experts to look at their study, their procedures and see how this could have happened to make sure it doesn't happen again. But I'm sure that like I said, they go to extremes. They use all kinds of DNA, forensic DNA. They use a next generation DNA, all any different type of science tests that they can do. They're pretty thorough in what they're doing. They had to use a next generation because we found out that for example, North Korea, when they were getting, they were storing their remains of American soldiers and they were coding them with formaldehyde and other preservatives and that affected the actual, our ability to get out the DNA. And so this next generation, they've overcome that problem and that's why they use any type of multiple analysis, scientific analysis, they use it all. So this next generation is a way of kind of counteracting this formaldehyde and other preservatives. Yeah, it overcame all what they were doing, yes. That's great, that's great. So it sounds like we're talking about a lot of forensic work and the DPAA definitely employs forensic anthropologists. And I understand one this year was awarded a very prestigious award. Yes, one of our forensic scientists, Dr. Gregory Berg at the lab in Hawaii has been recognized for his outstanding work in using isotopes and he received a very prestigious award last year, this past year. Well, that's great to hear. Well again, Vincent D'Arcangelo, the chairman of DAV's POW-MIA committee, I think you shared some really great information that means quite a lot to a lot of veterans out there. So thanks for being with me today. Can I say one more thing, Matthew? Sure, yes, of course. A lot of, we still have perhaps 80,000 missing men and women from our past wars, World War II, Korea, Vietnam, Cold War. We know that about half of those were lost over water and there's very little chance of us ever recovering them. However, we do believe about 39,000 of our missing are possible to be recovered and identified. And so that again, that's a lot of work on the DPA's soldiers. It's their job to recover them, identify them and bring them home. I still wear my POW-MIA bracelets and I wear POW-MIA pins and paraphernalia. Every year the DPAA releases a brand new poster, which are available for anybody to order and get from the Department of Defense. All of those things are good, they're crucial.  And, but it's also sending a message to future soldiers that may join the military, that if something should happen to them and they become a prisoner of war, we want them to know that they are not going to be forgotten about. We're gonna, this country does everything it can to bring them home. Absolutely, I remember when I served in the Army and I was in Iraq, I knew if things would go bad that my government would move heaven and earth to try to bring me home. So you're right, it is a great message we send to not only our current service members and our veterans, but also our would-be service members who are thinking about joining today. Vincent, again, is a great way to get involved by getting his bracelets and other pins. Great way of bringing the message out there. Thank you so much and folks, thanks for tuning in. Thank you, Matthew.


My name is Sergeant First Class Carriaga, I'm with the 158 Bravo Company, I'm the second platoon sergeant. We are here in Florence, Arizona, the automatic rifle fire range, so the qualification will take place, the new Army qualification, 40 rounds from different positions and you must shoot at least 23 to qualify. It's fairly basic, it is more involved, this whole entire qualification course from start to finish, six tables is more involved than the old way. So this is more combat focused, the positions and the transitions are on the soldier, the tower doesn't call a switch from one position to the other, it's all on him, he needs to react to the targets as they pop up, from the prone unsupported to the prone supported to the kneeling, on a barricade to standing on a barricade, it's all on him.  It's more realistic, it applies more to real shooting than just a canned qualification course. Readiness for an infantryman is being able to hit a target, so the qualification just verifies that every individual is ready, it's part of a job, you need to be able to engage them. Strong sense of patriotism started out when I saw my fellow soldiers in Somalia get back in 93, for me personally, that's what got me to join the army, got to do a lot of good things in the range of Italian, got out and came back into the National Guard to continue to serve while doing my job as a citizen.


Well, thank you very much for the invitation and good day. Good evening. I know we're all over time zone-wise here. And what I've been working on for some time, and this is joint work with Shreem Krishnamurthy, who's also at Brown, is thinking about how we rethink introductory computer science to better support learning data science. And there's several reasons why I think we should do this, which we'll go over here. So for starters, it's worth thinking about the pressures that are on the computing curriculum within the university context. So first of all, you have the rise of data science. There are many programs and students who want to be learning about data science, and we have to figure out how that fits in the computing curriculum. There are questions about the societal impacts of algorithmic decision-making and what we should be teaching about that. There are concerns about diversity in tech and the tech workforce. And with the strong tech economy, you're bringing many more students from many more backgrounds into our computing courses. So all of these pressures are building up on intro computer science classes. So it raises a question about how we can redesign our introductory courses to support data science, while also thinking about some of these diversity and social impacts issues, which at least in the United States are generating a lot of discussion with regards to curricula. And the proposal that I'm gonna put forth in this talk is we should centralize data in a way that leads us into data structures. And this is going to let us combine some data science work with some conventional computer science work. Where am I coming from with this? So my technical job title is I am a research professor of computer science. I'm also the associate director of the undergraduate program in computer science at my university. So I see this from all sides. I see this as a researcher who studies computing education as a person who lectures large introductory courses in computer science and from an administrator position trying to manage a large undergraduate program. I've been teaching first year computing for 25 years and for the last 10 years my primary research has been in computing education, looking at the intersection of languages and pedagogy and tooling and things like that. I am a functional programmer at heart and at core. I can play other kinds of programmers on TV when necessary but really I tend to think from a functional programming perspective. So if we think about different ways that different linguistic communities approach intro computer science, let's look at what they do and how well they might accommodate data. So if you generally are teaching intro computing from an imperative programming perspective you go heavy on conditionals and loops and assignment statements with some arrays and lists and that's how you get started. If you start with objects well then you're getting into starting with classes and objects then getting into conditionals loops and if you take an algorithmic focus now you go into some of the classic algorithms and sorting maybe some of the basic graph algorithms. Another model which is starting more functionally is where you're emphasizing functions, lists, recursion, higher order functions and these form the early foundation of your computing curriculum. In my case in particular I mostly have taught with the how to design programs curriculum which is based in racket. So that's kind of where some of my thinking on the role of functional programming and education is coming from. And if we step back and ask ourselves how these three approaches might accommodate data or think about data. Well an imperative intro is really designed to emphasize control, not data. The object oriented perspective tends to put data structures before data. And the functional intro ends up emphasizing traversing data structures but not necessarily thinking about data in the data science sense of it. So the question I wanna ask is what if a two dimensional table were the first data structure that we showed students? So here's a sample, small two dimensional table drawn from one of my own lectures. And what you can think about in looking at this table and why this might be an interesting place to start it's rich structured data but it's in a non-threatening format. So I think a lot about how to offer introductory computing education to students who do not have prior experience in programming who maybe are not even majoring in computer science. They might be studying social sciences or something else but they still need to learn about data and computing because of the way this is under learning all of their different career options. You can come up with many authentic tasks when you work with a two dimensional table. And if you want to be raising some of these issues about the impacts of technology they can come up rather naturally. I'll give some examples as we go. And if you have questions like how many tickets got sold with a student discount you're letting students explore problem decomposition which is something we often teach early on in programming but it's in a very concrete format. Students can imagine taking the tables apart or scratching out on them or drawing on them. I've seen students do this in ways that I have not seen them do when we try to work with general data structures like lists. You also can give students something of a process that they can understand for preparing data to work with. We normalize, we look for suspicious data we use visualization, we analyze. It's another good format to expose students to the idea that software development and coding proceed with processes and not just something that we kind of do because we really were good at it necessarily but there are steps that they can follow. In the context of data science I'll point out that this is as much data engineering as it is data science. Notice I haven't really talked much about statistics and regressions and what kinds of analysis methods you use as much as how you think about managing, maintaining your data as a precursor to doing that kind of statistical analysis. And I think this data engineering perspective is really important if we're going to try to bring computer science faculty into embracing data more from the way we start teaching our courses. Now anytime I give this variant of this presentation and I say we should start with tables people invariably say, well, what's the best language for working with tables? And we're back arguing about what programming language to start with when teaching interest students are in Python get a lot of the airtime Julia comes up and as a computing education person what I wanna say is just stop. This isn't how we design curricula. You don't design curricula by picking a language. You design a curricula by laying out what you're trying to teach first. So I wanna start there that if we're thinking about a narrative for introducing students to computing and programming that embraces data what does that narrative look like and what topics does that suggest? So what I'm describing here is a vision that we've been calling data-centric intro to computing. So very much computer science, but with data at its core. In my experience, it helps to start by helping students realize that both information and code have structure. It's not obvious to a student who's never programmed before that a program is not a sequence of characters but rather a structure of functions and expressions and computation. We want students to understand that the role of computation is to transform or summarize data or in the case of tables, data sets. Sometimes we aggregate information across data points. Lists are a natural vehicle for bringing up that notion of aggregation across data points. The fact that your data set attributes might themselves have structure leads you to an introduction of data types. Understanding that data points might have relationships among themselves and not necessarily be independent is a natural segue to talking about trees. Sometimes programs actually end up needing to update their data sets. And this is where things like state and assignment can come into the story. And then when your programs start getting more sophisticated, you have to start thinking more about the efficiency of working with associative data. And this is a good reason to bring in dictionaries or hash tables. So what you see on the screen here is the topic sequence that I use in my data-centric intro course starting very heavily functional. We're functional all the way up until the state portion of it, but tables come much earlier than in a typical functional programming curriculum. Woven throughout this, we try to always draw students back to the data. Every topic we do is motivated by something a student might want to do with a data set. And this motivation is important for working with students who do not see themselves as computing students, but instead students who are trying to prepare in data. There's many points in this curriculum when I can bring up issues about social impacts of computing. We bring up planning, composing plans, decomposing problems from the very start with tables. Notional machines is the term that programming, sorry, that computing education researchers use for semantics. I spend a lot of time teaching through semantics and models of program execution and evolution. In my classes, because I want students to start to understand how languages work. And that again is something we can concretely visualize at the level of tables and repeatedly bring up as we go through this curriculum. So I just wanna give you a couple of more concrete examples about what I mean by some of these orange boxes and what we're trying to teach. When I talk about students appreciating the structure of data and the structure of code, I first teach them how to construct images like flags. Because if we're constructing flags of the world, we're seeing small pits of images like three stripes here. And we see how the image has a structure of stacking and the code has a structure of nesting. We do a lot in the beginning trying to appreciate this relationship between structure of data and structure of code. And this will translate very nicely into tables and some of the other things we're trying to do. When we get to tables, we are going to pull the tables into a programming language either by writing small tables manually or importing them from CSV or a Google Drive. And we learn how to write functions and make small programs that do things like compute new columns on tables, which is what I'm showing at the bottom of this slide here. So a simple lambda-like function gets used to extend this table with a new column. In this table context, I can talk about normalizing data and that's a process of filtering or searching for values that we don't understand, mapping, transforming data in the process of normalization. We can talk about checking whether all the values are expected as part of just confirming that our data makes sense before we process it. We can capture filters of the table to focus on different subsets of our data. All of these operations that we like to teach as higher order functions say on lists extend very naturally into tables and they make sense to students because it's a context that they can envision working in in whatever domain they're coming from. We also get into discussions about how to represent data. One of my favorite lectures is I ask students how we should capture timestamps. Do we use multiple columns for hours and minutes? Do we make them strings? Do we use big numbers? And this gets us to talking about issues like data schemas for time and for names which get into issues of internationalization and having students think about who they are designing software for. This is an example of social impact kind of thinking that I try to bring across. There's a series of articles that I like a lot. Falsehood programmers believe about these long lists that have been compiled by professional programmers of mistakes people make in trying to represent things like names and dates. It's instructive and natural for students who are looking at early stages of data. You can also bring in many practical questions that show data design trade-offs. We look at how to store lists in a CSV file, how to extract lists from a CSV file. A lot of programs of the kind of scale and heft that we might normally do in an intro programming class can come up very naturally within this focus on tables. So now I've given you some examples of what I wanna be able to do. Now we can come back to the question, what language should I be doing this in? And more often than not, people will say we have to do this in Python. Why? Well, because it's the place that students need to end up with if they're gonna do anything practical. And yes, I agree that ending the students someplace practical makes sense. In fact, the course that I teach at the very end comes back to tables and we show them pandas. So Python's a great place to end up for giving students something concrete that they can look on Stack Overflow or get online help with. It works very nicely. But do we have to start there? And that's again, where my pedagogy comes on. We are functionally inclined programmers, assuming if you're at closure. And functional programming underlies tools for processing tabular data, for doing data science work. Hadley Wickham is the developer of RStudio. He writes a lot about teaching and learning data science and the importance of functional programming. So in the curricula that I work on, we start functionally. And we're starting with a language called Pirate that we have developed in-house at Brown University. It has built in support for images and tables like I showed you on those couple of slides. It has a Python-esque syntax. The PY in Pirate is not accidental. We lifted some things from Pirate. We did drop the white space having semantics. That's not very friendly to new programmers. But the other notational forms look rather similar, but it's a functional language with proper data types. It builds testing into function definition. So we really enhance for students this idea of testing and writing illustrative examples as part of how they write functions, habits that we think we should be building from very early on. One of the fun things about Pirate is it's backed by a lot of research that's going on in our Computing Education Research Group at Brown. So we have looked at building techniques like having students check whether their test cases, their test suites are thorough and accurate before they write programs. This is the kind of tool that we can easily build into a research environment. We have studied how to make students write good tests, how to learn how to organize data and how tool support can help in getting them to that point. We've been studying higher order functions and how students learn to use them and learn to develop them. All of this work in Pirate is driven by education research for computer science. And that's something that can't really be said for the developments of things like Python and R. They have good places that they came from. I'm not at all knocking those. But my perspective is I'm trying to introduce people to thinking about programming and data. So I want education to really be driving how I do this. So when we're doing this course, we do the first two months of it functionally in Pirate. We're learning how to write abstract data types. We're learning how to process these data types with recursion and functional programming from a strongly data-driven perspective. At the point that I'm ready to introduce state and updating data, we take that as our opportunity to switch to Python. And there we do state hash tables and wrap it back around to pandas, showing them that all the things they did in Pirate at the beginning, we can also bring over to Python at the end. And then there's follow-on courses that get into things like objects and data structures and algorithms and other more advanced topics. This is the first in a multi-course sequence that we're teaching. So to kind of pull this together, what's the problem I think we're trying to deal with here? At least in the United States, we're seeing a lot of schools developing data science programs. And the data science programs are starting with intro statistics, maybe a little bit of data scripting, they do more statistics, big data, and eventually they get to the point of wanting to do data management. A computer science major is organized differently. We start with intro programming, we get into data structures and then we go into more advanced classes like databases, data science and machine learning. And what we often see are students who see that little bit of scripting, say in their second or third course in data science and say, oh, I like programming, I wanna be a CS major. Or we see CS students who get up to the upper level data science class and say, I'm really not into developing software but I really like this focus on data. The student gets to data management on the data science side and now they say, well, I need databases because I think I wanna do more data engineering. And what we have effectively done here is set up a system where it's extremely hard for students to switch. There's so little content alignment from a conventional CS approach and a conventional data science approach that students effectively have to start over to switch. And that's unfortunate, especially when we see that there is a way to start these things commonly with tables and higher order functions as our early programming examples and then let students do a second course in whichever of data science, computer science, computer engineering most fits what they're trying to do. Novice students don't understand these fields well enough to decide which one they want or what they all mean. We really have to think about pedagogy that's gonna help them figure out those interests as they go. So to put this in perspective, I think we have three different subfields or job titles in some sense that we see competing for mind share in early computing education. Data engineering is overlooked frequently even though it's a really important component of being actually able to write scripts that are maintainable in a data science context. Data science is exciting because students across campus are interested in it. Data engineering needs non-trivial computer science. So it needs a foundation to build on that it won't get if we do a statistics based data science alone. Every computer science student these days needs some grounding in data and statistics given the way data is part of everything we do. And we've got these increasing calls for social responsibility at least being raised to students. The sweet spot is the intersection of these three pieces start in the sweet spot and then branch out. And this is what we have been working on. If you're interested in seeing this laid out more as an argument, we have a paper that we wrote in communications of the ACM on this model of data-centric computing. It's really the article version of this talk. We have a textbook that we have been writing called the Data-Centric Conduction to Computing. It's available online. The first version is out. The second version will come out sometime over the winter break when I make revisions after this semester. I've also put the URL there for the course that I'm teaching out of all of this. So thank you very much. I'm happy to take questions on the curricular design or things we know about learning programming through these different venues. But thank you very much.


The topic of my presentation is MRI evaluation of spectrum of transverse myelitis. Introduction transverse myelitis is a acute inflammatory disease of spinal cord characterized by rapid onset of bilateral neurological symptoms. The symptoms can be motor in the form of symmetric or asymmetric upper or lower limb weakness depending upon the level of cord involvement, sensory disturbances in the form of hypoesthesia, spenesthesia, or allodynia, autonomic dysfunction, involving bowel, bladder, or sexual dysfunction. Symptoms evolve over hours or days, maximum clinical severity within 10 days of onset. Even though clinical features are helpful to orient the diagnostic suspicions, for example timing and severity of myelopathy symptoms, the differential diagnosis of inflammatory myelopathies is often challenging due to overlapping features. Moreover, non-inflammatory etiologies can sometimes mimic an inflammatory process in this setting. Magnetic resonance imaging that is MRI is becoming a fundamental tool for the characterization of spinal cord damage. Causes of transverse myelitis are diverse, broadly classified as etiopathic, which is a diagnosis of exclusion, and those which are attributable to underlying disease process. Transverse myelitis can be longitudinally extensive, involving more than three segments and all or most of the cross-section of the cord, or it can be short segment cord involvement, which has less than two segments of eccentric or asymmetric cord involvement. Inflammatory myelopathies can be recognized in numerous immune-mediated disorders, including multiple sclerosis, apropylene-4, IgG-positive, and MO spectrum disorder, and myelin oligodendrocyte glycoprotein, antibody-associated disease. Based on underlying pathophysiology, inflammatory myelopathies can be classified into cell-mediated autoimmune disorders that are confined to CNS, for example MS, or associated with specific antibodies primarily targeting CNS antigens, or associated with systemic autoimmune disorders having secondary CNS involvement. For example, in SLE, chockdown syndrome, and sarcoidosis. The characterization of spinal cord lesions in terms of longitudinal extension, location of axial plane, involvement of white matter, and or gray matter, specific patterns of contrast enhancement, often allows proper differentiation of these diseases. Besides imaging, paraclinical testing helps in diagnostic framing of these disorders. For example, the presence of oligolucleinol bands in CSF, and typical brain lesions involving periventricular or just acortical areas, suggest multiple sclerosis as the most likely disease cause. While autoindie bodies targeting apropylene-4 and MOG are the most frequent causes of antibody-associated transverse myelitis. AIM and methodology. AIM of study is MRI evaluation of spectrum of transverse myelitis. Methodology of the study was conducted in department of radio diagnosis, common medical college. The study included 30 patients suspected of transverse myelitis fulfilling the inclusion criteria. The standard of our protocols, that is, sahaj and axial T1, T2 images, followed by both contrast T1 images. Diffusion weighted abs sequences were taken wherever required. Inclusion criteria, those patients who were suspected of transverse myelitis based on symptoms. Such as acute or subacute onset of motor, sensory or autonomic dysfunction involving spanning cord. Patients, those who were referred for MRI evaluation as suspected transverse myelitis. Exclusion criteria, those patients were excluded who had an altered native diagnosis of cord pathology at the time of presentation. For example, traumatic cord injury, and patients who had passes of hypersensitivity to have a contrast. This is the case of 54-year-old woman with weakness in bilateral lower limbs with associated minimally retention. See, MRI numbers spying. D2 sahaj image shows mild expansion of conus with altered signal intensity in distal cord and conus. On post contrast imaging, there is thin smooth peripheral enhancement of the cord. This is another case of a 40-year-old woman presenting with sudden onset of weakness of bilateral upper and lower limbs. On T2 sahaj images, there is long segment hyperimdensity and on axial images, there is more than two-third construction of cord in movement. This is sahaj in axial post contrast image of the same patient showing faint patchy peripheral enhancement. This is MRI of a 14-year-old patient presenting with history of fever followed by all four limb weakness. Third images show long segment linear hyperimdensity involving lower cervical upper dorsal cord. On axial T2 images, central involvement of cord is noted with characteristic edge sign of grave involvement. Results of 50 patients in our study, 21 had transverse malitis as the cause for these symptoms. But as nine patients had other causes like spying cord infarction, nutritional deficiencies in the form of B2L and copper deficiencies, foundiotic myelopathies, spinal dural edu fistula and spinal metastasis. Out of 21 patients who had transverse malitis as the cause for their symptoms, 13 were females and 8 were males. 9 out of 21 patients presented with acute onset motor and sensory symptoms both. 5 patients presented with bilateral upper limb weakness only. 3 patients presented with bilateral lower limb weakness only. 2 patients presented with bowel and bladder involvement and 2 patients presented with all of these symptoms. Out of 21 patients, 10 patients were diagnosed with multiple sclerosis. That is about 47% of the total patients. 6 patients were found positive for aproposin-4 antibody disease and 4 patients were found positive for malif, oligodendrocyte, therapeutic protein, antibody. 1 patient was diagnosed with saccharinopathy. Most common MRA finding was altered cord signal intensity that is T2-stir hyper intense cord signal that was found in all the 21 patients with associated cord expansion in 14 and cord enhancement on post-contrast images in the rest 15 patients. On X-ray T2 images, most common location of the legion was peripheral that is in 11 patients forming 52 posterior patients followed by central gray and white meta-involvement in 6 and only central gray meta-involvement in the rest 4 patients. The short segment cord involvement was found in around 11 patients with the rest 10 showing long segment cord involvement, cervical dorsal spine being the most commonly involved part of spine followed by whole spinal cord involvement in only dorsal cord involvement in 4 patients while involvement of conus was found in 3 patients. For discussion, most common cause of transverse myelitis in our study was found out to be multiple sclerosis forming about 47.6% of the patients followed by neuro myelitis optical spectrum disorder and malin oligodendrocyte glycoprotein antibody disease. Most common symptom was acute onset motor and sensory weakness combined in about 42% patients followed by volatile lower limb weakness. Most common MRA finding was T2 hyper intense signal intensity of the cord followed by cord enhancement. These were my references. Thank you.


Good morning folks. This is Steve Rhodes coming to you live from the shores of sunny Delray Beach, Florida. This is your 11 a.m. update and currently have all the U.S. entities trading to the downside. You've got the U.S. Dow. The Dow Jones is off 670 points, about 2%. The lower 2% for the S&P are 86 points, nearly 3% for the Nasdaq 100, 322. The Russell's off about 2% at 35 points to the downside. Gold's off 30 bucks. Silver is down 73 cents. Light's recruiters off 75 pennies. Natural gas is up a nickel and a 30-year treasury up one point. Trade out $13204. If we go take a look at our nine-panel market update chart, we begin. We take a look at the ESMini. What we can see at the moment, this price is trading below the bottom of its daily profile as well as very close to the bottom of its consolidation. I would say the consolidation would definitely be broken with a close below $39.4550 or $39.40 right now. Now, what that would do, we'll take a look at that, during the Treader's Ed Show is set up a measured move, a consolidation breakdown measured move. Now, the interesting thing about suggesting that we're going to at least make a measured move to the downside is the fact the spot follow till the X is still well below the 50-day X-panel's moving average. So we've got a divergence here. I'm not sure how to deal with it. $23.98 is the 50-day X-panel's moving average. The NQ, trading below the bottom of its daily profile. And as well, I would say a close here below $11.535.50 would go ahead and create a consolidation breakdown as well. Now, the U.S. Dollar Index, you don't see it on this chart, but there's a road to indicator signal. You can certainly visualize the A to B equal CD pattern. We most certainly at this stage at 11.01 in the morning, we've got a bullish engulfing candle. We've got a key reversal candle. Now, prices dealing with here is resistance, which is the bottom of the profile. So, price is able to close above $104.23. We likely have a signal from the dollar of a bottom. Well, that should continue to put pressure on the U.S. equities. It should put pressure on gold and silver. Gold's trading lower. It's trading back with inside its daily profile. Its next outside target of a close below $17.7560 would be in the $17.34 to $17.56 range. Silver's got a new profile. It's attempting to form its level of support from a daily perspective of $22.63, likely accrued. Even though we've got an A to B equal CD pattern drawn in here, price is trading above the top of its daily profile. Even though it's pulling back, that's still a bullish message. Hey, folks, stay tuned for the Trader's Edge show. But if you have to start during Thursday, please have a terrific one. I will look forward to seeing you again soon. Take care.