On Thu, Apr 27, 2017 at 6:17 AM, Susan Hares <[email protected]> wrote:
> Ekr: > > Thank you for your insightful comments. The track has been changed to > informational in version 13. Your comments have been fixed in version 15 > (or in earlier versions). > > Sue > > > -----Original Message----- > From: I2nsf [mailto:[email protected]] On Behalf Of Eric Rescorla > Sent: Friday, April 7, 2017 7:42 PM > To: The IESG > Cc: [email protected]; [email protected]; > [email protected]; [email protected] > Subject: [I2nsf] Eric Rescorla's No Objection on > draft-ietf-i2nsf-problem-and-use-cases-11: (with COMMENT) > > Eric Rescorla has entered the following ballot position for > draft-ietf-i2nsf-problem-and-use-cases-11: 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 don't have any problem with this document per se, but it's a little odd > how it's written in a vacuum as if there weren't already technologies which > did a lot of the things you are talking about here (e.g., YANG) and which > the WG intends to use. I think this document would be a lot stronger if it > didn't act as if the WG was agnostic and instead called out what solutions > the WG intends to adopt for these. > > Sue: Having set-up requirements for the I2RS protocol changes to YANG, > NETCONF, and RESTCONF, I respectfully disagree with you. In writing the > document in this style, it allows other technologies (CBOR or COAP) to be > used. We may invent other functions in the future that may better secure > mobile devices. > OK, well, this is a WG decision, but I found it kind of hard to read as an outsider. > S 2. > Flow-based NSF: An NSF which inspects network flows according to a > security policy. Flow-based security also means that packets are > inspected in the order they are received, > > This seems over-specific, because sometimes firewalls and the like will > store packets so that it can re-assemble them, in which case it inspects > them in logical not time order. > > Sue: This specific comment summarizes a decision by the WG to define > flow-based security in this fashion. This definition was the source of > much > debate in the WG. I agree that logical order can be used rather than time > order, but the WG focused on time order So I guess my question is: say I had such a firewall. Would it not be a flow-based NSF? If not, what would it be? Note: My ask here is merely that the document be clear about what's in or out. I'm not arguing about the content of the decision. > S 3.1.9; bullet 3. > Symmetric keys and group keys are not the same type of category, so I can't > read this section. What are you trying to say here? > > Agreed - symmetric keys and group keys are not the same type of category. > The point is that automated key management needs to support both. > Otherwise > requirements 1 + 2 cannot be met. If you can suggest a better way to put > this section, please let me know. > > Section 3.1.9 - bullet 3: > Old /Automated key management needs to support both symmetric keys and > group keys via the abstract key service provided by items 1 and > 2. I2NSF controllers within the NSF required to exchange data > with NSFs may exchange data with individual NSFs using individual > symmetric keys or with a group of NSFs simultaneously using an IP > group address secured by a group security key(s). / I would suggest using "pairwise" and "group" as that's the distinction I think you want to draw. S 3.5. > "xamine" and "scnearios" are misspelled. > > Sue: Fixed in earlier version. My apologies for the error. (I had the joy > of finding out my spell checker had been corrupted on my tool (notepad++)). > > > S 3.6. > ToR seems to be undefined. > > Sue: It was changed prior to version 15. > > > Figure 3. > I think this dotted circle-thing is intended to tell me that the operator > controls the stuff inside the circle, but I'm not sure. Maybe some labels > would help. > > Sue: Label "Service provider is within figure 3. Any further suggestions > would help. > Huh. Maybe move the label outside and have an arrow to the circle saying "service provider boundary"? I know that ASCII art is tough here. -Ekr > > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf > >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
