Mirja Kühlewind has entered the following ballot position for draft-ietf-i2nsf-framework-08: Discuss
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-framework/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have two points below: 1) The first one should be easy to address: "Transport redundancy mechanisms such as Multipath TCP (MPTCP) and the Stream Control Transmission Protocol (SCTP) will need to be evaluated for applicability. " This sentence is not correct; MPTP and SCTP do not provide any redundancy mechanisms; they simply just provide a reliable transport as TCP does. Therefore I would just remove this sentence here. Further, on this paragraph, it is not clear to me why you say that reliable transport is needed. Especially for some monitoring purposes, unreliable transport might be acceptable as well. Or do you think that all communication for security systems have always to be reliable? I don't think this document discusses things in detail enough to make such an assessment. 2) This second is a very high level concern and I'm not sure if balloting discuss on this is the right thing to do but I definitely would like to get some feedback from the group to better understand this document before publication: This document seem not very security specific to me. To say this in a somehow sloppy way: I have the feeling that if you would just remove the word "security" everywhere in the text, it would still be the same document. I checked the charter and the charter is also not very concrete about what to expect, besides motivating the needed interfaces with the need for in-network security function. However, if there is nothing security specific about this, what's the difference to the usually control plane architecture as usually deployed with the use of NETCONF? And I am actually wondering if this is the right wg to write such a document. Further, I would at least have expected that this framework mandates for high control plan security given we are talking about the configuration and deployment of security function. However, it does not. It does rarely provide any concrete recommendation here, and basically leaves the door open to used these interfaces without authentication which I think is not acceptable. _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
