Review of draft-ietf-insipid-logme-reqs-11

Dan Romascanu <> Thu, 12 January 2017 16:17 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 0DCDD1294C9; Thu, 12 Jan 2017 08:17:17 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dan Romascanu <>
Subject: Review of draft-ietf-insipid-logme-reqs-11
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Thu, 12 Jan 2017 08:17:17 -0800
Archived-At: <>
X-Mailman-Version: 2.1.17
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Jan 2017 16:17:17 -0000

Reviewer: Dan Romascanu
Review result: Ready

I have reviewed this document as part of the Operational directorate's

ongoing effort to review all IETF documents being processed by the
IESG.  These 
comments were written with the intent of improving the operational
aspects of the 
IETF drafts. Comments that are not addressed in last call may be
included in AD reviews 
during the IESG review.  Document editors and WG chairs should treat
these comments 
just like any other last call comments. 

   This informational document describes requirements for adding an
indicator to the SIP
   protocol data unit (PDU, or a SIP message) that marks the PDU as a
   candidate for logging.  Such marking will typically be applied as
   part of network testing controlled by the network operator and not
   used in regular client signaling.  However, such marking can be
   carried end-to-end including the SIP terminals, even if a session
   originates and terminates in different networks.

It's a short, focused and well-written document. It is interesting for
the operators of networks that use SIP, as this indicator can be used
to trigger testing or debugging in the networks that they operate. It
seems that different implications on security and network behavior
were considered, although some of them are not explicitly mentioned -
such as the potential overload or DoS attacks in case of
mis-configuration or malicious configuration of a big number of
terminals in a SIP network leading to simultaneous activation of debug
modes. It may be good to explicitly mentions these, but otherwise this
document is READY from an OPS-DIR perspective.