Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-architecture-13: 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-i2rs-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - If i2rs were used to control home networks, then that would raise more privacy issues, e.g. the agent's IP address can be privacy sensitive. Would it be useful to rule that out of scope? E.g. to say that i2rs SHOULD NOT be used where the agent/router in question is specific to one person or home? - section 2: security role, hmm..... Do netconf/restconf have the concept of mapping identifiers to roles? If not, that might be tricky to graft on. Not sure. - section 4: "Mutual authentication between the I2RS Client and I2RS Agent is required. " yay! thanks:-) Even better if you did s/Mutual/Strong mutual/ to prevent someone saying that TCP-MD5 is good enough. - section 4: "The primary communication channel that is used for client authentication and then used by the client to write data requires integrity, confidentiality and replay protection." yay! again! :-) - section 4: "Other communications via I2RS may not require integrity, confidentiality, and replay protection. For instance, if an I2RS Client subscribes to an information stream of prefix announcements from OSPF, those may require integrity but probably not confidentiality or replay protection." sorry, boo! :-) It's often unsafe to mix and match differently protected sets of data between the same sets of entities. I think you'd be better off there saying that the requirements may *exceptionnally* differ but usually only because of e.g. some level of broadcast or multicast being part of the story, where we don't have good usable security solutions today. (This is not a DISCUSS because I think the protocol work will end up saying "just use TLS always" as that'll be simpler and better, so I hope this'll be a non-issue. If you know already that there's some other plan in place, then please say so we can chat now and avoid a trickier discussion later.) - section 4: I think you're heading here towards use of TLS and not object level security. Is that right? If so, would it be useful to say so? (Just so as to correctly set expectations for later.) - 7.7: Would it be useful to say that the relevant information here is only about network state and stastics and not about connections (e.g. who spoke to whom) or payloads? That might save some discussions about RFC2804 later on. _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
