Re: [Gen-art] [Insipid] Genart LC review: draft-ietf-insipid-logme-reqs-11

Stewart Bryant <stewart.bryant@gmail.com> Wed, 04 January 2017 19:29 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEDF129441; Wed, 4 Jan 2017 11:29:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEK1P19ZEz3c; Wed, 4 Jan 2017 11:29:47 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB731200A0; Wed, 4 Jan 2017 11:29:47 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id k184so269721572wme.1; Wed, 04 Jan 2017 11:29:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=2ETFgXZxUWYzKyrRZnGlf2MiW+5c8SWi2zzH2ZkeRb0=; b=PStF29rxng/iUrYPRW8oB/gZ5EpHfyO3FDVV2CMwH/mjXWx0wf7+ZHf+rXyKLW5qF8 qbdhok/ucFUPS9Rx9nn4mewfcK4eqXfwZZrihHOMEhx3KwfH+c7z8OdNBcnsQk6ogns4 pEywfCoaQlXQDSCr/kUYt9Vx6xjPXBtGnHH3chZC+34j5adOVLmaHZg+ZhaQf8e1Hoeh bHYsMB9iWrSn3WntjDEaydsQ0arJ3zg6AWBTyXL75tMKDUU1/P6o323bVD13P73hxY18 NrHNAGZndN6Quz3aM7bpR/gn6XyMkyrJxGUomK247ZOCmm8k41tLQCqWISNjtn1TUuNv KlbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2ETFgXZxUWYzKyrRZnGlf2MiW+5c8SWi2zzH2ZkeRb0=; b=obJjxbjQYFerlDqw08vAe93fvOewPLggoXDCTNQRUCVglCG0Q/lucDswFPeVhIlz8Z wWARvc3UX57Ujak/jvsrjad+v2Iw9xiy4IuIOgIZAxbWYnsMSabGBOTV25GkrOg5uX/x HjV95hSqiCu/ALGAEaaq3raNHRZUckk6pJra4iO8qqPGWwH6lfSv5SLb3rjcYJ+u/K4g jqj6mVl/IU5oS/5UDP9OG3//QHB2QeCZ6ac4ITim2lfNrHH+2/Bx3OsB301NumKiuLVE eChZJ2DvRqmiE5J39vPbICv51zJs9LQ+NvXSR3wleFQ7Q4MEYiaQr2B5i5+WnlT81prK AQHg==
X-Gm-Message-State: AIkVDXJ1id1QLXyvzNt979F+QltZVcLnkNnt/zSxHNaEFESrmzfIs6MjfLh5wfaq8ePk8w==
X-Received: by 10.28.135.5 with SMTP id j5mr63666339wmd.3.1483558185426; Wed, 04 Jan 2017 11:29:45 -0800 (PST)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id uz7sm5312201wjc.11.2017.01.04.11.29.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jan 2017 11:29:44 -0800 (PST)
To: "Arun Arunachalam (carunach)" <carunach@cisco.com>
References: <4d11bb6c-c286-0e56-282a-4003fc518eab@gmail.com> <16B3F47D-2E14-4F2A-B99B-CF309474DB20@cisco.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <949f78f9-f08e-62c2-5be0-e1fe6e981656@gmail.com>
Date: Wed, 4 Jan 2017 19:29:43 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <16B3F47D-2E14-4F2A-B99B-CF309474DB20@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/kMK-xB9PI_XYty0yPMqnPliifVI>
Cc: General Area Review Team <gen-art@ietf.org>, "insipid@ietf.org" <insipid@ietf.org>, IETF Discussion <ietf@ietf.org>, "draft-ietf-insipid-logme-reqs@ietf.org" <draft-ietf-insipid-logme-reqs@ietf.org>
Subject: Re: [Gen-art] [Insipid] Genart LC review: draft-ietf-insipid-logme-reqs-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jan 2017 19:29:51 -0000

Hi Arun

Those changes look good to me.

Thanks

Stewart


On 04/01/2017 17:53, Arun Arunachalam (carunach) wrote:
> Hi Stewart,
>
> Thanks for taking the time to review !
>
> Please see inline and let us know your input.
>
>
>> On Jan 3, 2017, at 10:11 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote:
>>
>> 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.
> We can change from SHOULD to MUST.
>
>
>
>> 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.
>
> We will change it to “…and the Session Border Controller (SBC)…”.
>
>> ===================
>>
>>    [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.
>
> We can rewrite this paragraph as follows:
>     
>     Topology hiding and protocol repair (see [RFC5853]) are two common
>     functions that manipulate signaling at the network boundary. These
>     functions are performed by SIP device types  (see [RFC7092]) such as
>     Session Border Controller and Interconnection Border Control Function (IBCF).
>    
>
>> ===================
>>
>>    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.
> We will change it to “….with User Agents (UA) that have not …"
>
> Thanks!
> Arun
>
>>
>>
>> _______________________________________________
>> insipid mailing list
>> insipid@ietf.org
>> https://www.ietf.org/mailman/listinfo/insipid