Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-traceability-09: 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-i2rs-traceability/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Intro: I don't agree that all data retention aspects are out of scope here. They are about as in-scope as log rotation I'd say. I do think it'd be worthwhile noting that if log content contains sensitive data (either security- or privacy-sensitive) then retaining that data for extended durations has a cost, in terms of creating risks if data leaks. While one cannot say here how to evaluate such risks, they do exist and should really be noted. It would also be sensible IMO to say that implementations SHOULD provide a way to purge ancient log content that is no longer needed or useful, but that the definition of when content is no longer needed or useful is out of scope. In saying this I do recognise that much or perhaps even most i2rs log content will not be security or privacy sensitive, but in some cases it can be, e.g. if an operation involved an address that is specific to a user or device carried by a user. In addition, some data retention regimes could impose a requirement to purge log content after a certain duration. I'd say a note about this in the intro or in the security considerations should be a fine way to handle this issue, and to acknowledge that not all data retention issues are out of scope for implementations. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 5.2: Requested/Applied Operation Data - I would guess this can include sensitive values, e.g. keys/passwords. Shouldn’t you say to at least be careful of those, or perhaps to not log them, or to zero out known sensitive values before logging? - 7.2: how is privacy an implementation detail? - 7.4: What does "being preferred" mean in 2119 terms? Why is one of the three options not mandatory-to-implement? _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
