Re: [Insipid] Mirja Kühlewind's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)

Ben Campbell <> Wed, 15 August 2018 00:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 386AA130E2F; Tue, 14 Aug 2018 17:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k6F_f29tNkhm; Tue, 14 Aug 2018 17:41:51 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D21AB130E35; Tue, 14 Aug 2018 17:41:51 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id w7F0fcPZ040783 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Aug 2018 19:41:39 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_D645F3F9-6580-4096-9E34-D2C192532D25"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 14 Aug 2018 19:41:36 -0500
In-Reply-To: <>
Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= <>, "Arun Arunachalam (carunach)" <>, "" <>, "Dawes, Peter, Vodafone Group" <>, "Gonzalo Salgueiro (gsalguei)" <>, "" <>, The IESG <>, "" <>
To: "Arun Arunachalam (carunach)" <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [Insipid] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-insipid-logme-marking-12=3A_=28with_COMMENT=29?=
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Aug 2018 00:41:54 -0000

> On Aug 14, 2018, at 5:13 PM, Arun Arunachalam (carunach) <> wrote:
>>>> A couple of quick comments/questions:
>>>> 1) How do you know that both endpoints are "log me" enabled? I guess because of
>>>> the requirement that all messages of a dialog must have the marker, you cannot
>>>> just add it and see if the other end is able to apply it to its responses…?
>>> It is not possible for the originating endpoint to determine whether the terminating endpoint or intermediary supports “log me” prior to setting up a dialog.
>>> If the originating endpoint sent an INVITE with logme marker and received a provisional or final response with logme marker then it can infer that one or more of the intermediaries in the call signaling path (or) the terminating endpoint supports "log me".
>> Okay, this does makes sense to me, however, it is a bit contradicting to the normative requirement in Section 3.2:
>> "If a request or response is "log me" marked, then all re-transmissions of the request or response MUST be similarly "log me" marked. “
> We are trying to better understand this comment specifically how it contradicts. The purpose of the above sentence was to address a scenario in which a SIP message with “log me” marker is sent over UDP and it gets re-transmitted. This sentence was added to make sure that the re-transmitted message also had the “log me” marker. Please explain.

Hi Arun,

I apologize that I missed this in previous reviews--but such a normative statement as in section 3.2 is unnecessary and redundant. That’s just the way SIP works. A retransmission is a retransmission of the _same_ request for purposes of UDP reliability.

This is in contrast with sending new messages associated with the dialog.