[Insipid] Stephen Farrell's No Objection on draft-ietf-insipid-logme-reqs-12: (with COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-insipid-logme-reqs-12: 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-insipid-logme-reqs/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Note that I'm balloting no-objection here. If some of
these things weren't fixed, I'd be a DISCUSS ballot when
the protocol spec turned up, should I still be on the
IESG at that point (which I guess is unlikely:-)

- 3.2: I think "trust domain" isn't a great term, and
doesn't really match the definition offered well. You're
including the entire "source" operator plus the bits of
any other operator that have agreed to help the
source-operator with logging. I don't think that set of
things is really a domain. Nor are the things in that set
"trusted" except to do this logging stuff properly. It's
also not clear to me if the relevant set is meant to
differ per-call, or to be the same for all calls that a
source-operator might originate.

- 5.1: REQ1 seems to me to ignore privacy in one bad
respect - isn't the right thing to log the entire message
*except* bits that are considered sensitive by the
logging entity concerned?  E.g. any secrets or PII in the
SIP message may be best not logged. Forcing everyone to
log the entire thing would seem brittle to me - it may
cause operators to not co-operate with one another esp if
data privacy laws differ between them. (Or maybe more
likely, the logs will not have the sensitive bits, or
will eventually have them XXXX'd out.)

- REQ9: Not quite sure, but I wonder are there additional
requirements for intermediaries inserting this that
aren't covered. For example, that that not be (ab)used
for other than diagnostics and hence ought not be on by
default and maybe more. I think the thing to do is to get
someone to do a privacy analysis of this situation before
the protocol spec is done - some minor changes might make
a biggish difference there.

- 6.1: See above wrt 3.2. I'm not convinced that there is
such a thing as a "trust domain boundary" as you use the
term. I think (not sure) that may mean that logme stuff
is either dropped on ingress or else never dropped
which'd seem like a bad outcome.