Skip to main content

Last Call Review of draft-ietf-insipid-logme-reqs-11
review-ietf-insipid-logme-reqs-11-genart-lc-bryant-2017-01-03-00

Request Review of draft-ietf-insipid-logme-reqs
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-01-13
Requested 2016-12-21
Authors Peter Dawes , Chidambaram Arunachalam
I-D last updated 2017-01-03
Completed reviews Secdir Last Call review of -11 by Sean Turner (diff)
Genart Last Call review of -11 by Stewart Bryant (diff)
Opsdir Last Call review of -11 by Dan Romascanu (diff)
Genart Telechat review of -12 by Stewart Bryant
Assignment Reviewer Stewart Bryant
State Completed
Request Last Call review on draft-ietf-insipid-logme-reqs by General Area Review Team (Gen-ART) Assigned
Reviewed revision 11 (document currently at 12)
Result Ready w/nits
Completed 2017-01-03
review-ietf-insipid-logme-reqs-11-genart-lc-bryant-2017-01-03-00
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.