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

Brett Tate <> Wed, 29 June 2016 19:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D91F212D1A7 for <>; Wed, 29 Jun 2016 12:47:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Phcc4-377q9H for <>; Wed, 29 Jun 2016 12:47:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CA74C12B020 for <>; Wed, 29 Jun 2016 12:47:19 -0700 (PDT)
Received: by with SMTP id q79so107498053qke.0 for <>; Wed, 29 Jun 2016 12:47:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id 142mr12153752qkg.206.1467229638947; Wed, 29 Jun 2016 12:47:18 -0700 (PDT)
From: Brett Tate <>
References: <> <>
In-Reply-To: <>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJYHjEyn2HnOUIArFJ66fkofx5w4wEVOIbFnusWd3A=
Date: Wed, 29 Jun 2016 15:47:18 -0400
Message-ID: <>
To: "Paul Giralt (pgiralt)" <>,
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Insipid] draft-ietf-insipid-session-id versus RFC 3323
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Jun 2016 19:47:22 -0000


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.