Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs

Paul Giralt <pgiralt@cisco.com> Wed, 14 September 2016 16:46 UTC

Return-Path: <pgiralt@cisco.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8895D12B22F for <insipid@ietfa.amsl.com>; Wed, 14 Sep 2016 09:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.028
X-Spam-Level:
X-Spam-Status: No, score=-16.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 mwygV8D6F6N1 for <insipid@ietfa.amsl.com>; Wed, 14 Sep 2016 09:46:52 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6E312B213 for <insipid@ietf.org>; Wed, 14 Sep 2016 09:46:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11101; q=dns/txt; s=iport; t=1473871612; x=1475081212; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=kNrH8KKcCt+QAkXFbpPPYFg5qfEviuu2we7TOJhmt7M=; b=Yxzs9wTODFbm2WNC9GkFy21DNHi2eh6XVY4jipQ58L8dCdCrHIrZ05hW 3v5+fZ2p8MmDTmdIP5MRmFmNBOD/5HhhsODQXJQxoBLt6k3fYr5f+njIw GZA9550k3re8hPWMGyRZnQp4pTCTZ5xtE4qpruTzR+TRPmey5m3YYuwXV 4=;
X-Files: signature.asc : 842
X-IronPort-AV: E=Sophos;i="5.30,334,1470700800"; d="asc'?scan'208,217";a="321723035"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2016 16:46:51 +0000
Received: from rtp-vpn3-146.cisco.com (rtp-vpn3-146.cisco.com [10.82.216.146]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u8EGkoo5010124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2016 16:46:51 GMT
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_A674EADB-8B47-4CE8-BC06-A76F51EA1F00"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Paul Giralt <pgiralt@cisco.com>
In-Reply-To: <4C52DDE4-07CF-4F5F-8DB7-8CEB51119A6A@cisco.com>
Date: Wed, 14 Sep 2016 12:46:47 -0400
Message-Id: <7FA11A21-D8BC-4829-B6D5-EE2B44200D8E@cisco.com>
References: <4C52DDE4-07CF-4F5F-8DB7-8CEB51119A6A@cisco.com>
To: Gonzalo Salgueiro <gsalguei@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/f_beIBObjU0emSfFNrPcQJo1g9A>
Cc: "Arun Arunachalam (carunach)" <carunach@cisco.com>, "ben@nostrum.com" <ben@nostrum.com>, "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>, "insipid@ietf.org" <insipid@ietf.org>
Subject: Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Sep 2016 16:46:54 -0000

Sorry for the delay in commenting. Here’s some feedback:

Abstract: It states "that marks the PDU as a candidate for logging”. Does this really just mark the particular message for logging or does it mark the entire session for logging? Section 4 says "Subsequent responses and requests in the same dialog are logged” which means to me that the indicator affects the logging of more than just the PDU, but then Section 5, REQ7 makes it possible for stateless intermediaries to only log based on the presence of the marker. Then REQ9 makes it seem like the marker must be present in all messages in the dialog.

Section 1 Introduction: Why are we singling out service providers? Wouldn’t this be useful in large enterprise environments as well?

Section 4: This was already mentioned, but requiring that messages be logged in their long form doesn’t seem like a good idea to me. This could be computationally intensive and what is the reason for the failure is that a device is not handling headers in their compact form correctly? Seems like we should try to preserve as much of the original, raw message as possible.

Section 5, REQ 5: What about new requests within the same dialog / session (e.g. ACK or re-INVITE)? I think those should also include the log me marker as well.

REQ8: Should update to latest session-id draft. Also, I have some concerns about using Session-ID as the test case identifier. The Session-ID can change (in fact will change for every session because the initial INVITE will have a null remote UUID).

6.2.1 - “MUST not” should be “MUST NOT”

Also, there is a non-normative use of “must” and “must not” in this section. Is that intentional? Does the debugging configuration have to be supplied by a server? Can the debug configuration not be done locally on the terminal?

Same thing with the logs. Do they have to be sent to a server? Can they just be retained locally on the terminal?


I only see mention of Proxies, but not other intermediaries such as B2BUA’s. I think there should be some call out to be encompassing of all intermediaries.


-Paul






> On Aug 20, 2016, at 1:18 AM, Gonzalo Salgueiro (gsalguei) <gsalguei@cisco.com> wrote:
> 
> Dear INSIPID Participants,
> 
> We have finally completed the Session-ID draft and it is now in the RFC Editor’s queue. It is now time to move forward with the completion of the pending bottlenecked milestones. The first one of these is draft-ietf-insipid-logme-reqs, which has previously received sufficient review and currently has no pending unaddressed issues.
> 
> This message begins a Working Group Last Call on draft-ietf-insipid-logme-reqs-07 (https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs-07 <https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs>), to end on Friday September 9th, 2016. Please post comments and feedback to the insipid@ietf.org <mailto:insipid@ietf.org> list, including just a simple "looks good” if you have read the draft and have no material comments.
> 
> I kindly request the authors to please address any WGLC comments in a timely fashion.
> 
> It is my hope we can muster the energy for a final push to finish up the two remaining milestones and then close out this WG.
> 
> Regards,
> 
> Gonzalo (as chair)
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid