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

Mirja Kühlewind <> Tue, 14 August 2018 16:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73990130DD3 for <>; Tue, 14 Aug 2018 09:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vvRQbCKf77qw for <>; Tue, 14 Aug 2018 09:48:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2DE9512D949 for <>; Tue, 14 Aug 2018 09:48:27 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default;; b=YCofHI65bo6XMKJJbZVkxkQeT4wkuR+AWkrV1cdcPcDhhTQlSGHr/L0RkH5RdgZHGiyr/4lqPmGcFy18rbbs6oRQptI8UN4XdG3zhwoigeecqDByWPyILRGSiioegPz9b+84XHFdnev2n+LWshxMgJqIg3ltlowXj25Ca61y6L4=; h=Received:Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 28152 invoked from network); 14 Aug 2018 18:47:24 +0200
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 14 Aug 2018 18:47:24 +0200
To: "Arun Arunachalam (carunach)" <>
Cc: The IESG <>, "" <>, "" <>, "Gonzalo Salgueiro (gsalguei)" <>, "" <>, "Dawes, Peter, Vodafone Group" <>
References: <> <>
From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= <>
Message-ID: <>
Date: Tue, 14 Aug 2018 18:47:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------C279463A95F8AC56B6EEFC4D"
Content-Language: en-US
X-PPP-Message-ID: <>
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: Tue, 14 Aug 2018 16:48:31 -0000

Hi Arun, hi Peter,

please see below.

On 14.08.2018 16:51, Arun Arunachalam (carunach) wrote:
> Hi Mirja,
> Thanks for taking the time to review and sharing feedback!
> Please see inline.
>> On Aug 13, 2018, at 12:24 PM, Mirja Kühlewind < 
>> <>> wrote:
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-insipid-logme-marking-12: No Objection
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> Please refer to
>> for more information about IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> 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. "

Maybe you can clarify this and maybe also spell out more explicitly in 
the document what you just explained above.

>> 2) Sec 3.2: "firstly because it is configured to
>>   do so, or secondly because it has detected that a dialog is being
>>   "log me" marked, causing it to maintain state to ensure that all
>>   requests and responses in the dialog are similarly "log me" marked."
>> I was first quite confused by this sentence because I though the 
>> second case
>> meant that intermediates needs to ensure that all messages are marked
>> correctly. However, I guess the second case is when the other ends is
>> configured to do marking, one needs to reply with the marking as 
>> well. I think
>> I was mainly confused by the word "detects". Maybe it's worth to further
>> clarify this sentence…?
> We can rephrase as:
>    A user agent or intermediary adds a "log me" marker in an unmarked
>    request or response in two cases:firstly because it is configured to
>    add the marking to a dialog-creating request, or secondly because 
> it has
>    received a dialog-creating request that is being "log me" marked, 
> causing it to
>    maintain state to ensure that all requests and responses in the 
> dialog are
>    similarly "log me" marked.

Thanks! Much better for me!

>> 3) Section 4.6 feels a little misplace but I not sure where it belong 
>> otherwise
>> (maybe section 3 or 5?). Or maybe move section 4.5 in an own section 
>> later in
>> the doc…?
> We added "4.6 Error Handling” under Section 4 since this section talks 
> about endpoint and intermediary behavior. Error handling needs to be 
> implemented in SIP entities, and we could reword the beginning of 4.6. 
> to: "The two error types that SIP entities must handle are defined in 
> Section 5, a missing marker error and an error of "log me" marking 
> that begins mid-dialog."
> Or if needed, we could move it as first part of Section 5 and rename 
> this section as "5. Error Handling” and make “5.1 Error cases” as a 
> sub-section.
I'd prefer this solution. But it's just an editorial comment, so I leave 
it to you.

> Please let us know your preference.
>> 4) Also Section 4.6: "It MUST NOT forward the "log me" marker"
>> Does it mean an intermediate MUST remove the marker if an error is 
>> detected? Is
>> that safe given the proxy scenarios? If at all I would recommend to 
>> use MAY
>> here, I guess…
> If the proxy is logme aware then it is expected to remove logme marker 
> in error scenarios. It is safe to remove. The objective is to stop the 
> propagation of incorrect marking as soon as possible.

I have the feeling that this could be more explicitly spelled out in the 
doc and maybe also providing further guidance when it is actually safe 
to remove a marking would be really good.

>> 5) Sec 8.1.:
>> "An end user or network administrator MUST give permission for a
>>   terminal to perform "log me" marking in the context of regression
>>   testing or troubleshooting a problem. "
>> and
>> "The configuration of a SIP intermediary to perform
>>   "log me" marking on behalf of a terminal MUST be authorized by the
>>   network administrator."
>> I'm actually not sure what these normative sentences mean for an
>> implementation. Is this maybe rather "An implementation MUST provide a
>> configuration to active logging and logging MUST be disabled by 
>> default.”?
> We can rephrase as:
>   “Log me” marking MUST be disabled by default both at the endpoints 
> and intermediaries and MUST be enabled only by authorized users.
>    For example, an end user or network administrator must give 
> permission for a terminal that supports “log me” marking in order to 
> initiate marking.
>    Similarly, a network administrator must enable a configuration at 
> the SIP intermediary to perform "log me" marking on behalf of a 
> terminal that doesn’t
>    support “log me” marking. The permission MUST be limited to only 
> specific calls of interest that are originated in a given time duration.
Yes, thanks!

>> 6) Section 8.2:
>> "If SIP requests and responses are exchanged with an external network
>>   with which there is no agreement to pass "log me" marking, then the
>>   "log me" marking is removed."
>> Should this be normative, maybe:
>> "If SIP requests and responses are exchanged with an external network
>>   with which there is no agreement to pass "log me" marking, then the
>>   "log me" marking SHOULD be removed at the network border."
>> Or MUST?
> The last sentence in section 3.4.2 says “However, since a "log me" 
> marker may cause a SIP entity to log
> the SIP header and body of a request or response, if no agreement 
> exists between peer networks then the
>  "log me" marker MUST be removed at a network boundary.”
> So we can add a few words in 8.2 to say:
> "If SIP requests and responses are exchanged with an external network 
> with which there is no agreement to
> pass "log me" marking, then the "log me" marking is removed as 
> mandated in section 3.4.2."

Thanks, adding the reference really helps!
>> 7) Also a related question: Should a network perform ingress 
>> filtering/removal
>> of "log me" markers?
> Yes, this scenario is discussed in Section

Yes, the scenarios is fine but providing guidance that ingress filtering 
should be done, should probably be also discussed in the security 
considerations section.


>> 8) Nit:
>> Sec 2: I guess the following sentence was coped and pasted from 
>> RFC8123 and
>> should be removed for this doc: "Rather than describing interoperability
>>   requirements, they are used to describe requirements to be satisfied
>>   by the "log me" marking solution.”
> Yes, we will remove it.
> Thanks!
> Peter & Arun