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

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Thu, 16 August 2018 09:40 UTC

Return-Path: <Peter.Dawes@vodafone.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 338171286E3; Thu, 16 Aug 2018 02:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 PXA6c5ct3dst; Thu, 16 Aug 2018 02:40:42 -0700 (PDT)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054DC129619; Thu, 16 Aug 2018 02:40:40 -0700 (PDT)
Received: from [85.158.142.200] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-b.eu-central-1.aws.symcld.net id 7C/88-11008-696457B5; Thu, 16 Aug 2018 09:40:38 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNJsWRWlGSWpSXmKPExsWi75kzT3eqW2m 0wdbNFhbbj69ismh8MI3dYv+lOYwWc6f4Wcz4M5HZ4sX1j8wWjx79YLKYf/8ZkwOHx5TfG1k9 Tiy7wuqxZMlPJo+WjwtZA1iiWDPzkvIrElgztrxaxVbw8ytjxdWWOewNjA8+MXYxcnEICWxnl LhxeBmUc5hR4tzbfla4zP+ul1DORUaJw09/MEE4U5kknt3eyA7hPGaUOHp8BXMXIwcHm4C9xI w9MV2MnBwiAsYShyd/B+tmFmhhllhzaBHYEmGBHkaJ/e2tYN0iAr2MEntu/mOBaAmTOHDyLzO IzSKgKjHh5lsmEJtXIEFi7aZuNoh1a5gl7h38wgaS4BRwkri4Yw2YzSggK/GlcTVYM7OAuMSt J/PBmiUEBCSW7DnPDGGLSrx8/A/sJl6BRywSv/6uZIJojpKY/PE6VIOixLZbZ1khbFmJS/O7w e6WEDjALvHt9C+ohK7Eh6lToab6Sixc/54Vougko0TT7pnsoNCQENCRmPA1FKImX2Lxkw42iH CNxIx/4RBhOYlVvQ9ZJjAazUJy9yygKmYBTYn1u/QhwooSU7ofss8Ch4WgxMmZT1gWMLKsYrR IKspMzyjJTczM0TU0MNA1NDTWNdG1MNFLrNJN0kst1U1OzSspSgRK6iWWF+sVV+Ym56To5aWW bGIEJjMGINjBeHx6yiFGSQ4mJVFe/eriaCG+pPyUyozE4oz4otKc1OJDjDIcHEoSvL2updFCg kWp6akVaZk5wLQKk5bg4FES4f0PkuYtLkjMLc5Mh0idYrTnmPWsexIzR9vxfiD55/1UIHmne9 okZiGWvPy8VClx3jMgbQIgbRmleXBDYXngEqOslDAvI9CZQjwFqUW5mSWo8q8YxTkYlYR5I0G m8GTmlcDtfgV0FhPQWdMEwM4qSURISTUwJu0++nX3zT9/T+Ta5fdd22Kh4mp7wOiwj/6WxPua Kzb9Mz75c/n+DA/GpLfs0nN9F3MU3Q62eWWQzOodW2/et5OP800K19btcWWf3y89mXQ50DU7R MyhnPf/zR8TE1yubJ/5tyra/eQODS7OeemPPDbMNz0gdeN41YuqOGf/3YpbJ29Tf5M6V4mlOC PRUIu5qDgRANsYwCn+AwAA
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-26.tower-245.messagelabs.com!1534412437!4675621!2
X-Originating-IP: [47.73.108.158]
X-SYMC-ESS-Client-Auth: outbound-route-from=pass
X-StarScan-Received:
X-StarScan-Version: 9.9.15; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32649 invoked from network); 16 Aug 2018 09:40:37 -0000
Received: from vgdpm16vr.vodafone.com (HELO voxe04hw.internal.vodafone.com) (47.73.108.158) by server-26.tower-245.messagelabs.com with AES256-SHA256 encrypted SMTP; 16 Aug 2018 09:40:37 -0000
Received: from VOEXH11W.internal.vodafone.com (47.73.211.215) by edge1.vodafone.com (195.232.244.49) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 16 Aug 2018 11:40:34 +0200
Received: from voxe05hw.internal.vodafone.com (195.232.244.50) by VOEXH11W.internal.vodafone.com (47.73.211.209) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 16 Aug 2018 11:40:34 +0200
Received: from VOEXH06W.internal.vodafone.com (47.73.211.204) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 16 Aug 2018 11:40:33 +0200
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (172.17.213.43) by VOEXH06W.internal.vodafone.com (47.73.211.210) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 16 Aug 2018 11:40:32 +0200
Received: from AM5PR0501MB2465.eurprd05.prod.outlook.com (10.169.150.10) by AM5PR0501MB2515.eurprd05.prod.outlook.com (10.169.150.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1059.20; Thu, 16 Aug 2018 09:40:30 +0000
Received: from AM5PR0501MB2465.eurprd05.prod.outlook.com ([fe80::a17b:3f43:e94f:42ee]) by AM5PR0501MB2465.eurprd05.prod.outlook.com ([fe80::a17b:3f43:e94f:42ee%9]) with mapi id 15.20.1038.025; Thu, 16 Aug 2018 09:40:30 +0000
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
CC: "Arun Arunachalam (carunach)" <carunach=40cisco.com@dmarc.ietf.org>, "Arun Arunachalam (carunach)" <carunach@cisco.com>, "insipid-chairs@ietf.org" <insipid-chairs@ietf.org>, "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>, "insipid@ietf.org" <insipid@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-insipid-logme-marking@ietf.org" <draft-ietf-insipid-logme-marking@ietf.org>
Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-insipid-logme-marking-12:_(with_COMMENT)?=
Thread-Index: AQHUM95jlO2wh//a3USYU+l+rVis76S/dTYAgABbKwCAAJvqAIAAdnCAgAEwRoCAAAWs0A==
Date: Thu, 16 Aug 2018 09:40:30 +0000
Message-ID: <AM5PR0501MB246514BAE0FA7DFF60BB2AB3973E0@AM5PR0501MB2465.eurprd05.prod.outlook.com>
References: <153417744610.24989.8583018232862453031.idtracker@ietfa.amsl.com> <47069B3D-25CE-409F-9099-E235D656C498@cisco.com> <a7811c35-2843-1b8b-1862-4fe7e0abe69a@kuehlewind.net> <CBE69AF1-8AFC-4FC2-898A-0D70B96BE009@cisco.com> <4EA01E28-6DEB-4B6F-861F-E2C753E37541@kuehlewind.net> <AM5PR0501MB24654C915AD02EC5CDE97233973F0@AM5PR0501MB2465.eurprd05.prod.outlook.com> <C329E425-B4EB-48D0-AE1F-965F92965486@kuehlewind.net>
In-Reply-To: <C329E425-B4EB-48D0-AE1F-965F92965486@kuehlewind.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17da11e7-ad83-4459-98c6-12a88e2eac78_Enabled=True; MSIP_Label_17da11e7-ad83-4459-98c6-12a88e2eac78_SiteId=68283f3b-8487-4c86-adb3-a5228f18b893; MSIP_Label_17da11e7-ad83-4459-98c6-12a88e2eac78_Owner=peter.dawes@vodafone.com; MSIP_Label_17da11e7-ad83-4459-98c6-12a88e2eac78_SetDate=2018-08-16T09:05:03.2551886Z; MSIP_Label_17da11e7-ad83-4459-98c6-12a88e2eac78_Name=Unclassified; MSIP_Label_17da11e7-ad83-4459-98c6-12a88e2eac78_Application=Microsoft Azure Information Protection; MSIP_Label_17da11e7-ad83-4459-98c6-12a88e2eac78_Extended_MSFT_Method=Manual; Sensitivity=Unclassified
x-originating-ip: [47.73.248.151]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0501MB2515; 6:PSedh7Ixi2uTA+LUehsE0z1JVXwW98eIoqs9ZOWqAYfMf/CazpdRFjC0U1V1OL8p/5uFU0r9Qa/6vmHPMVZC/3T/d+bHBhzlvkFx9ef7r7NCbUuozgp7HzDWcoov7fYJoSvwqq/Y85et5xfexGZLhbe+dn46/nYKgf1ZPG9b9lab8vdusIJcofQDoVIsaWEFUUDEtNS7j2GaFGNsQ4fIWpoDIdWwnOrkOG1jaMQX7zPGCRKXbimnUEbMeQ9RQoF8+ow0dVZ35s61qWIHNHkdz4xWRPpVn3TaEBQbvdNN4Ta7Y/TbQBzV5JMa/zS7DP29kCBxmSk/GDYPbEKlFWEtF1wisnS8v5yolIMFM7fIDSNC9BMG5vPGLv+E/BabANfxZjE6pWyWXgNDQo0ERNAxH+wPwMGGd3chZeSnabJQpLLK3gl7rdFkmrtieHVOilhF89z7vtOWdNMy3XGFwezOhA==; 5:zKvKM0Qxnon5wiFmRZwC8PWaHxHioxlEV1MteFYaHO9vjqmZEkpHyNGHyUT43klb5NkXcu+evhg2E3vmOvqCpzxx0uhd7PVZeLlws6a5+aSP1bZ5m4qNWit5glZyxZGIpKcp/bfu2j3f0YiC4Y0VnTbZpmlvkV9LEI9uG8cdjpY=; 7:mjjxLxOj/2gsinEY7NU1/Q/Un5rKeeKWdsrq3bKsP0g8nSg2LIG4qcS0+5ebG7fIDLVFUYSDR1tzTweKQzUTSmvGKdz+nha/fWFCWKDZIZch2ctwTmYr22dQn290HS3MeQnxjmq81gssBkdgTf1t1rdDUnY6vf4rQR+f4q54/CpE+Q4fse3zLW1Poi40hQxTYxSfTZZy7RLKXb7uFW5XKLTFHNm/nZFfQkf7/LQdWchn/9aNzhgt1xyHdJjq+hQT
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 113da6a3-2967-4e1a-f727-08d6035c4e88
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM5PR0501MB2515;
x-ms-traffictypediagnostic: AM5PR0501MB2515:
x-microsoft-antispam-prvs: <AM5PR0501MB2515B51045EA76E5A709ECE5973E0@AM5PR0501MB2515.eurprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(67444318432085)(120809045254105)(192374486261705)(95692535739014)(29966359920796);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231311)(11241501184)(806099)(944501410)(52105095)(3002001)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699016); SRVR:AM5PR0501MB2515; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0501MB2515;
x-forefront-prvs: 07665BE9D1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(39860400002)(396003)(366004)(376002)(13464003)(199004)(189003)(486006)(256004)(55016002)(14444005)(97736004)(6506007)(76176011)(102836004)(7696005)(81166006)(316002)(6436002)(53546011)(2900100001)(53946003)(99286004)(86362001)(81156014)(476003)(966005)(54906003)(68736007)(25786009)(3846002)(6116002)(6916009)(11346002)(6306002)(72206003)(53936002)(93886005)(478600001)(9686003)(446003)(66066001)(4326008)(14454004)(26005)(74316002)(229853002)(2906002)(186003)(6246003)(7736002)(33656002)(8936002)(305945005)(224303003)(224313004)(106356001)(5250100002)(105586002)(5660300001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0501MB2515; H:AM5PR0501MB2465.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: vodafone.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: eMctmzjgcadeBNrxsjPolzUIJGAb4BmQ2UvICYrERft/yaIbrtE4M/3bJcR8ViplUxsJXobSj57qraFn3/c9XaaDs0mKw2I3CZfY6F5EkscG3mKlkud4WQ/1/HxfrPsp/4PLWmxJM23mX7k6QXLKs5/Uw7Afk8PNAWMoYgCP0csDlGXm+jGJ9Hbn/Tku+gRBfDWrcNBTsKkApDHRebZMDRDP2oeNfxYEgIUpUvJP5EIt+FZD715ScUNg6Cx1shDYrk6QAPG7HcQdnpP3ahDsCgDmDpVMhtEWYSzSxHcrUHdwvu6TEJ3Bm2nVXqFDY2+Hho7e1uWDFYsv5wS+xtAhytT9R6kToBOIlHizALSGVL46wr//IWa3L1f4OYwS9WkiW/GW8WyFOnRnUxcj7AQMtQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
x-ms-exchange-crosstenant-network-message-id: 113da6a3-2967-4e1a-f727-08d6035c4e88
x-ms-exchange-crosstenant-originalarrivaltime: 16 Aug 2018 09:40:30.6965 (UTC)
x-ms-exchange-crosstenant-fromentityheader: Hosted
x-ms-exchange-crosstenant-id: 68283f3b-8487-4c86-adb3-a5228f18b893
x-ms-exchange-transport-crosstenantheadersstamped: AM5PR0501MB2515
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: vodafone.com
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/OiKU-SaOdP6f8fZx-LNl3nbvpmo>
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-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.27
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: Thu, 16 Aug 2018 09:40:45 -0000

Hi Mirja,
Please see in-line below a response on missing marker handling based on the motivating scenario in the requirements RFC 8213.

-Peter

> -----Original Message-----
> From: Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>;
> Sent: 16 August 2018 09:45
> To: Dawes, Peter, Vodafone Group <Peter.Dawes@vodafone.com>;
> Cc: Arun Arunachalam (carunach) <carunach=40cisco.com@dmarc.ietf.org>;;
> Arun Arunachalam (carunach) <carunach@cisco.com>;; insipid-
> chairs@ietf.org; Gonzalo Salgueiro (gsalguei) <gsalguei@cisco.com>;;
> insipid@ietf.org; The IESG <iesg@ietf.org>;; draft-ietf-insipid-logme-
> marking@ietf.org
> Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-insipid-logme-
> marking-12: (with COMMENT)
>
> Hi Peter,
>
> see below.
>
> > Am 15.08.2018 um 16:57 schrieb Dawes, Peter, Vodafone Group
> <Peter.Dawes@vodafone.com>;:
> >
> > Hi Mirja,
> > Please find some further proposals trying to resolve your comments in-line
> below. Thanks again for your review.
> >
> > Regards,
> > Peter
> >
> >> -----Original Message-----
> >> From: Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>;
> >> Sent: 15 August 2018 08:32
> >> To: Arun Arunachalam (carunach)
> <carunach=40cisco.com@dmarc.ietf.org>;
> >> Cc: Arun Arunachalam (carunach) <carunach@cisco.com>;; insipid-
> >> chairs@ietf.org; Dawes, Peter, Vodafone Group
> >> <Peter.Dawes@vodafone.com>;; Gonzalo Salgueiro (gsalguei)
> >> <gsalguei@cisco.com>;; insipid@ietf.org; The IESG <iesg@ietf.org>;;
> >> draft- ietf-insipid-logme-marking@ietf.org
> >> Subject: Re: Mirja Kühlewind's No Objection on
> >> draft-ietf-insipid-logme-
> >> marking-12: (with COMMENT)
> >>
> >> Hi Arun,
> >>
> >> please see below.
> >>
> >>> Am 15.08.2018 um 00:13 schrieb Arun Arunachalam (carunach)
> >> <carunach=40cisco.com@dmarc.ietf.org>;:
> >>>
> >>> Thanks Mirja.
> >>>
> >>> We would like to get a couple of clarifications. Please see inline.
> >>>
> >>>
> >>>> On Aug 14, 2018, at 12:47 PM, Mirja Kühlewind <ietf@kuehlewind.net>;
> >> wrote:
> >>>>
> >>>> 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
> >>>>>> <ietf@kuehlewind.net>;
> >> 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
> >>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >>>>>> for more information about IESG DISCUSS and COMMENT positions.
> >>>>>>
> >>>>>>
> >>>>>> The document, along with other ballot positions, can be found here:
> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking
> >>>>>> /
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -----------------------------------------------------------------
> >>>>>> --
> >>>>>> ---
> >>>>>> COMMENT:
> >>>>>> -----------------------------------------------------------------
> >>>>>> --
> >>>>>> ---
> >>>>>>
> >>>>>> 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.
> >>
> >>
> >> Sorry I was actually copied the wrong statement:
> >>
> >> "Once the "log me" marking is started for a dialog, all subsequent
> >>   requests and responses in this dialog are "log me" marked and marking
> >>   is stopped when this dialog and its related dialogs end.“
> >>
> >> This is not normative, so there is no conflict, but it’s a bit
> >> confusing given you don’t know if the other end supports logme or
> >> not. If you could clarify, that it is okay to probe with a logme
> >> message in the first request and then see if the other end replies,
> >> would be really helpful I think. Also if you send a logme message and
> >> the other end does not send one back, should other messages for me
> >> originating host in the same dialog be marked or not? That is not
> >> fully clear and it is seems that most of the normative statements in
> >> the draft only apply to the case where both hosts (or some intermediate
> on both sides) are already known to support logme. Maybe double-check!
> >>
> >
> > The main aim of 3.2 is to set the boundaries of the protocol impact and
> outline the maximum ideal case, rather than to be normative procedural
> specification. Also, end-to-end support is not assumed by the mechanism so
> how about the following revision:
> >
> > 3.2.  Starting and Stopping Logging
> > In the ideal case, marking starts with a dialog-initiating request (described
> in Section 12.1 of [RFC3261]), continues for the lifetime of the dialog and
> ends when the dialog ends, applies to each request and response in that
> dialog, and applies end-to-end including user devices. The proportion of the
> signalling path that is marked can be reduced by non-support of the “log me”
> marking mechanism or removal of the “log me” marker by one or more
> endpoints or intermediaries(see Section 3.4.2, Section 3.4.3, and Section
> 4.5.2), and marking errors can terminate marking before the dialog ends (see
> Section 5). The “log me” marking mechanism will still work even if parts of
> the signalling path do not support it but troubleshooting and testing is most
> effective if marking is carried uninterrupted end-to-end.
>
> Yes, thanks. That’s clear now.
> >
> > Your question "Also if you send a logme message and the other end does
> not send one back, should other messages for me originating host in the
> same dialog be marked or not? " is a valid one, but marking needs user or
> administrator permission to be used and must be explicitly configured by a
> network administrator. Also, it lasts for only a single SIP dialog. Therefore if,
> for example, only a single terminal supports it then we would expect such a
> terminal to not be configured to use it, or if it is then it will have no effect on
> the terminal or the network other than cause the terminal to log its own
> messages for one dialog. So we don’t think the draft needs to provide any
> detection or handling of such cases.
>
> For me the document somehow read like an endpoint should detect that the
> other end (as well as no intermediate that could proxy) supports marking
> and stop marking. You are right that that does really have any effect on the
> scheme. However, clarifying that such a detection does not need to be
> implemented, could help. On the other hand, I would actually need to re-
> read to figure out why I was assuming that. Maybe it’s already better with
> the new text above.
>
>
> >
> >>>
> >>>
> >>>>
> >>>> 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.
> >>>
> >>>
> >>> We plan to move it to Section 5.
> >>>
> >>>
> >>>>
> >>>>>
> >>>>> 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.
> >>>
> >>>
> >>> The situations when “log me” marking can be safely removed is
> >>> discussed
> >> in Section 8.2 "Log Me" Marker Removal” and in Section 8.3 “Denial of
> >> Service Attacks". Please let us know whether these sections address
> >> your comment
> >> (or) whether we are missing something specific.
> >>>
> >> These sections only discuss the case of inter-domain traffic. My
> >> question was should an intermediate that understands logme also
> >> remove markings in error cases (markings show up mitdterm or
> >> something)? Maybe you can say something more in section 5 or 4.6.
> >>
> >
> > We can further clarify Section 4.6 (which will be moved to within Section 5)
> as below. This section specifies error handling by both UAs and
> intermediaries.
> >
> > 4.6.  Error Handling
> >
> >   Two error types are defined in Section 5, a missing marker error and
> >   an error of "log me" marking that begins mid-dialog.  Section 6 gives
> >   exceptions which have a missing marker or marking that begins mid-
> >   dialog but are not errors.
> >
> >   If a missing marker error is detected by a “log me” aware UA, SIP
> intermediary,
> >   it SHOULD consider this as an error condition.  It MUST NOT
> >   mark subsequent requests and responses and MUST stop logging
> messages
> >   in the same dialog.  Any previously logged messages SHOULD be
> >   retained and not deleted.
> >
> >   If a "log me" marking that begins mid-dialog error is detected by a
> >    “log me” aware UA, SIP intermediary, it SHOULD consider this as an error
> >   condition.  A UA MUST ignore the “log me” marker, SIP intermediaries
> MUST
> >   remove the "log me" marker from the Session-ID
> >   header prior to forwarding the message to the next hop and the received
> message
> >   MUST NOT be logged.  It MUST NOT mark subsequent requests and
> responses and
> >   MUST NOT log subsequent messages in the same dialog.
>
> Thanks.
>
> However, now that you said above that an UA does not need to detect that
> no one else is supporting marking (and subsequently marking anyway if
> configure to do so), I’m wondering why intermediates are required to
> remove the mark in this case…? Is that because UA marking without any
> additional support on the other end is seen as an error? If so that goes back
> to my initial question: How do you know that both endpoints are "log me"
> enabled? I guess in this case the answer is you have to have „out-of-band“
> knowledge by configuration and should not try to just test and see if the
> other end echos the marking back…?
>

"log me" aware UAs and intermediaries remove marking in error cases to protect their network from malicious marking and marking errors, but not all missing markers are errors. In the scenario below from RFC 8123, it might be that Operator A supports "log me" marking and wants to perform end-to-end testing between its networks in different countries. So a marked INVITE sent from Operator A in COUNTRY W would expect "log me" marking to be echoed by Operator A UAs in COUNTRY X. In this case a missing marker in responses means something is wrong (missing marker error) and "log me" marking stops. However, if Operator A is experiencing failures when setting up calls with Operator B in COUNTRY Y who does not support "log me" marking, Operator A would not expect marking to be echoed by UAs belonging to Operator B. In this case Operator A uses the procedure in 4.5.2.5 where a SIP intermediary acts on behalf of the terminating network in order to support logging in its own network. In this case a missing marker from Operator B is a non-error case as described in 6.1.

From RFC 8123

Example Network Arrangement


   The figure below gives an example of a signaling path through
   multiple networks.

      +------------------+          +------------------+
      | COUNTRY W        |          | COUNTRY X        |
      | Operator A       |          | Operator A       |
      |                  |          |                  |
      | SIP Phones       |          | SIP Phones       |
      |                  |        //|                  |
      +------------------+       // +------------------+
             |                  //
             |                 //
          ,'```',             //    +------------------+
      .`',.'      `..'``',<==//     | COUNTRY X        |
      ,'  Operator A         `',    | Operator A       |
      ;    Backbone Network    ..'--|                  |
      ',            ,.,    .'`      | PSTN phones      |
      '.,.`'.,,,.`   `''`           |                  |
             ||                     +------------------+
             ||
             \/
      +------------------+
      |                  |
      |  Transit Network |
      |                  |
      |                  |\\
      +------------------+ \\
              |             \\
              |              \\
      +------------------+    \\    +------------------+
      | COUNTRY Z        |     \\   | COUNTRY Y        |
      | Operator C       |      \\=>| Operator B       |
      |                  |          |                  |
      | SIP Phones       |          | SIP Phones       |
      |                  |          |                  |
      +------------------+          +------------------+


        Figure 1: Example Signaling Path through Multiple Networks




>
>
> >
> >>
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>> 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 4.5.2.5.
> >>>>
> >>>> Yes, the scenarios is fine but providing guidance that ingress
> >>>> filtering
> >> should be done, should probably be also discussed in the security
> >> considerations section.
> >>>
> >>>
> >>> We think the following text in Section 8.2 covers both egress and
> >>> ingress
> >> filtering:
> >>>
> >>> "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.”
> >>>
> >>> If we need to explicitly mention ingress filtering, we can update the text
> as:
> >>>
> >>> "If SIP requests and responses are exchanged with an external
> >>> network with which there is no agreement to pass "log me" marking,
> >>> then egress/ingress filtering is applied to remove "log me” marking
> >>> as mandated in section 3.4.2.“
> >>
> >>
> >> I somehow happen to read this only as egress filtering. But you are
> >> right, it doesn’t say that. However, it probably doesn’t hurt to be explicit
> here.
> >>
> >
> > We can add a paragraph at the end of 8.2 to cover deliberate removal of
> "log me" marking in order to prevent logging as follows.
> >
> > 8.2.  "Log Me" Marker Removal
> >
> >
> >   The log me marker is not sensitive information, although it will
> >   sometimes be inserted because a particular device is experiencing
> >   problems.
> >
> >   The presence of a log me marker will cause some SIP entities to log
> >   signaling messages.  Therefore, this marker MUST be removed at the
> >   earliest opportunity if it has been incorrectly inserted, such as
> >   appearing mid-dialog in a dialog that was not being logged or outside
> >   the configured start and stop of logging.
> >
> >   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, for both ingress and egress, as mandated
> >   in Section 3.4.2.
> >
> >  If SIP requests and responses are sent or received by a network
> >   that wishes to prevent logging, then the "log me" marking is removed,
> >   for both ingress and egress, as described in Section 4.5.2.4.
>
> That would be good.
>
> Mirja
>
>
> >
> >> Thanks!
> >> Mirja
> >>
> >>
> >>>
> >>> Thanks!
> >>> Peter & Arun
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>> Mirja
> >>>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>> 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
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >