Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-15: 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-protocol-security-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for adding REQ-16. Comments below are unchanged from my previous discuss ballot. - The topic of marking things as allowing insecure read access has been discussed a lot so I won't get into it again. - section 4: "Data passed over the insecure transport channel MUST NOT contain any data which identifies a person or any "write" transactions." I don't get what identifying a write transaction might mean? - 4.1: "AAA protocols MAY be used to distribute these identifiers, but other mechanism can be used." If I'm doing TLS with mutual-auth, then I need a private key and certificate. I don't think AAA protocols can transport those (and they probably ought not) so I'm not sure what's meant here. - 4.2: What do "valid identity" and "valid identifier" mean? If the same then use the same terms. But I think you need to define "validity" or else say that work needs to be done later. - 4.3: I think you're saying here that the i2rs client is trusted to simply assert the secondary identifier. If so, then saying that would be good. If not, then I don't know what you mean. - 4.4: I still don't see why it'd not be better to use a different protocol for the non-secure stuff and avoid all the potential discussion and pitfalls of trying to do all this in one protocol. - 4.4: "It is mandatory to use (MTU) on any I2RS client's Write transaction or the configuration of an Event Scope transaction." Which "it" do you mean? - 4.4: The BCP107 stuff is still not useful. - 4.5: "detect when the data integrity is questionable" - I've no idea what that means. Nor what it could mean. Can you explain? _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
