Re: [Insipid] Adam Roach's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)
"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Thu, 06 September 2018 10:42 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 A862F128CF2; Thu, 6 Sep 2018 03:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 UH6aW7_5QG3F; Thu, 6 Sep 2018 03:42:52 -0700 (PDT)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.1]) (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 57493130DEF; Thu, 6 Sep 2018 03:42:51 -0700 (PDT)
Received: from [46.226.52.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-a.eu-west-1.aws.symcld.net id 92/3E-18431-9A4019B5; Thu, 06 Sep 2018 10:42:49 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WTW0zTcBTG+bfdVggzZYAcEYzWy4PYsYEmMyb eE+cDamLURLxQoGw1YyPrCCAmosZEEeNQIEJQUFEQHrxtRBSDoIkZxslA4BGEAYKikuCFcNF1 nahvv3O+75zzpfmXxFXf5NEkl2vjrGbWRMtDiPidputMHVGcrLk/FaFrnr2p0J3qL1PoWjork e5ayS7d1ZliXDcw8BPTVfUNY5sV+pLpBzJ9Tc0Upq9o8hJ78IMy3pxqyU2RGd2eV7KsvvaQ3N bCW7ICNOgMLkQhpIpqROCtnMGkog3BmfNOYl55XuyVS0UHgu7XHbhUlGDw0vNIIRX9CMo/Tcs KEUnKqU1wtfmQ2I+gziIYGq/2T+DUEILZiRHfRDAZThmhduq2XOQIigd7+QCSeCsU1Vb7PQS1 AkaftuIiK6kUePPZEwjVg+DJ0EX/cLDv2qfBUkJkRMXC5KkG/wBORcHpybsykYGioKb5LS5xJ IwOzskk/0G4MtGLSf1lcO/XO0LiWOisuoDEY0A9V4DH6ZJLAgNfS0sDi5Kg7PuQXDK5ENQWOQ OmNTBc6Q2wBbrKRgJ8Aq44agOJlkD9xfeENOzGYcA+h9mRpuKf5BKbYczTiyr8nyAMXOVeQup r4Iu7Cpc4Du7c+BjgeHgw+Qb9269GinqkS7XyBqMtk+VNjFajYbTaBEa7PpFJSFyrZo8zrJrL ZnI4wcZo1WyOoBbyMtNM6WozZ3uIfE8wPat17DF6UmdoQ4tIjI5UxugvJasWpFrS84ysYDxqz TZxQhuKIUkalAfw4mRVmJUzcLkZvMn3jv/IQIbSEcomUVYKWWymwBskqR0x5MyX0su4ijBbzF x0lFIvmijRZMw2z6/48zd0otjocCUKCgpShWZx1kze9r8+hqJIRIcr7eKWUN5sm7805guB+UL 0NNnFEDb2rxRdgMioVUFFP+IOxzvmZl/U9F2r3z3edTKfdXzev2pR1bnGDw77UnfjBmyv5cXE +MN+mnE9c3Q/LUhpOFK9Q9XAuulgZ/vyvPy6pLnjdYv5b9Rpzb6k/JiNC7d5u27YkrZ17ewV7 qqnR5fSW1o8uw90Z2yfcR2bsOasG1l5ZhILe5tmoAnByGpX41aB/Q2EvAaeCAQAAA==
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-18.tower-267.messagelabs.com!1536230564!8030272!5
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 13857 invoked from network); 6 Sep 2018 10:42:47 -0000
Received: from vgdpm16vr.vodafone.com (HELO voxe04hw.internal.vodafone.com) (47.73.108.158) by server-18.tower-267.messagelabs.com with AES256-SHA256 encrypted SMTP; 6 Sep 2018 10:42:47 -0000
Received: from VOEXH09W.internal.vodafone.com (47.73.211.207) by edge1.vodafone.com (195.232.244.49) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 6 Sep 2018 12:42:34 +0200
Received: from voxe02hw.internal.vodafone.com (195.232.244.47) by VOEXH09W.internal.vodafone.com (47.73.211.207) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 6 Sep 2018 12:42:32 +0200
Received: from VOEXH08W.internal.vodafone.com (47.73.211.206) by edge1.vodafone.com (195.232.244.47) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 6 Sep 2018 12:42:29 +0200
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (172.17.213.45) by VOEXH08W.internal.vodafone.com (47.73.211.212) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 6 Sep 2018 12:42:28 +0200
Received: from AM5PR0501MB2465.eurprd05.prod.outlook.com (10.169.150.10) by AM5PR0501MB2579.eurprd05.prod.outlook.com (10.169.150.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1101.16; Thu, 6 Sep 2018 10:42:26 +0000
Received: from AM5PR0501MB2465.eurprd05.prod.outlook.com ([fe80::cd89:7dc:63de:8cc3]) by AM5PR0501MB2465.eurprd05.prod.outlook.com ([fe80::cd89:7dc:63de:8cc3%6]) with mapi id 15.20.1101.019; Thu, 6 Sep 2018 10:42:26 +0000
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>, "Arun Arunachalam (carunach) (carunach@cisco.com)" <carunach@cisco.com>
CC: "draft-ietf-insipid-logme-marking@ietf.org" <draft-ietf-insipid-logme-marking@ietf.org>, "insipid@ietf.org" <insipid@ietf.org>, "gsalguei@cisco.com" <gsalguei@cisco.com>, "insipid-chairs@ietf.org" <insipid-chairs@ietf.org>
Thread-Topic: [Insipid] Adam Roach's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)
Thread-Index: AQHUNPbM8RYnSHk+00CLTKSPtgoZ2qTCSrqggAA4sQCAIKx22Q==
Date: Thu, 06 Sep 2018 10:42:26 +0000
Message-ID: <AM5PR0501MB24652A98561FDA52551A4F1897010@AM5PR0501MB2465.eurprd05.prod.outlook.com>
References: <153437875319.3073.15951759162383331116.idtracker@ietfa.amsl.com> <AM5PR0501MB24659A3566177F30C6B48623973E0@AM5PR0501MB2465.eurprd05.prod.outlook.com>, <a9436eb5-8f8e-2795-0c8d-83ab3dd84b0b@nostrum.com>
In-Reply-To: <a9436eb5-8f8e-2795-0c8d-83ab3dd84b0b@nostrum.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [47.73.248.123]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0501MB2579; 6:I+eWNXpNKXqArH1C3HT6yVVULbbc8itX/RUsa/EhZIe8uC17ZcbPcqQP8/EAsetAQ+sKrMtfBjjK2V3HllBpbar+A+T7VuUGGQKUsLmYg625vlOPyKPfKk7HlfnHFaz1yWgYaWctbMxIlO60v9laB62NxSeXwLh8+dDrrBtFg9jeO2GH27dRWduwF0I2/3YsSUb1TyFj7LBlZxfLdnLk6h407YNUbhTcfrdI3MO62PFUvgcHmZ+kmSciG+GmRuP8rW1DRwixkqgEuY9DvGVXjCa/Z1gEITI+IJKY+jCIwCGlmj2T1Q/QpROgC+KCZcCTtHQmjqaZaoO59JDlVLM0y+c0pdR1go7bL+Hl2leq64l7Ok22D0QxLV029OakL9ljejYxB/r3EYpgSD/PXYNpVHFY2vaf968Xtpg39+Ec7XfDwNxsOgj0TQVkH1Jo0UE6vwhGnP5jH2dtROy0id4ixg==; 5:6bjrz0N/uotFDEw1z7xJA37GKUG7//WzkEJyaFC2Skhw0o4xuRpgb+IUy1HV5W0mQ/Hzp0f0xQNRvlUUe6Dj2qxvEULxoMtK/NM+CShY95/gAmMrWdeyPVP/KOr1QuETG9brQrkgj0niH/YZ8rXmk/J+xLEx8u4sPbnkz7/gBrk=; 7:qIFaJ2QUW5kmaw2AI/KIyQM05cSRZ3mfWqtFH9D4n1yv8HM/C0EFPbdSix2025pStkCicR+vDBIiFevODf7F6BLz5pa4ayKLL5DDfgOtMMl2wZbxqZJFNCntXoEbtN0FwqX3FcIkybjooVLAgyn2gRbYMWNZCUz2xP1sipL2S+TJXUdfRHsSBXvJ6C8B8zUN1CJvL7Wxz1g1XpT2pSmkPsuZLKXCKXfdykDZKGVQg5OdoL0LqtuloAZ5S8msu6FA
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: ce1ce77e-9049-493b-1baf-08d613e57003
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM5PR0501MB2579;
x-ms-traffictypediagnostic: AM5PR0501MB2579:
x-microsoft-antispam-prvs: <AM5PR0501MB2579B8DF000192D77960CFBB97010@AM5PR0501MB2579.eurprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(72170088055959)(120809045254105)(131327999870524)(95692535739014)(21532816269658);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699016); SRVR:AM5PR0501MB2579; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0501MB2579;
x-forefront-prvs: 0787459938
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(396003)(346002)(366004)(39860400002)(199004)(189003)(54164003)(54896002)(33656002)(8676002)(86362001)(66066001)(575784001)(6116002)(19627405001)(26005)(186003)(81166006)(81156014)(99286004)(106356001)(74316002)(105586002)(7736002)(6606003)(53546011)(5660300001)(2900100001)(6506007)(102836004)(316002)(2906002)(110136005)(1015004)(54906003)(5250100002)(68736007)(4326008)(25786009)(97736004)(966005)(476003)(6246003)(478600001)(446003)(72206003)(11346002)(53936002)(486006)(53946003)(256004)(14444005)(16200700003)(236005)(9686003)(229853002)(606006)(6306002)(7696005)(55016002)(8936002)(3846002)(6436002)(76176011)(14454004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0501MB2579; 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: gp9toeZVvpiVRRitupEJHDkBIV7bumrCzIw6MkqRJYUZVtYK3X4mptbYE3w3E99Wh9olDKTminIdZXhQSMDIY/W7IEgvOUlE1rV8qwJ9yuMroovQM+w8ATa7nCq/ZoK/F8khB9y5VXgFHOaFVakShFa0tnn3Xj77IGDH1gelW7woERnK148Z/OOeasjk5fAhunnSVSNNCxzQ/k0JXOOwlIKOG+LvWb/u4w1m1Xd3AG4ONZzfyn4MQ5nNd385CUrM+gG3kmj/YftI9dEuQZECmutnQjvLK2sElIKSOpdcMcKJ2wGhORI2TtfRL2P5Zw7mvItgmLNxvtZJKYKHSIe6RGfNm5WjRC102ODq/DKpUOctan4q12pPkyLacmB+E4+Qx7S+7ZJarG/Oj66Pk4pktg==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
x-ms-exchange-crosstenant-network-message-id: ce1ce77e-9049-493b-1baf-08d613e57003
x-ms-exchange-crosstenant-originalarrivaltime: 06 Sep 2018 10:42:26.6256 (UTC)
x-ms-exchange-crosstenant-fromentityheader: Hosted
x-ms-exchange-crosstenant-id: 68283f3b-8487-4c86-adb3-a5228f18b893
x-ms-exchange-transport-crosstenantheadersstamped: AM5PR0501MB2579
Content-Type: multipart/alternative; boundary="_000_AM5PR0501MB24652A98561FDA52551A4F1897010AM5PR0501MB2465_"
MIME-Version: 1.0
X-OriginatorOrg: vodafone.com
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/fYTf668b3EtncJrD0RkDhW1N644>
Subject: Re: [Insipid] Adam Roach's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.29
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, 06 Sep 2018 10:42:58 -0000
Hello Adam, Thanks again for the detailed review and helpful pointers. Please see inline our proposed resolutions. Some of the section numbers have changed in the revision -13 we have prepared (not yet submitted), so section numbers for changes don't always match the review of -12. Best regards, Peter and Arun >From: insipid <insipid-bounces@ietf.org> on behalf of Adam Roach ><adam@nostrum.com> >Sent: 16 August 2018 01:19 >To: The IESG >Cc: draft-ietf-insipid-logme-marking@ietf.org; insipid@ietf.org; >gsalguei@cisco.com; insipid-chairs@ietf.org >Subject: [Insipid] Adam Roach's No Objection on draft-ietf-insipid-logme- >marking-12: (with COMMENT) > >Adam Roach 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: >---------------------------------------------------------------------- > >Thanks to everyone who has contributed work towards this document. I have several comments of >varying importance, and believe that this document requires significant changes before publication. > >--------------------------------------------------------------------------- > >General: > >All of the examples in this document use IPv4 addresses. Please use either a mix of IPv4 and IPv6, or IPv6 >only. See https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for additional guidance. > Figure 2 now uses IPv6 as below. F1 INVITE Transferee -> Transferor INVITE sips:transferor@atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432 Max-Forwards: 70 To: <sips:transferor@atlanta.example.com> From: <sips:transferee@biloxi.example.com>;tag=7553452 Call-ID: 090459243588173445 Session-ID: ab30317f1a784dc48ff824d0d3715d86 ;remote=00000000000000000000000000000000;logme CSeq: 29887 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu, tdialog Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha> Content-Type: application/sdp Content-Length: ... >--------------------------------------------------------------------------- > >Abstract: > >> SIP networks use signaling monitoring tools to diagnose user reported > >Nit: "...user-reported..." > In the Abstract, changed user reported to user-reported. SIP networks use signaling monitoring tools to diagnose user-reported problems and for regression testing if network or user agent software is upgraded. >--------------------------------------------------------------------------- > >§3.2: > >> "User-Agent" header value, or for a specific set of called party > >Nit: "...header field value..." > In 3.2 changed to “User-Agent” header field value as per the comment. >--------------------------------------------------------------------------- > >§3.6: > >> The entire SIP message (SIP headers and message body) SHOULD be > >Nit: Choose either "SIP header fields and message body" or "SIP header and message body". See the >definitions of "Header" and "Header Field" in RFC 3261 at the bottom of page 21 for assistance. > >More substantive comment: it is probably useful to also log the request line (method, request-URI, and >SIP version) or response line (SIP version, response code, and reason phrase), as applicable, in addition >to the header and body. Revised the first sentence of 3.6 to: The entire SIP message (SIP request line, response line, header fields and message body) SHOULD be logged since troubleshooting might be difficult if information is missing. > >--------------------------------------------------------------------------- > >§3.7: > >This scenario is hard to follow. These points seem contradictory: > > - "[Alice's] terminal is configured to log signaling for calls from the > network administrator Bob" > > - Bob's terminal is presumably *not* configured to add "log me" marking, since > the document doesn't mention this, and implies that the configuration at > Alice's terminal is sufficient > > - "Logging by Alice's terminal begins when it receives and echoes the > "logme" marker in INVITE F1" > >Why does INVITE F1 have a "logme" marker in it? > > - "Logging by Bob's terminal begins when it sends INVITE F1, which > includes the "logme" marker" > >Again: why does this happen? The scenario doesn't include any special configuration at Bob's terminal. > Revised the beginning of the second paragraph in 3.7 as follows. In the example shown in Figure 2, Alice has reported problems making call transfers. Her terminal is placed in debug mode in preparation to log marked signaling from the network administrator Bob. Bob's terminal is configured to "log me" mark and log signaling for calls originated during the troubleshooting session (e.g. for a duration of 15 minutes). Bob, who is troubleshooting the problem, arranges to make a call that Alice can attempt to transfer. Bob calls Alice, which creates initial dialog1, and then Alice transfers the call to connect Bob to Carol. Logged signaling is correlated using the test case identifier, which is the local UUID ab30317f1a784dc48ff824d0d3715d86 in the Session-ID header field of INVITE request F1. >> F1 - Bob's UA inserts the "logme" parameter in the Session-ID header >> of the INVITE request that creates dialog1. > >Same question. > The new text in 3.7 indicates that Bob’s terminal is configured to both mark and log signaling. Changed Session-ID header to Session-ID header field throughout the document. >Nit: "...header field..." > >> F3 - Alice's UA inserts the "logme" parameter in the Session-ID >> header of the REFER request that creates dialog2 which is related to >> dialog1. > >Nit: "...header field..." Changed Session-ID header to Session-ID header field throughout the document. > >--------------------------------------------------------------------------- > >§3.7: > >> | REFER F3 (Target-Dialog:1) | >> dialog2 |------------------->| | >> | 202 Accepted | | >> dialog2 |<-------------------| | > >The use of 202 in this context is deprecated. See RFC 7647 §5. In Figure 2, changed 202 Accepted to 200 OK | ACK | | dialog1 |------------------->| | | REFER F3 (Target-Dialog:1) | dialog2 |------------------->| | | 200 OK | | dialog2 |<-------------------| | | NOTIFY (100 Trying) F4 | dialog2 |<-------------------| | > >--------------------------------------------------------------------------- > >§3.8: > >> A SIP intermediary MUST copy the "log me" marker into forked requests >> (see sections 4, 16.6 in [RFC3261]). > >It's generally bad form to reiterate normative protocol requirements in different language. Please >rephrase to something along the lines of: > > A SIP intermediary is required to copy the "log me" marker into forked > requests by the rules defined in sections 4 and 16.6 of [RFC3261]. Revised 3.8 to: 3.8. Forked Requests A SIP intermediary is required to copy the "log me" marker into forked requests. SIP request forking is discussed in sections 4 and 16.6 of [RFC3261]. > >--------------------------------------------------------------------------- > >§4.1 > >> o The mechanisms in this section limit initiation of "log me" >> marking only in dialog creation requests (e.g. SIP INVITE) sent >> by an originating endpoint or an intermediary that marks on behalf >> of the originating endpoint. The final terminating endpoint or an >> intermediary that marks on behalf of the terminating endpoint >> detects an incoming "log me" marker and takes action as defined in >> Section 4.2 and Section 4.3. > >To be clear, this implies that a terminating endpoint has no means of activating >logging; only an originating endpoint (or an intermediary acting on its >behalf) is capable of doing so. If that is the intention, it needs to be stated >explicitly -- because that constraint is unclear enough that even this >document appears to have gotten it wrong (see my comments on §3.7, above). Revised the second bullet of 4.1 to make it clear that the originating endpoint controls the start of logging. The terminating endpoint can only reflect the marking as follows: o If a dialog is to be marked, the only way to initiate "log me" marking is at the dialog creating request (e.g. SIP INVITE) sent by an originating endpoint or an intermediary that marks on behalf of the originating endpoint. Marking that appears mid-dialog is an error as described in Section 5.1.2. The final terminating endpoint or an intermediary that marks on behalf of the terminating endpoint cannot initiate marking but takes action as defined in Section 4.2 and Section 4.3 if it receives an incoming "log me" marker. > >--------------------------------------------------------------------------- > >§4.3: > >The text in here implies, but does not state, that intermediaries acting on behalf of endpoints generally >need to understand RFC 4538 ("Target-Dialog"), RFC 3911 ("Join"), and RFC 3819 ("Replaces"). This >needs to be explicitly noted, as intermediaries typically do not act on these header fields in any way. In 4.3, added the sentence: Originating and terminating intermediaries that are configured for "log me" marking on behalf of the endpoint must also mark dialog-creating requests that contain Target-Dialog [RFC4538], Join [RFC3911] and Replaces [RFC3891] header fields and corresponding responses. > >--------------------------------------------------------------------------- > >§4.5.2.5: > >> In Figure 6 below Proxy 2 removes "log me" marking from all SIP >> requests and responses entering network B and Proxy 2 does not >> support "log me" marking. > >I'm on the fence about whether this is a DISCUSS. Per RFC 3261 processing rules, proxies simply pass >through header fields, unchanged, that they do not understand -- so Proxy 2, if it does not support "log >me" marking, will *NOT* remove the header field, and will *NOT* remove the "log me" marking. One of >the only reasons that this mechanism (and the Session-ID mechanism itself) can even be deployed is >precisely because of this proxy behavior. > >I'm pretty sure that this section needs to be revised to say that Proxy 2 doesn't remove the "log me" >marking because it doesn't understand it, and that Bob's UA doesn't reflect it because it doesn't >understand it. The resulting call flow would look like the following (note the changes in F4, F14, and >F20): > > [ NETWORK A ] [ NETWORK B ] > Alice Proxy 1 Proxy 2 Bob > | | | | > | INVITE F1 | | | > | (log me) | | | > |--------------->| | | > | | INVITE F2 | | > | | (log me) | | > | |--------------->| | > | | | | > | | | | > | 100 F3 | | | > | (log me) | | | > |<---------------| | | > | | | INVITE F4 | > | | | (log me) | > | | 100 F5 |--------------->| > | | (no log me) | | > | |<---------------| | > | | | 180 F6 | > | | | (no log me) | > | | |<---------------| > | | 180 F7 | | > | | (no log me) | | > | |<---------------| | > | | | | > | | | | > | 180 F8 | | | > | (log me) | | | > |<---------------| | 200 F9 | > | | | (no log me) | > | | 200 F10 |<---------------| > | | (no log me) | | > | 200 F11 |<---------------| | > | (log me) | | | > |<---------------| | | > | ACK F12 | | | > | (log me) | | | > |--------------->| | | > | | ACK F13 | | > | | (log me) | | > | |--------------->| ACK F14 | > | | | (log me) | > | | |--------------->| > | Both Way RTP Media | > |<================================================>| > | | | BYE F15 | > | | | (no log me) | > | | BYE F16 |<---------------| > | | (no log me) | | > | BYE F17 |<---------------| | > | (log me) | | | > |<---------------| | | > | 200 F18 | | | > | (log me) | | | > |--------------->| | | > | | 200 F19 | | > | | (log me) | | > | |--------------->| 200 F20 | > | | | (log me) | > | | |--------------->| > | | | | > >The prose description for "F2" also needs to be updated to instead talk about F6, F9, and F15. Changed the title of 4.5.2.5. from "Log Me" marking removed by Non-Supporting Terminating Network to 4.5.2.5. "Log Me" marking passed by Non-Supporting Terminating Network. Revised Figure 7 to show that marking is passed by Proxy 2 (not removed) and is not echoed by Bob's UA as per the review comment. Added the following line of explanatory text below Figure 7 to point out that Bob's UA does not echo marking: F6 - Bob's UA does not support "log me" marking and does not echo the "log me" marker in response F6. The same applies to responses F9 and F15. > >--------------------------------------------------------------------------- > >§4.6: > >> Two error types are defined in Section 5, a missing marker error and > >Nit: "...Section 5: a missing..." > ^ > Changed comma to colon as per the review comment. >--------------------------------------------------------------------------- > >§5.2: > >This section needs to address what is supposed to happen when "Join" (RFC 3911) is used to combine >two dialogs, where one was started with "log me" marking, and the other one was not. > Added the following non-error case section 5.2.3 "Combining Dialogs Non-Error Case" to describe combining dialogs: 5.2.3. Combining Dialogs Non-Error Case When troubleshooting call flows that involve the SIP Join header field specified in [RFC3911], the ideal scenario is to have "log me" marking enabled on all UAs and intermediaries participating in the end-to-end session. If the ideal scenario is not feasible, the following rules apply. o If a "log me" aware endpoint or intermediary that is already "log me" marking a dialog receives a SIP INVITE with a Join header field and without a "log me" marker, it MUST NOT "log me" mark responses and requests exchanged within the new dialog established as a result of processing the SIP INVITE. o If a "log me" aware endpoint or intermediary that is not "log me" marking a dialog receives a SIP INVITE with a Join header field and with a "log me" marker, it MUST "log me" mark responses and requests exchanged within the new dialog established as a result of processing the SIP INVITE as per Section 4 of this document. >--------------------------------------------------------------------------- > >§7: > >> "logme"parameter for the Session-ID header field defined in Section 5 > >Nit: insert space before "parameter" > inserted space as per review comment. >--------------------------------------------------------------------------- > >§8.4: > >This section needs to also include information about using GRUUs not based on AORs (see RFC 5627 >§3.1.2). > >This section should further mention that fields beyond those cited here might contain information that >can be traced to the user or a small set of users; e.g., the "user" field in the "o=" parameter of an SDP >body, and the Request URI itself. Basically, it's going to be very difficult to ensure that the identity of the >calling and/or called users is completely removed in all circumstances, and operators must not assume >that messages are anonymized even when the techniques in this section are applied. > Revised the Privacy section (now a top-level section renamed Privacy Considerations) to include the following new text: 8. Privacy Considerations Logging includes all SIP header fields. The SIP privacy mechanisms defined in [RFC3323] can be used to ensure that logs do not divulge personal identity information in the core SIP header fields specified in [RFC3261]. Privacy mechanisms might also need to be applied to header fields defined by SIP extensions and for managing the confidentiality of the Request URI and SIP header fields and bodies. 8.1. Personal Identifiers "Log me" marking is defined for the SIP Protocol, and SIP has header fields such as From, Contact, P-Asserted-Identity that can carry personal identifiers. Different protocol interactions can be correlated using the Session-ID and Call-ID header fields, but such correlation is limited to a single end-to-end session. In order to protect user privacy during logging, privacy settings can be enabled or requested by the terminal used by the end user. [RFC3323] suggests two mechanisms: o By using the value anonymous in the From header field o By requesting header and session level privacy from SIP intermediaries using the Privacy header Endpoints that support Globally Routable User Agent URIs (GRUUs) can use a temporary GRUU (see Section 3.1.2 of [RFC5627]) assigned by the Registrar in order to protect user privacy as discussed in Section 10.3 of [RFC5627]. Intermediaries that perform "log me" marking on behalf of the endpoints (see Section 4.3) may also be configured to apply privacy (as defined in Section 3.3 of [RFC3323]) on messages that belong to a dialog that is "log me" marked. Complete anonymization (e.g. the Request URI and the "username" field in the "o=" parameter of an SDP body) may not be possible in all circumstances and therefore administrators of the originating and terminating networks should consider how privacy will be ensured when providing consent for "log me" marking. "Log me" marking is typically used for troubleshooting and regression testing, and in some cases a service provider owned device with a dummy account can be used instead of a customer device. In such cases, no personal identifiers are included in the logged signaling messages. >--------------------------------------------------------------------------- > >§8.4.6: > >I share some of Benjamin's concerns, and am somewhat surprised that this section does not include >guidance to ensure that the user is informed of sessions on which "log me" marking has been activated. >Although we don't deal with UI in the IETF, it's completely fair game to require that UAs that are capable >of indicating that logging is taking place MUST do so. > Added the following paragraph to 8.6: 8.6. User Control of Logging Consent to turn on "log me" marking for a given session MUST be provided by the end user or by the network administrator. It is handled outside of the protocol through user interface or application programming interfaces at the end point, call control elements and network management systems. Originating and terminating endpoints that are "log me" aware and have a user interface MUST indicate (using text, icon etc.) to the user that a session is being logged. SIP entities across the communication path MAY be configured to pass through the "log me" marking but not honor the request i.e. not log the data based on local policies. > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid ________________________________ From: insipid <insipid-bounces@ietf.org> on behalf of Adam Roach <adam@nostrum.com> Sent: 16 August 2018 16:34 To: Dawes, Peter, Vodafone Group; The IESG; Arun Arunachalam (carunach) (carunach@cisco.com) Cc: draft-ietf-insipid-logme-marking@ietf.org; insipid@ietf.org; gsalguei@cisco.com; insipid-chairs@ietf.org Subject: Re: [Insipid] Adam Roach's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT) On 8/16/18 07:31, Dawes, Peter, Vodafone Group wrote: > Regarding non-supporting networks and the example in 4.5.2.5, 3.4.3 (below) states that "log me" marking can either be dropped or passed by a non-supporting intermediary using similar language to Section 7 of RFC 7989 (End-to-End Session Identification in IP-Based Multimedia Communication Networks). Maybe we need to include both the case that it is dropped and the case that it is passed, which would operate as you describe in your review. > > 3.4.3. Across a Non-Supporting SIP Intermediary > "Log me" marking is most effective if passed end-to-end. However, > intermediaries that do not comply with this specification might pass > the "log me" marker unchanged or drop it entirely. The problem here is definitional. Section 3.4.3 talks about intermediaries removing this marker, but that's only true if the intermediary in question is a B2BUA. Section 4.5.2.5 talks about proxies, whose behavior is governed by RFC 3261 §16.6: > The proxy starts with a copy of the received request. The copy > MUST initially contain all of the header fields from the > received request. Fields not detailed in the processing > described below MUST NOT be removed. /a _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid
- [Insipid] Adam Roach's No Objection on draft-ietf… Adam Roach
- Re: [Insipid] Adam Roach's No Objection on draft-… Dawes, Peter, Vodafone Group
- Re: [Insipid] Adam Roach's No Objection on draft-… Adam Roach
- Re: [Insipid] Adam Roach's No Objection on draft-… Dawes, Peter, Vodafone Group
- Re: [Insipid] Adam Roach's No Objection on draft-… Adam Roach
- Re: [Insipid] Adam Roach's No Objection on draft-… Arun Arunachalam (carunach)