Requirements for Marking SIP Messages to be Logged
draft-ietf-insipid-logme-reqs-12

In addition to Stephen's questions, I would like to see a little more text in the following sentence of the Security Considerations section:
OLD:
   If a prior agreement to log
   sessions exists with the next hop network then the "log me" marker
   SHOULD NOT be removed.
NEW: (or something similar that ties this back to requirement 7)
   If a prior agreement to log 
   sessions, at a debugging or regression testing level for data, exists with the next hop network then the "log me" marker
   SHOULD NOT be removed.

That requirement only shows up in one place (as far as I could see and I think it would be helpful in the security considerations section as it shows the limited scope of use besides the "trust domain" (name may be changed?).

Note that I am balloting No Objection as this is part of the WG's charter (also pointed out in the SecDir review).

I don't see a value in publishing this draft as a stand-alone document. If needed content can be merged into draft-ietf-insipid-logme-marking (maybe in the appendix); especially the security considerations belong in the spec itself.

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.