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, 06 September 2018 11:23 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 C8F7B124BE5; Thu, 6 Sep 2018 04:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=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 IfDC3xfdxu3w; Thu, 6 Sep 2018 04:23:15 -0700 (PDT)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.68]) (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 E074F130E6E; Thu, 6 Sep 2018 04:23:12 -0700 (PDT)
Received: from [46.226.52.199] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-b.eu-west-1.aws.symcld.net id 37/4A-26718-E1E019B5; Thu, 06 Sep 2018 11:23:10 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WTa0hTYRjHfc9lO5onTrPwcbUu60JUZ7qgmp8 SIlhEFyT6kEGd6ckNtmk7G80uNCsQvOVqlpq1TLFSqFbSVSi8lFam2ehiUWbLygJdTehe2znL 6svh97z///M8f17eQ+GKUrmS4p123mblzGpZHJG8wlzMqsa7M1JGD8/QXbrVgOny+w/JdUc9q 3UV39247u2jIK4bGPiM6bwvBjHdSV8llkbpPd98pL6j3k/q6+q+YPp9wRpSv+duO76W3ECarI Yc52bS2L73Jpbb2YGco63NpAsNNqJCFEcpmIsIrg+EZFLRguBy42fZmHK4YISQih4E3tfv5FL hwSCQXxi19SOocR8JFxQlY5ZCRfPGQhRLTWTUUNu1T/TgzDMMQudPiRsTmGIEHwNVMslVguB5 rVHi9XCtOkBGmGBmwYmvD0UPzWyG0jO/MGnbMRwenAqKQiyzCPpcH/AII0YFofxGkXEmEfaET ouDgGGgrrkbl3gSvHv1k5T8G+Bg8BEmnc+As7/8hMQq6PUWiUmBuSGHr8XHoiYWRsrLo4NWQe tgKyGZOhG4z43IJGEBnO7uizbkQNP7kmiKnfCk2BXlqdBQ8jLafA+H/qedqAwlV/2TXGIrtH7 0YVXiFUyAzsoAIZ2nwPA9Ly7xfKiveR/lZPCFutC/58eRvAEtNthM2Ua7hTOZWW1KCqvVLmS1 qUvYVA23nTVoeAe7jRfsrFbDbRM0Qp4l05ylsfL28yj8HrNy22Mvox+F2S0oicLUk+gp+v0Zi vGGnKw8IycYN9kcZl5oQVMoSg30XNqdoZhg47N55xaTOfyo/8hAxasn0pMjMi3kchbBlC1Jt1 Eq1fbccwCnesTv9+HyA7iCsOZYeWUiTUQamEiD0WEdG/fnN+lFKmUCjWJiYhTxubzNYrL/rw+ hRAqpE+jkyJR4k9U+tnUoHAgLB3p4pSwSyM79lZQutKLtKL6u+ZrrZVGSutExquiprVs7femn tOX+3r1EQZznS/eOvArPyby7FU3HlVvXDFl800pneqn9F+uLVD+YpBfp8zMM928Gzj51lVF9W /lF1Zn+rExHZdy3O9X+guHdSx4P9w/N6TqyLHhhZWx62xt22a7Z49IK0pqc/Lh1zNWOejUhGD ntPNwmcL8BBWQBmSEEAAA=
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-17.tower-287.messagelabs.com!1536232988!8636319!2
X-Originating-IP: [47.73.108.140]
X-SYMC-ESS-Client-Auth: outbound-route-from=pass
X-StarScan-Received:
X-StarScan-Version: 9.9.15; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6690 invoked from network); 6 Sep 2018 11:23:09 -0000
Received: from vgdpm14vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) (47.73.108.140) by server-17.tower-287.messagelabs.com with AES256-SHA256 encrypted SMTP; 6 Sep 2018 11:23:09 -0000
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, 6 Sep 2018 13:23:06 +0200
Received: from voxe02hw.internal.vodafone.com (195.232.244.47) by VOEXH06W.internal.vodafone.com (47.73.211.204) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 6 Sep 2018 13:23:05 +0200
Received: from VOEXH07W.internal.vodafone.com (47.73.211.205) by edge1.vodafone.com (195.232.244.47) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 6 Sep 2018 13:23:04 +0200
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (172.17.213.40) by VOEXH07W.internal.vodafone.com (47.73.211.211) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 6 Sep 2018 13:23:03 +0200
Received: from AM5PR0501MB2465.eurprd05.prod.outlook.com (10.169.150.10) by AM5PR0501MB2435.eurprd05.prod.outlook.com (10.169.149.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1101.18; Thu, 6 Sep 2018 11:23:01 +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 11:23:01 +0000
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, "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>
Thread-Topic: =?Windows-1252?Q?Mirja_K=FChlewind's_No_Objection_on_draft-ietf-insipid-l?= =?Windows-1252?Q?ogme-marking-12:_(with_COMMENT)?=
Thread-Index: AQHUM95jlO2wh//a3USYU+l+rVis76S/dTYAgABbKwCAAJvqAIAAdnCAgAF/OgCAIN0GFQ==
Date: Thu, 6 Sep 2018 11:23:01 +0000
Message-ID: <AM5PR0501MB24655B035AADEC9998816E4A97010@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>, <20180816132715.GD40887@kduck.kaduk.org>
In-Reply-To: <20180816132715.GD40887@kduck.kaduk.org>
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; AM5PR0501MB2435; 6:hvWemdxm+LYXSEpWydjChS421stX7F0UpxEkQMhq2BgOqecpzYUfAKq3eMPciO59mDO/IHaYteZ2ib/lIyVl4TE8I5hxStPtnq5sjamiOej6QV0kaPIBmVvYKnxZ/zU5sOM+vzumIR0wuXZdv0TF+E8alaQGVzzoSIzHkBMjoFyn6oPpWvHoOG8jEzWzPDG2m7UbJDahE7TYV8apS5XP3XdkM0sbzY6FPl0fzQOfv+aSg1f/4ZmcftDtDlJQhlfslS4zEkmqBa2/R5jChITBk9U3nPUCjXW6LsMPmb2cR2CkqgZzdJmWcZkNd9REu/AtSM1mz0xuVkWnlnMzao+E91A6IKXXgtXNyMPErXV4xuJlkKGiu6w94xXAfELDfAxppiCFUeZQb/KS5uW5AC/0XSB3Hp/Ws2KIikS38S1rsL5UV0lZVUXFwvvTC0X2RMEgsyMq+aqv/k1tlMzck+CJkw==; 5:79hZs4PJJ+0Nug0sW3e9uP5b8YLq/t+p+DmSZdQBHKVqdPsWBGdiPHdHJexqq1uk9Z/+WQNLIcHAwegydkMe4G5Z7ZlPrgJdbcTHWAi2j4gE6X84Mhgd4qz9eT9O5VdwSbzejEmkC1Icm8h7F8FlnX3Sb+sV0gFZoIYaSEmaBE8=; 7:TQ9nQQVrzzQCHKSYzJkN0+zWR0vNX+vypK8G1CZh27DKJ4nfEdTzsnbKNDmh+4uvsqrtP/0GhzR56usVQE/ZICK0VemJ8yC9vkv/VWytckAPBXf2khV+BPsbGNA8JazsuURNd7oOq52/a1up0wu0/n1xAhswDW6AtPGzB9sz0DG8b4hSmt8DguX+VieyiqTBJ/AytGRJ3d2QDN1dkYrHoieAA0rbQlxXORi8AGfSfysPRepOCjswYfqwrbgIVGYF
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 24e740f7-1e24-42f4-9e27-08d613eb1b82
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM5PR0501MB2435;
x-ms-traffictypediagnostic: AM5PR0501MB2435:
x-microsoft-antispam-prvs: <AM5PR0501MB2435EB3AAC2813ECBBD7A58897010@AM5PR0501MB2435.eurprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(67444318432085)(192374486261705)(95692535739014)(240460790083961)(29966359920796);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231311)(11241501184)(806099)(944501410)(52105095)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(201708071742011)(7699016); SRVR:AM5PR0501MB2435; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0501MB2435;
x-forefront-prvs: 0787459938
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(376002)(396003)(346002)(136003)(39860400002)(366004)(13464003)(199004)(189003)(81156014)(446003)(81166006)(11346002)(7696005)(54896002)(9686003)(316002)(55016002)(2171002)(5660300001)(6246003)(4326008)(53546011)(6506007)(74316002)(25786009)(486006)(19627405001)(53936002)(102836004)(476003)(72206003)(6606003)(8936002)(6916009)(93886005)(229853002)(186003)(224313004)(26005)(105586002)(66066001)(76176011)(2900100001)(6436002)(54906003)(33656002)(14454004)(5250100002)(478600001)(224303003)(106356001)(3846002)(6116002)(68736007)(256004)(99286004)(7736002)(14444005)(97736004)(86362001)(2906002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0501MB2435; 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: qHBGQkOWhDC9BZyiYe19vqdNHZsw69aJC0Sd7yfaVHACK8jhACD979ZuYppNHHcmeQdLHd+MpO+gZeM3PW7bsWBc/lICiLsYA0SMcQSPnNAtlBfB8029yDSxgDnWu2USm42FaGoQtkqe6FooWNBhORCeUEA4mEdtWzTKlhiKhQ2q1kU/+XiLS6piWHG6NGq59U7SH5Q0QHXKmszBEePU3UNxKFzL89OSMloZ/77fw3P3xRQ4vQGP2PYA5Jw57HE9kNUZuru8GDxgUsnaU1UOuM6ynl6uoEWrMf5txkJCcEpecfjCAXjgEfuqAfH/qE64gMrixmldbHJKBOuEUj4S3E8q22HIktfcHa1QwP/0ksXTlThrFGRBdM/zeo2x4/cKFziCGyjFRRdMr+l/EANIHA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
x-ms-exchange-crosstenant-network-message-id: 24e740f7-1e24-42f4-9e27-08d613eb1b82
x-ms-exchange-crosstenant-originalarrivaltime: 06 Sep 2018 11:23:01.8509 (UTC)
x-ms-exchange-crosstenant-fromentityheader: Hosted
x-ms-exchange-crosstenant-id: 68283f3b-8487-4c86-adb3-a5228f18b893
x-ms-exchange-transport-crosstenantheadersstamped: AM5PR0501MB2435
Content-Type: multipart/alternative; boundary="_000_AM5PR0501MB24655B035AADEC9998816E4A97010AM5PR0501MB2465_"
MIME-Version: 1.0
X-OriginatorOrg: vodafone.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/b63t3qkkCFu4XRXA0lTfrFtnzR8>
Subject: Re: [Insipid] =?windows-1252?q?Mirja_K=FChlewind=27s_No_Objection_on?= =?windows-1252?q?_draft-ietf-insipid-logme-marking-12=3A_=28with_COMMENT?= =?windows-1252?q?=29?=
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 11:23:18 -0000

Hello Benjamin,

Below is the proposed resolution to your comment regarding error cases, which will be in version -13 of the draft.


Thanks!

Peter and Arun


>I expect this is just my communications security background speaking, but I'm used to seeing "this is an

>error condition" get a response of "tear down the entire connection/dialog/whatever".  That doesn't

>seem to be the case, here, though -- is the appropriate response to the error condition just the behavior

>described in the document of ceasing to use "log me"

>markers and stopping logging?  It may be more clear to explicitly say "error condition in the "log me"

>functionality" to avoid the misreading that it is a broader error condition of the entire dialog.



We have revised the text in 5.3 to make it clear that the errors are “log me” errors and not errors with the session itself as follows.



5.3.  Error Handling



   The two error types that SIP entities must handle are defined in

   Section 5.1, a missing marker error and an error of "log me" marking

   that begins mid-dialog.  Section 5.2 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 UA, SIP intermediary, or

   B2BUA, it SHOULD consider this as an error condition in the "log me"

   functionality.  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

   UA, SIP intermediary, or B2BUA, it SHOULD consider this as an error

   condition in the "log me" functionality.  It MUST NOT forward the

   "log me" marker and MUST NOT log the message.  It MUST NOT mark

   subsequent requests and responses and MUST NOT log subsequent

   messages in the same dialog.



   "Log me" marking errors can be detected and handled only by

   supporting UAs or B2BUAs.  A SIP proxy as defined in [RFC3261] cannot

   detect or handle marking errors and will simply forward any "log me"

   marker it receives.



>

>-Benjamin



________________________________
From: Benjamin Kaduk <kaduk@mit.edu>;
Sent: 16 August 2018 14:27
To: Dawes, Peter, Vodafone Group
Cc: Mirja Kuehlewind (IETF); Arun Arunachalam (carunach); Arun Arunachalam (carunach); insipid-chairs@ietf.org; Gonzalo Salgueiro (gsalguei); insipid@ietf.org; The IESG; draft-ietf-insipid-logme-marking@ietf.org
Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)

Sorry to jump in with something only semi-related...

On Wed, Aug 15, 2018 at 02:57:44PM +0000, Dawes, Peter, Vodafone Group wrote:
> 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)
> >
> >
> > > Am 15.08.2018 um 00:13 schrieb Arun Arunachalam (carunach)
> > <carunach=40cisco.com@dmarc.ietf.org>;:
> > >
> > >> On Aug 14, 2018, at 12:47 PM, Mirja Kühlewind <ietf@kuehlewind.net>;
> > >>
> > >> On 14.08.2018 16:51, Arun Arunachalam (carunach) wrote:
> > >>>
> > >>>> On Aug 13, 2018, at 12:24 PM, Mirja Kühlewind <ietf@kuehlewind.net>;
> > wrote:
> > >>>>
> > >>>>
> > >>>> 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.

I expect this is just my communications security background speaking, but
I'm used to seeing "this is an error condition" get a response of "tear
down the entire connection/dialog/whatever".  That doesn't seem to be the
case, here, though -- is the appropriate response to the error condition
just the behavior described in the document of ceasing to use "log me"
markers and stopping logging?  It may be more clear to explicitly say
"error condition in the "log me" functionality" to avoid the misreading
that it is a broader error condition of the entire dialog.

-Benjamin