Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions

Brett Tate <brett@broadsoft.com> Wed, 06 January 2016 15:07 UTC

Return-Path: <brett@broadsoft.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646571B2DBC for <insipid@ietfa.amsl.com>; Wed, 6 Jan 2016 07:07:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.279
X-Spam-Level:
X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
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 BWMbqpnVtgiv for <insipid@ietfa.amsl.com>; Wed, 6 Jan 2016 07:07:17 -0800 (PST)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 DA70F1B2C07 for <insipid@ietf.org>; Wed, 6 Jan 2016 07:07:16 -0800 (PST)
Received: by mail-wm0-x232.google.com with SMTP id l65so62614306wmf.1 for <insipid@ietf.org>; Wed, 06 Jan 2016 07:07:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to :content-type:content-transfer-encoding; bh=9XqXB774y56fsaeiPl4FtzMMkczd6zaETLQ+pB/w9HU=; b=RktYb1tZKlztrUSEB+4ORd0jcmZgnr4Ndn1PXDCMSa8uXDTnk0XcN2gL6H3CUAUnB3 cbWjNxfNFyjt8tijr1NAg3lGvlDVjwmSOrQSC6juQFN5dR52ce7rw5VRoQw5BuW9D7ic f5rRS2ysKN5/5qle6QGJKESOxLl+D0dyT/+nuguHTnrGdjy+yuhJywkGV6anG/vZ+XUK 6D+RyTnTjvW63/deh6v/PE90U9yGsFQHfkdq1UzlGsjgDqhSwErqT74sZvsbzbmWkH9e BuSeLrFZ5dpLK+M2IDzIB8aLTP4T2379+6yWP8Wke7srWf4bJ7gJOpoiCanEFJlvwsc9 R3ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type:content-transfer-encoding; bh=9XqXB774y56fsaeiPl4FtzMMkczd6zaETLQ+pB/w9HU=; b=Y02sirvviv2k+5Bcsl+dHvWj4DccA6IQzcJtu8MIW5wuI8/PqNBMtOsuUvylySm9V3 fHWVVBoukrXDDSqzmTJF7KQc9gbTrSDcKU+dJaE0eWcDl49LuKatHpiPTH5bvQ1CXWP7 qIqhYd2TPyJ9FQlb/pg4mUMx1vvDt24SJr3QlEIN2ycgIntpXptFBNRixDRc8dPs/we/ 4fRfWLBCtZswfcTPug9is1CY6B1CqoCJp4e6CJXrJcBtVq8JACXHaQN0w2UCguw6R9V5 9IhFM3tcAlM1FxZL22G1d489Rzx2HAU/Ei9C3XZuehNeUbyn3ngkXpEd49ttDKziNs/T NbYg==
X-Gm-Message-State: ALoCoQnACFc8PPAsZyOzgnspef37Bf5+mv5KiH3QVrbEOWxmkefS9bfsnOfqoRTkifLIEt0yEBcAwwUmYAj+ZTVzdyf6d1BPpWeyh/VnIPjzP34vXhPZiho=
X-Received: by 10.194.21.101 with SMTP id u5mr108609435wje.53.1452092835327; Wed, 06 Jan 2016 07:07:15 -0800 (PST)
From: Brett Tate <brett@broadsoft.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdFIk7nfPBr0WWyqRea8Ossvwf5GUw==
Date: Wed, 6 Jan 2016 10:07:14 -0500
Message-ID: <06a9f77d38a13c9991ec9a6fb7e0b042@mail.gmail.com>
To: insipid@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/8J0CKmvPFhX07Q02ofZWM9PmE54>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.15
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, 06 Jan 2016 15:07:18 -0000

Hi,

I'm glad to hear others within the working group agree that the draft (with
or without Paul Giralt's proposed changes) provides no way to avoid
intermediaries from sending inaccurate Session-ID values when generating
related requests and responses.  Similarly, the draft provides no way to
avoid endpoints from sending inaccurate remote uuid values when generating
requests and responses (although Paul Giralt's proposed change provides some
consistency concerning responses).

The inability of intermediaries to avoid sending inaccurate Session-ID
values when generating related requests and responses has been why I
occasionally ask for the limitation to be explicitly mentioned within the
draft and why I occasionally raise issues with the draft's MUST statements.

The draft currently allows intermediaries (excluding maybe any which might
be required to track the uuids) to not add Session-ID when generating
(instead of relaying) requests and responses.  This is because the draft
prefers no Session-ID instead of one which might cause a non-desired uuid
change.  I'm not sure if Paul Giralt intends to change this aspect of the
draft.

I'm not sure if the current limitations of the draft (or proposed change)
will meet the expectations of the working group or 3GPP.  However, I guess
that the draft will continue to evolve until it is abandoned or deemed good
enough.

Thanks,
Brett

> -----Original Message-----
> From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Giralt
> (pgiralt)
> Sent: Tuesday, January 05, 2016 5:22 PM
> To: Paul Kyzivat
> Cc: insipid@ietf.org
> Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and
> questions
>
> I don’t think it’s all doom and gloom. I think in the majority of cases
> the
> Session-ID will be consistent end-to-end. It is these corner case error
> conditions that lead to ambiguity as to the right thing to do which is why
> I’d prefer expected behavior be documented as clearly as possible, even if
> it
> may knowingly result in a situation where all devices don’t necessarily
> agree
> on the Session-ID for some period of time in the call. I think there will
> still be enough information in the message exchange that any
> post-processing
> tools being used to diagnose a problem will have enough information to
> correlate calls even in such scenarios.
>
> -Paul
>
>
> > On Jan 5, 2016, at 2:51 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> >
> > This discussion is reinforcing my belief that this mechanism is a mess -
> that the chance is slim to none of getting consistent results in all the
> connected devices.
> >