I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-insipid-logme-reqs-11 Reviewer: Stewart Bryant Review Date: 2017-01-03 IETF LC End Date: 2017-01-13 IESG Telechat date: unknown Summary: Ready with minor issue This is a well written document that describes a useful feature in its intended purpose. However I could not help but think that it has an inevitable alternate use in the observation of users. There is guidance on how to prevent this, but that seems easily ignored. Thus the guidance from Security Area review will be of particular importance. Major issues: None. Minor issues: 6.1. Trust Domain Since a "log me" marker may cause a SIP entity to log the SIP header and body of a request or response, the "log me" marker SHOULD be removed at a trust domain boundary. SB> I am not convinced that SHOULD is strong enough given that the traffic SB> is leaving the trust domain. Nits/editorial comments: 3.1. Network Boundary Figure 2 shows a network boundary between GW-A1 in operator A's network and the SBC in operator B's network. A SB> SBC needs expanding on first use. =================== [RFC5853] gives examples of manipulating signaling to prevent the sending network passing on sensitive information, for example topology hiding, or the receiving network protecting itself from signaling that is not under its control, for example protocol repair. SB> The last sentence does not scan well. =================== o REQ9: The "log me" marker mechanism SHOULD allow a SIP intermediary to request logging SIP requests and responses on behalf of the originating endpoint. The typical use case for this requirement is for compatibility with UAs that have not SB> UA needs expanding on first use.