Rakesh, I agree with you that we can give feedback during WGLC. Once you address the comments from Christian, you can submit the revision and then ask our I2NSF WG chairs, Linda and Adrian, to start the WGLC for our draft.
Thanks. Paul On Wed, Dec 7, 2016 at 6:32 AM, Rakesh Kumar <[email protected]> wrote: > Hi Sue and all, > > > > Linda wanted to proceed with WGLC ASAP and address any comments as part of > WGLC with the discussion I had with her. > > > > Christian, > > > > Please look at my response below with [Rakesh]. We should incorporate the > suggested rewording. I would be happy make edits based on rewording here. > > > > Thanks > > Rakesh > > > > *From: *Susan Hares <[email protected]> > *Date: *Tuesday, December 6, 2016 at 6:13 AM > *To: *"[email protected]" <[email protected]>, > Rakesh Kumar <[email protected]>, 'Linda Dunbar' < > [email protected]>, "'Diego R. Lopez'" <[email protected] > > > *Cc: *"[email protected]" <[email protected]>, 'Myo Zarny' <[email protected]> > *Subject: *RE: [I2nsf] Suggested updaste from Paul Jeong > > > > Rakesh: > > > > Are you taking the editing token to resolve Christian’s comments from > section 2, 3.4, 4.4, and 4.5? I agree with Christians comments on 2, 3.4, > 4.4 and 4.5. I would like to see Paul create a use case document with 4.4 > and 4.5’s original text. > > > > Sue Hares > > > > *From:* I2nsf [mailto:[email protected]] *On Behalf Of * > [email protected] > *Sent:* Tuesday, December 6, 2016 3:37 AM > *To:* Rakesh Kumar; Linda Dunbar; Susan Hares; 'Diego R. Lopez' > *Cc:* [email protected]; 'Myo Zarny' > *Subject:* Re: [I2nsf] Suggested updaste from Paul Jeong > > > > Dear all, > > > > Thanks to Rakesh for posting this new version. I have several comments but > let me first reiterate I’m fine with welcoming Paul as a co-author. > > > > 1. Section 2: > > [Rakesh] This is terminology section. I think, you mean section 3.1.1. > > · I fail to understand the need for the discussion about > centralized and distributed functions, besides the fact the proposed text > does not belong to a terminology function per se. I think this primarily > relates to (service provider-specific) design considerations, as a function > of the nature of the service to be delivered, how a security policy is > defined/enforced, etc. If there is consensus to keep this text in the > document, I think it should rather belong to some kind of “deployment > considerations” section. > > [Rakesh] Some background; the reason for this section was to bring content > from Paul’s contributions. Anyway, based on my discussion with customers > (Enterprise and Service provider), firewalls could be deployed either > centralized or distributed (NSX is one such example). The firewall design > of course is based on multiple factors such as customer needs, network > design and a security admin must know in order to provision security > policies. This is the very thing we want to simply where a security admin > does not know/care about firewall design but only about the policies it > want to enforce. > > > > · I don’t quite understand the rationale either: why large > traffic should rather encourage a centralized design instead of a > distributed design? > > [Rakesh] This was given just an example and not a reason to deploy > centralized firewall. I can remove large. > > > > · I don’t understand what “consistent mechanism” means – the same > protocol regardless of the nature of the security policy to be enforced, > and the nature/location of the NSFs? Else? > > [Rakesh] Basically same client interface irrespective of the firewall > design. > > > > · Finally, I would avoid qualitative appreciations about the > potential complexity of such and such design or the simplification brought > by another design: I don’t think this makes sense, especially because this > is so dependent on the nature of the security policy to be enforced. So, I > guess I would delete the whole paragraph. > > [Rakesh] All the problems described in section 3.1 are subjective to > different opinions, use-cases and perspective. It is hard to say one > problem is bigger than other. > > > > 2. Section 3.4: > > · I have a concern with this section too, which looks out of the > scope of the draft. I also fail to understand the key message of this > section: that SDN techniques raise additional security issues and may > distort how “legacy” security policies are enforced? If so, I think I would > elaborate in terms of (SDN-inferred) specific requirements, e.g., make sure > a controller is entitled to access/configure/invoke participating NSFs, > make sure NSFs are entitled to talk to a SDN controller (to send a > notification that may affect decision-making process handled by the SDN > computation logic), etc. > > [Rakesh] This section was written to take Paul’s contributions based on > suggestions we discussed earlier. Security enforcement can be totally > different beast in SDN than legacy network because of overlay network > design and potential workloads migration that affect micro-segmentation > policies. > > > > · Several typos in the paragraph – here’s a rewording proposal: > “Software-Defined Networks (SDN) have changed the landscape of data center > designs by introducing overlay networks deployed over ToR switches that > connect to a hypervisor. SDN techniques are meant to improve the > flexibility of workload management without affecting applications and how > they work. Workload can thus be easily and seamlessly managed across > private and public clouds. SDN techniques optimize resource usage and are > now being deployed in various networking environments, besides cloud > infrastructures. Yet, such SDN-inferred agility may raise specific security > issues: a security admin must for example make sure that any security > policy can be enforced regardless of the location of the involved NSFs, > thereby raising concerns about the ability of making sure the SDN > computation logic is entitled to send security policy-provisioning > information to the participating NSFs, for example. NSF migration to a > public cloud infrastructure may also raise additional complexity.” > > [Rakesh] Will do. > > > > 3. Section 4.4: > > · I would rephrase part of the new text. For example: > > o Similarly, a network could be exposed to malware attacks and become > an attack vector to jeopardize the operation of other networks, by means of > remote commands for example. > > o Voice over packet networks (VoIP/VoLTE) are also exposed to such > attacks. (I would delete the last part of the sentence which is a kind of > tautology that is not specific to VoIP-targeted networks). > > o In order for organizations to better secure their networks against > this kind of attacks, the I2NSF framework should provide client-side > interfaces that are use case-independent and technology-agnostic. For > example, such I2NSF interface could be used to provision security policy > configuration information that looks for specific malware signatures. > > [Rakesh] Will do. > > > > 4. Section 4.5: > > · s/security/security (in the title) > > · I also have a few rewording proposals: > > o Organizations are not only supposed to protect their networks against > attacks, but they should also adhere to various industry regulations: any > organization that falls under a specific regulation like PCI-DSS (payment > industry) or HIPPA (healthcare industry) must be able to isolate various > kinds of traffic. They must also show records of their security policies > whenever audited. > > o s/violations/violation > > o this information can be provided in the event of an audit as a proof > that traffic is isolated between specific endpoints, in full compliance > with the required regulation. > > [Rakesh] Will do. > > > > > > Cheers, > > > > Christian. > > > > *De :* Rakesh Kumar [mailto:[email protected] <[email protected]>] > *Envoyé :* lundi 5 décembre 2016 23:08 > *À :* Linda Dunbar; Susan Hares; 'Diego R. Lopez' > *Cc :* 'Myo Zarny'; JACQUENET Christian IMT/OLN; [email protected] > *Objet :* Re: Suggested updaste from Paul Jeong > > > > HI Linda, > > > > I just uploaded the version -05 with the updates listed below in this > thread. > > > > Thanks > > Rakesh > > *From: *Linda Dunbar <[email protected]> > *Date: *Monday, December 5, 2016 at 1:44 PM > *To: *Rakesh Kumar <[email protected]>, Susan Hares <[email protected]>, > "'Diego R. Lopez'" <[email protected]> > *Cc: *'Myo Zarny' <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]> > *Subject: *RE: Suggested updaste from Paul Jeong > > > > Rakesh, > > > > I would think uploading soon (ASAP), so we can get over the WGLC by end of > the year. > > > > Linda > > > > *From:* Rakesh Kumar [mailto:[email protected] <[email protected]>] > *Sent:* 2016年12月5日 15:41 > *To:* Linda Dunbar <[email protected]>; Susan Hares <[email protected]>; > 'Diego R. Lopez' <[email protected]> > *Cc:* 'Myo Zarny' <[email protected]>; [email protected]; > [email protected] > *Subject:* Re: Suggested updaste from Paul Jeong > > > > Linda, > > > > Let me know when do you want me to upload this version. > > > > Thanks > > Rakesh > > *From: *Linda Dunbar <[email protected]> > *Date: *Monday, December 5, 2016 at 11:37 AM > *To: *Rakesh Kumar <[email protected]>, Susan Hares <[email protected]>, > "'Diego R. Lopez'" <[email protected]> > *Cc: *'Myo Zarny' <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]> > *Subject: *RE: Suggested updaste from Paul Jeong > > > > Is there anyone objecting adding Paul as co-author? > > If not, please go ahead adding his name and upload the draft. So that we > can start the WGLC. > > > > Linda > > > > *From:* Rakesh Kumar [mailto:[email protected] <[email protected]>] > *Sent:* 2016年12月5日 13:19 > *To:* Linda Dunbar <[email protected]>; Susan Hares <[email protected]>; > 'Diego R. Lopez' <[email protected]> > *Cc:* 'Myo Zarny' <[email protected]>; [email protected]; > [email protected]; Rakesh Kumar <[email protected]> > *Subject:* Re: Suggested updaste from Paul Jeong > > > > HI Linda, > > > > I think, we should add Paul’s name. > > We can put his name as contributing author or as a co-author as others > feel appropriate. > > > > Thanks > > Rakesh > > > > *From: *Linda Dunbar <[email protected]> > *Date: *Monday, December 5, 2016 at 10:03 AM > *To: *Rakesh Kumar <[email protected]>, Susan Hares <[email protected]>, > "'Diego R. Lopez'" <[email protected]> > *Cc: *'Myo Zarny' <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]> > *Subject: *RE: Suggested updaste from Paul Jeong > > > > Sue, Rakesh, Diego, et al, > > > > Do you think the version updated by Rakesh is good enough for WGLC? > > We are hoping to get the process started & finished by 2017. > > > > Thanks, Linda > > > > *From:* Rakesh Kumar [mailto:[email protected] <[email protected]>] > *Sent:* 2016年11月30日 13:59 > *To:* Susan Hares <[email protected]>; 'Diego R. Lopez' < > [email protected]> > *Cc:* 'Myo Zarny' <[email protected]>; [email protected]; > [email protected]; Linda Dunbar <[email protected]>; > Rakesh Kumar <[email protected]> > *Subject:* Re: Suggested updaste from Paul Jeong > > > > Hi Susan and all, > > > > I took as much as possible from Pau’l contributions and added one section > on “Regulatory and compliance” which I wanted to add. > > > > Please find the attached “xml” document. I added following to the document > sent by Diego. I don’t know how to diff between Diego’s version and mine. > > > > 1. Section 3.1.1, Added a new item “*Centralized or Distributed > security functions*:” > > 2. Section 3.4, Added a new section *“Software-Defined Networks”* > > 3. Section 4.4, Added section “*Preventing Distributed DoS, Malware > and Botnet attacks*” > > 4. Section 4.5, Added section “*Regulatory and compliance security > policies*” > > 5. In my opinion, we should add Paul’s name back. I have not done in > the attached document but I feel we should. > > > > Thanks > > Rakesh > > *From: *Susan Hares <[email protected]> > *Date: *Tuesday, November 29, 2016 at 5:49 PM > *To: *Rakesh Kumar <[email protected]>, "'Diego R. Lopez'" < > [email protected]> > *Cc: *'Myo Zarny' <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" < > [email protected]>, 'Linda Dunbar' <[email protected]> > *Subject: *RE: Suggested updaste from Paul Jeong > > > > Rakesh: > > > > Thank you for letting me know. > > > > Sue > > > > *From:* Rakesh Kumar [mailto:[email protected] <[email protected]>] > *Sent:* Tuesday, November 29, 2016 11:42 AM > *To:* Susan Hares; 'Diego R. Lopez' > *Cc:* 'Myo Zarny'; [email protected]; [email protected]; > 'Linda Dunbar' > *Subject:* Re: Suggested updaste from Paul Jeong > > > > Hi Susan, > > > > I will send you the changes in next couple of days. > > > > Thanks > > Rakesh > > > > *From: *Susan Hares <[email protected]> > *Date: *Monday, November 28, 2016 at 1:28 AM > *To: *"'Diego R. Lopez'" <[email protected]>, Rakesh Kumar < > [email protected]> > *Cc: *'Myo Zarny' <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" < > [email protected]>, 'Linda Dunbar' <[email protected]> > *Subject: *RE: Suggested updaste from Paul Jeong > > > > Diego and Rakesh: > > > Let me know who has the token. If Rakesh wants to send changes, I will > update to this work. > > > > Wi will unavailable via email during normal hours (8am-5pm ET) due to jury > duty in the US. I will be working 5pm (2pm PT) to 12pm ET, and 6-7 ET > (am). > > > > Sue > > > > *From:* Diego R. Lopez [mailto:[email protected] > <[email protected]>] > *Sent:* Sunday, November 27, 2016 5:22 PM > *To:* Rakesh Kumar > *Cc:* Susan Hares; Myo Zarny; [email protected]; > [email protected]; Linda Dunbar > *Subject:* Re: Suggested updaste from Paul Jeong > > > > Hi Rakesh, > > > > Good! I am attaching the latest version Sue shared with us. > > > > Be goode, > > > > > > On 27 Nov 2016, at 21:41 , Rakesh Kumar <[email protected]> wrote: > > > > I will do it. > > > > Please send me the latest copy otherwise I will take the latest version > from IETF website. > > > > Regards > > Rakesh > > Sent from my iPhone > > > On Nov 27, 2016, at 12:12 PM, Diego R. Lopez <[email protected]> > wrote: > > Hi Sue, > > > > Trying to sort out a token deadlock we seemed to have… > > > > Be goode, > > > > On 26 Nov 2016, at 22:45 , Susan Hares <[email protected]> wrote: > > > > Rakesh, Diego, Myo, and Christian: > > > > Any updates on this document? If you want me to edit in the changes, > please let me know. > > > > Sue > > > > *From:* Rakesh Kumar [mailto:[email protected] <[email protected]>] > *Sent:* Wednesday, November 23, 2016 1:45 PM > *To:* Diego R. Lopez > *Cc:* Susan Hares; Myo Zarny; [email protected]; chris > [email protected]; Linda Dunbar > *Subject:* Re: Suggested updaste from Paul Jeong > > > > Hi Diego, > > > > I wanted to take a stab at Paul's comment but it looks like you are > planning for the same. I will let you handle in that case. > > > > I wanted to add use-case listing how I2NSF would be useful for regulatory > and compliance policy. > > > > Let me know if anything you would like me to do. I am fine with you taking > the lead. > > > > Regards > > Rakesh > > > > Sent from my iPhone > > > > On Nov 22, 2016, at 6:21 AM, Diego R. Lopez <[email protected]> > wrote: > > > > Hi Rakesh, > > > > I am happy if you take the editorial token before I do. Just tell me when > you are ready. I was thinking to deal with most of Paul's contribution as > an annex exemplifying an implementation pattern using SDN, pointing to the > annex from the main text. > > > > What I am not sure is about including anything about regulation in an > RFC-to-be. Regulation is outside of IETF’s scope… > > > > Be goode, > > > > On 21 Nov 2016, at 21:44 , Rakesh Kumar <[email protected]> wrote: > > > > Hi Susan & others, > > > > I have already given suggestions regarding how to incorporate changes from > Paul’s contributions in this thread. > > Basically it’s a mix of problem space and use-case as mentioned earlier. > > > > I can make the changes if we want to incorporate Paul’s suggestions based > on my thinking. Let me know. I can also add a use-case for regulatory and > compliance. > > > > Thanks > > Rakesh > > > > *From: *Susan Hares <[email protected]> > *Date: *Sunday, November 20, 2016 at 1:59 PM > *To: *'Myo Zarny' <[email protected]>, Rakesh Kumar <[email protected] > > > *Cc: *"[email protected]" <[email protected]>, "'Diego R. Lopez'" < > [email protected]>, "[email protected]" < > [email protected]>, 'Linda Dunbar' <[email protected]> > *Subject: *RE: Suggested updaste from Paul Jeong > > > > Myo, Deigo, Rakesh, and Christian: > > > > Thanks for the input. I’ve removed sections 4.4 and 4.5 to a > implementation draft. Do you want me to remove Paul as a co-author at > this point or leave him on? I’ve edited a version 5. > > > > Diego – do you have the editing token at this point? > > > > Sue > > > > *From:* Myo Zarny [mailto:[email protected] <[email protected]>] > *Sent:* Saturday, November 19, 2016 3:36 PM > *To:* Rakesh Kumar > *Cc:* Susan Hares; [email protected]; Diego R. Lopez; christian.jacquenet@ > orange.com; Linda Dunbar > *Subject:* Re: Suggested updaste from Paul Jeong > > > > Hello Sue and team, > > > > My initial reaction was pretty much the same as Rakesh's. Sections 4.4 and > 4.5 by themselves can be an implementation draft. Now, SDN implementations > could certainly benefit from I2NSF, and the draft should contain a section > on SDN. Such a section would complement NFV use cases. > > > > The text as it stands now--sections 4.5.1 to 4.5.3--describes how SDN > could be used to solve certain network security use cases but doesn't > mention not where/how I2NSF fits in. Let's update the text to illustrate > I2NSF's value to make it relevant to the purpose of the draft. > > > > Diego, thanks for volunteering to make editorial changes. > > > > Cheers, > > > > > > On Sun, Nov 13, 2016 at 6:58 PM, Rakesh Kumar <[email protected]> wrote: > > Hi Sue, > > > > On a different topic; you asked me about if there is anything else we need > to take fromhttps://tools.ietf.org/html/draft-kumar-i2nsf- > controller-use-cases-00 into consideration. > > After looking at it again, I see you did a great job in incorporating most > of the stuff. The only small thing left out is “Regulatory and Compliance:” > related use-case. > > > > Are you open to adding one use-case regarding this ““Regulatory and > Compliance”? I will let you decide on the text what you want to put. I am > also fine if you are not comfortable with this. > > > > Thanks & Regards, > > Rakesh > > > > > > *From: *Rakesh Kumar <[email protected]> > *Date: *Sunday, November 13, 2016 at 1:46 PM > > > *To: *Susan Hares <[email protected]>, "[email protected]" <[email protected]>, > 'Myo Zarny' <[email protected]>, "'Diego R. Lopez'" < > [email protected]>, "[email protected]" < > [email protected]> > *Cc: *'Linda Dunbar' <[email protected]>, Rakesh Kumar < > [email protected]> > *Subject: *Re: Suggested updaste from Paul Jeong > > > > Hi Sue, > > > > Sure, let us meet. > > > > You are absolutely right. Paul pointed out a good use-case of VoIP/VoLTE > and how I2NSF can help. I forgot to mention this earlier; my apologies for > this. > > > > Thanks & Regards, > > Rakesh > > > > *From: *Susan Hares <[email protected]> > *Date: *Sunday, November 13, 2016 at 12:19 PM > *To: *Rakesh Kumar <[email protected]>, "[email protected]" < > [email protected]>, 'Myo Zarny' <[email protected]>, "'Diego R. Lopez'" < > [email protected]>, "[email protected]" < > [email protected]> > *Cc: *'Linda Dunbar' <[email protected]> > *Subject: *RE: Suggested updaste from Paul Jeong > > > > Rakesh: > > > > Let’s talk in person today. Could we chat right after I2NSF? I think > Paul’s sections actually talked about a user perspective. > > > > Sue > > > > *From:* Rakesh Kumar [mailto:[email protected]] > *Sent:* Sunday, November 13, 2016 6:30 AM > *To:* Susan Hares; [email protected]; 'Myo Zarny'; 'Diego R. Lopez'; > [email protected] > *Cc:* 'Linda Dunbar'; Rakesh Kumar > *Subject:* Re: Suggested updaste from Paul Jeong > > > > Hi Sue, > > > > After having a talk with you today, I thought about it some more about > this. I feel, section 4.0 describes the various use-cases (from security > admin/user perspective). The use-case don’t care about a specific > implementation (SDN/non-SDN/Centralized/distributed) approach; rather it > shouldn’t be a matter of concern for the security admin as long its > use-case can be implemented. > > > > If we want to preserve the new contents, I was wondering whether you would > be open to moving around the new additions. Here are my thoughts, let me > what you think. > > > > 1. Move section (“Software-Defined Networks”) under section 3.0 as > a problem, SDN is making security provisioning a complex task. Basically > security policy in the SDN networks cannot deployed the same way as in > legacy networks. > > 2. Combine sections (“Centralized Firewall System), section > (“Centralized DDoS-attack Mitigation System”) and section (“Centralized > VoIP/VoLTE Security System) into two sub-sections under section 3.0 as a > problem, the NSF implementation pose a challenge in deploying security > policies since security admin need to be aware whether a specific NSF is > centralized or distributed in order for security policy to be effectively > enforced. > > > > The I2NSF client interface would definitely address both of the above > concerns/problems. > > > > What do you think? > > > > Thanks > > Rakesh > > > > *From: *Rakesh Kumar <[email protected]> > *Date: *Saturday, November 12, 2016 at 10:49 PM > *To: *Susan Hares <[email protected]>, "[email protected]" <[email protected]>, > 'Myo Zarny' <[email protected]>, "'Diego R. Lopez'" < > [email protected]>, "[email protected]" < > [email protected]> > *Cc: *'Linda Dunbar' <[email protected]>, Rakesh Kumar < > [email protected]> > *Subject: *Re: Suggested updaste from Paul Jeong > > > > Hi Sue, > > > > Thanks for sending the changes. > > > > I looked at the contents in section 4.5 (it looks to me from the diffs > that this has been added). In my opinion, SDN is just a way to create > orchestrate network path for application hosting and of course connecting > these application to the eco-system. This is a means to solve a problem > where undelay network does not provide this flexibility or hard to achieve. > > Having said, I don’t think this belongs to problem and use-case draft > since as far as I know the purpose of this draft is to highlight problem > and use-cases in the security area, irrespective of how the networks are > designed. All I am trying to say is that this draft should care about > solutions (SDN/non-SDN/Legacy/Distributed/Centralized). This could go in > some other draft (may be NSF-facing interface). > > > > It is possible that I am not reading it properly but this is how I see it. > I am open to discussions. > > > > Thanks > > Rakesh > > > > *From: *Susan Hares <[email protected]> > *Date: *Saturday, November 12, 2016 at 2:08 PM > *To: *"[email protected]" <[email protected]>, 'Myo Zarny' < > [email protected]>, "'Diego R. Lopez'" <[email protected]>, > Rakesh Kumar <[email protected]>, "[email protected]" < > [email protected]> > *Cc: *'Linda Dunbar' <[email protected]> > *Subject: *Suggested updaste from Paul Jeong > > > > Myo, Diego, Rakesh, and Christian: > > > > I suggest that we include Paul’s addition in section 4.4 and include Paul > on the author list. Please provide me feedback on this change. Could you > review the text and answer the following: > > > > a) Do you think the text in section 4.4 makes sense to add, > > b) Do you thinking adding Paul as a co-author makes sense, > > c) Do you see any editorial changes in Paul’s section 4.4? > > > > Sue Hares > > > > > > -- > > Regards, > Myo > > > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: [email protected] > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ---------------------------------- > > > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: [email protected] > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ---------------------------------- > > > > > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: [email protected] > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ---------------------------------- > > > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > > Thank you. > > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf > > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: [email protected], [email protected] Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
