> On Apr 27, 2017, at 7:20 AM, Susan Hares <[email protected]> wrote: > > Ben: > > I am dealing with the editorial comments you indicated. I am not dealing > with the wider scope issues of information for support documents. Version > 13 is submitted to fix these issues, and to change the draft's status to > informational. > > Sue > > -----Original Message----- > From: I2nsf [mailto:[email protected]] On Behalf Of Ben Campbell > Sent: Monday, April 24, 2017 10:05 PM > To: The IESG > Cc: [email protected]; [email protected]; > [email protected]; [email protected] > Subject: [I2nsf] Ben Campbell's No Objection on > draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) > > Ben Campbell has entered the following ballot position for > draft-ietf-i2nsf-problem-and-use-cases-12: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with the various abstains about this draft not appearing to have > archival value. I chose not to ballot "abstain" because I think it's best to > handle that issue at charter or adoption time rather than doing so this > close to the finish line. (I note that the WG charter explicitly says that > the WG may choose not to publish, so this is a borderline > case.) If there really are good reasons to expect archival value, it would > be helpful to include a paragraph early in the document describing those > reasons. > > I have a few additional comments on the odd chance this draft > progresses: > > -2: > -- B2B describes a business model. I don't see how that is useful for IETF > discussion unless it implies specific technical characteristics. If it does, > them please describe them. > Bespoke": In other usages, "bespoke" often implies positive thing, which I > don't think the draft intends. I think the work "customized" would better > fit the usage herein. > > 2-a) Removed B2B in sentence: > New/For example, an enterprise may mandate that firewalls serving Internet > traffic, within organization, and inter-organization traffic be separated./
WFM > > 2-b) > Webster defines bespoke as: custom-made > (https://www.merriam-webster.com/dictionary/bespoke). I believe the > nuances in bespoke better fit, but several people have comment on this issue > - so let's just change it. > The text you refer to is: > Old /Since no widely accepted industry standard security interface > to security NSFs exists today, management of NSFs (device and policy > provisioning, > monitoring, etc.) tends to be bespoke security management offered by > product vendors. As a result, automation of such services, if it > exists at all, is also bespoke. > / > New/ > Since no widely accepted industry standard security interface > to security NSFs exists today, management of NSFs (device and policy > provisioning, > monitoring, etc.) tends to be custom-made security management offered by > product vendors. As a result, automation of such services, if it > exists at all, is also custom-made. > / That WFM. In this context, I might suggest “customized”, but either is okay. > > > -3: "The "Customer-Provider" relationship may be between any two parties. > The parties can be in different firms or different domains of the same > firm." > There again seem to be implied business models here. Is it technically > relevant if organizations qualify as "firms"? > > Sue: a replacement of > > New/The "Customer-Provider" relationship may be between any two parties. > The parties can be in different organization or different domains of > the same > organization./ WFM > > - 3.1.1: > -- Consider adding DMZ to the glossary > > Sue: DMZ - is in the security glossary - RFC4949. As such, it was > suggested that we do not need to add it to this draft. Okay. > > -- "Centralized or Distributed security functions" seems out of place. > The rest of the section describes kinds of security functions; this > describes the design of security functions. > > Sue: beginning of the lists states "Below are a few examples of security > functions and locations or contexts in which they are often deployed:" . > On the list is "DMZ", Centralized or distributed security functions, and > "security gateways". The WG choose not to debate whether each was a > function or a location. Please let me know how high a priority this is for > you as I will have modify the whole list. It’s certainly not a showstopper, so I will leave it to you to decide. In my case, It took me out of the flow of reading and left me with the Big Bird singing “One of these things….” in my head. But maybe that’s just me. :-) [Several points elided to which my replies would be along the lines of “sounds good”] > -7: Are there no privacy related requirements? > > I've added some text, but I can added more. The text in version 15 looks good to me. (Not sure which version first contained it.) Thanks! Ben. _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
