Hi Linda and Roman, I have submitted a revised I-D for I2NSF Applicability: https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-18
According to Linda's advice, I added Security Policy Translator as a new section, i.e., Section 5. Also, I enhanced two XML files for Web Filter such as a high-level security policy and the low-level security policy using the Consumer-Facing Interface and NSF-Facing Interface data models. The main changes in this version are as follows: o In Section 4 <https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-18#section-4>, a high-level security policy XML file in Figure 2 and the corresponding low-level security policy XML file Figure 3 are constructed using the Consumer-Facing Interface data model and the NSF-Facing data model, respectively. o For the applicability of I2NSF to the real world, Section 5 <https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-18#section-5> is added to support the Intent-based Security Services using I2NSF. This section explains the security policy translation based on an I2NSF User's intents on the required security services. Figure 4 shows the architecture and procedure of the I2NSF security policy translator. I think this version can give the audience the applicability sense of how to apply the I2NSF to the real world. Roman, Could you let the IESG review this revised I-D to move it forward? Thanks. Best Regards, Paul 2019년 8월 14일 (수) 오전 7:24, Mr. Jaehoon Paul Jeong <[email protected]>님이 작성: > Hi Linda, > It seems a good suggestion to include the Security Policy Translation into > the I2NSF Applicability draft as a new section. > > Roman, > Could you guide us how to proceed with our draft in order to penetrate the > IESG evaluation? > > Thanks. > > Best Regards, > Paul > > > 2019년 8월 12일 (월) 오후 2:53, Linda Dunbar <[email protected]>님이 작성: > >> Paul, >> >> >> >> I consulted some seasoned experts in IETF community on how to make the >> case, Adrian Farrel’s explanation is really helpful. Making me think that >> the content of your Translation Draft is actually more appropriate in the >> Applicability draft. I am not sure if it is too late to add some content.. >> >> >> >> Linda >> >> ------------------------------------- >> >> >> >> *Background. * >> >> >> >> *Applicability Statements have always tried to be an explanation of how >> to apply a technology to a use case. This differs considerably from a >> statement that a use case can be solved with a technology.* >> >> >> >> *Of course, over time, a number of Applicability Statements have been >> published that are far more dilute. Sometimes they have been just >> collections of use cases to which the technology could be applied. >> Sometimes they have been frameworks or architectures showing how the >> technology fits into a picture that contains many other components and >> technologies.* >> >> >> >> *Sadly, we should not use past failures to justify continued failure * >> *😊** I think the IESG (in general) and Alvaro (in this instance) are >> trying to tighten up the meaning of "Applicability Statement".* >> >> >> >> *They are looking for tighter descriptions that might also be called >> "implementation cookbooks". That is: to deliver this use case using the new >> technology, you need to use this protocol configured with these values, and >> you need to integrate with these other components by sending these messages >> and using these defaults, and you have to select these options, and you >> have to treat the "SHOULD" on page 27 as a "MUST". Of course, part of what >> you get is a framework, but a lot is implementation/deployment guidance. * >> >> >> >> *As a result, applicability statements are often quite short and >> technical. And (of course?) they come out after most of the specification >> work because they are depending heavily on that work -- after all, you >> can't describe how to configure and use a protocol until it has been >> specified. That usually means that the protocol specs are normative >> references from the applicability statement.* >> >> >> >> *From:* Mr. Jaehoon Paul Jeong <[email protected]> >> *Sent:* Friday, August 09, 2019 1:27 AM >> *To:* Susan Hares <[email protected]>; DIEGO LOPEZ GARCIA < >> [email protected]> >> *Cc:* Roman Danyliw <[email protected]>; Linda Dunbar < >> [email protected]>; Yoav Nir <[email protected]>; Sangwon >> Hyun <[email protected]>; Tae-Jin Ahn <[email protected]>; Mr. Jaehoon >> Paul Jeong <[email protected]> >> *Subject:* Request for Your Help on I2NSF Applicability Draft >> >> >> >> Hi Susan and Diego, >> >> As you can see, our I2NSF Applicability Draft was discussed by the IESG >> yesterday. >> >> Could you help me defense our I2NSF Applicability Draft as co-authors? >> >> >> >> Since Susan and Diegou are the editor of I2NSF PS and Use Cases (RFC >> 8192) and >> >> the editor of I2NSF Framework (RFC 8329), respectively, your voice will >> be helpful. >> >> >> >> We need to appeal why this applicability draft needs to be published as >> an Informational RFC >> >> even though the two RFCs were published for I2NSF use cases and framework. >> >> >> >> Thanks. >> >> >> >> Best Regards, >> >> Paul >> >> -- >> >> =========================== >> Mr. Jaehoon (Paul) Jeong, Ph.D. >> Associate 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 >> <https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcpslab.skku.edu%2Fpeople-jaehoon-jeong.php&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C159b4b4256fe4b94f81e08d71c92abb5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637009288598143883&sdata=0Cj1nsqhwJ%2BCJWawKD08eH1mauR3OiD4hjIKk%2B33FyU%3D&reserved=0> >> >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
