SECDIR early review of draft-ietf-i2rs-problem-statement-04     I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.   These comments were written with the intent of improving security requirements and considerations in IETF drafts.   Comments not addressed in last call may be included in AD reviews during the IESG review.   Document editors and WG chairs should treat these comments just like any other last call comments.   This is a short document describing the problem being addressed by the I2RS WG, and establishing some requirements for solutions.   Section 2 describes the model for I2RS. It calls for using existing transport protocols to provide security, a good statement as part of the base protocol requirements. Looking at Figure 1, it seems that the only paths that are in scope for I2RS are between an I2RS agent and client and between clients. In section 5, authentication, authorization, and integrity are explicitly cited as requirements. This is a good statement of requirements. It might be nice to state whether confidentiality is also perceived as a requirement, or if it explicitly not a requirement.   The Security Considerations section is a single paragraph consisting of 2 sentences. It opens with a nice statement about the importance of security in the I2RS context. I think a back pointer to the “secure Control” text would be appropriate. The second sentence says that more investigation is needed to fully define security requirements such as authorization and authentication levels. I don’t know what this last phrase means. Authorization (aka access control) isn’t usually described as having levels per se. Do you mean granularity of access control, or something else. Also, for authentication, there are various mechanisms one can employ, and these may be described as offering varying “levels” of security, but that is an oversimplification in many cases. A clearer description of what the authors are trying to convey here would be good.   I also looked briefly at draft-hares-i2rs-security-02. That document begins with a very good discussion of security terminology based on RFC 4949. It also proposes very specific security requirements for communications in the I2RS model. That document calls for confidentiality as a requirement, which further motivates some mention of this security service in the problem statement, even if the statement is equivocal.     Two typos I noted:   Section 2: measuresments -> measurements   Section 5:   Such communications must also have its integrity protected. ->   Such communications must also be integrity-protected.