IETF Logo Mail Archive

Re: [Insipid] draft-ietf-insipid-session-id versus RFC 3323

Brett Tate <brett@broadsoft.com> Wed, 29 June 2016 19:47 UTC

Return-Path: <brett@broadsoft.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 D91F212D1A7 for <insipid@ietfa.amsl.com>; Wed, 29 Jun 2016 12:47:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=broadsoft-com.20150623.gappssmtp.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 Phcc4-377q9H for <insipid@ietfa.amsl.com>; Wed, 29 Jun 2016 12:47:20 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 CA74C12B020 for <insipid@ietf.org>; Wed, 29 Jun 2016 12:47:19 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id q79so107498053qke.0 for <insipid@ietf.org>; Wed, 29 Jun 2016 12:47:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-transfer-encoding; bh=KTsLcNZYuL94mB1DD3h49WJ6AKx3csrv+o3MaqdbiwU=; b=T2+fOXkcFmuZprIVVXFSnoLYiTXKZ5fJyioqZZoqcmZIWQWv/DjO8GaOiH+dMdsptL vEetZCnV6nLAa7fRISskwFLzO0s39+kcGM4C0R2/UlGEegOEjXbfi6UDHqv+mVdrqTUK GgnAtSZubczfFZtEAPf5u1VmuOS+h7jtiZVRPTNHD1OtnKEOYkDhWO6SVlR0ZKPF9nbO szpWg5+xwuV4Re6E5JwBloW/4e3rioT3MRyl5o4wvXcABZ8uRQN2EkVkdmoFknE7obxt x5s2TUp446gNdPWO3cz+YnhfwrSX59VB9b1HGoS8BdZV7K6PdZO9AUHKgB0HBPCwhu4L cuUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-transfer-encoding; bh=KTsLcNZYuL94mB1DD3h49WJ6AKx3csrv+o3MaqdbiwU=; b=RlcZIuy6u7gLEOsPZZ0gevaNgSdBfTy2vI++umGeQ8HEf9d0gtam0ysei3a9gzF/Nz KNSI6O1huouy948AX5PuZ7V8LfVnMTWfoy7hsMjyC67G06qz+6d8wxX83atVJMrgdGYW GNAS/rRKwQJlIX9cuou+i+DqQAxZYLmEsq7yOkYpTHRpQnZF9c2ll/T/QipViHU47j37 +vZ7s4OgLpCH5VZlN1YEZP8LLM5eR/9LhmJYAYXWmFVQr+zVj5+aZpbNQCNoA2SQIQWT uZtzsJrH/Fjr87m2P41YKN1RNNJaF9Xv0V+7uaG+rc3lUkNsbM5cAsdpc871YJh4QrOI IFVA==
X-Gm-Message-State: ALyK8tKtV8UFPLj0uf6IBcFcTsZBTVwcICWj4JNfOfxDnjAQInxveghWF0RWvBB4Dgctc5FveHHBKxfOvy1MFzO2
X-Received: by 10.55.6.148 with SMTP id 142mr12153752qkg.206.1467229638947; Wed, 29 Jun 2016 12:47:18 -0700 (PDT)
From: Brett Tate <brett@broadsoft.com>
References: <21575ee6e889d5d4fdd306e7ca579185@mail.gmail.com> <D98EFE31-60FF-4038-8D81-36572B4A39CF@cisco.com>
In-Reply-To: <D98EFE31-60FF-4038-8D81-36572B4A39CF@cisco.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJYHjEyn2HnOUIArFJ66fkofx5w4wEVOIbFnusWd3A=
Date: Wed, 29 Jun 2016 15:47:18 -0400
Message-ID: <fe19523ad1cfdc0d74894e5ac2902753@mail.gmail.com>
To: "Paul Giralt (pgiralt)" <pgiralt@cisco.com>, insipid@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/dZypicDrC-X8922WQjDZ4Yo_LoU>
Subject: Re: [Insipid] draft-ietf-insipid-session-id versus RFC 3323
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, 29 Jun 2016 19:47:22 -0000

Hi,

Thanks for the response; reply is inline.

> Could it be considered “essential” for troubleshooting?
> Maybe not because you could troubleshoot without it - it
> would just be more difficult - but it is not absolutely
> necessary (essential). However, a customer may have some
> diagnostic infrastructure in place that relies on the
> presence of the Session-ID header in which case then
> it is essential for their tools to work.

I agree that some administrators might not want Session-ID to be removed.


> Are there any examples of other headers that
> implementers of 3323 have not removed based on the
> clause in section 5.3?

I assume that vendors have applied the concept in a variety of ways with
various degrees of configurability.


> Do you have a strong opinion either way?  I can see
> arguments for and against removing it, so I don’t have
> a strong opinion.

I also do not have a strong opinion.


> Either way, does it bear mentioning in the Session-ID
> specification?

Depending upon interpretation, draft-ietf-insipid-session-id and RFC 3323
have conflicting mandates.

If the working group desires a specific behavior, it should likely be
discussed within the draft if RFC 3323 causes an ambiguity or conflict with
the desired behavior.

If the intermediary removes the Session-ID, I assume that a different (or
maybe the same) intermediary might add a different Session-ID.

As usual, the topic of privacy related to lawful intercept doesn't need to
be discussed.  I assume that some vendors will implement conferenced lawful
intercept as not being a conference.

v2.23.0 | Report a Bug | By Email