Requirements for Marking SIP Messages to be Logged
RFC 8123

Note: This ballot was opened for revision 12 and is now closed.

(Ben Campbell) (was Discuss, Yes) Yes

(Jari Arkko) No Objection

Deborah Brungard No Objection

(Stephen Farrell) No Objection

Comment (2017-02-01)
No email
send info
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.

(Joel Jaeggli) No Objection

(Mirja K├╝hlewind) No Objection

Comment (2017-01-31)
No email
send info
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.

(Kathleen Moriarty) No Objection

Comment (2017-02-01)
No email
send info
In addition to Stephen's questions, I would like to see a little more text in the following sentence of the Security Considerations section:
   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).

(Alia Atlas) Abstain

Comment (2017-02-01)
No email
send info
I agree with Mirja that useful content would be better placed in the solution document.
I don't think that there are communication issues between WGs where requirements need
to be nailed down - and obviously no delay in working on a solution.

Alissa Cooper Abstain

Comment (2017-02-01)
No email
send info
Agree with Alvaro.

(Suresh Krishnan) Abstain

Comment (2017-02-01)
No email
send info
I do see the value in the content of this document, but I do not see the value of publishing it as a separate RFC at this point of time. I think it should be merged into the solution document.

(Terry Manderson) Abstain

Comment (2017-02-01)
No email
send info
I fail to see the value in publishing this document as an RFC in its own right. However I shall not stand in the way of publication should that be the ballot outcome.

Alvaro Retana Abstain

Comment (2017-01-31)
No email
send info
I agree with Mirja in that I to don't see any archival value in this document as is, especially given that the WG has been working on the solution draft (draft-ietf-insipid-logme-marking) for over two years.

I am however not standing in the way of publication and am ABSTAINing instead.