From nobody Sun Mar 1 23:15:54 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE323A0E7B; Sun, 1 Mar 2020 23:15:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder_via_Datatracker?= To: Cc: last-call@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-data-only-ea.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158313332586.32567.7766771438755577752@ietfa.amsl.com> Reply-To: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= Date: Sun, 01 Mar 2020 23:15:25 -0800 Archived-At: Subject: [Ecrit] Opsdir telechat review of draft-ietf-ecrit-data-only-ea-21 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 07:15:26 -0000 Reviewer: Jürgen Schönwälder Review result: Ready I have reviewed -18 before and I am fine the changes in -21. From nobody Mon Mar 2 11:48:53 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D74E3A100E; Mon, 2 Mar 2020 11:48:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Gonzalo Salgueiro via Datatracker To: Cc: draft-ietf-ecrit-data-only-ea.all@ietf.org, last-call@ietf.org, ecrit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158317853107.27458.1826052910979859321@ietfa.amsl.com> Reply-To: Gonzalo Salgueiro Date: Mon, 02 Mar 2020 11:48:51 -0800 Archived-At: Subject: [Ecrit] Iotdir telechat review of draft-ietf-ecrit-data-only-ea-21 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 19:48:52 -0000 Reviewer: Gonzalo Salgueiro Review result: Ready with Nits Document: draft-ietf-ecrit-data-only-ea-21 Review result: Ready with Nits Review type: iotdir - Last Call review Requested version for review: Current Review Date: 2020-03-02 Reviewer: Gonzalo Salgueiro I am the assigned IoT directorate reviewer for . These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the IoT Directorate, see https://datatracker.ietf.org/group/iotdir/about/ This document describes (1) how method of including a CAP message in a SIP transaction by defining it as a block of "additional data" as well as (2) describes how a SIP MESSAGE transaction can be used to send a non-interactive call. I have reviewed this document from the IoT perspective and the document appears to be informative, clear and without obvious technical gaps. There are just a few the authors might consider addressing. Nits: ==== S: Abstract "type of interactions" -> "types of interactions" S:1 "alert specific" -> "alert-specific" S:9 "Location specific" -> "Location-specific" S:9 "Note that none of the security mechanism in this document" -> "Note that none of the security mechanisms in this document" From nobody Mon Mar 2 12:01:51 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCF43A10E4; Mon, 2 Mar 2020 12:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=d1j19Dec; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hoBUwvLv 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 z_dPWhFb7xwY; Mon, 2 Mar 2020 12:01:30 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3A73A1090; Mon, 2 Mar 2020 12:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3510; q=dns/txt; s=iport; t=1583179290; x=1584388890; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Mxtf/MIbWMiuD2Fw9rKT4fyGkqUQ3MnqsB64D1oMvk0=; b=d1j19DecqcQl4N5gkMVk9FMKSzpgYFSiDvSG2bPEr5UCKlhcluVI8w/Z UwphxNGu8o7vDzfkOA4HgSN1vtkbeyJGegXfJuw/rCtVw0I3qZoPbv6W1 XYI3s/qbM9keudAnM2BOBLC9pF3W9zmASiPDUe1uZxtwxxSfBYCy94PRO E=; IronPort-PHdr: =?us-ascii?q?9a23=3AMIRj1BJokH78ebpnkdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEDlPfjhbCESF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBBQDzZF1e/4kNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVFAFbFggBAsqhBSDRgOKZoI6JZgVglIDVAkBAQEMAQEYCwo?= =?us-ascii?q?CBAEBhEACF4F0JDgTAgMNAQEFAQEBAgEFBG2FVgyFYwEBAQEDAQEQEQQNDAE?= =?us-ascii?q?BLAsBCwQCAQgRAwECAwImAgICJQsVCAgCBAENBSKDBAGCSgMuAQ6hGgKBOYh?= =?us-ascii?q?idX8zgn8BAQWFBxiCDAMGgQ4qjCUagUE/gREnDBSCTT6CZAEBA4FigxEygiy?= =?us-ascii?q?NXkGCRp86CoI8h1KKYoQyHJsxjnKIfJJOAgQCBAUCDgEBBYFpIoFYcBU7KgG?= =?us-ascii?q?CDQEzUBgNjh2Dc4UUhUF0gSmPSwEB?= X-IronPort-AV: E=Sophos;i="5.70,508,1574121600"; d="scan'208";a="452466852" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Mar 2020 20:01:29 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 022K1TP3024486 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Mar 2020 20:01:29 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 2 Mar 2020 14:01:29 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 2 Mar 2020 14:01:28 -0600 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 2 Mar 2020 15:01:28 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IVBxeG2AZBnw5gjCvXWHULd4L+uoz93/gWBWJzB2PxBCh19T1kwWRMSyOUMvgl5WXHpA2bM1SzgJ0ZCuQe7XfMpA+3PtN4WRbiwCQSaA3DKgoTl19p5kHSEknmwIYeSfle8ho63J1bFSbfIeoL7Q7qTu3uiOMZKi5FmN0PsbzVhHPvcEGpWxum4gZleuS+6VcwKDR2zYE8VJ9wZZP5AmFMoC68URF6siom2rice8KQnPnk5Ppd5RD6/I3pH064tzFy6DdAgbnrIso2x0uV2f5clr/8Xa2dck4dRAqoP/6OaXFDFX2wyjXzPOtucODUgdJ0AGzf3QKanpMG++rDo4fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mxtf/MIbWMiuD2Fw9rKT4fyGkqUQ3MnqsB64D1oMvk0=; b=Hi1rmwefGPtLwE5lYxiJnQdY5pflP5fETadQqME7ndY16aUdTi8WchhtlZWoAY/PThblfrjpnBk+HFKdDxQMNKdvLKcs+IVi61YtNPXB4R5XIn4tgUbBR4d4JAgsSdY1bNmWHznSOkpyRxv9f7QLBeaUyOAaq5qNPGvgXqqTKALAVSbWvXFlIJk1OTOp0RgSqaTQOlkRaiDScv0pHLQnBRUuVxzaFnc8qMUWPdVYApN0mPzCDsg2l6yilRJzwkeb+9vAtrHmCIFdgOoKZ+mbkzQqvaoYkP6CZqTuxKdYLrl6eZuH4eIs8rxTNt+DVhY+M4LBtGaqjvkMijmOLYfCgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mxtf/MIbWMiuD2Fw9rKT4fyGkqUQ3MnqsB64D1oMvk0=; b=hoBUwvLv8/FfvSMTYMqh0/LLl9/ClMXresCIVnhh7b+giPbvEuPVPBJf00RPu2K6iVt034iIysfp0wtcSBUAn1jclXJagf+D83GD2ozArI+XcAnI28ftsyXfUKO+YtSd8xd6k8PQ+N1jhKlLvLhEm7ZfUNvE5SYEFRxmfGo1Ti4= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1369.namprd11.prod.outlook.com (2603:10b6:3:c::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Mon, 2 Mar 2020 20:01:27 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca%3]) with mapi id 15.20.2772.019; Mon, 2 Mar 2020 20:01:27 +0000 From: "Eric Vyncke (evyncke)" To: "Gonzalo Salgueiro (gsalguei)" , "iot-directorate@ietf.org" CC: "last-call@ietf.org" , "draft-ietf-ecrit-data-only-ea.all@ietf.org" , "ecrit@ietf.org" Thread-Topic: [Last-Call] Iotdir telechat review of draft-ietf-ecrit-data-only-ea-21 Thread-Index: AQHV8MuveTBpDC0ggkiWisRoxpw7Lag1yeEA Date: Mon, 2 Mar 2020 20:01:27 +0000 Message-ID: <66FD8949-84E5-4507-9D67-2BB328AD97B6@cisco.com> References: <158317853107.27458.1826052910979859321@ietfa.amsl.com> In-Reply-To: <158317853107.27458.1826052910979859321@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:4408:f224:e183:e99c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 46dff91d-5dc6-4e90-354e-08d7bee47e40 x-ms-traffictypediagnostic: DM5PR11MB1369: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(366004)(376002)(39860400002)(346002)(199004)(189003)(186003)(8936002)(2616005)(316002)(110136005)(36756003)(2906002)(54906003)(33656002)(966005)(478600001)(86362001)(8676002)(71200400001)(81166006)(81156014)(66574012)(6512007)(4326008)(6486002)(66556008)(53546011)(6506007)(66476007)(66946007)(450100002)(5660300002)(64756008)(66446008)(76116006)(91956017); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1369; H:DM5PR11MB1753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: thDL1ehN+RhBst4oI/i1fLxgpgZCaNw1FOv1nMOLK1F++JXflXjs2tXtcJFO36mEqIz5Wn/qR3Z3odcegK0dCxCVnPcQEDp2U00QHE8TsP98WdbSjEGXdAkQbWgTvHhJiqDsjRCVNRaqhehMn7zp95OXA2Zy6uo5SmmW9HNNiH7BPKykM7blLRC0KhRHs4dkXEJdLyN8qeEmMREbB5juW68k3DiygPxV9YsHGX4ihbKkcEJ1UK7TU/i1RwUNgiihyhlfHjX6pV6KTRXKb+c9CoRztsDGQnOerI77vc9VUzPEgEkDHIRZNm0tn5IAMBQOCAcRjNbwDYVJ+ZjS+cFMIEmcFAyT8NhlcjDQF+xc/v1Ka1OelxBQgsQ1oMld0kdPOrWCWh/ZgwBkqH70ppEuPUQQx7Sfg5WQ1FWzgwiH7PGwBFC/S0h3/SwtxQZo/2t2vF6u+EJzSaANn03FKqFEYiJzqIgwWy7u5Ge84gu9bUDJGM60D3VGW0UYw8D63W/lVqwcVsIN3RmLyyzyGbCfeA== x-ms-exchange-antispam-messagedata: VOay4VaxTwXkchRoVtapk03YTmcx1MnCroB6xVBRO3ZPT3lQw1z7OjHKrv/X6mfw+i/j/ht2S3U9u9TlxPfCDvPGMT5oBC06RfAeAZWDFCiYMU7cslW54VdXxLKefcLB4UuHCyI2338qs3yPdRaXBdDYKEhIO7TJgstGiMjklA1Ew2zfsrqHZQeH9OWMghIG+CnoaGMhSAUvZXPpKa7tNA== Content-Type: text/plain; charset="utf-8" Content-ID: <1418A27891ABBD42A928E80A4CFECD4D@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 46dff91d-5dc6-4e90-354e-08d7bee47e40 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 20:01:27.5482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Y/iidf9RkistTH+ntZvd3sV4Cd/xKZyK6eTLORlC15R9vLNfuIxYM3tA1epnlNrqGBjEAhpYHvYrviRARKcqiw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1369 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [Ecrit] [Last-Call] Iotdir telechat review of draft-ietf-ecrit-data-only-ea-21 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 20:01:40 -0000 VGhhbmsgeW91IHZlcnkgbXVjaCBHb256YWxvLA0KDQpJIHdpbGwgdXNlIHlvdXIgcmV2aWV3IHdo ZW4gZW50ZXJpbmcgbXkgSUVTRyBiYWxsb3QgbGF0ZXIgdG9kYXkuIEhhdmluZyBhIGRpcmVjdG9y YXRlIHJldmlldyByZWFsbHkgaGVscHMgdGhlIEFEIGpvYiA7LSkNCg0KUmVnYXJkcw0KDQotw6ly aWMNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGxhc3QtY2FsbCA8bGFz dC1jYWxsLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBHb256YWxvIFNhbGd1ZWlybyB2 aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+DQpSZXBseS1UbzogIkdvbnphbG8gU2Fs Z3VlaXJvIChnc2FsZ3VlaSkiIDxnc2FsZ3VlaUBjaXNjby5jb20+DQpEYXRlOiBNb25kYXksIDIg TWFyY2ggMjAyMCBhdCAyMDo0OQ0KVG86ICJpb3QtZGlyZWN0b3JhdGVAaWV0Zi5vcmciIDxpb3Qt ZGlyZWN0b3JhdGVAaWV0Zi5vcmc+DQpDYzogImxhc3QtY2FsbEBpZXRmLm9yZyIgPGxhc3QtY2Fs bEBpZXRmLm9yZz4sICJkcmFmdC1pZXRmLWVjcml0LWRhdGEtb25seS1lYS5hbGxAaWV0Zi5vcmci IDxkcmFmdC1pZXRmLWVjcml0LWRhdGEtb25seS1lYS5hbGxAaWV0Zi5vcmc+LCAiZWNyaXRAaWV0 Zi5vcmciIDxlY3JpdEBpZXRmLm9yZz4NClN1YmplY3Q6IFtMYXN0LUNhbGxdIElvdGRpciB0ZWxl Y2hhdCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1lY3JpdC1kYXRhLW9ubHktZWEtMjENCg0KICAgIFJl dmlld2VyOiBHb256YWxvIFNhbGd1ZWlybw0KICAgIFJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGgg Tml0cw0KICAgIA0KICAgIERvY3VtZW50OiBkcmFmdC1pZXRmLWVjcml0LWRhdGEtb25seS1lYS0y MQ0KICAgIFJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGggTml0cw0KICAgIFJldmlldyB0eXBlOiBp b3RkaXIgLSBMYXN0IENhbGwgcmV2aWV3DQogICAgUmVxdWVzdGVkIHZlcnNpb24gZm9yIHJldmll dzogQ3VycmVudA0KICAgIFJldmlldyBEYXRlOiAyMDIwLTAzLTAyDQogICAgUmV2aWV3ZXI6IEdv bnphbG8gU2FsZ3VlaXJvDQogICAgDQogICAgSSBhbSB0aGUgYXNzaWduZWQgSW9UIGRpcmVjdG9y YXRlIHJldmlld2VyIGZvciA8ZHJhZnQtaWV0Zi1lY3JpdC1kYXRhLW9ubHktZWE+Lg0KICAgIFRo ZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRo ZSBJbnRlcm5ldCBBcmVhDQogICAgRGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBzaGVw aGVyZChzKSBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdA0KICAgIGxpa2UgdGhleSB3 b3VsZCB0cmVhdCBjb21tZW50cyBmcm9tIGFueSBvdGhlciBJRVRGIGNvbnRyaWJ1dG9ycyBhbmQg cmVzb2x2ZQ0KICAgIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgTGFzdCBDYWxsIGNvbW1lbnRz IHRoYXQgaGF2ZSBiZWVuIHJlY2VpdmVkLiBGb3IgbW9yZQ0KICAgIGRldGFpbHMgb24gdGhlIElv VCBEaXJlY3RvcmF0ZSwgc2VlDQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ncm91 cC9pb3RkaXIvYWJvdXQvDQogICAgDQogICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgKDEpIGhv dyBtZXRob2Qgb2YgaW5jbHVkaW5nIGEgQ0FQIG1lc3NhZ2UgaW4gYSBTSVANCiAgICB0cmFuc2Fj dGlvbiBieSBkZWZpbmluZyBpdCBhcyBhIGJsb2NrIG9mICJhZGRpdGlvbmFsIGRhdGEiIGFzIHdl bGwgYXMgKDIpDQogICAgZGVzY3JpYmVzIGhvdyBhIFNJUCBNRVNTQUdFIHRyYW5zYWN0aW9uIGNh biBiZSB1c2VkIHRvIHNlbmQgYSBub24taW50ZXJhY3RpdmUNCiAgICBjYWxsLiBJIGhhdmUgcmV2 aWV3ZWQgdGhpcyBkb2N1bWVudCBmcm9tIHRoZSBJb1QgcGVyc3BlY3RpdmUgYW5kIHRoZSBkb2N1 bWVudA0KICAgIGFwcGVhcnMgdG8gYmUgaW5mb3JtYXRpdmUsIGNsZWFyIGFuZCB3aXRob3V0IG9i dmlvdXMgdGVjaG5pY2FsIGdhcHMuIFRoZXJlIGFyZQ0KICAgIGp1c3QgYSBmZXcgdGhlIGF1dGhv cnMgbWlnaHQgY29uc2lkZXIgYWRkcmVzc2luZy4NCiAgICANCiAgICBOaXRzOg0KICAgID09PT0N CiAgICANCiAgICBTOiBBYnN0cmFjdA0KICAgIA0KICAgICJ0eXBlIG9mIGludGVyYWN0aW9ucyIg LT4gInR5cGVzIG9mIGludGVyYWN0aW9ucyINCiAgICANCiAgICBTOjENCiAgICANCiAgICAiYWxl cnQgc3BlY2lmaWMiIC0+ICJhbGVydC1zcGVjaWZpYyINCiAgICANCiAgICBTOjkNCiAgICANCiAg ICAiTG9jYXRpb24gc3BlY2lmaWMiIC0+ICJMb2NhdGlvbi1zcGVjaWZpYyINCiAgICANCiAgICBT OjkNCiAgICANCiAgICAiTm90ZSB0aGF0IG5vbmUgb2YgdGhlIHNlY3VyaXR5IG1lY2hhbmlzbSBp biB0aGlzIGRvY3VtZW50IiAtPiAiTm90ZSB0aGF0IG5vbmUNCiAgICBvZiB0aGUgc2VjdXJpdHkg bWVjaGFuaXNtcyBpbiB0aGlzIGRvY3VtZW50Ig0KICAgIA0KICAgIA0KICAgIA0KICAgIC0tIA0K ICAgIGxhc3QtY2FsbCBtYWlsaW5nIGxpc3QNCiAgICBsYXN0LWNhbGxAaWV0Zi5vcmcNCiAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xhc3QtY2FsbA0KICAgIA0KDQo= From nobody Mon Mar 2 13:19:11 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CD73A11B5 for ; Mon, 2 Mar 2020 13:19:05 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 Fnql3Yi5FP-T for ; Mon, 2 Mar 2020 13:19:03 -0800 (PST) Received: from mail-yw1-xc30.google.com (mail-yw1-xc30.google.com [IPv6:2607:f8b0:4864:20::c30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D133A11A9 for ; Mon, 2 Mar 2020 13:19:03 -0800 (PST) Received: by mail-yw1-xc30.google.com with SMTP id a132so1305507ywb.2 for ; Mon, 02 Mar 2020 13:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K1N4oToJhR3i3Tey6DT/INlkPqYoYgVyJToFn3HyGxM=; b=bQPEHENq0PoI9QCK6nwiVMRVWOUrRs9DoIL/YXN73G2UD+M9fzbjnvLZ+YPxVYFelG +Oh4zGlBPDhy0khwXyHHgEm5rz5f97kb8ld7jPMKg44eIGAZV8nccMA0H6/+5OHE430q LN1QWNvepn94DKlXb5WMYeOy7gb6ttRgZzk7gYzJWjPpW3ulJMghpAongNCuUV19P1ur mTU4/0+c8XkbuFPFfPBICxYOSxG9fx/miGDD/h7f1zioF1cTZIFyzWKKrCynKf1BBCrs kG68dVboJuGtLFcFfaE9kF///N7Pv5Df8OMCxj4TAL3QDIn4Vvtiqvuh1qsIS2pHGSfa ToXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K1N4oToJhR3i3Tey6DT/INlkPqYoYgVyJToFn3HyGxM=; b=XBbc1kIxj905t5j2WhaJe9qh8p0YaVV8SCoRQUxJNQn/eprB/A4Kfh3xyyZJ3mnDz0 +CZLSpn0TGRdyTOVMyvxf3H7ONXV0FLAdEmNgZUGcjDGRpTekoONjRz/AAdqZTu0pweV UQEnNiixC+TYftR6y5qz3Ic9c9xXIKVFWA9BTY1aVzAEujMmRXPU2XhAPpI+vB0UNuHx MoQliXSMEly+CMdfXPlB0p9JXToeIp9qwsHoL4nAa4L/YkrRfIx6/GAwcL975BwOgWjd F0puiw+zTHOqbgh0ZXIub6+cHKvAhReLypPzcAbZSYIOi4jYCxrp13Dd8Ud/+JaqTtPF SgWQ== X-Gm-Message-State: ANhLgQ113CwQUIktsgH3byiQZiDfGUoEoOoqcVuG5vY4o2xELhko+28a DpmWwKIK4XMrkFdkarvGRnOaPg== X-Google-Smtp-Source: ADFU+vv/D6Op2ralrjepH38lJn2OGklDK54jM5ht/f8jCIbQJh5Lye+Vc1eP7xMy7QNcY6lrK7Cm1g== X-Received: by 2002:a5b:383:: with SMTP id k3mr1027757ybp.260.1583183942117; Mon, 02 Mar 2020 13:19:02 -0800 (PST) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id f7sm2163800ywc.44.2020.03.02.13.19.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2020 13:19:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Brian Rosen In-Reply-To: <158317853107.27458.1826052910979859321@ietfa.amsl.com> Date: Mon, 2 Mar 2020 16:18:59 -0500 Cc: iot-directorate@ietf.org, draft-ietf-ecrit-data-only-ea.all@ietf.org, last-call@ietf.org, ecrit@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <158317853107.27458.1826052910979859321@ietfa.amsl.com> To: Gonzalo Salgueiro X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Ecrit] Iotdir telechat review of draft-ietf-ecrit-data-only-ea-21 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 21:19:05 -0000 Thanks for the review. I will fix the nits. You did understand that this is the mechanism by which an IoT device = makes an emergency call when the device doesn=E2=80=99t have two way = interactive media, right? Brian > On Mar 2, 2020, at 2:48 PM, Gonzalo Salgueiro via Datatracker = wrote: >=20 > Reviewer: Gonzalo Salgueiro > Review result: Ready with Nits >=20 > Document: draft-ietf-ecrit-data-only-ea-21 > Review result: Ready with Nits > Review type: iotdir - Last Call review > Requested version for review: Current > Review Date: 2020-03-02 > Reviewer: Gonzalo Salgueiro >=20 > I am the assigned IoT directorate reviewer for = . > These comments were written primarily for the benefit of the Internet = Area > Directors. Document editors and shepherd(s) should treat these = comments just > like they would treat comments from any other IETF contributors and = resolve > them along with any other Last Call comments that have been received. = For more > details on the IoT Directorate, see > https://datatracker.ietf.org/group/iotdir/about/ >=20 > This document describes (1) how method of including a CAP message in a = SIP > transaction by defining it as a block of "additional data" as well as = (2) > describes how a SIP MESSAGE transaction can be used to send a = non-interactive > call. I have reviewed this document from the IoT perspective and the = document > appears to be informative, clear and without obvious technical gaps. = There are > just a few the authors might consider addressing. >=20 > Nits: > =3D=3D=3D=3D >=20 > S: Abstract >=20 > "type of interactions" -> "types of interactions" >=20 > S:1 >=20 > "alert specific" -> "alert-specific" >=20 > S:9 >=20 > "Location specific" -> "Location-specific" >=20 > S:9 >=20 > "Note that none of the security mechanism in this document" -> "Note = that none > of the security mechanisms in this document" >=20 >=20 >=20 From nobody Mon Mar 2 13:35:48 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D11C23A11FC; Mon, 2 Mar 2020 13:35:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, allison.mankin@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <158318494177.27467.10769075669362560529@ietfa.amsl.com> Date: Mon, 02 Mar 2020 13:35:41 -0800 Archived-At: Subject: [Ecrit] Roman Danyliw's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 21:35:42 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-ecrit-data-only-ea-21: Discuss 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-ecrit-data-only-ea/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 9. Since CAPs can be included by reference (via URI) and the senders may be unknown to the ESRP/PSAP, please include language on the security considerations for untrusted URIs per Section 7 of RFC3986 Section 9. Per “To provide protection of the entire SIP message exchange between neighboring SIP entities, the usage of TLS is REQUIRED.”, can you please provide guidance on how to use TLS. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1. Per “These messages may be one-shot alerts to emergency authorities …”, aren’t these alerts as scoped for the purposes of this document _always_ “one-shot alerts”? Section 4.2. In the definition of ‘area’, please note that the various conversions (e.g., arc-bands to equivalent polygons) are out of scope of this document. From nobody Mon Mar 2 13:45:17 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540AD3A1269; Mon, 2 Mar 2020 13:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.276, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 nuMq2y1RoXEJ; Mon, 2 Mar 2020 13:44:58 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3581A3A1288; Mon, 2 Mar 2020 13:44:58 -0800 (PST) Received: from [172.17.121.48] (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 022LimOH000546 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 2 Mar 2020 15:44:49 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1583185490; bh=tDBnRDsLUvhlDgI09FHugTGTB3I8293Zu2/jbbZTNaI=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=lSm7LHXOApa07Tkho4B5YjgIxP3taeEoFCxN7YGzNAmaao7R4vvwRx8Ao4XvtBMcD i5Ka6a+fFGuw9ymNH2kBaQNXzfWmLBimGglPli9weVI4fib0xsqmzvh6gBxEeK8nPp g5B6xh/rAqIBZRRWHbzduINKvEJgagQ2ejJZUx7k= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be [172.17.121.48] To: Roman Danyliw , The IESG Cc: allison.mankin@gmail.com, ecrit-chairs@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-data-only-ea@ietf.org References: <158318494177.27467.10769075669362560529@ietfa.amsl.com> From: Adam Roach Message-ID: <227ba0d7-8ace-2ad2-c28c-e74996210c4e@nostrum.com> Date: Mon, 2 Mar 2020 15:44:41 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <158318494177.27467.10769075669362560529@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Ecrit] Roman Danyliw's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 21:45:07 -0000 On 3/2/2020 3:35 PM, Roman Danyliw via Datatracker wrote: > Section 9. Per “To provide protection of the entire SIP message exchange > between neighboring SIP entities, the usage of TLS is REQUIRED.”, can you > please provide guidance on how to use TLS. I think the strong implication here is that TLS is to be used in the same way that TLS is used in other SIP applications (in the same way that an HTTP document saying "MUST use TLS" is pretty clearly saying to use HTTPS as per the existing HTTP RFCs). Unfortunately, the TLS handling for SIP is mixed into RFC 3261 all _over_ the place, so there's not anything particularly comprehensive to point to. The best that I think could be said would be something along the lines of "...the usage of TLS, as described in section 26 of [RFC3261], is REQUIRED." Would that satisfy your concern? /a From nobody Mon Mar 2 13:51:17 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D57E3A087C; Mon, 2 Mar 2020 13:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 yOU5EqfQE-ps; Mon, 2 Mar 2020 13:51:07 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 297763A12B2; Mon, 2 Mar 2020 13:51:07 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 022Lp5fd029378; Mon, 2 Mar 2020 16:51:05 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 022Lp5fd029378 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1583185865; bh=M0b5uPCFko54ZojnNEFL09EH4A/T95c+2GGKJ6v0lDg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=U+ULPRA2J38OtQvLR20PwoYxDX6RXlSaZNruAU/XdFCqul/Hb4BPp7XTLaqhHpZ1u Qx5PB0QE91MLQqqxwCLBTaKi2qCQCUkzfGq8NUMzSEaXJlfvdSVPbRW8db1p6me6oO 0pzIC/DlWrNm1Ir5Cchx2SIcYsWYDZJ55nY9rTQA= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 022Lp1Aj029740; Mon, 2 Mar 2020 16:51:01 -0500 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Mon, 2 Mar 2020 16:51:01 -0500 From: Roman Danyliw To: Adam Roach , The IESG CC: "allison.mankin@gmail.com" , "ecrit-chairs@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-data-only-ea@ietf.org" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) Thread-Index: AQHV8NqN37oWVGSDVkywGLx4ZMRJEqg2KauA//+trjA= Date: Mon, 2 Mar 2020 21:51:00 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0216F60CEA@marchand> References: <158318494177.27467.10769075669362560529@ietfa.amsl.com> <227ba0d7-8ace-2ad2-c28c-e74996210c4e@nostrum.com> In-Reply-To: <227ba0d7-8ace-2ad2-c28c-e74996210c4e@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] Roman Danyliw's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 21:51:11 -0000 SGkgQWRhbSENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBZGFtIFJv YWNoIDxhZGFtQG5vc3RydW0uY29tPg0KPiBTZW50OiBNb25kYXksIE1hcmNoIDAyLCAyMDIwIDQ6 NDUgUE0NCj4gVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz47IFRoZSBJRVNHIDxpZXNn QGlldGYub3JnPg0KPiBDYzogYWxsaXNvbi5tYW5raW5AZ21haWwuY29tOyBlY3JpdC1jaGFpcnNA aWV0Zi5vcmc7IGVjcml0QGlldGYub3JnOyBkcmFmdC0NCj4gaWV0Zi1lY3JpdC1kYXRhLW9ubHkt ZWFAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFJvbWFuIERhbnlsaXcncyBEaXNjdXNzIG9uIGRy YWZ0LWlldGYtZWNyaXQtZGF0YS1vbmx5LWVhLTIxOg0KPiAod2l0aCBESVNDVVNTIGFuZCBDT01N RU5UKQ0KPiANCj4gT24gMy8yLzIwMjAgMzozNSBQTSwgUm9tYW4gRGFueWxpdyB2aWEgRGF0YXRy YWNrZXIgd3JvdGU6DQo+ID4gU2VjdGlvbiA5LiAgUGVyIOKAnFRvIHByb3ZpZGUgcHJvdGVjdGlv biBvZiB0aGUgZW50aXJlIFNJUCBtZXNzYWdlDQo+ID4gZXhjaGFuZ2UgYmV0d2VlbiBuZWlnaGJv cmluZyBTSVAgZW50aXRpZXMsIHRoZSB1c2FnZSBvZiBUTFMgaXMNCj4gPiBSRVFVSVJFRC7igJ0s IGNhbiB5b3UgcGxlYXNlIHByb3ZpZGUgZ3VpZGFuY2Ugb24gaG93IHRvIHVzZSBUTFMuDQo+IA0K PiANCj4gSSB0aGluayB0aGUgc3Ryb25nIGltcGxpY2F0aW9uIGhlcmUgaXMgdGhhdCBUTFMgaXMg dG8gYmUgdXNlZCBpbiB0aGUgc2FtZSB3YXkNCj4gdGhhdCBUTFMgaXMgdXNlZCBpbiBvdGhlciBT SVAgYXBwbGljYXRpb25zIChpbiB0aGUgc2FtZSB3YXkgdGhhdCBhbiBIVFRQDQo+IGRvY3VtZW50 IHNheWluZyAiTVVTVCB1c2UgVExTIiBpcyBwcmV0dHkgY2xlYXJseSBzYXlpbmcgdG8gdXNlIEhU VFBTIGFzIHBlcg0KPiB0aGUgZXhpc3RpbmcgSFRUUCBSRkNzKS4NCj4gDQo+IFVuZm9ydHVuYXRl bHksIHRoZSBUTFMgaGFuZGxpbmcgZm9yIFNJUCBpcyBtaXhlZCBpbnRvIFJGQyAzMjYxIGFsbCBf b3Zlcl8gdGhlDQo+IHBsYWNlLCBzbyB0aGVyZSdzIG5vdCBhbnl0aGluZyBwYXJ0aWN1bGFybHkg Y29tcHJlaGVuc2l2ZSB0byBwb2ludCB0by4gVGhlDQo+IGJlc3QgdGhhdCBJIHRoaW5rIGNvdWxk IGJlIHNhaWQgd291bGQgYmUgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiAiLi4udGhlDQo+ IHVzYWdlIG9mIFRMUywgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMjYgb2YgW1JGQzMyNjFdLCBp cyBSRVFVSVJFRC4iDQo+IA0KPiBXb3VsZCB0aGF0IHNhdGlzZnkgeW91ciBjb25jZXJuPw0KDQpJ IGNhbiBhcHByZWNpYXRlIHRoaXMgZGlmZmljdWx0eS4gIFNvdW5kcyBnb29kIHRvIG1lLiANCg0K Um9tYW4NCg== From nobody Mon Mar 2 13:51:44 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801E53A087D; Mon, 2 Mar 2020 13:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=RoCh00j5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=w9QoG7AG 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 dYh5yO9QDCfb; Mon, 2 Mar 2020 13:51:40 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D533A07DC; Mon, 2 Mar 2020 13:51:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10871; q=dns/txt; s=iport; t=1583185900; x=1584395500; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=foEJRquD5I1Ktrddk0yL8HwhJAFzZVjoMR1pxILngAY=; b=RoCh00j5v3Iih0RlTqXs8k7utFlyj8MHWPGIGXsuui7Ed7s90QlH48of YCAhoio8MPHlPt78gV6AdFk2+SIppma9nRXj/F6pYDluJCogSGxwkAi6I oHt/m4hQrJrVWPbkeQFGJBii1IWtvwNWda8oRYWmGfZt8J1hDhv9/X6UF 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AaK4cVBHKMG5Zxf84JcUl0Z1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efHxZig1AclDfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfBQCYfl1e/5tdJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVFAFbFggBAsqCoQKg0YDimaCX5MzhGKCUgNUCQEBAQwBARg?= =?us-ascii?q?BCgoCBAEBhEACF4F0JDgTAgMBAQsBAQUBAQECAQUEbYVWDIVkAgEDAQEQEQQ?= =?us-ascii?q?ZAQEsCwEPAgEIDgYrAwICAiULFBECBA4FIoMEAYF9TQMuAQ6hSAKBOYhidX8?= =?us-ascii?q?zgn8BAQWFHhiCDAMGgTiMJRqBQT+BOCCCTT6CZAEBA4ICDYJkMoIsjV6DB4V?= =?us-ascii?q?wmUoKgjyHUopihDIcgkmMbIt8l26STgIEAgQFAg4BAQWBaSKBWHAVOyoBgg0?= =?us-ascii?q?BM1AYDY4dDBeDUIUUhUF0gSmOOgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.70,508,1574121600"; d="scan'208,217";a="727252544" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Mar 2020 21:51:39 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 022LpcIY028265 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Mar 2020 21:51:39 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 2 Mar 2020 15:51:38 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 2 Mar 2020 16:51:37 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 2 Mar 2020 15:51:37 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lyPW+ccYth7eZIZRRHJM7kkzl32bAXAFgZ9UYb6e6yHKiMv4U1IfAa9W2FF9gSsC5U+1omCBVo3O3VSevV2xOzZBSiUgYu6q3i1lAX78DnGxrjl3uy3PDiZsVgNbzFJ6ZhFrgtBss9GvYjYUB37L3Rmk2F414XbzmlLInCLHGABJS5asVPUBn0+IJmC3mUHJ1U/k3tV0N+cyfrL5Pbx2YJWmMG191T9/E2IyllPoU5iyHhNZzzT94KWK4kduoBF/mNA3KNtpeTLPIwiC63Eq/2wQNEFvPck8/6aAbzQG/F+EjuhDAt3FZGHOzG1SDOtLD40uPDI1uamlVdt9nuR2ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=foEJRquD5I1Ktrddk0yL8HwhJAFzZVjoMR1pxILngAY=; b=Wkd9Wp8PV0CgY4pK/C8IMvp0A8/csRncWJkxGG6UfRUfukVu2sJfHWhaW3jOJKLj55HouHK3rxJ+mFdfyLkuimdStP6RMordFsXXQP0o8eRXpv/adrejRHzi6IlaC3kUr9h1FvlEY6Jr1Y3+AotF6lQ1fn/dD2Js1qidb6TxfiWH1SfX+aYxkKrsBABSn8XQ9005npeP9bk/haHOvtuhK6rVscXzQ9m4rD7E23cly2RvLPn28L4f2k/ejhyc1KL5eda+7bp4Ub/w+JGeIsmNH33m2LpA5JBz1GFl8coRCrXBqbKEUpMw0NAP77MXbp8BZK7beSDcYmXGdwECIXIcwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=foEJRquD5I1Ktrddk0yL8HwhJAFzZVjoMR1pxILngAY=; b=w9QoG7AGiCOkm15rBFbn+tFqhI7kRFvpUcb8vqveEgWNXxKdS0vOJ60rYhsC3g+ZG8fWAv3u+F92sxIb1XDNr2itzbnpe1G4cd+beGxMvfnMxOH4Gu2IMfaQQ0p1MeMvZ7HMKVvRaq3ouftwLoyHvXxube6z3HKemohjKQzCugA= Received: from BN6PR11MB1810.namprd11.prod.outlook.com (2603:10b6:404:fc::20) by BN6PR11MB3857.namprd11.prod.outlook.com (2603:10b6:405:79::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Mon, 2 Mar 2020 21:51:36 +0000 Received: from BN6PR11MB1810.namprd11.prod.outlook.com ([fe80::1c0e:b45c:7c54:74d]) by BN6PR11MB1810.namprd11.prod.outlook.com ([fe80::1c0e:b45c:7c54:74d%5]) with mapi id 15.20.2772.019; Mon, 2 Mar 2020 21:51:36 +0000 From: "Gonzalo Salgueiro (gsalguei)" To: Brian Rosen CC: "iot-directorate@ietf.org" , "draft-ietf-ecrit-data-only-ea.all@ietf.org" , "ecrit@ietf.org" , "last-call@ietf.org" Thread-Topic: [Last-Call] Iotdir telechat review of draft-ietf-ecrit-data-only-ea-21 Thread-Index: AQHV8NhG8e5d76WcaUe3H6rUGcK4uKg118uA Date: Mon, 2 Mar 2020 21:51:36 +0000 Message-ID: <0A4C322A-A0EB-467E-B225-B9EBA61FB7ED@cisco.com> References: <158317853107.27458.1826052910979859321@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gsalguei@cisco.com; x-originating-ip: [104.182.55.116] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6b421b97-a764-4d35-8e3a-08d7bef3e177 x-ms-traffictypediagnostic: BN6PR11MB3857: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(346002)(366004)(396003)(199004)(189003)(316002)(54906003)(66574012)(26005)(53546011)(6506007)(76116006)(2616005)(64756008)(66556008)(66476007)(66946007)(5660300002)(33656002)(186003)(66446008)(2906002)(4326008)(6512007)(86362001)(8936002)(36756003)(6486002)(8676002)(478600001)(71200400001)(6916009)(81156014)(81166006)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB3857; H:BN6PR11MB1810.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dDHhjgF6pH2GDObgEGH8vxwEs5Wr4WbUkFAJbIu5gzCyaulkyEkckv7k1qVTHE+SiOb3ihgJVEISH8/q/2pkNKDRNryeNCVU38+VwiUnjtwu4iDpGkpMJpCEI0oMOJYZ2Te41V2IGDziI17zeKzd/LfXRYhzcTDVon0wrlbFxdp8xNa1fdY3WKr79Q8CHNeDeeryZ8f/zqgpMuS9VcpdsBysI51UWPm4V4rMB3mBi6embtBArOmF4FHqI+0hUC7o6rxUzFdk0jOoLYgB0po+9Uh2le+T5WcnVvk1bWf6XIU2ULe5h7jc7iOiBRYiLN3tQ07rkxgTFZ4B7HUroDJqVknwbQuz1xvBDAJ16XWMrriy435l8zzs+I/zEjlFNUxa24gPTimNsqNVYxDpUP57dqdzdhQLp4Wx/Ei6AuJVntZcZ+xCJDJeMAlCJFnbiiL9L1OyK1Gvairu/jxys9bX8Px9Go10IEKiuAXaKK4fEjD2WgYI9pHHULYX5PtPNeeiOg+gvBkzyjJ1ylZMWvPDfg== x-ms-exchange-antispam-messagedata: JLPvMGnmBqpa8ZWs8ZHatmhBb7pS56mswYlFby6P2rvtrgrMdrSLnAD5sqoQxqO/gFtxmhf3zEQZxvrGMZhmLG3Ffs0npkSsZO078klkT6X3tE2aqh+Pnp7cl5vSNAlIgBybn3fqUZplKEv1xlWC8g== Content-Type: multipart/alternative; boundary="_000_0A4C322AA0EB467EB225B9EBA61FB7EDciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6b421b97-a764-4d35-8e3a-08d7bef3e177 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 21:51:36.3364 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: cNDNsGbtvBNfHGKYoVnRR2m73RudWgG25tX2lW6yYhbW+zR+oYrnLoeL8ui8bAF04UlZRGYueYlLyR6F1NH6Ig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB3857 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Ecrit] [Last-Call] Iotdir telechat review of draft-ietf-ecrit-data-only-ea-21 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 21:51:43 -0000 --_000_0A4C322AA0EB467EB225B9EBA61FB7EDciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4gLQ0KDQpZZXMsIHRoZSBzY29wZSBzZWVtZWQgY2xlYXIgdG8gbWUuIE9uZSB0aGlu ZyBJIHdvdWxkIHF1YWxpZnkgaXMgdGhhdCBJIGludGVycHJldGVkIHRoZSBzY29wZSB0byBiZSBz bGlnaHRseSBicm9hZGVyIHRoYW4gYSAibWVjaGFuaXNtIGJ5IHdoaWNoIGFuIElvVCBkZXZpY2Ug bWFrZXMgYW4gZW1lcmdlbmN5IGNhbGzigJ0uIFdoaWxlIHlvdSBleHBsaWNpdGx5IGNhbGwgb3V0 IHNlbnNvcnMgKHJlYWQ6IGNvbnN0cmFpbmVkIGRldmljZXMpIEkgZG9u4oCZdCBiZWxpZXZlIHlv dSBleHBsaWNpdGx5IHJlc3RyaWN0IHRoZSBtZWNoYW5pc20gIHRvIHRob3NlIGRldmljZXMuIEkg aW5mZXJyZWQgdGhhdCB3b3VsZCBiZSB0aGUgdHlwaWNhbCB1c2UgY2FzZSBidXQgSSBtb3JlIGdl bmVyYWxseSB0b29rIGl0IGFzICphbnkqIGRldmljZSB0aGF0IG5lZWRzIHRvIGluaXRpYXRlIGEg cmVxdWVzdCBmb3IgZW1lcmdlbmN5IHNlcnZpY2VzIHdoZXJlIG5vIGludGVyYWN0aXZlIG1lZGlh IGNoYW5uZWwgd2lsbCBiZSBlc3RhYmxpc2hlZCB3b3VsZCB1c2UgdGhlIG1lY2hhbmlzbXMgZGVz Y3JpYmVkIGluIHRoaXMgZG9jdW1lbnQuIEkgYXNzdW1lZCB0aGlzIHNjb3BlIHRvIGJlIGFwcHJv cHJpYXRlIGJ1dCBpZiB5b3UgdGhpbmsgeW91IG5lZWQgdG8gbmFycm93IGl0IGZ1cnRoZXIgdG8g ZXhjbHVzaXZlbHkgY29uc3RyYWluZWQgZGV2aWNlcyB0aGVuIHBlcmhhcHMgeW91IGNhbiBhZGQg YSBibHVyYiBhYm91dCB0aGF0LiBIb3BlIHRoaXMgaGVscHMuDQoNCg0KQ2hlZXJzLA0KDQpHb256 YWxvDQoNCg0KT24gTWFyIDIsIDIwMjAsIGF0IDQ6MTggUE0sIEJyaWFuIFJvc2VuIDxickBicmlh bnJvc2VuLm5ldDxtYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQ+PiB3cm90ZToNCg0KVGhhbmtzIGZv ciB0aGUgcmV2aWV3LiAgSSB3aWxsIGZpeCB0aGUgbml0cy4NCg0KWW91IGRpZCB1bmRlcnN0YW5k IHRoYXQgdGhpcyBpcyB0aGUgbWVjaGFuaXNtIGJ5IHdoaWNoIGFuIElvVCBkZXZpY2UgbWFrZXMg YW4gZW1lcmdlbmN5IGNhbGwgd2hlbiB0aGUgZGV2aWNlIGRvZXNu4oCZdCBoYXZlIHR3byB3YXkg aW50ZXJhY3RpdmUgbWVkaWEsIHJpZ2h0Pw0KDQpCcmlhbg0KDQpPbiBNYXIgMiwgMjAyMCwgYXQg Mjo0OCBQTSwgR29uemFsbyBTYWxndWVpcm8gdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYu b3JnPG1haWx0bzpub3JlcGx5QGlldGYub3JnPj4gd3JvdGU6DQoNClJldmlld2VyOiBHb256YWxv IFNhbGd1ZWlybw0KUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBOaXRzDQoNCkRvY3VtZW50OiBk cmFmdC1pZXRmLWVjcml0LWRhdGEtb25seS1lYS0yMQ0KUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0 aCBOaXRzDQpSZXZpZXcgdHlwZTogaW90ZGlyIC0gTGFzdCBDYWxsIHJldmlldw0KUmVxdWVzdGVk IHZlcnNpb24gZm9yIHJldmlldzogQ3VycmVudA0KUmV2aWV3IERhdGU6IDIwMjAtMDMtMDINClJl dmlld2VyOiBHb256YWxvIFNhbGd1ZWlybw0KDQpJIGFtIHRoZSBhc3NpZ25lZCBJb1QgZGlyZWN0 b3JhdGUgcmV2aWV3ZXIgZm9yIDxkcmFmdC1pZXRmLWVjcml0LWRhdGEtb25seS1lYT4uDQpUaGVz ZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUg SW50ZXJuZXQgQXJlYQ0KRGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBzaGVwaGVyZChz KSBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdA0KbGlrZSB0aGV5IHdvdWxkIHRyZWF0 IGNvbW1lbnRzIGZyb20gYW55IG90aGVyIElFVEYgY29udHJpYnV0b3JzIGFuZCByZXNvbHZlDQp0 aGVtIGFsb25nIHdpdGggYW55IG90aGVyIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IGhhdmUgYmVl biByZWNlaXZlZC4gRm9yIG1vcmUNCmRldGFpbHMgb24gdGhlIElvVCBEaXJlY3RvcmF0ZSwgc2Vl DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2dyb3VwL2lvdGRpci9hYm91dC8NCg0KVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgKDEpIGhvdyBtZXRob2Qgb2YgaW5jbHVkaW5nIGEgQ0FQIG1l c3NhZ2UgaW4gYSBTSVANCnRyYW5zYWN0aW9uIGJ5IGRlZmluaW5nIGl0IGFzIGEgYmxvY2sgb2Yg ImFkZGl0aW9uYWwgZGF0YSIgYXMgd2VsbCBhcyAoMikNCmRlc2NyaWJlcyBob3cgYSBTSVAgTUVT U0FHRSB0cmFuc2FjdGlvbiBjYW4gYmUgdXNlZCB0byBzZW5kIGEgbm9uLWludGVyYWN0aXZlDQpj YWxsLiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBmcm9tIHRoZSBJb1QgcGVyc3BlY3Rp dmUgYW5kIHRoZSBkb2N1bWVudA0KYXBwZWFycyB0byBiZSBpbmZvcm1hdGl2ZSwgY2xlYXIgYW5k IHdpdGhvdXQgb2J2aW91cyB0ZWNobmljYWwgZ2Fwcy4gVGhlcmUgYXJlDQpqdXN0IGEgZmV3IHRo ZSBhdXRob3JzIG1pZ2h0IGNvbnNpZGVyIGFkZHJlc3NpbmcuDQoNCk5pdHM6DQo9PT09DQoNClM6 IEFic3RyYWN0DQoNCiJ0eXBlIG9mIGludGVyYWN0aW9ucyIgLT4gInR5cGVzIG9mIGludGVyYWN0 aW9ucyINCg0KUzoxDQoNCiJhbGVydCBzcGVjaWZpYyIgLT4gImFsZXJ0LXNwZWNpZmljIg0KDQpT OjkNCg0KIkxvY2F0aW9uIHNwZWNpZmljIiAtPiAiTG9jYXRpb24tc3BlY2lmaWMiDQoNClM6OQ0K DQoiTm90ZSB0aGF0IG5vbmUgb2YgdGhlIHNlY3VyaXR5IG1lY2hhbmlzbSBpbiB0aGlzIGRvY3Vt ZW50IiAtPiAiTm90ZSB0aGF0IG5vbmUNCm9mIHRoZSBzZWN1cml0eSBtZWNoYW5pc21zIGluIHRo aXMgZG9jdW1lbnQiDQoNCg0KDQoNCi0tDQpsYXN0LWNhbGwgbWFpbGluZyBsaXN0DQpsYXN0LWNh bGxAaWV0Zi5vcmc8bWFpbHRvOmxhc3QtY2FsbEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbGFzdC1jYWxsDQoNCg== --_000_0A4C322AA0EB467EB225B9EBA61FB7EDciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4B718186DAF7654F9487365B656FA6F1@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIEJyaWFuIC0mbmJzcDsNCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlllcywgdGhlIHNjb3BlIHNl ZW1lZCBjbGVhciB0byBtZS4gT25lIHRoaW5nIEkgd291bGQgcXVhbGlmeSBpcyB0aGF0IEkgaW50 ZXJwcmV0ZWQgdGhlIHNjb3BlIHRvIGJlIHNsaWdodGx5IGJyb2FkZXIgdGhhbiBhICZxdW90Ozxm b250IGNvbG9yPSIjMDAwMDAwIiBjbGFzcz0iIj5tZWNoYW5pc20gYnkgd2hpY2ggYW4gSW9UIGRl dmljZSBtYWtlcyBhbiBlbWVyZ2VuY3kgY2FsbOKAnS4gV2hpbGUgeW91IGV4cGxpY2l0bHkgY2Fs bCBvdXQNCiBzZW5zb3JzIChyZWFkOiBjb25zdHJhaW5lZCBkZXZpY2VzKSBJIGRvbuKAmXQgYmVs aWV2ZSB5b3UgZXhwbGljaXRseSZuYnNwOzxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApOyIgY2xhc3M9IiI+cmVzdHJpY3QgdGhlIG1lY2hhbmlzbSAmbmJzcDt0byB0aG9zZSBk ZXZpY2VzLiBJIGluZmVycmVkIHRoYXQgd291bGQgYmUgdGhlIHR5cGljYWwgdXNlIGNhc2UgYnV0 IEkgbW9yZSBnZW5lcmFsbHkgdG9vayBpdCBhcyAqYW55KiBkZXZpY2UmbmJzcDs8L3NwYW4+PC9m b250PnRoYXQNCiBuZWVkcyB0byBpbml0aWF0ZSBhIHJlcXVlc3QgZm9yIGVtZXJnZW5jeSBzZXJ2 aWNlcyB3aGVyZSBubyBpbnRlcmFjdGl2ZSBtZWRpYSBjaGFubmVsIHdpbGwgYmUgZXN0YWJsaXNo ZWQgd291bGQgdXNlIHRoZSBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LiBJ IGFzc3VtZWQgdGhpcyBzY29wZSB0byBiZSBhcHByb3ByaWF0ZSBidXQgaWYgeW91IHRoaW5rIHlv dSBuZWVkIHRvIG5hcnJvdyBpdCBmdXJ0aGVyIHRvIGV4Y2x1c2l2ZWx5DQogY29uc3RyYWluZWQg ZGV2aWNlcyB0aGVuIHBlcmhhcHMgeW91IGNhbiBhZGQgYSBibHVyYiBhYm91dCB0aGF0LiBIb3Bl IHRoaXMgaGVscHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q2hlZXJz LDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+R29uemFsbzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXIgMiwgMjAyMCwgYXQgNDoxOCBQTSwgQnJp YW4gUm9zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpickBicmlhbnJvc2VuLm5ldCIgY2xhc3M9IiI+ YnJAYnJpYW5yb3Nlbi5uZXQ8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5UaGFu a3MgZm9yIHRoZSByZXZpZXcuICZuYnNwO0kgd2lsbCBmaXggdGhlIG5pdHMuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KWW91IGRpZCB1bmRlcnN0YW5kIHRoYXQgdGhpcyBpcyB0aGUgbWVj aGFuaXNtIGJ5IHdoaWNoIGFuIElvVCBkZXZpY2UgbWFrZXMgYW4gZW1lcmdlbmN5IGNhbGwgd2hl biB0aGUgZGV2aWNlIGRvZXNu4oCZdCBoYXZlIHR3byB3YXkgaW50ZXJhY3RpdmUgbWVkaWEsIHJp Z2h0PzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJyaWFuPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gTWFyIDIsIDIw MjAsIGF0IDI6NDggUE0sIEdvbnphbG8gU2FsZ3VlaXJvIHZpYSBEYXRhdHJhY2tlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmciIGNsYXNzPSIiPm5vcmVwbHlAaWV0Zi5vcmc8 L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSZXZpZXdlcjogR29u emFsbyBTYWxndWVpcm88YnIgY2xhc3M9IiI+DQpSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIE5p dHM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpEb2N1bWVudDogZHJhZnQtaWV0Zi1lY3Jp dC1kYXRhLW9ubHktZWEtMjE8YnIgY2xhc3M9IiI+DQpSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRo IE5pdHM8YnIgY2xhc3M9IiI+DQpSZXZpZXcgdHlwZTogaW90ZGlyIC0gTGFzdCBDYWxsIHJldmll dzxiciBjbGFzcz0iIj4NClJlcXVlc3RlZCB2ZXJzaW9uIGZvciByZXZpZXc6IEN1cnJlbnQ8YnIg Y2xhc3M9IiI+DQpSZXZpZXcgRGF0ZTogMjAyMC0wMy0wMjxiciBjbGFzcz0iIj4NClJldmlld2Vy OiBHb256YWxvIFNhbGd1ZWlybzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgYW0gdGhl IGFzc2lnbmVkIElvVCBkaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgJmx0O2RyYWZ0LWlldGYtZWNy aXQtZGF0YS1vbmx5LWVhJmd0Oy48YnIgY2xhc3M9IiI+DQpUaGVzZSBjb21tZW50cyB3ZXJlIHdy aXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgSW50ZXJuZXQgQXJlYTxiciBj bGFzcz0iIj4NCkRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgc2hlcGhlcmQocykgc2hv dWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3Q8YnIgY2xhc3M9IiI+DQpsaWtlIHRoZXkgd291 bGQgdHJlYXQgY29tbWVudHMgZnJvbSBhbnkgb3RoZXIgSUVURiBjb250cmlidXRvcnMgYW5kIHJl c29sdmU8YnIgY2xhc3M9IiI+DQp0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIExhc3QgQ2FsbCBj b21tZW50cyB0aGF0IGhhdmUgYmVlbiByZWNlaXZlZC4gRm9yIG1vcmU8YnIgY2xhc3M9IiI+DQpk ZXRhaWxzIG9uIHRoZSBJb1QgRGlyZWN0b3JhdGUsIHNlZTxiciBjbGFzcz0iIj4NCjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZ3JvdXAvaW90ZGlyL2Fib3V0LyIgY2xhc3M9 IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ncm91cC9pb3RkaXIvYWJvdXQvPC9hPjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzICgxKSBo b3cgbWV0aG9kIG9mIGluY2x1ZGluZyBhIENBUCBtZXNzYWdlIGluIGEgU0lQPGJyIGNsYXNzPSIi Pg0KdHJhbnNhY3Rpb24gYnkgZGVmaW5pbmcgaXQgYXMgYSBibG9jayBvZiAmcXVvdDthZGRpdGlv bmFsIGRhdGEmcXVvdDsgYXMgd2VsbCBhcyAoMik8YnIgY2xhc3M9IiI+DQpkZXNjcmliZXMgaG93 IGEgU0lQIE1FU1NBR0UgdHJhbnNhY3Rpb24gY2FuIGJlIHVzZWQgdG8gc2VuZCBhIG5vbi1pbnRl cmFjdGl2ZTxiciBjbGFzcz0iIj4NCmNhbGwuIEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50 IGZyb20gdGhlIElvVCBwZXJzcGVjdGl2ZSBhbmQgdGhlIGRvY3VtZW50PGJyIGNsYXNzPSIiPg0K YXBwZWFycyB0byBiZSBpbmZvcm1hdGl2ZSwgY2xlYXIgYW5kIHdpdGhvdXQgb2J2aW91cyB0ZWNo bmljYWwgZ2Fwcy4gVGhlcmUgYXJlPGJyIGNsYXNzPSIiPg0KanVzdCBhIGZldyB0aGUgYXV0aG9y cyBtaWdodCBjb25zaWRlciBhZGRyZXNzaW5nLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N Ck5pdHM6PGJyIGNsYXNzPSIiPg0KPT09PTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClM6 IEFic3RyYWN0PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJnF1b3Q7dHlwZSBvZiBpbnRl cmFjdGlvbnMmcXVvdDsgLSZndDsgJnF1b3Q7dHlwZXMgb2YgaW50ZXJhY3Rpb25zJnF1b3Q7PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUzoxPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KJnF1b3Q7YWxlcnQgc3BlY2lmaWMmcXVvdDsgLSZndDsgJnF1b3Q7YWxlcnQtc3BlY2lmaWMm cXVvdDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTOjk8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQomcXVvdDtMb2NhdGlvbiBzcGVjaWZpYyZxdW90OyAtJmd0OyAmcXVvdDtMb2Nh dGlvbi1zcGVjaWZpYyZxdW90OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClM6OTxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZxdW90O05vdGUgdGhhdCBub25lIG9mIHRoZSBzZWN1 cml0eSBtZWNoYW5pc20gaW4gdGhpcyBkb2N1bWVudCZxdW90OyAtJmd0OyAmcXVvdDtOb3RlIHRo YXQgbm9uZTxiciBjbGFzcz0iIj4NCm9mIHRoZSBzZWN1cml0eSBtZWNoYW5pc21zIGluIHRoaXMg ZG9jdW1lbnQmcXVvdDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQotLSA8YnIgY2xh c3M9IiI+DQpsYXN0LWNhbGwgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFp bHRvOmxhc3QtY2FsbEBpZXRmLm9yZyIgY2xhc3M9IiI+bGFzdC1jYWxsQGlldGYub3JnPC9hPjxi ciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGFzdC1j YWxsPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0A4C322AA0EB467EB225B9EBA61FB7EDciscocom_-- From nobody Mon Mar 2 13:52:57 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56AE3A0897 for ; Mon, 2 Mar 2020 13:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 FvILJy_F3x4l for ; Mon, 2 Mar 2020 13:52:52 -0800 (PST) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D663A0880 for ; Mon, 2 Mar 2020 13:52:52 -0800 (PST) Received: by mail-yw1-xc2c.google.com with SMTP id 10so1378593ywv.5 for ; Mon, 02 Mar 2020 13:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iC4XMJZLopPzLS6mSLnmstT/Qlw+dxw/N43bQ+tfeHs=; b=oKZmdcM2N6rFkf7M2wcLLUK5XUHlwREE699AbF4Ic8femkaXkeyJvZvRB1V8ILCwTp SD7spSu6pKjlwJbuwI0xyOeSyARDtmXaQelb4Nw8etNSVwnRxXBs4blGRAL7X4x+DRgK JTns2i66nBVULeQMmSofINz9o1goIJ6RNbJZPdtckEigRbkeUAUuVxWYvqMBgwA3rgHr 5yA7ZwL18up2G91ST6CpP2/do3K6h5HNg//c6JpPwwXCtbxz5tVCzYLyKIs1Bd3dMPPJ ph2rYA8XIcSOA0QsBKDLDan0HxsO4bmGPMew0JqAgxRH6Il9+XMd2FO3j7Ymqg2HAChK eAmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iC4XMJZLopPzLS6mSLnmstT/Qlw+dxw/N43bQ+tfeHs=; b=umfJSZKObfL56PrUR+/Sv1JgL1XRHt4hEVyWZlwcfajxUOayDahK/gcx0676gD/JrH 7rFtIKhIw7ORBg+SqRaqDpKR4NNVv53BF3ObFRS1jQ+PSbCM/qEDys2gSG/GTOfXaMjQ YPTiIQmD8I3KuQL5881jA/TxbEy3Q19ABdnoHawpOXHQyqtjFVyviMbAuUUoJGebSs0Z PZ8TUK5DtqCC8XHxKqbnjqk5jOtvqOpvRSxvjemtMXxd/FkQuwz02Y5D2C+6g87mJqjn LWb5vgTG3MvkfeOG0xOAoHf6ALP9LVScHZau4hJzoFg/zebuyA2woVozKKJetg9pnf3R lIdw== X-Gm-Message-State: ANhLgQ0Y5dxGeRCx14kn05w6uoDgcoK4QLVOt2dCQkE5KghTu1r6lCcW Id9rxX/xZ1rCAj2EDKge90m9UA== X-Google-Smtp-Source: ADFU+vsp0thkyYFn9kzNL8AD3LNq0rWmjp0JbmjIi9FVGXvVMu0P8jw/h7OuJRA+G4p+ewhz8/hqAg== X-Received: by 2002:a25:a246:: with SMTP id b64mr1107499ybi.38.1583185971186; Mon, 02 Mar 2020 13:52:51 -0800 (PST) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id s38sm2127365ywa.14.2020.03.02.13.52.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2020 13:52:50 -0800 (PST) From: Brian Rosen Message-Id: <168876F3-9B51-4088-BD9B-BFFA00E4F07E@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_81D35F25-4B56-40B3-9AC7-A823C05D4CC2" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Mon, 2 Mar 2020 16:52:49 -0500 In-Reply-To: <0A4C322A-A0EB-467E-B225-B9EBA61FB7ED@cisco.com> Cc: "iot-directorate@ietf.org" , "draft-ietf-ecrit-data-only-ea.all@ietf.org" , "ecrit@ietf.org" , "last-call@ietf.org" To: "Gonzalo Salgueiro (gsalguei)" References: <158317853107.27458.1826052910979859321@ietfa.amsl.com> <0A4C322A-A0EB-467E-B225-B9EBA61FB7ED@cisco.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Ecrit] [Last-Call] Iotdir telechat review of draft-ietf-ecrit-data-only-ea-21 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 21:52:55 -0000 --Apple-Mail=_81D35F25-4B56-40B3-9AC7-A823C05D4CC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You interpreted it correctly: any device that doesn=E2=80=99t have two = way interactive media. Brian > On Mar 2, 2020, at 4:51 PM, Gonzalo Salgueiro (gsalguei) = wrote: >=20 > Hi Brian -=20 >=20 > Yes, the scope seemed clear to me. One thing I would qualify is that I = interpreted the scope to be slightly broader than a "mechanism by which = an IoT device makes an emergency call=E2=80=9D. While you explicitly = call out sensors (read: constrained devices) I don=E2=80=99t believe you = explicitly restrict the mechanism to those devices. I inferred that = would be the typical use case but I more generally took it as *any* = device that needs to initiate a request for emergency services where no = interactive media channel will be established would use the mechanisms = described in this document. I assumed this scope to be appropriate but = if you think you need to narrow it further to exclusively constrained = devices then perhaps you can add a blurb about that. Hope this helps. >=20 >=20 > Cheers, >=20 > Gonzalo >=20 >=20 >> On Mar 2, 2020, at 4:18 PM, Brian Rosen > wrote: >>=20 >> Thanks for the review. I will fix the nits. >>=20 >> You did understand that this is the mechanism by which an IoT device = makes an emergency call when the device doesn=E2=80=99t have two way = interactive media, right? >>=20 >> Brian >>=20 >>> On Mar 2, 2020, at 2:48 PM, Gonzalo Salgueiro via Datatracker = > wrote: >>>=20 >>> Reviewer: Gonzalo Salgueiro >>> Review result: Ready with Nits >>>=20 >>> Document: draft-ietf-ecrit-data-only-ea-21 >>> Review result: Ready with Nits >>> Review type: iotdir - Last Call review >>> Requested version for review: Current >>> Review Date: 2020-03-02 >>> Reviewer: Gonzalo Salgueiro >>>=20 >>> I am the assigned IoT directorate reviewer for = . >>> These comments were written primarily for the benefit of the = Internet Area >>> Directors. Document editors and shepherd(s) should treat these = comments just >>> like they would treat comments from any other IETF contributors and = resolve >>> them along with any other Last Call comments that have been = received. For more >>> details on the IoT Directorate, see >>> https://datatracker.ietf.org/group/iotdir/about/ = >>>=20 >>> This document describes (1) how method of including a CAP message in = a SIP >>> transaction by defining it as a block of "additional data" as well = as (2) >>> describes how a SIP MESSAGE transaction can be used to send a = non-interactive >>> call. I have reviewed this document from the IoT perspective and the = document >>> appears to be informative, clear and without obvious technical gaps. = There are >>> just a few the authors might consider addressing. >>>=20 >>> Nits: >>> =3D=3D=3D=3D >>>=20 >>> S: Abstract >>>=20 >>> "type of interactions" -> "types of interactions" >>>=20 >>> S:1 >>>=20 >>> "alert specific" -> "alert-specific" >>>=20 >>> S:9 >>>=20 >>> "Location specific" -> "Location-specific" >>>=20 >>> S:9 >>>=20 >>> "Note that none of the security mechanism in this document" -> "Note = that none >>> of the security mechanisms in this document" >>>=20 >>>=20 >>>=20 >>=20 >> --=20 >> last-call mailing list >> last-call@ietf.org >> https://www.ietf.org/mailman/listinfo/last-call >=20 --Apple-Mail=_81D35F25-4B56-40B3-9AC7-A823C05D4CC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You = interpreted it correctly: any device that doesn=E2=80=99t have two way = interactive media.

Brian

On Mar 2, 2020, at 4:51 PM, = Gonzalo Salgueiro (gsalguei) <gsalguei@cisco.com> wrote:

Hi Brian - 

Yes, the scope seemed clear to me. One thing I would = qualify is that I interpreted the scope to be slightly broader than a = "mechanism by which an IoT device makes an emergency = call=E2=80=9D. While you explicitly call out sensors (read: constrained devices) I don=E2=80=99t believe you = explicitly restrict the mechanism  to those devices. I inferred = that would be the typical use case but I more generally took it as *any* = device that needs to initiate a request for emergency services where no interactive = media channel will be established would use the mechanisms described in = this document. I assumed this scope to be appropriate but if you think = you need to narrow it further to exclusively constrained devices then perhaps you can add a blurb about that. Hope = this helps.


Cheers,

Gonzalo


On Mar 2, 2020, at 4:18 PM, Brian Rosen <br@brianrosen.net> = wrote:

Thanks for the review.  I will fix the nits.

You did understand that this is the mechanism by which an IoT device = makes an emergency call when the device doesn=E2=80=99t have two way = interactive media, right?

Brian

On Mar 2, 2020, at 2:48 PM, Gonzalo = Salgueiro via Datatracker <noreply@ietf.org> wrote:

Reviewer: Gonzalo Salgueiro
Review result: Ready with Nits

Document: draft-ietf-ecrit-data-only-ea-21
Review result: Ready with Nits
Review type: iotdir - Last Call review
Requested version for review: Current
Review Date: 2020-03-02
Reviewer: Gonzalo Salgueiro

I am the assigned IoT directorate reviewer for = <draft-ietf-ecrit-data-only-ea>.
These comments were written primarily for the benefit of the Internet = Area
Directors. Document editors and shepherd(s) should treat these comments = just
like they would treat comments from any other IETF contributors and = resolve
them along with any other Last Call comments that have been received. = For more
details on the IoT Directorate, see
https://datatracker.ietf.org/group/iotdir/about/

This document describes (1) how method of including a CAP message in a = SIP
transaction by defining it as a block of "additional data" as well as = (2)
describes how a SIP MESSAGE transaction can be used to send a = non-interactive
call. I have reviewed this document from the IoT perspective and the = document
appears to be informative, clear and without obvious technical gaps. = There are
just a few the authors might consider addressing.

Nits:
=3D=3D=3D=3D

S: Abstract

"type of interactions" -> "types of interactions"

S:1

"alert specific" -> "alert-specific"

S:9

"Location specific" -> "Location-specific"

S:9

"Note that none of the security mechanism in this document" -> "Note = that none
of the security mechanisms in this document"




--
last-call mailing list
last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call


= --Apple-Mail=_81D35F25-4B56-40B3-9AC7-A823C05D4CC2-- From nobody Mon Mar 2 14:24:28 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7370A3A097F for ; Mon, 2 Mar 2020 14:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 RCWnYegFOZJj for ; Mon, 2 Mar 2020 14:24:16 -0800 (PST) Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A576B3A12F2 for ; Mon, 2 Mar 2020 14:24:15 -0800 (PST) Received: by mail-yw1-xc2d.google.com with SMTP id y62so1403506ywd.13 for ; Mon, 02 Mar 2020 14:24:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ToUKNo8rywA/VY1UgyWFz0vA27cCH+3zL8JSLDyta+4=; b=kguiLkBW8tGArQgrta9NjQBZOVOQzvYJP+tgwyjIV6y7Uw5NjX29HP+vU+YmX3amd6 O/ws9fd+k5r+2D5lXI6JFGvfr6QN38RTLQQj37v7f8+pD9DJSjkh6QXxXXp0y2Oe+mBM yq7gdYmdiCxuqHYxkKFPETfDM38QDqqHGxRTzz+ZUJz6jr/8mkbWjQf9csyNdBIde7Hq pbHzlq/48meTRkUNkTyVbR27QKKkjLcWoekcaVtUEyuDiSq/9hLTuCLxhvPC80JJ7mt/ y0e8OZKWGPG1ARh4/e0evBWT1hJeqb8Qly2lK5GNtMZ9tla5d6bnU/sQ6Y1b4haLKoib ZCKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ToUKNo8rywA/VY1UgyWFz0vA27cCH+3zL8JSLDyta+4=; b=bm92QzOv0KJ/dPNd5KdWegwbUmG05VKvoh67TpEiwBGP/LnZzwgxgcnAtzCoFtOJAY wrmlKwAZkgKI7M6rqPWXN9e6kgLxAoOLeZKErMPnsy5gIkQ2A0qTo1hrCRFgxgdokFTT VZD3RYorn7fdSX0NIAIuc10yUJA85tvvsMKJ5B4y5ta1HGYgWLY4tIqDasU8l9/wOuJO 4WS671DroUEdN72+Ku8fdpQBJcX19GbXH0EmNm50ryybeQq2wrpYybdM2ZsybdhcJHK8 xSPBxFKC9sPJZt71s053M7D6Q0OuNJvrvWBUmvs08dx9cqOAZMeatYzwuIjtIcMtXy4S 65ag== X-Gm-Message-State: ANhLgQ2YTplIxXUQLzkHIes6V3jmCPg1I13ZjvmaBcbAqUfL+vuWwAyw 49p7vs65GCa46gErPFmuc4ArdA== X-Google-Smtp-Source: ADFU+vtzRhz+gNzRa2FMOk5kbzq0q3S99W8AVTYmNiDPJVp/pVyanoYCSTczX5rymJiL2C53SQFgmw== X-Received: by 2002:a25:2c49:: with SMTP id s70mr1218355ybs.359.1583187854709; Mon, 02 Mar 2020 14:24:14 -0800 (PST) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id w15sm8852663ywg.1.2020.03.02.14.24.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2020 14:24:13 -0800 (PST) From: Brian Rosen Message-Id: <4C966190-8F2F-42EB-BD24-60D90C86F2EA@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_6A29F059-C9D7-4253-B850-0212B91E00AA" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Mon, 2 Mar 2020 17:24:12 -0500 In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0216F60CEA@marchand> Cc: Adam Roach , The IESG , Allison Mankin , "ecrit-chairs@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-data-only-ea@ietf.org" To: Roman Danyliw References: <158318494177.27467.10769075669362560529@ietfa.amsl.com> <227ba0d7-8ace-2ad2-c28c-e74996210c4e@nostrum.com> <359EC4B99E040048A7131E0F4E113AFC0216F60CEA@marchand> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Ecrit] Roman Danyliw's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 22:24:19 -0000 --Apple-Mail=_6A29F059-C9D7-4253-B850-0212B91E00AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ll add Adam=E2=80=99s suggested language. WRT the first issue: URIs to untrusted entities, I note that there is no = discussion of untrusted entities in Section 7 of RFC 3986. There is = discussion of misleading URIs. If I added text to the security section = that read: When the CAP message is passed by reference, the recipients of the = MESSAGE may not have a trust relationship with the sender. Recipients = MUST take precautions in retrieving the CAP message because the URI may = point to a malicious actor. =20 Would that satisfy your concerns? I will also fix the nits. > On Mar 2, 2020, at 4:51 PM, Roman Danyliw wrote: >=20 > Hi Adam! >=20 >> -----Original Message----- >> From: Adam Roach > >> Sent: Monday, March 02, 2020 4:45 PM >> To: Roman Danyliw >; The IESG = > >> Cc: allison.mankin@gmail.com ; = ecrit-chairs@ietf.org ; ecrit@ietf.org = ; draft- >> ietf-ecrit-data-only-ea@ietf.org = >> Subject: Re: Roman Danyliw's Discuss on = draft-ietf-ecrit-data-only-ea-21: >> (with DISCUSS and COMMENT) >>=20 >> On 3/2/2020 3:35 PM, Roman Danyliw via Datatracker wrote: >>> Section 9. Per =E2=80=9CTo provide protection of the entire SIP = message >>> exchange between neighboring SIP entities, the usage of TLS is >>> REQUIRED.=E2=80=9D, can you please provide guidance on how to use = TLS. >>=20 >>=20 >> I think the strong implication here is that TLS is to be used in the = same way >> that TLS is used in other SIP applications (in the same way that an = HTTP >> document saying "MUST use TLS" is pretty clearly saying to use HTTPS = as per >> the existing HTTP RFCs). >>=20 >> Unfortunately, the TLS handling for SIP is mixed into RFC 3261 all = _over_ the >> place, so there's not anything particularly comprehensive to point = to. The >> best that I think could be said would be something along the lines of = "...the >> usage of TLS, as described in section 26 of [RFC3261], is REQUIRED." >>=20 >> Would that satisfy your concern? >=20 > I can appreciate this difficulty. Sounds good to me.=20 >=20 > Roman --Apple-Mail=_6A29F059-C9D7-4253-B850-0212B91E00AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99ll add Adam=E2=80=99s suggested language.

WRT the first issue: = URIs to untrusted entities, I note that there is no discussion of = untrusted entities in Section 7 of RFC 3986.  There is discussion = of misleading URIs.  If I added text to the security section that = read:

When the CAP message is passed by reference, the recipients = of the MESSAGE may not have a trust relationship with the sender. =  Recipients MUST take precautions in retrieving the CAP message = because the URI may point to a malicious actor.  

Would that satisfy your = concerns?

I = will also fix the nits.

On Mar = 2, 2020, at 4:51 PM, Roman Danyliw <rdd@cert.org> wrote:

Hi Adam!

-----Original Message-----
From: Adam Roach = <adam@nostrum.com>
Sent: Monday, March = 02, 2020 4:45 PM
To: Roman Danyliw <rdd@cert.org>; The IESG = <iesg@ietf.org>
Cc: allison.mankin@gmail.com; ecrit-chairs@ietf.org; ecrit@ietf.org; draft-
ietf-ecrit-data-only-ea@ietf.org
Subject: = Re: Roman Danyliw's Discuss on draft-ietf-ecrit-data-only-ea-21:
(with DISCUSS and COMMENT)

On = 3/2/2020 3:35 PM, Roman Danyliw via Datatracker wrote:
Section 9.  Per = =E2=80=9CTo provide protection of the entire SIP message
exchange between neighboring SIP entities, the usage of TLS = is
REQUIRED.=E2=80=9D, can you please provide guidance on = how to use TLS.


I= think the strong implication here is that TLS is to be used in the same = way
that TLS is used in other SIP applications (in the = same way that an HTTP
document saying "MUST use TLS" is = pretty clearly saying to use HTTPS as per
the existing = HTTP RFCs).

Unfortunately, the TLS handling = for SIP is mixed into RFC 3261 all _over_ the
place, so = there's not anything particularly comprehensive to point to. The
best that I think could be said would be something along the = lines of "...the
usage of TLS, as described in section 26 = of [RFC3261], is REQUIRED."

Would that = satisfy your concern?

I can appreciate this difficulty.  Sounds good to = me. 

Roman

= --Apple-Mail=_6A29F059-C9D7-4253-B850-0212B91E00AA-- From nobody Mon Mar 2 17:16:56 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 453293A155A; Mon, 2 Mar 2020 17:16:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, allison.mankin@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158319820318.27328.12390339422433838277@ietfa.amsl.com> Date: Mon, 02 Mar 2020 17:16:43 -0800 Archived-At: Subject: [Ecrit] Benjamin Kaduk's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2020 01:16:44 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-ecrit-data-only-ea-21: Discuss 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-ecrit-data-only-ea/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Roman's Discuss (and comment) and will expound on his first point some more. The use of URIs to refer to remote content, potentially hosted on a third party, has numerous security considerations, some better known than others. We need to reference the security considerations of RFC 3986 to get some coverage of these, such as the "reliability and consistency" point. One of the more subtle security considerations of using a URI to a remote resource as part of a request in cases such as this, is that the binding between the identity of the entity referring to the remote URI and the identity of the site providing the corresponding resource (i.e., the authority compoent of the URI) is not always clear. Although RFC 7852 requires TLS mutual authentication and HTTPS transport for information provided by reference, it makes no statement requiring the TLS server certificate to correspond to the SIP initiator, or any other indication of authorization that the indicated resource makes sense as part of the indicated request. I also have two other Discuss-level points: We discuss the use of timestamps in protocol elements for detecting replay; this requires that all participants have (secure and) accurate time. We need to document this dependency on accurate time, and optionally point out that common internet time protocols such as NTP are not particularly secure at present. I'm also not sure where there's existing treatment of using SIP MESSAGEs as a DoS attack vector; that seems particularly pronounced in the emergency-services case since emergency messages may receive preferential treatment from the network. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Introduction (and Abstract?) medical monitors. These messages may be one-shot alerts to emergency authorities and do not require establishment of a session. These type of interactions are called 'non-interactive emergency calls'. Is this an existing/widespread definition or one new to this document? It may be worth providing a reference or rewording to clarify that it is a new definition. Section 2 CID is Content InDirection [RFC2392] The string "InDirection" does not appear in RFC 2392. Section 4.1 A CAP message may be sent in the initial message of any SIP transaction. However, this document only addresses sending a CAP message in a SIP MESSAGE transaction for a one-shot, non-interactive emergency call. Behavior with other transactions is not defined. I suggest rephrasing to "A CAP message is sent in the initial message of a SIP transaction" to avoid potential concerns about inconsistency between "may be sent" and "not defined". the CAP message. Alternatively, the Call-Info header field may contain a Content Indirect url [RFC2392] and the CAP message included nit: "Indirect" here vs. "InDirection" in Section 2 Section 4.2 field. If there is a need to copy the PIDF-LO structure referenced by 'geolocation' to , implementers must be aware When might this occur? (It seems almost out of scope for this document based on my limited understanding.) that is limited to a circle or polygon, and conversion of other shapes will be required. Points SHOULD be converted to a circle with a radius equal to the uncertainty of the point. Arc- bands and ellipses SHOULD be converted to an equivalent polygon. 3D locations SHOULD be converted to their equivalent 2D forms. nit: what is an "equivalent" polygon to an ellipse or arc-band? In a mathematical sense it might mean "strict equivalence" or a large-n limit of an n-gon, or perhaps there is a corresponding uncertainty on the ellipse/arc-band that the polygon must stay within? Rewording to "corresponding" might be an easy fix. Section 5.1 The 425 response code is a rejection of the request due to its included alert content, indicating that it was malformed or not satisfactory for the recipient's purpose. A SIP intermediary can also reject an alert it receives from a User Agent (UA) when it detects that the provided alert is malformed. (I assume there's an implicit "reject with this code" in here.) It is only appropriate to generate a 425 response when the responding entity has no other information in the request that is usable by the responder. I'm not sure I'm parsing this sentence correctly. My best guess is that it's saying "if there's anything in the request that you can respond to, don't use 425, even if there's some malformed CAP", but that doesn't really seem to be what the actual words are saying. [Section 5.2 seems to support my guess.] Section 5.2 message-header /= AlertMsg-Error ; (message-header from 3261) nit: mybe "RFC3261" to match the later comments? wrong with the alert in the request. This error code has a pedantic nit: the ABNF has 1-to-3-digit standardized -- meaning an operator can change the strings -- but MUST NOT change the meaning of the error code. Similar to how RFC 3261 specifies, there MUST NOT be more than one string per error code. RFC 3261 is ... pretty long. Maybe throw us a bone with a section reference? Also, I assume this "MUST NOT be more than one" is within a single AlertMsg-Error construction, since a truly global interpretation would mean that (since this document assigns strings) there cannot actually be changes made to the strings by an operator, which we just said is possible. This document defines an initial list of AlertMsg-Error values for any SIP response, including provisional responses (other than 100 Trying) and the new 425 response. There MUST be no more than one AlertMsg-Error code in a SIP response. AlertMsg-Error values sent in Is this redundant with the "MUST NOT" I was asking about above? Additionally, if an entity cannot or chooses not to process the alert message from a SIP request, a 500 (Server Internal Error) SHOULD be used with or without a configurable Retry-After header field. I don't think I understand when it's recommended to use 500 vs 425 (and vice versa). Section 7 It's probably worth mentioning RFC 3428's note about: % The size of MESSAGE requests outside of a media session MUST NOT % exceed 1300 bytes, unless the UAC has positive knowledge that the % message will not traverse a congestion-unsafe link at any hop, or % that the message size is at least 200 bytes less than the lowest MTU % value found en route to the UAS since that seems to still apply here. Section 8 I'd consider using a more recent date than 2008-11-19 for the example time. Also, why is the timestamp in the additional information 2010-11-14, almost two years later? 32.86726 -97.16054 Is that ... someone's house? Maybe some different coordinates would be more appropriate. Figure 3 has "Content-Disposition: by-reference;handling=optional" but Figure 4 does not; is that significant? Section 9 In any case, for alerts initiated by sensors, the identity could play an important role in deciding whether to accept or ignore an incoming alert message. With the scenario shown in Figure 1 it is very likely that only authenticated sensor input will be processed. For this reason, it needs to be possible to refuse to accept alert messages from an unknown origin. Two types of information elements can be used for this purpose: 1. SIP itself provides security mechanisms that allow the verification of the originator's identity, such as P-Asserted- Identity [RFC3325] or SIP Identity [RFC8224]. The latter provides a cryptographic assurance while the former relies on a chain of trust model. These mechanisms can be reused. 2. CAP provides additional security mechanisms and the ability to carry further information about the sender's identity. Section 3.3.4.1 of [cap] specifies the signing algorithms of CAP documents. I'd consider adding a note that "the specific policy and mechanisms used in a given deployment are out of scope for this document", since the actual requirements in practice are so broad that we cannot really make detailed recommendations here. In addition to the desire to perform identity-based access control, the classic communication security threats need to be considered, including integrity protection to prevent forgery or replay of alert messages in transit. To deal with replay of alerts, a CAP document contains the mandatory , , elements and an optional element. Together, these elements make the CAP document unique for a specific sender and provide time restrictions. An entity that has already received a CAP message within the indicated timeframe is able to detect a replayed message and, if the content of that message is unchanged, then no additional security Is *able* to detect, sure. But is it recommended to do so? Required? vulnerability is created. Additionally, it is RECOMMENDED to make use of SIP security mechanisms, such as the SIP Identity PASSporT [RFC8225], to tie the CAP message to the SIP message. To provide Not required? Please describe the risks of not doing so (whether directly or by reference). protection of the entire SIP message exchange between neighboring SIP entities, the usage of TLS is REQUIRED. Just to check: this is a 100% always, for everyone, "REQUIRED", not just in the subset of cases where protection of the entire exchange is desired? Note that none of the security mechanism in this document protect against a compromised sensor sending crafted alerts. Privacy provided for any emergency calls, including non-interactive messages, is subject to local regulations. I suggest using "confidentiality protection" rather than "privacy" (unless it's a term of art in this field), to avoid confusion with... Privacy considerations for alerts (e.g., generated by sensors) that should be discussed. RFC 7852 has some extensive privacy considerations that can be referenced to do the bulk of the work here. I'd also consider reiterating the opportunistic nature of cryptographic protection on emergency messages, as discussed in 6443 (since insecure emergency messaging is preferred to no emergency messaging), but this is not strictly speaking required. Section 12.2 RFC 8225, as a RECOMMENDED feature, is more properly listed as a normative reference, per https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ From nobody Tue Mar 3 06:58:11 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C12A33A21EE; Tue, 3 Mar 2020 06:58:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov via Datatracker To: "The IESG" Cc: draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, allison.mankin@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alexey Melnikov Message-ID: <158324748449.7657.12581369226723862050@ietfa.amsl.com> Date: Tue, 03 Mar 2020 06:58:04 -0800 Archived-At: Subject: [Ecrit] Alexey Melnikov's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2020 14:58:05 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-ecrit-data-only-ea-21: Discuss 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-ecrit-data-only-ea/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a tiny point, but I think it needs fixing for clarity: 5.2. The AlertMsg-Error Header Field error-code = 1*3DIGIT The text below makes it clear that the error-code is 3 digits: The ErrorValue contains a 3-digit error code indicating what was wrong with the alert in the request. What you have above allows for 1, 2 or 3 digits. I think you meant: error-code = 3DIGIT ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I initially thought that error-codes are from the same namespace as SIP Status Codes. I think you should explicitly say that they are not. The first mention of HTTPS needs a normative reference. In Section 10.1: Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See [RFC7303], Section 3.2. This field of the form should say one of "7bit", "8bit", "binary" or "framed". I think in your case it is "binary", because UTF-16 charsets are not prohibited in your document. From nobody Tue Mar 3 07:27:58 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017A83A0E58 for ; Tue, 3 Mar 2020 07:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 9ZbXh7nqg6Ha for ; Tue, 3 Mar 2020 07:27:42 -0800 (PST) Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329B53A2267 for ; Tue, 3 Mar 2020 07:27:42 -0800 (PST) Received: by mail-yw1-xc2d.google.com with SMTP id d206so3622918ywa.12 for ; Tue, 03 Mar 2020 07:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8bcgB8PHDTURaEPa/NJXYeEQaK2V7LojaYFW4ROVRPw=; b=aIcAj0Jnp1I4QG9qorCyB+QWqr/r9ajL0KnICMT1GW3RDMLOIFnq3lp5+yxMl6Lvzg WVx7odWfHFJlvHKvaTAASSLHx0veejstlKyt5Rd0hxYuKJ1wZm7m005Pam9wcdtqy5Xr nSQ5wtq9O971OPKzGQBgb+a8VdkzCXLEqu9GjOCnSxS+uem9Vws6L7UUdyr3YPPLu01S iAbfIQY5w3qiv6DHEHHuMjiw4fT+SQcULM/DECIgtGOSWJcbC4JYXhHmK5jhycQoLM2M a1JrHaBBRV3DycyfNhDR6abdo+QiYXWwd7ClxA3iStM9fzkkPUQcQPruSVUBBkl02Kks ARjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8bcgB8PHDTURaEPa/NJXYeEQaK2V7LojaYFW4ROVRPw=; b=tB7WecZY3EMkEpEXUCxM5dxzaxRpyCzncmZ5EX8qPqHnbba0RA9vKoApF6CMZNRJSI dieyFDtRTgFjU3LDLBm6xA/GmYxSpyf6q1N5ZvYFAWXjQJ/skPbOA0VMHbFIq8idwcMD Lhnl/PicDfIsWOe7nYM+97NRdfJuJJUGayd1ZbUDy+MP1qt0UYD/sbDCxmMQYSDDRtbr UYE6eFTvVQz1wxOeDGzr4LCvaRbtzRIeWrP/bEoz3mbxMPMmFpNKID5vsDRXc6NwvpQU 1jIoG9ddLqH73+IeLhNguRq9JSKxpHIIeEqFyz9p019+/Ijs9RegCbvQhj8WuVMLFwZ+ PaBA== X-Gm-Message-State: ANhLgQ15SfXaNWeeWRSXnZyek1+hsA3gPECh6qP2ZSXtD+1asXZqnD2K M4mhD9dsDTCGP5qi9KHvbNSH9g== X-Google-Smtp-Source: ADFU+vvk7uRxYD+xk/lZ4grEe9Efwe/YdOqAG7562jVaIHFsoLFaHBJ2oSwDSaZcC9EMVqYFrd8pgg== X-Received: by 2002:a25:ace2:: with SMTP id x34mr4814976ybd.83.1583249261171; Tue, 03 Mar 2020 07:27:41 -0800 (PST) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id g70sm2025860ywh.53.2020.03.03.07.27.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Mar 2020 07:27:40 -0800 (PST) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6F8B71EA-BD80-4352-B9A8-15EADA99B2AC" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Tue, 3 Mar 2020 10:27:38 -0500 In-Reply-To: <158319820318.27328.12390339422433838277@ietfa.amsl.com> Cc: The IESG , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ECRIT , Allison Mankin , Roman Danyliw To: Benjamin Kaduk References: <158319820318.27328.12390339422433838277@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Ecrit] Benjamin Kaduk's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2020 15:27:46 -0000 --Apple-Mail=_6F8B71EA-BD80-4352-B9A8-15EADA99B2AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It will be very common for the entity sending the message to not be the = entity hosting the referenced document. For example, a device may send = the MESSAGE, but some service that the device=E2=80=99s mfg operates = hosts the CAP. So we make NO assumptions that there is any connection = between them. The same is true for the Additional Data from 7852.=20 Proposed text (revises the text I previously suggested to Roman) This document describes potential retrieval of information by = dereferencing URIs found in a Call Info header of a SIP MESSAGE. These = may include a CAP message as well as other Additional Data (RFC7852) = blocks. The domain of the device sending the SIP MESSAGE, the domain of = the server holding the CAP message, if sent by reference, and the domain = of other Additional Data blocks, if sent by reference, may all be = different. No assumptions can be made that there are trust = relationships between these entities. Recipients MUST take precautions = in retrieving any Additional Data blocks passed by reference, including = the CAP message, because the URI may point to a malicious actor. The = considerations in handling URIs in RFC3986 apply. =20 With respect to your DISCUSS on timestamps. Can I add: Use of timestamps to prevent replay is subject to the availability of = accurate time at all participants. Because emergency event notification = via this mechanism is relatively low frequency and generally involves = human interaction, implementations may wish to consider messages with = times within small number of seconds of each other to be effectively = simultaneous for the purposes of detecting replay. Implementations may = also wish to consider that most deployed time distribution protocols = likely to be used by these systems are not presently secure. With regard to DoS, the only thing that makes this different from any = emergency call situation is that there is no two way media with a human, = and so you immediately assume a bot rather than a human, and therefore = probably more likely to be a DoS source. OTOH, there isn=E2=80=99t anything we can do with that information. If = I can generate large numbers of malicious SIP transactions, whether they = are INVITE or MESSAGE doesn=E2=80=99t matter. If I can compromise a = device, whether it=E2=80=99s a phone that generates INVITE or an IOT = device that generates MESSAGE, then I can misuse it. I=E2=80=99m at a = loss to know what to say. I can supply the advice that the emergency = authorities have always offered: automated devices have increased = probability to generate false positive emergency calls/messages. This = is a burden on the emergency services which has to respond to all = calls/messages. In some jurisdictions, there are legal restrictions on = automated emergency calls/messages, and in others, there are penalties = for repeated false positive calls/messages. I=E2=80=99ll work on the comments and reply if I have any issues as I = update in response to them.=20 Brian > On Mar 2, 2020, at 8:16 PM, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-ecrit-data-only-ea-21: Discuss >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I support Roman's Discuss (and comment) and will expound on his first > point some more. >=20 > The use of URIs to refer to remote content, potentially hosted on a > third party, has numerous security considerations, some better known > than others. We need to reference the security considerations of RFC > 3986 to get some coverage of these, such as the "reliability and > consistency" point. >=20 > One of the more subtle security considerations of using a URI to a > remote resource as part of a request in cases such as this, is that = the > binding between the identity of the entity referring to the remote URI > and the identity of the site providing the corresponding resource = (i.e., > the authority compoent of the URI) is not always clear. Although RFC > 7852 requires TLS mutual authentication and HTTPS transport for > information provided by reference, it makes no statement requiring the > TLS server certificate to correspond to the SIP initiator, or any = other > indication of authorization that the indicated resource makes sense as > part of the indicated request. >=20 > I also have two other Discuss-level points: >=20 > We discuss the use of timestamps in protocol elements for detecting > replay; this requires that all participants have (secure and) accurate > time. We need to document this dependency on accurate time, and > optionally point out that common internet time protocols such as NTP = are > not particularly secure at present. >=20 > I'm also not sure where there's existing treatment of using SIP = MESSAGEs > as a DoS attack vector; that seems particularly pronounced in the > emergency-services case since emergency messages may receive > preferential treatment from the network. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Introduction (and Abstract?) >=20 > medical monitors. These messages may be one-shot alerts to = emergency > authorities and do not require establishment of a session. These > type of interactions are called 'non-interactive emergency calls'. >=20 > Is this an existing/widespread definition or one new to this document? > It may be worth providing a reference or rewording to clarify that it = is > a new definition. >=20 > Section 2 >=20 > CID is Content InDirection [RFC2392] >=20 > The string "InDirection" does not appear in RFC 2392. >=20 > Section 4.1 >=20 > A CAP message may be sent in the initial message of any SIP > transaction. However, this document only addresses sending a CAP > message in a SIP MESSAGE transaction for a one-shot, non-interactive > emergency call. Behavior with other transactions is not defined. >=20 > I suggest rephrasing to "A CAP message is sent in the initial message = of > a SIP transaction" to avoid potential concerns about inconsistency > between "may be sent" and "not defined". >=20 > the CAP message. Alternatively, the Call-Info header field may > contain a Content Indirect url [RFC2392] and the CAP message = included >=20 > nit: "Indirect" here vs. "InDirection" in Section 2 >=20 > Section 4.2 >=20 > field. If there is a need to copy the PIDF-LO structure > referenced by 'geolocation' to , implementers must be aware >=20 > When might this occur? (It seems almost out of scope for this = document > based on my limited understanding.) >=20 > that is limited to a circle or polygon, and conversion of > other shapes will be required. Points SHOULD be converted to a > circle with a radius equal to the uncertainty of the point. Arc- > bands and ellipses SHOULD be converted to an equivalent polygon. > 3D locations SHOULD be converted to their equivalent 2D forms. >=20 > nit: what is an "equivalent" polygon to an ellipse or arc-band? In a > mathematical sense it might mean "strict equivalence" or a large-n = limit > of an n-gon, or perhaps there is a corresponding uncertainty on the > ellipse/arc-band that the polygon must stay within? Rewording to > "corresponding" might be an easy fix. >=20 > Section 5.1 >=20 > The 425 response code is a rejection of the request due to its > included alert content, indicating that it was malformed or not > satisfactory for the recipient's purpose. >=20 > A SIP intermediary can also reject an alert it receives from a User > Agent (UA) when it detects that the provided alert is malformed. >=20 > (I assume there's an implicit "reject with this code" in here.) >=20 > It is only appropriate to generate a 425 response when the = responding > entity has no other information in the request that is usable by the > responder. >=20 > I'm not sure I'm parsing this sentence correctly. My best guess is = that > it's saying "if there's anything in the request that you can respond = to, > don't use 425, even if there's some malformed CAP", but that doesn't > really seem to be what the actual words are saying. [Section 5.2 = seems > to support my guess.] >=20 > Section 5.2 >=20 > message-header /=3D AlertMsg-Error > ; (message-header from 3261) >=20 > nit: mybe "RFC3261" to match the later comments? >=20 > wrong with the alert in the request. This error code has a >=20 > pedantic nit: the ABNF has 1-to-3-digit >=20 > standardized -- meaning an operator can change the strings -- but > MUST NOT change the meaning of the error code. Similar to how RFC > 3261 specifies, there MUST NOT be more than one string per error > code. >=20 > RFC 3261 is ... pretty long. Maybe throw us a bone with a section > reference? Also, I assume this "MUST NOT be more than one" is within = a > single AlertMsg-Error construction, since a truly global = interpretation > would mean that (since this document assigns strings) there cannot > actually be changes made to the strings by an operator, which we just > said is possible. >=20 > This document defines an initial list of AlertMsg-Error values for > any SIP response, including provisional responses (other than 100 > Trying) and the new 425 response. There MUST be no more than one > AlertMsg-Error code in a SIP response. AlertMsg-Error values sent = in >=20 > Is this redundant with the "MUST NOT" I was asking about above? >=20 > Additionally, if an entity cannot or chooses not to process the = alert > message from a SIP request, a 500 (Server Internal Error) SHOULD be > used with or without a configurable Retry-After header field. >=20 > I don't think I understand when it's recommended to use 500 vs 425 = (and > vice versa). >=20 > Section 7 >=20 > It's probably worth mentioning RFC 3428's note about: >=20 > % The size of MESSAGE requests outside of a media session MUST NOT > % exceed 1300 bytes, unless the UAC has positive knowledge that the > % message will not traverse a congestion-unsafe link at any hop, or > % that the message size is at least 200 bytes less than the lowest = MTU > % value found en route to the UAS >=20 > since that seems to still apply here. >=20 > Section 8 >=20 > I'd consider using a more recent date than 2008-11-19 for the example > time. Also, why is the timestamp in the additional information > 2010-11-14, almost two years later? >=20 > 32.86726 -97.16054 >=20 > Is that ... someone's house? Maybe some different coordinates would = be > more appropriate. >=20 > Figure 3 has "Content-Disposition: by-reference;handling=3Doptional" = but > Figure 4 does not; is that significant? >=20 > Section 9 >=20 > In any case, for alerts initiated by sensors, the identity could = play > an important role in deciding whether to accept or ignore an = incoming > alert message. With the scenario shown in Figure 1 it is very = likely > that only authenticated sensor input will be processed. For this > reason, it needs to be possible to refuse to accept alert messages > from an unknown origin. Two types of information elements can be > used for this purpose: >=20 > 1. SIP itself provides security mechanisms that allow the > verification of the originator's identity, such as P-Asserted- > Identity [RFC3325] or SIP Identity [RFC8224]. The latter > provides a cryptographic assurance while the former relies on a > chain of trust model. These mechanisms can be reused. >=20 > 2. CAP provides additional security mechanisms and the ability to > carry further information about the sender's identity. > Section 3.3.4.1 of [cap] specifies the signing algorithms of CAP > documents. >=20 > I'd consider adding a note that "the specific policy and mechanisms = used > in a given deployment are out of scope for this document", since the > actual requirements in practice are so broad that we cannot really = make > detailed recommendations here. >=20 > In addition to the desire to perform identity-based access control, > the classic communication security threats need to be considered, > including integrity protection to prevent forgery or replay of alert > messages in transit. To deal with replay of alerts, a CAP document > contains the mandatory , , elements and = an > optional element. Together, these elements make the CAP > document unique for a specific sender and provide time restrictions. > An entity that has already received a CAP message within the > indicated timeframe is able to detect a replayed message and, if the > content of that message is unchanged, then no additional security >=20 > Is *able* to detect, sure. But is it recommended to do so? Required? >=20 > vulnerability is created. Additionally, it is RECOMMENDED to make > use of SIP security mechanisms, such as the SIP Identity PASSporT > [RFC8225], to tie the CAP message to the SIP message. To provide >=20 > Not required? Please describe the risks of not doing so (whether > directly or by reference). >=20 > protection of the entire SIP message exchange between neighboring = SIP > entities, the usage of TLS is REQUIRED. >=20 > Just to check: this is a 100% always, for everyone, "REQUIRED", not = just > in the subset of cases where protection of the entire exchange is > desired? >=20 > Note that none of the security mechanism in this document protect > against a compromised sensor sending crafted alerts. Privacy > provided for any emergency calls, including non-interactive = messages, > is subject to local regulations. >=20 > I suggest using "confidentiality protection" rather than "privacy" > (unless it's a term of art in this field), to avoid confusion with... > Privacy considerations for alerts (e.g., generated by sensors) that > should be discussed. RFC 7852 has some extensive privacy = considerations > that can be referenced to do the bulk of the work here. >=20 > I'd also consider reiterating the opportunistic nature of = cryptographic > protection on emergency messages, as discussed in 6443 (since insecure > emergency messaging is preferred to no emergency messaging), but this = is > not strictly speaking required. >=20 > Section 12.2 >=20 > RFC 8225, as a RECOMMENDED feature, is more properly listed as a > normative reference, per > = https://www.ietf.org/about/groups/iesg/statements/normative-informative-re= ferences/ >=20 >=20 >=20 --Apple-Mail=_6F8B71EA-BD80-4352-B9A8-15EADA99B2AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It = will be very common for the entity sending the message to not be the = entity hosting the referenced document.  For example, a device may = send the MESSAGE, but some service that the device=E2=80=99s mfg = operates hosts the CAP.  So we make NO assumptions that there is = any connection between them.  The same is true for the Additional = Data from 7852. 

Proposed text (revises the text I previously suggested to = Roman)
This document describes = potential retrieval of information by dereferencing URIs found in a Call = Info header of a SIP MESSAGE.  These may include a CAP message as = well as other Additional Data (RFC7852) blocks.  The domain of the = device sending the SIP MESSAGE, the domain of the server holding the CAP = message, if sent by reference, and the domain of other Additional Data = blocks, if sent by reference, may all be different.  No assumptions = can be made that there are trust relationships between these entities. =  Recipients MUST take precautions in retrieving = any Additional Data blocks passed by reference, including the CAP = message, because the URI may point to a malicious actor. =  The considerations in handling URIs in RFC3986 apply. =  


With respect to your DISCUSS on = timestamps.  Can I add:
Use of = timestamps to prevent replay is subject to the availability of accurate = time at all participants.  Because emergency event notification via = this mechanism is relatively low frequency and generally involves human = interaction, implementations may wish to consider messages with times = within small number of seconds of each other to be effectively = simultaneous for the purposes of detecting replay.  Implementations = may also wish to consider that most deployed time distribution protocols = likely to be used by these systems are not presently = secure.

With= regard to DoS, the only thing that makes this different from any = emergency call situation is that there is no two way media with a human, = and so you immediately assume a bot rather than a human, and therefore = probably more likely to be a DoS source.

OTOH, there isn=E2=80=99t anything we = can do with that information.  If I can generate large numbers of = malicious SIP transactions, whether they are INVITE or MESSAGE doesn=E2=80= =99t matter.  If I can compromise a device, whether it=E2=80=99s a = phone that generates INVITE or an IOT device that generates MESSAGE, = then I can misuse it.  I=E2=80=99m at a loss to know what to say. =  I can supply the advice that the emergency authorities have always = offered: automated devices have increased probability to = generate false positive emergency calls/messages.  This is a burden = on the emergency services which has to respond to all calls/messages. =  In some jurisdictions, there are legal restrictions on automated = emergency calls/messages, and in others, there are penalties for = repeated false positive calls/messages.

I=E2=80=99ll work on the comments and = reply if I have any issues as I update in response to = them. 

Brian


On Mar 2, 2020, at 8:16 PM, Benjamin Kaduk via Datatracker = <noreply@ietf.org> wrote:

Benjamin Kaduk has entered the following ballot position = for
draft-ietf-ecrit-data-only-ea-21: Discuss

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.htmlfor 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-ecrit-data-only-ea/=



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

I support Roman's Discuss (and = comment) and will expound on his first
point some more.

The use of URIs to refer to remote content, = potentially hosted on a
third party, has numerous security = considerations, some better known
than others.  We = need to reference the security considerations of RFC
3986 = to get some coverage of these, such as the "reliability and
consistency" point.

One of the = more subtle security considerations of using a URI to a
remote resource as part of a request in cases such as this, = is that the
binding between the identity of the entity = referring to the remote URI
and the identity of the site = providing the corresponding resource (i.e.,
the authority = compoent of the URI) is not always clear.  Although RFC
7852 requires TLS mutual authentication and HTTPS transport = for
information provided by reference, it makes no = statement requiring the
TLS server certificate to = correspond to the SIP initiator, or any other
indication = of authorization that the indicated resource makes sense as
part of the indicated request.

I = also have two other Discuss-level points:

We = discuss the use of timestamps in protocol elements for detecting
replay; this requires that all participants have (secure and) = accurate
time.  We need to document this dependency = on accurate time, and
optionally point out that common = internet time protocols such as NTP are
not particularly = secure at present.

I'm also not sure where = there's existing treatment of using SIP MESSAGEs
as a DoS = attack vector; that seems particularly pronounced in the
emergency-services case since emergency messages may = receive
preferential treatment from the network.


---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Introduction (and Abstract?)

  medical monitors.  These = messages may be one-shot alerts to emergency
=   authorities and do not require establishment of a session. =  These
  type of interactions are called = 'non-interactive emergency calls'.

Is this = an existing/widespread definition or one new to this document?
It may be worth providing a reference or rewording to clarify = that it is
a new definition.

Section 2

  CID is = Content InDirection [RFC2392]

The string = "InDirection" does not appear in RFC 2392.

Section 4.1

  A CAP = message may be sent in the initial message of any SIP
=   transaction.  However, this document only addresses = sending a CAP
  message in a SIP MESSAGE = transaction for a one-shot, non-interactive
=   emergency call.  Behavior with other transactions is = not defined.

I suggest rephrasing to "A CAP = message is sent in the initial message of
a SIP = transaction" to avoid potential concerns about inconsistency
between "may be sent" and "not defined".

  the CAP message.  Alternatively, the = Call-Info header field may
  contain a Content = Indirect url [RFC2392] and the CAP message included

nit: "Indirect" here vs. "InDirection" in Section 2

Section 4.2

=      field.  If there is a need to copy = the PIDF-LO structure
=      referenced by 'geolocation' to = <area>, implementers must be aware

When= might this occur?  (It seems almost out of scope for this = document
based on my limited understanding.)

     that = <area> is limited to a circle or polygon, and conversion of
     other shapes will be required. =  Points SHOULD be converted to a
=      circle with a radius equal to the = uncertainty of the point.  Arc-
=      bands and ellipses SHOULD be converted to = an equivalent polygon.
     3D = locations SHOULD be converted to their equivalent 2D forms.

nit: what is an "equivalent" polygon to an = ellipse or arc-band?  In a
mathematical sense it = might mean "strict equivalence" or a large-n limit
of an = n-gon, or perhaps there is a corresponding uncertainty on the
ellipse/arc-band that the polygon must stay within? =  Rewording to
"corresponding" might be an easy = fix.

Section 5.1

  The 425 response code is a rejection of the = request due to its
  included alert content, = indicating that it was malformed or not
=   satisfactory for the recipient's purpose.

  A SIP intermediary can also reject an alert it = receives from a User
  Agent (UA) when it = detects that the provided alert is malformed.

(I assume there's an implicit "reject with this code" in = here.)

  It is only appropriate = to generate a 425 response when the responding
=   entity has no other information in the request that is = usable by the
  responder.

I'm not sure I'm parsing this sentence correctly.  My = best guess is that
it's saying "if there's anything in the = request that you can respond to,
don't use 425, even if = there's some malformed CAP", but that doesn't
really seem = to be what the actual words are saying.  [Section 5.2 seems
to support my guess.]

Section = 5.2

=      message-header   /=3D = AlertMsg-Error
=             &n= bsp;           &nbs= p;    ; (message-header from 3261)

nit: mybe "RFC3261" to match the later comments?

  wrong with the alert in the = request.  This error code has a

pedantic= nit: the ABNF has 1-to-3-digit

=   standardized -- meaning an operator can change the strings = -- but
  MUST NOT change the meaning of the = error code.  Similar to how RFC
  3261 = specifies, there MUST NOT be more than one string per error
=   code.

RFC 3261 is ... pretty = long.  Maybe throw us a bone with a section
reference? =  Also, I assume this "MUST NOT be more than one" is within a
single AlertMsg-Error construction, since a truly global = interpretation
would mean that (since this document = assigns strings) there cannot
actually be changes made to = the strings by an operator, which we just
said is = possible.

  This document = defines an initial list of AlertMsg-Error values for
=   any SIP response, including provisional responses (other = than 100
  Trying) and the new 425 response. =  There MUST be no more than one
=   AlertMsg-Error code in a SIP response.  AlertMsg-Error = values sent in

Is this redundant with the = "MUST NOT" I was asking about above?

=   Additionally, if an entity cannot or chooses not to process = the alert
  message from a SIP request, a 500 = (Server Internal Error) SHOULD be
  used with = or without a configurable Retry-After header field.

I don't think I understand when it's recommended to use 500 = vs 425 (and
vice versa).

Section 7

It's probably worth = mentioning RFC 3428's note about:

% =  The size of MESSAGE requests outside of a media session MUST = NOT
%  exceed 1300 bytes, unless the UAC has positive = knowledge that the
%  message will not traverse a = congestion-unsafe link at any hop, or
%  that the = message size is at least 200 bytes less than the lowest MTU
%  value found en route to the UAS

since that seems to still apply here.

Section 8

I'd consider using a = more recent date than 2008-11-19 for the example
<sent> time.  Also, why is the timestamp in the = additional information
2010-11-14, almost two years = later?

=             &n= bsp;       <gml:pos>32.86726 = -97.16054</gml:pos>

Is that ... = someone's house?  Maybe some different coordinates would be
more appropriate.

Figure 3 has = "Content-Disposition: by-reference;handling=3Doptional" but
Figure 4 does not; is that significant?

Section 9

  In any = case, for alerts initiated by sensors, the identity could play
  an important role in deciding whether to accept = or ignore an incoming
  alert message. =  With the scenario shown in Figure 1 it is very likely
=   that only authenticated sensor input will be processed. =  For this
  reason, it needs to be = possible to refuse to accept alert messages
=   from an unknown origin.  Two types of information = elements can be
  used for this purpose:

  1.  SIP itself provides = security mechanisms that allow the
=       verification of the originator's = identity, such as P-Asserted-
=       Identity [RFC3325] or SIP Identity = [RFC8224].  The latter
=       provides a cryptographic assurance = while the former relies on a
=       chain of trust model.  These = mechanisms can be reused.

  2. =  CAP provides additional security mechanisms and the ability to
      carry further = information about the sender's identity.
=       Section 3.3.4.1 of [cap] specifies = the signing algorithms of CAP
=       documents.

I'd consider adding a note that "the specific policy and = mechanisms used
in a given deployment are out of scope for = this document", since the
actual requirements in practice = are so broad that we cannot really make
detailed = recommendations here.

  In = addition to the desire to perform identity-based access control,
  the classic communication security threats need = to be considered,
  including integrity = protection to prevent forgery or replay of alert
=   messages in transit.  To deal with replay of alerts, a = CAP document
  contains the mandatory = <identifier>, <sender>, <sent> elements and an
  optional <expire> element.  Together, = these elements make the CAP
  document unique = for a specific sender and provide time restrictions.
=   An entity that has already received a CAP message within = the
  indicated timeframe is able to detect a = replayed message and, if the
  content of that = message is unchanged, then no additional security

Is *able* to detect, sure.  But is it recommended to do = so?  Required?

=   vulnerability is created.  Additionally, it is = RECOMMENDED to make
  use of SIP security = mechanisms, such as the SIP Identity PASSporT
=   [RFC8225], to tie the CAP message to the SIP message. =  To provide

Not required?  Please = describe the risks of not doing so (whether
directly or by = reference).

  protection of the = entire SIP message exchange between neighboring SIP
=   entities, the usage of TLS is REQUIRED.

Just to check: this is a 100% always, for everyone, = "REQUIRED", not just
in the subset of cases where = protection of the entire exchange is
desired?

  Note that none of the security = mechanism in this document protect
  against a = compromised sensor sending crafted alerts.  Privacy
=   provided for any emergency calls, including non-interactive = messages,
  is subject to local regulations.

I suggest using "confidentiality protection" = rather than "privacy"
(unless it's a term of art in this = field), to avoid confusion with...
Privacy considerations = for alerts (e.g., generated by sensors) that
should be = discussed.  RFC 7852 has some extensive privacy considerations
that can be referenced to do the bulk of the work here.

I'd also consider reiterating the = opportunistic nature of cryptographic
protection on = emergency messages, as discussed in 6443 (since insecure
emergency messaging is preferred to no emergency messaging), = but this is
not strictly speaking required.

Section 12.2

RFC = 8225, as a RECOMMENDED feature, is more properly listed as a
normative reference, per
https://www.ietf.org/about/groups/iesg/statements/normative-inf= ormative-references/




= --Apple-Mail=_6F8B71EA-BD80-4352-B9A8-15EADA99B2AC-- From nobody Tue Mar 3 07:28:46 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184B73A2265 for ; Tue, 3 Mar 2020 07:28:36 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 igqjEcNsZkdn for ; Tue, 3 Mar 2020 07:28:33 -0800 (PST) Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F1D3A2267 for ; Tue, 3 Mar 2020 07:28:33 -0800 (PST) Received: by mail-yw1-xc35.google.com with SMTP id t141so3631153ywc.11 for ; Tue, 03 Mar 2020 07:28:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vIi23la1rr7Pz1PmSxB7pb1lFnaD3Qes/oyfyQJBdSQ=; b=mAnpSimeT9NKmA80eSp1B2EH290tEUGydf4UkqqHY66tyO3EalycXmTeLCJVjdOBpf kEvJUyAZ6jYaHFFYVSkcEPd27ttmHeLycH9WSkdgg5SbRFS1bS9OE1P5hd0liVVIsg4q fIvNjdIqSLL8pJfzPXMt4M7zLFaLE+GvBF0mZxcnNGn+gBY9UeLignJTe3vnT2nj5K8B 2sWwvY+p1yTlkyGRdzachoiOSUAJOon+cGqSGE9xF+F6tniCzWFJ/5sfpjWzETLa4dqb SN6GwxyfyzN7OXFkhJ7mW+x4Sm2y3TD/rnaMSolQYWPJdW3+uFzv7/EDhKUK+rRaDEkM TyuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vIi23la1rr7Pz1PmSxB7pb1lFnaD3Qes/oyfyQJBdSQ=; b=mc4EnxRhp99jC7pZVu6GLp2yGaIvbQEHQcvCw2sqhi517pG12chRzReUTAXz3J8CtK nzh+a6HRoEzOXcTEskYHgu0RChcPW+c9YZFCYLXVnDIRTefAY+4G3AMHuDRBndI3MvD4 Tkdlv9xXndWNWAc5XM8qlX/2PTZI7PRHqMUZZGPioO9gXWMc8k/tZJ88V0bbyhe/R04r qU8B+MBhCXJcp12sOEE6IUrR3OJrtsd2eyPhY34Wyo4MSmR3wSUK1K6zKagMzVPjDfgR e7eGWMAQ0O8Sffxr8rcNcd6+m6vTEckMJFxAiLUOwcrCaqVTISMggwVH09ADhxaMlAb4 YFoQ== X-Gm-Message-State: ANhLgQ2y2rGTHufgXruwkjn/PeJJ4msx6uBjXwLqVSTrlt+k0CDeCoer E5OvA02xYyPiV01S1H5Ngrwsmg== X-Google-Smtp-Source: ADFU+vsuya5NsWbsLFqC63iICg4+FYx9PKtYrwUQ5D3QJa3kHOJePrSGqets7uVf7PvxrgzPZt28pg== X-Received: by 2002:a81:602:: with SMTP id 2mr5279044ywg.81.1583249312458; Tue, 03 Mar 2020 07:28:32 -0800 (PST) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id g70sm2025860ywh.53.2020.03.03.07.28.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Mar 2020 07:28:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Brian Rosen In-Reply-To: <158324748449.7657.12581369226723862050@ietfa.amsl.com> Date: Tue, 3 Mar 2020 10:28:31 -0500 Cc: The IESG , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin Content-Transfer-Encoding: quoted-printable Message-Id: References: <158324748449.7657.12581369226723862050@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Ecrit] Alexey Melnikov's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2020 15:28:36 -0000 Thanks for your comments. I will fix them all. Brian > On Mar 3, 2020, at 9:58 AM, Alexey Melnikov via Datatracker = wrote: >=20 > Alexey Melnikov has entered the following ballot position for > draft-ietf-ecrit-data-only-ea-21: Discuss >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This is a tiny point, but I think it needs fixing for clarity: >=20 > 5.2. The AlertMsg-Error Header Field >=20 > error-code =3D 1*3DIGIT >=20 > The text below makes it clear that the error-code is 3 digits: >=20 > The ErrorValue contains a 3-digit error code indicating what was > wrong with the alert in the request. >=20 > What you have above allows for 1, 2 or 3 digits. I think you meant: >=20 > error-code =3D 3DIGIT >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I initially thought that error-codes are from the same namespace as = SIP Status > Codes. I think you should explicitly say that they are not. >=20 > The first mention of HTTPS needs a normative reference. >=20 > In Section 10.1: >=20 > Encoding considerations: Uses XML, which can employ 8-bit > characters, depending on the character encoding used. See > [RFC7303], Section 3.2. >=20 > This field of the form should say one of "7bit", "8bit", "binary" or = "framed". > I think in your case it is "binary", because UTF-16 charsets are not = prohibited > in your document. >=20 >=20 >=20 From nobody Tue Mar 3 11:14:40 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30973A046A; Tue, 3 Mar 2020 11:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=KqGR+Oe+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=4FdF/hU0 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 XRTtKDQ3caJO; Tue, 3 Mar 2020 11:14:18 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4543A045B; Tue, 3 Mar 2020 11:14:15 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id AA1292206E; Tue, 3 Mar 2020 14:14:14 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 03 Mar 2020 14:14:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=d VLfmUSfBjSW7ocTvuOBvpkIdollo6J/t+p2LKqO7IY=; b=KqGR+Oe+fYIO/8tEG dtM5MKw/nO0CDQhiBqhrREKlxeILP78d2ov/8GYr2C6qcRJpUy+3Hi3WCAytvyRo 1lDOnvolpTALr8h7G7H4JI1NTGOvDYVMzwhGbiKGRe9gMV/qLdpQMqd/bJpIvUTc 3y9WL0N9k857tA5eieucSp2xgtmlxUsd/YnyKCVzoyioSXzSuSbfIcBuIbtN/2bK ak5X5mVPvyHEBkBSR91MfDpxManuu55ZMT+q2ZLJeBzryzK1jQdgNY3BYoVSmiT7 ZQmEP4cXdgbPkds+TQYE8CPAS7z3xAnUyrLs4aavAkMkqPpLXdgWT+wARItJlHU5 m6MOQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=dVLfmUSfBjSW7ocTvuOBvpkIdollo6J/t+p2LKqO7 IY=; b=4FdF/hU0PtxNiySYpkJt2kyeQGA2Rxz2dSGcU0cHw/iUmw/7SDooNhTxH ZAcVbagDcJK0w7Rg1SssmUYHOfxHwXtsNg0fijdCA93UdFMPuP4t9omlKAoZEOzs w/xJALlxU8PTRyIIDHJo8f5ma7ruXwntoqOh3NMOHLnaStkCzDyDwufJ+91kvyWx rezfdjuLN0r+/CQf2MpQO4zpnahuXAUCHwHFNeKZXndknmTA8xheVzTgD1GzNb7i qtknwAgWDS552WwSXqJM0/oSaW57m6cjmTNpJ/zoofWV0dy/k1V6geP1obtMECZ8 sb2plCXqqs2f/Uevzu9e9w5dILZWg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddtiedguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomh grihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdektdenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestg hoohhpvghrfidrihhn X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.80]) by mail.messagingengine.com (Postfix) with ESMTPA id F39893060BD1; Tue, 3 Mar 2020 14:14:13 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <158286145629.12729.7571746436683650433@ietfa.amsl.com> Date: Tue, 3 Mar 2020 14:14:12 -0500 Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-ecrit-data-only-ea.all@ietf.org, ecrit@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1A7377AC-BB86-4B02-8387-F59AFBFA4621@cooperw.in> References: <158286145629.12729.7571746436683650433@ietfa.amsl.com> To: Mohit Sethi X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ecrit] [Gen-art] Genart telechat review of draft-ietf-ecrit-data-only-ea-21 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2020 19:14:20 -0000 Mohit, thanks for your reviews. Brian, thanks for your response. I = entered a Yes ballot. Glad to finally see this getting done! Alissa > On Feb 27, 2020, at 10:44 PM, Mohit Sethi via Datatracker = wrote: >=20 > Reviewer: Mohit Sethi > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-ecrit-data-only-ea-21 > Reviewer: Mohit Sethi > Review Date: 2020-02-27 > IETF LC End Date: 2019-09-02 > IESG Telechat date: 2020-03-05 >=20 > Summary: My comments on version -18 were addressed. The document is = ready.=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Mar 4 09:46:24 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 355B73A1378; Wed, 4 Mar 2020 09:46:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, allison.mankin@gmail.com, gsalguei@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158334397518.29417.7001281477331520733@ietfa.amsl.com> Date: Wed, 04 Mar 2020 09:46:15 -0800 Archived-At: Subject: [Ecrit] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-ecrit-data-only-ea-21=3A_=28with_COMMENT=29?= X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 17:46:16 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-ecrit-data-only-ea-21: 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-ecrit-data-only-ea/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please address all the NITs found in the IoT directorate review by Gonzalo Salgueiro: https://datatracker.ietf.org/doc/review-ietf-ecrit-data-only-ea-21-iotdir-telechat-salgueiro-2020-03-02/ Thank you again Gonzalo ! And another NIT below. I hope that this helps to improve the document, Regards, -éric -- Section 4.2 -- About "incidents", s/may not be present/MAY not be present/ ? From nobody Thu Mar 5 03:49:38 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAB43A0F00; Thu, 5 Mar 2020 03:49:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux via Datatracker To: "The IESG" Cc: draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, allison.mankin@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Vigoureux Message-ID: <158340897626.14780.336877226240940284@ietfa.amsl.com> Date: Thu, 05 Mar 2020 03:49:36 -0800 Archived-At: Subject: [Ecrit] Martin Vigoureux's No Objection on draft-ietf-ecrit-data-only-ea-21: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 11:49:37 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-ecrit-data-only-ea-21: 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-ecrit-data-only-ea/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, A very minor question: I have noticed 4 occurrences of "SIP message" (lower case). Just checking if this is intentional since there are occurrences in upper case. From nobody Thu Mar 5 04:42:30 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6563A1401; Thu, 5 Mar 2020 04:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 sG8FGdcd3uvM; Thu, 5 Mar 2020 04:42:08 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2071.outbound.protection.outlook.com [40.107.20.71]) (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 7C4CB3A1400; Thu, 5 Mar 2020 04:42:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=klcFZ7DkqiTBQBHjpGZvVkMXNhSZsVfU7p3vfG0BM/3PAKDL0VVImz5F+0TTuMiQw1VzAIXed03AWddcEwEGbOQAD2qSJsW3lTOG/kPV8F8X1DrVCmV+RNE3K+/YdCiAiLUJ66GeLlraCC8SMnTKFnpGfqCgncAuv+U0as+2fEdtkGzDWUAQyRsoFEUjp3wgSiL/79CQGGzmazbfhAgXKqkc2um/hkHmUHTrcmupEdfB89C89dg4JzF8CU892SRVlKCLlEr/VbuaYWb2nQJogHSTToJuceayLMaj1L5/L6GMbvp+KQjDWOWdpNJ2NaPBxqedGvrcQ7g3lgOL8OQQrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qtiiN36E4vrxweDifc3H6B1R8chfqSq0EwiqyEqf1rU=; b=k1sldiAC3vHx4hL0mTpP1PKraCng34EPblUZLoclIjwoSrZnkEWjiZjVc1RQEbMDN6WhiRJXVDxFZ0pW2A5DHG6r6AD+jyzVEz3zL5iMGj5zs9SMcKyVIww6DEZZv0CrkS14ya+4AzZkjyGggOQh/mrvcHVL6Xb/FMwKTywahhsM59SAOJtSJ+o+0pjwbkJBOMcH9LzX4rYNlYMBQhkoFgwbhRGXdp02OI1I6qZZMg7dvGATblrjF68hSDx9J1GGDZgMxhg1NSyI+0DawGETiGRW4OeB8CqtlfyOMgOlA5hyYdmKWYNluGcQd9Rl2prai3cTIeG72IFC5dh57h1VgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qtiiN36E4vrxweDifc3H6B1R8chfqSq0EwiqyEqf1rU=; b=k1Cf6DBRXyqO8/4DUuIQbDNvXZ3TX4lJIOguviIxkRyGaouVTgyCTtCl9htmIiT0aE0sfLAnYsiGwlAmWL3tKxtiE6dhCTDMs1UhP6uAUsq1U3Y+wKEj+I4WWdh/NJSj6rS9phMgPV2ng5g9cn/RBEzHAtWO2WKKXLexU2n3n9I= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (52.134.82.159) by AM0PR07MB5124.eurprd07.prod.outlook.com (20.178.16.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.5; Thu, 5 Mar 2020 12:42:05 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512%7]) with mapi id 15.20.2793.011; Thu, 5 Mar 2020 12:42:05 +0000 From: Christer Holmberg To: Martin Vigoureux , The IESG CC: "allison.mankin@gmail.com" , "ecrit-chairs@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-data-only-ea@ietf.org" Thread-Topic: [Ecrit] Martin Vigoureux's No Objection on draft-ietf-ecrit-data-only-ea-21: (with COMMENT) Thread-Index: AQHV8uQtrL0lrIqKw0+PSL6/mVW91Kg6ErAA Date: Thu, 5 Mar 2020 12:42:05 +0000 Message-ID: References: <158340897626.14780.336877226240940284@ietfa.amsl.com> In-Reply-To: <158340897626.14780.336877226240940284@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f741ba63-7fc4-405a-f6d4-08d7c1029c73 x-ms-traffictypediagnostic: AM0PR07MB5124: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 03333C607F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(39860400002)(346002)(136003)(376002)(199004)(189003)(6486002)(44832011)(6512007)(33656002)(36756003)(71200400001)(76116006)(2616005)(91956017)(5660300002)(6506007)(54906003)(66556008)(64756008)(4744005)(66476007)(66446008)(316002)(478600001)(296002)(110136005)(66946007)(186003)(26005)(81166006)(4326008)(8676002)(86362001)(2906002)(81156014)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5124; H:AM0PR07MB3987.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tRrHHogUMNfHovCrEM71G7rNp55YlQxzmaOOaUAIn+iq3Tom+n103P3KaD4RKqTvwQcBaaRGvIl+SWw8bT6xAZdxo1bJlO9mKK8uJouVy1c/TPfODGtr04gKjhdv4qKt0duPjYByVWRq4PVZQLnnzVfVQZ8yL2FuqZwpNMihfXeafwzW2jVpBL4jjgMl9NdUYt6dG/rqTR+HoSc4/gSR2fio528KM9nqQMTcbqewhBr5eVNbPWKNZjSl7znpqox0OtwDAmWBb5jDtsdTUyMLtPG0YrWXW7bXVyM59rQNxsDBYbi6r+Y8iU0Z5NW8gewz0af35UItBRoB5gLgfXM1UI8Q/yGPix2DM+nn1/ss3ICIPBpBhIy9r1beRSJyWnix2tScaxxoDNCMW2YBd0JQ4NyPVCDT9/BnyhpmXmeo0+BoxBHsYrNq8cuBFT1QJWhV x-ms-exchange-antispam-messagedata: LqzXamM21kjfAzao0J64IgnRG7tWOXwE95bjADbzSnUhC6rKurUL0hxi64G4d6+3YUiixObwMU5YzlfsZ6nist4HycsG5w6lN/cYDNH6qXLskZiVmo/nQVdAeZ7ToRE7a+V2t7As0Z7v3v04ssFVjQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <269CD6DC2B6D13418F8F2BBB5DB55946@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f741ba63-7fc4-405a-f6d4-08d7c1029c73 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2020 12:42:05.4225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oghBSSPCHWHt62YFsOTriHvY1Qx9B5mncnxfzUD+PiCVhOhlo1dZ/foVJvfWzjdm9koI98w9i5Uik2EZmnYQHUjP6RWZ5zvj3hsBieyR74M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5124 Archived-At: Subject: Re: [Ecrit] Martin Vigoureux's No Objection on draft-ietf-ecrit-data-only-ea-21: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 12:42:13 -0000 SGkgTWFydGluLA0KDQpJIGFtIG5vdCBhbiBhdXRob3Igb2YgdGhpcyBkcmFmdCwgYnV0IEkgY2Fu IGFuc3dlciB5b3VyIHF1ZXN0aW9uIDopICAgIA0KICAgICAgICANCj4gICAgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiAgICBDT01NRU5UOg0KPiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAgIA0KPiAgICBIaSwNCj4g ICAgDQo+ICAgIEEgdmVyeSBtaW5vciBxdWVzdGlvbjoNCj4gICAgSSBoYXZlIG5vdGljZWQgNCBv Y2N1cnJlbmNlcyBvZiAiU0lQIG1lc3NhZ2UiIChsb3dlciBjYXNlKS4gSnVzdCBjaGVja2luZyBp Zg0KPiAgICB0aGlzIGlzIGludGVudGlvbmFsIHNpbmNlIHRoZXJlIGFyZSBvY2N1cnJlbmNlcyBp biB1cHBlciBjYXNlLg0KICANCiJTSVAgbWVzc2FnZSIgaXMgYSBnZW5lcmljIHRlcm0gZm9yIFNJ UCByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzLg0KDQoiU0lQIE1FU1NBR0UiIHJlZmVycyB0byBhIFNJ UCByZXF1ZXN0L3JlcXVlc3QvdHJhbnNhY3Rpb24gd2hlcmUgdGhlIFNJUCBtZXRob2QgdmFsdWUg aXMgIk1FU1NBR0UiIChzaW1pbGFyIHRvICJJTlZJVEUiLCAiQ0FOQ0VMIiwgIkJZRSIsIGV0YyBl dGMpLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQogICAgDQoNCg== From nobody Thu Mar 5 04:57:12 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9E13A1428; Thu, 5 Mar 2020 04:57:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alexey Melnikov via Datatracker To: "The IESG" Cc: draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, allison.mankin@gmail.com, francesca.palombini@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alexey Melnikov Message-ID: <158341302575.14539.9415711039749515671@ietfa.amsl.com> Date: Thu, 05 Mar 2020 04:57:05 -0800 Archived-At: Subject: [Ecrit] Alexey Melnikov's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 12:57:06 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-ecrit-data-only-ea-21: Discuss 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-ecrit-data-only-ea/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (Updated, see the extra review comments) I have a few a tiny point, but I think they need fixing for clarity: 1) 5.2. The AlertMsg-Error Header Field error-code = 1*3DIGIT The text below makes it clear that the error-code is 3 digits: The ErrorValue contains a 3-digit error code indicating what was wrong with the alert in the request. What you have above allows for 1, 2 or 3 digits. I think you meant: error-code = 3DIGIT 2) As per Francesca's review: "/=" is illegal in ABNF, it should be "=/" ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I initially thought that error-codes are from the same namespace as SIP Status Codes. I think you should explicitly say that they are not. The first mention of HTTPS needs a normative reference. In Section 10.1: Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See [RFC7303], Section 3.2. This field of the form should say one of "7bit", "8bit", "binary" or "framed". I think in your case it is "binary", because UTF-16 charsets are not prohibited in your document. ********************************************************************** * Note, that I am conducting an experiment when people aspiring to be* * Area Directors get exposed to AD work ("AD shadowing experiment"). * * As a part of this experiment they get to review documents on IESG * * telechats according to IESG Discuss criteria document and their * * comments get relayed pretty much verbatim to relevant editors/WGs. * * As an AD I retain responsibility in defending their position when * * I agree with it. * * Recipients of these reviews are encouraged to reply to me directly * * about perceived successes or failures of this experiment. * ********************************************************************** The following comments were provided by Francesca Palombini . Comments from me are marked with [[Alexey:]]. Francesca would have balloted *DISCUSS* on this document. She wrote: * Shepherd did not indicate any ABNF verification was done, I took some time to check and: - message-header /= AlertMsg-Error I am aware of =/ rule but /=? Don't think that is a valid ABNF op. [[Alexey:]] well spotted. - Is error code 1 to 3 digits or 3 digits? [[Alexey:]] This is the same issue as was reported by me. - "there MUST NOT be more than one string per error code." but ABNF specifies there can be 0 or more error-params which itself contain 1 error code text... [[Alexey:]] While this can be fixed in ABNF, it is quite common in RFCs to specify such restrictions in prose. So I don't think this issue is problematic. * Maybe not worth a discuss? But "AlertMsg-Error: 100 ; code="Cannot Process the Alert Payload"" and following: these are error-code values not AlertMsg-Error (as defined in the ABNF) values, I suggest changing the name so that is clear (e.g. AlertMsg-Error-code: 100 ...) * Security considerations need to discuss Call-Info header field usage, as that is used, see 20.9 of RFC3261. I do not think the security considerations are enough. COMMENTS: * Reference to SIP (RFC3261) is missing first time it appears in the text. * "This scenario corresponds to the classic emergency services use case and the description in [RFC6881] is applicable." - I don’t find this sentence very clear. What description in RFC6881? Just needs rephrasing probably. * I'd like either a note in terminology or a pointer to where Service URN is described the first time it appears. * I would have liked more info about the "author vs originator" terminology of section 4.2 * "then the element MUST NOT contain the SIP URI of the user agent." MUST it contain author though? That is not specified. * "the element is optional" Should it be OPTIONAL? * "If the CAP message already contains an element" seems to imply the CAP message has been constructed elsewhere. Being more explicit about where this CAP message is expected to be formed would make things clearer. * "The 425 response code is a rejection of the request due to its included alert content, indicating that it was malformed or not satisfactory for the recipient's purpose." it is unclear to me what that means of a request not to be "satisfactory". I think it needs to be better specified what can be wrong. * "It is only appropriate to generate a 425 response when the responding entity has no other information in the request that is usable by the responder." like what other information? Again unclear imo. * "; (message-header from 3261)" - missing ref * Why in Fig3 is the sensor saying that it accepts these? Accept: application/pidf+xml,application/EmergencyCallData.cap+xml * thanks for checking XML *"An entity that has already received a CAP message within the indicated timeframe is able to detect a replayed message and, if the content of that message is unchanged, then no additional security vulnerability is created. " this mechanism needs to be specified in the document, while it is only hinted in the sec cons. If it is not in scope of this doc, that should be highlighted. * It's media type not MIME type ;) (see https://trac.ietf.org/trac/app/wiki/TypicalAppsAreaIssues#MediaTypes) From nobody Thu Mar 5 09:36:11 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F2A3A07AC; Thu, 5 Mar 2020 09:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 2QJUZJbdBOkw; Thu, 5 Mar 2020 09:36:03 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 CC8C13A07B1; Thu, 5 Mar 2020 09:36:02 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 025HZqnR000972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Mar 2020 12:35:54 -0500 Date: Thu, 5 Mar 2020 09:35:51 -0800 From: Benjamin Kaduk To: Brian Rosen Cc: The IESG , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ECRIT , Allison Mankin , Roman Danyliw Message-ID: <20200305173551.GT98042@kduck.mit.edu> References: <158319820318.27328.12390339422433838277@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ecrit] Benjamin Kaduk's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 17:36:06 -0000 Hi Brian, On Tue, Mar 03, 2020 at 10:27:38AM -0500, Brian Rosen wrote: > It will be very common for the entity sending the message to not be the entity hosting the referenced document. For example, a device may send the MESSAGE, but some service that the device’s mfg operates hosts the CAP. So we make NO assumptions that there is any connection between them. The same is true for the Additional Data from 7852. I was not trying to imply that they had to be the same entity, but rather that (for the case when they are not), we might reasonably expect there to be some policy relationship between them, such that the entity sending the message can be reasonably assured that the content referred to will remain stable and as-intended, and in the reverse direction to have the content hosting service give some indication of what entities are expected (or authorized) to refer to that content. Depending on the scenario and how important it is to the consuming application to enforce the desired semantics in this space, we might also construct protocol mechanisms to effectuate the desired enforcement, e.g., including a hash of the expected content alongside the URI to the content. Even if we don't deem the risk significant to merit protocol mechanisms, we should still document the risk, including the possibility for an attacker to send a notification with a URI to a server that was expecting that resource to be accessed in a different context and for an attacker to compromise the service hosting URIs that legitimate clients refer to. > Proposed text (revises the text I previously suggested to Roman) > This document describes potential retrieval of information by dereferencing URIs found in a Call Info header of a SIP MESSAGE. These may include a CAP message as well as other Additional Data (RFC7852) blocks. The domain of the device sending the SIP MESSAGE, the domain of the server holding the CAP message, if sent by reference, and the domain of other Additional Data blocks, if sent by reference, may all be different. No assumptions can be made that there are trust relationships between these entities. Recipients MUST take precautions in retrieving any Additional Data blocks passed by reference, including the CAP message, because the URI may point to a malicious actor. The considerations in handling URIs in RFC3986 apply. I think we should say "malicious actor or entity not expecting to be referred to for this purpose" (or similar). (I assume this is in addition to a reference to the full 3986 considerations.) > > With respect to your DISCUSS on timestamps. Can I add: > Use of timestamps to prevent replay is subject to the availability of accurate time at all participants. Because emergency event notification via this mechanism is relatively low frequency and generally involves human interaction, implementations may wish to consider messages with times within small number of seconds of each other to be effectively simultaneous for the purposes of detecting replay. Implementations may also wish to consider that most deployed time distribution protocols likely to be used by these systems are not presently secure. That seems to cover the salient points; thanks. > With regard to DoS, the only thing that makes this different from any emergency call situation is that there is no two way media with a human, and so you immediately assume a bot rather than a human, and therefore probably more likely to be a DoS source. > > OTOH, there isn’t anything we can do with that information. If I can generate large numbers of malicious SIP transactions, whether they are INVITE or MESSAGE doesn’t matter. If I can compromise a device, whether it’s a phone that generates INVITE or an IOT device that generates MESSAGE, then I can misuse it. I’m at a loss to know what to say. I can supply the advice that the emergency authorities have always offered: automated devices have increased probability to generate false positive emergency calls/messages. This is a burden on the emergency services which has to respond to all calls/messages. In some jurisdictions, there are legal restrictions on automated emergency calls/messages, and in others, there are penalties for repeated false positive calls/messages. I confess I did not have anything concrete in mind in terms of text to add, when I wrote this, so thank you for thinking it through with me. I probably would supply that standard advice, though I don't think I would insist upon it. > I’ll work on the comments and reply if I have any issues as I update in response to them. Thanks! -Ben > > > On Mar 2, 2020, at 8:16 PM, Benjamin Kaduk via Datatracker wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-ecrit-data-only-ea-21: Discuss > > > > 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-ecrit-data-only-ea/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I support Roman's Discuss (and comment) and will expound on his first > > point some more. > > > > The use of URIs to refer to remote content, potentially hosted on a > > third party, has numerous security considerations, some better known > > than others. We need to reference the security considerations of RFC > > 3986 to get some coverage of these, such as the "reliability and > > consistency" point. > > > > One of the more subtle security considerations of using a URI to a > > remote resource as part of a request in cases such as this, is that the > > binding between the identity of the entity referring to the remote URI > > and the identity of the site providing the corresponding resource (i.e., > > the authority compoent of the URI) is not always clear. Although RFC > > 7852 requires TLS mutual authentication and HTTPS transport for > > information provided by reference, it makes no statement requiring the > > TLS server certificate to correspond to the SIP initiator, or any other > > indication of authorization that the indicated resource makes sense as > > part of the indicated request. > > > > I also have two other Discuss-level points: > > > > We discuss the use of timestamps in protocol elements for detecting > > replay; this requires that all participants have (secure and) accurate > > time. We need to document this dependency on accurate time, and > > optionally point out that common internet time protocols such as NTP are > > not particularly secure at present. > > > > I'm also not sure where there's existing treatment of using SIP MESSAGEs > > as a DoS attack vector; that seems particularly pronounced in the > > emergency-services case since emergency messages may receive > > preferential treatment from the network. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Introduction (and Abstract?) > > > > medical monitors. These messages may be one-shot alerts to emergency > > authorities and do not require establishment of a session. These > > type of interactions are called 'non-interactive emergency calls'. > > > > Is this an existing/widespread definition or one new to this document? > > It may be worth providing a reference or rewording to clarify that it is > > a new definition. > > > > Section 2 > > > > CID is Content InDirection [RFC2392] > > > > The string "InDirection" does not appear in RFC 2392. > > > > Section 4.1 > > > > A CAP message may be sent in the initial message of any SIP > > transaction. However, this document only addresses sending a CAP > > message in a SIP MESSAGE transaction for a one-shot, non-interactive > > emergency call. Behavior with other transactions is not defined. > > > > I suggest rephrasing to "A CAP message is sent in the initial message of > > a SIP transaction" to avoid potential concerns about inconsistency > > between "may be sent" and "not defined". > > > > the CAP message. Alternatively, the Call-Info header field may > > contain a Content Indirect url [RFC2392] and the CAP message included > > > > nit: "Indirect" here vs. "InDirection" in Section 2 > > > > Section 4.2 > > > > field. If there is a need to copy the PIDF-LO structure > > referenced by 'geolocation' to , implementers must be aware > > > > When might this occur? (It seems almost out of scope for this document > > based on my limited understanding.) > > > > that is limited to a circle or polygon, and conversion of > > other shapes will be required. Points SHOULD be converted to a > > circle with a radius equal to the uncertainty of the point. Arc- > > bands and ellipses SHOULD be converted to an equivalent polygon. > > 3D locations SHOULD be converted to their equivalent 2D forms. > > > > nit: what is an "equivalent" polygon to an ellipse or arc-band? In a > > mathematical sense it might mean "strict equivalence" or a large-n limit > > of an n-gon, or perhaps there is a corresponding uncertainty on the > > ellipse/arc-band that the polygon must stay within? Rewording to > > "corresponding" might be an easy fix. > > > > Section 5.1 > > > > The 425 response code is a rejection of the request due to its > > included alert content, indicating that it was malformed or not > > satisfactory for the recipient's purpose. > > > > A SIP intermediary can also reject an alert it receives from a User > > Agent (UA) when it detects that the provided alert is malformed. > > > > (I assume there's an implicit "reject with this code" in here.) > > > > It is only appropriate to generate a 425 response when the responding > > entity has no other information in the request that is usable by the > > responder. > > > > I'm not sure I'm parsing this sentence correctly. My best guess is that > > it's saying "if there's anything in the request that you can respond to, > > don't use 425, even if there's some malformed CAP", but that doesn't > > really seem to be what the actual words are saying. [Section 5.2 seems > > to support my guess.] > > > > Section 5.2 > > > > message-header /= AlertMsg-Error > > ; (message-header from 3261) > > > > nit: mybe "RFC3261" to match the later comments? > > > > wrong with the alert in the request. This error code has a > > > > pedantic nit: the ABNF has 1-to-3-digit > > > > standardized -- meaning an operator can change the strings -- but > > MUST NOT change the meaning of the error code. Similar to how RFC > > 3261 specifies, there MUST NOT be more than one string per error > > code. > > > > RFC 3261 is ... pretty long. Maybe throw us a bone with a section > > reference? Also, I assume this "MUST NOT be more than one" is within a > > single AlertMsg-Error construction, since a truly global interpretation > > would mean that (since this document assigns strings) there cannot > > actually be changes made to the strings by an operator, which we just > > said is possible. > > > > This document defines an initial list of AlertMsg-Error values for > > any SIP response, including provisional responses (other than 100 > > Trying) and the new 425 response. There MUST be no more than one > > AlertMsg-Error code in a SIP response. AlertMsg-Error values sent in > > > > Is this redundant with the "MUST NOT" I was asking about above? > > > > Additionally, if an entity cannot or chooses not to process the alert > > message from a SIP request, a 500 (Server Internal Error) SHOULD be > > used with or without a configurable Retry-After header field. > > > > I don't think I understand when it's recommended to use 500 vs 425 (and > > vice versa). > > > > Section 7 > > > > It's probably worth mentioning RFC 3428's note about: > > > > % The size of MESSAGE requests outside of a media session MUST NOT > > % exceed 1300 bytes, unless the UAC has positive knowledge that the > > % message will not traverse a congestion-unsafe link at any hop, or > > % that the message size is at least 200 bytes less than the lowest MTU > > % value found en route to the UAS > > > > since that seems to still apply here. > > > > Section 8 > > > > I'd consider using a more recent date than 2008-11-19 for the example > > time. Also, why is the timestamp in the additional information > > 2010-11-14, almost two years later? > > > > 32.86726 -97.16054 > > > > Is that ... someone's house? Maybe some different coordinates would be > > more appropriate. > > > > Figure 3 has "Content-Disposition: by-reference;handling=optional" but > > Figure 4 does not; is that significant? > > > > Section 9 > > > > In any case, for alerts initiated by sensors, the identity could play > > an important role in deciding whether to accept or ignore an incoming > > alert message. With the scenario shown in Figure 1 it is very likely > > that only authenticated sensor input will be processed. For this > > reason, it needs to be possible to refuse to accept alert messages > > from an unknown origin. Two types of information elements can be > > used for this purpose: > > > > 1. SIP itself provides security mechanisms that allow the > > verification of the originator's identity, such as P-Asserted- > > Identity [RFC3325] or SIP Identity [RFC8224]. The latter > > provides a cryptographic assurance while the former relies on a > > chain of trust model. These mechanisms can be reused. > > > > 2. CAP provides additional security mechanisms and the ability to > > carry further information about the sender's identity. > > Section 3.3.4.1 of [cap] specifies the signing algorithms of CAP > > documents. > > > > I'd consider adding a note that "the specific policy and mechanisms used > > in a given deployment are out of scope for this document", since the > > actual requirements in practice are so broad that we cannot really make > > detailed recommendations here. > > > > In addition to the desire to perform identity-based access control, > > the classic communication security threats need to be considered, > > including integrity protection to prevent forgery or replay of alert > > messages in transit. To deal with replay of alerts, a CAP document > > contains the mandatory , , elements and an > > optional element. Together, these elements make the CAP > > document unique for a specific sender and provide time restrictions. > > An entity that has already received a CAP message within the > > indicated timeframe is able to detect a replayed message and, if the > > content of that message is unchanged, then no additional security > > > > Is *able* to detect, sure. But is it recommended to do so? Required? > > > > vulnerability is created. Additionally, it is RECOMMENDED to make > > use of SIP security mechanisms, such as the SIP Identity PASSporT > > [RFC8225], to tie the CAP message to the SIP message. To provide > > > > Not required? Please describe the risks of not doing so (whether > > directly or by reference). > > > > protection of the entire SIP message exchange between neighboring SIP > > entities, the usage of TLS is REQUIRED. > > > > Just to check: this is a 100% always, for everyone, "REQUIRED", not just > > in the subset of cases where protection of the entire exchange is > > desired? > > > > Note that none of the security mechanism in this document protect > > against a compromised sensor sending crafted alerts. Privacy > > provided for any emergency calls, including non-interactive messages, > > is subject to local regulations. > > > > I suggest using "confidentiality protection" rather than "privacy" > > (unless it's a term of art in this field), to avoid confusion with... > > Privacy considerations for alerts (e.g., generated by sensors) that > > should be discussed. RFC 7852 has some extensive privacy considerations > > that can be referenced to do the bulk of the work here. > > > > I'd also consider reiterating the opportunistic nature of cryptographic > > protection on emergency messages, as discussed in 6443 (since insecure > > emergency messaging is preferred to no emergency messaging), but this is > > not strictly speaking required. > > > > Section 12.2 > > > > RFC 8225, as a RECOMMENDED feature, is more properly listed as a > > normative reference, per > > https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ > > > > > > > From nobody Mon Mar 9 10:56:08 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCE33A14CA for ; Mon, 9 Mar 2020 10:56:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 muL0kb28SIET for ; Mon, 9 Mar 2020 10:55:57 -0700 (PDT) Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA9F03A147A for ; Mon, 9 Mar 2020 10:55:57 -0700 (PDT) Received: by mail-yw1-xc2d.google.com with SMTP id j186so11057182ywe.0 for ; Mon, 09 Mar 2020 10:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gHg93bhyQdrqLTzFfjHQLTaKanNreC31dBj3ktHW6L8=; b=LwX9c2pgl/xwcHupuT2gxz7D4L1QzINYJp7pU+P9C2sKWo1NUIJAGSiBTGe3QHKQiZ NOClhoQndNpUYkfswKvQyyXWJKlOTF/EZ+kxunC4R4zl9ZgerfiRkw6p5bzOCU3BjmDt nCRObF7J3dnS9pBhdn6N+yP/rAxUyUHZOmjY+fPheU31oxBCBJGQqmzhpVkbOfJGkcms +E39diFu0Ngnmx10BvVy+seqI5vVTyu6axzits5F7hvUDlWLpfOpzUPfPmxgIMH2cJLV hxb5O/KSqBQQTkl+3SIqfA54ihAV3kJpscEitHEKyNkC0s2DvkQ0cHLyHgQ8VBnQuznZ +zbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gHg93bhyQdrqLTzFfjHQLTaKanNreC31dBj3ktHW6L8=; b=HQ+H22c0XcBzlTvNRP6pUHdtZ7WCLF61omkpgwvJfRl2esaS6HBAQX6iKsnrtvhJ/X /XH3kyx6i40ze/Hd7eRc/xqzvr58/PKZTp8jF11eh4J2oeR2Ao9x7qoJVwUnjrdBzk9R SYB3t6zZQLSNnZJpnQp+o8r3Jh8IRSB08szz76ZypywM4Ot0iSyQGnxk08GHLOFpZ5j6 FFjqdkfPhBk+4mbw8bIVwRPQ1zEV0RF1UYuS2ot7Kvaamb4lUYUvF42JKSOh1VQgvv2v PcwhXYpsJmSa4BRs2cuJhrhJ6Rufc7V936C57SeNFDmrbBdhaVlXa4TusZ+X/1n3GW+V K1mQ== X-Gm-Message-State: ANhLgQ0PRbv3Gt9alpY9oWmfr9UHqACNbOTL7jLwCh8Fv+h2WaExIrQ3 DTJfbetjtEYjgMmfExCtIBAMXw== X-Google-Smtp-Source: ADFU+vsmzxQkfCoa38Eu55pCr2VKV/ItZLxrGEdGs3OV0iJXK44om/uKhN8PWNxHapZJyjMCvvvwNQ== X-Received: by 2002:a0d:f483:: with SMTP id d125mr18970120ywf.72.1583776556316; Mon, 09 Mar 2020 10:55:56 -0700 (PDT) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id r12sm6659004ywa.78.2020.03.09.10.55.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2020 10:55:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Brian Rosen In-Reply-To: <158319820318.27328.12390339422433838277@ietfa.amsl.com> Date: Mon, 9 Mar 2020 13:55:53 -0400 Cc: The IESG , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin Content-Transfer-Encoding: quoted-printable Message-Id: <89D77BF5-C9A0-45ED-ABAA-AE2207104D2B@brianrosen.net> References: <158319820318.27328.12390339422433838277@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Ecrit] Benjamin Kaduk's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 17:56:07 -0000 In going through your comments a couple say something I=E2=80=99m not = sure if I need to do anything with: > Additionally, if an entity cannot or chooses not to process the = alert > message from a SIP request, a 500 (Server Internal Error) SHOULD be > used with or without a configurable Retry-After header field. >=20 > I don't think I understand when it's recommended to use 500 vs 425 = (and > vice versa). In SIP and HTTP, 400 series errors are used when the client sends you = something the server doesn=E2=80=99t accept 500 series errors are used when the server itself has a problem. If the server cannot or will not process the alert even though the = request is valid, then 500 is appropriate. Do I really need to say that? > It's probably worth mentioning RFC 3428's note about: >=20 > % The size of MESSAGE requests outside of a media session MUST NOT > % exceed 1300 bytes, unless the UAC has positive knowledge that the > % message will not traverse a congestion-unsafe link at any hop, or > % that the message size is at least 200 bytes less than the lowest = MTU > % value found en route to the UAS >=20 > since that seems to still apply here. This is a SIP extension, 3261 has stuff about mtu, and SIP = implementations battle mtu issues all the time. There are no special = considerations here, just worth pointing out that the CAP message could = add to their woes. > In addition to the desire to perform identity-based access control, > the classic communication security threats need to be considered, > including integrity protection to prevent forgery or replay of alert > messages in transit. To deal with replay of alerts, a CAP document > contains the mandatory , , elements and = an > optional element. Together, these elements make the CAP > document unique for a specific sender and provide time restrictions. > An entity that has already received a CAP message within the > indicated timeframe is able to detect a replayed message and, if the > content of that message is unchanged, then no additional security >=20 > Is *able* to detect, sure. But is it recommended to do so? Required? It says =E2=80=9Cno additional vulnerability is created=E2=80=9D. It = could happen legitimately, so normative text is needed. But the = information COULD be used to detect bad guys. I don=E2=80=99t see what = text I could add that would help. >=20 > vulnerability is created. Additionally, it is RECOMMENDED to make > use of SIP security mechanisms, such as the SIP Identity PASSporT > [RFC8225], to tie the CAP message to the SIP message. To provide >=20 > Not required? Please describe the risks of not doing so (whether > directly or by reference). The risks are listed at the beginning of this paragraph. STIR isn=E2=80=99= t widely deployed yet, you can=E2=80=99t require it, and even if = deployed, it may not be passed to the PSAP. I think the RECOMMENDED is = correct > On Mar 2, 2020, at 8:16 PM, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-ecrit-data-only-ea-21: Discuss >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I support Roman's Discuss (and comment) and will expound on his first > point some more. >=20 > The use of URIs to refer to remote content, potentially hosted on a > third party, has numerous security considerations, some better known > than others. We need to reference the security considerations of RFC > 3986 to get some coverage of these, such as the "reliability and > consistency" point. >=20 > One of the more subtle security considerations of using a URI to a > remote resource as part of a request in cases such as this, is that = the > binding between the identity of the entity referring to the remote URI > and the identity of the site providing the corresponding resource = (i.e., > the authority compoent of the URI) is not always clear. Although RFC > 7852 requires TLS mutual authentication and HTTPS transport for > information provided by reference, it makes no statement requiring the > TLS server certificate to correspond to the SIP initiator, or any = other > indication of authorization that the indicated resource makes sense as > part of the indicated request. >=20 > I also have two other Discuss-level points: >=20 > We discuss the use of timestamps in protocol elements for detecting > replay; this requires that all participants have (secure and) accurate > time. We need to document this dependency on accurate time, and > optionally point out that common internet time protocols such as NTP = are > not particularly secure at present. >=20 > I'm also not sure where there's existing treatment of using SIP = MESSAGEs > as a DoS attack vector; that seems particularly pronounced in the > emergency-services case since emergency messages may receive > preferential treatment from the network. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Introduction (and Abstract?) >=20 > medical monitors. These messages may be one-shot alerts to = emergency > authorities and do not require establishment of a session. These > type of interactions are called 'non-interactive emergency calls'. >=20 > Is this an existing/widespread definition or one new to this document? > It may be worth providing a reference or rewording to clarify that it = is > a new definition. >=20 > Section 2 >=20 > CID is Content InDirection [RFC2392] >=20 > The string "InDirection" does not appear in RFC 2392. >=20 > Section 4.1 >=20 > A CAP message may be sent in the initial message of any SIP > transaction. However, this document only addresses sending a CAP > message in a SIP MESSAGE transaction for a one-shot, non-interactive > emergency call. Behavior with other transactions is not defined. >=20 > I suggest rephrasing to "A CAP message is sent in the initial message = of > a SIP transaction" to avoid potential concerns about inconsistency > between "may be sent" and "not defined". >=20 > the CAP message. Alternatively, the Call-Info header field may > contain a Content Indirect url [RFC2392] and the CAP message = included >=20 > nit: "Indirect" here vs. "InDirection" in Section 2 >=20 > Section 4.2 >=20 > field. If there is a need to copy the PIDF-LO structure > referenced by 'geolocation' to , implementers must be aware >=20 > When might this occur? (It seems almost out of scope for this = document > based on my limited understanding.) >=20 > that is limited to a circle or polygon, and conversion of > other shapes will be required. Points SHOULD be converted to a > circle with a radius equal to the uncertainty of the point. Arc- > bands and ellipses SHOULD be converted to an equivalent polygon. > 3D locations SHOULD be converted to their equivalent 2D forms. >=20 > nit: what is an "equivalent" polygon to an ellipse or arc-band? In a > mathematical sense it might mean "strict equivalence" or a large-n = limit > of an n-gon, or perhaps there is a corresponding uncertainty on the > ellipse/arc-band that the polygon must stay within? Rewording to > "corresponding" might be an easy fix. >=20 > Section 5.1 >=20 > The 425 response code is a rejection of the request due to its > included alert content, indicating that it was malformed or not > satisfactory for the recipient's purpose. >=20 > A SIP intermediary can also reject an alert it receives from a User > Agent (UA) when it detects that the provided alert is malformed. >=20 > (I assume there's an implicit "reject with this code" in here.) >=20 > It is only appropriate to generate a 425 response when the = responding > entity has no other information in the request that is usable by the > responder. >=20 > I'm not sure I'm parsing this sentence correctly. My best guess is = that > it's saying "if there's anything in the request that you can respond = to, > don't use 425, even if there's some malformed CAP", but that doesn't > really seem to be what the actual words are saying. [Section 5.2 = seems > to support my guess.] >=20 > Section 5.2 >=20 > message-header /=3D AlertMsg-Error > ; (message-header from 3261) >=20 > nit: mybe "RFC3261" to match the later comments? >=20 > wrong with the alert in the request. This error code has a >=20 > pedantic nit: the ABNF has 1-to-3-digit >=20 > standardized -- meaning an operator can change the strings -- but > MUST NOT change the meaning of the error code. Similar to how RFC > 3261 specifies, there MUST NOT be more than one string per error > code. >=20 > RFC 3261 is ... pretty long. Maybe throw us a bone with a section > reference? Also, I assume this "MUST NOT be more than one" is within = a > single AlertMsg-Error construction, since a truly global = interpretation > would mean that (since this document assigns strings) there cannot > actually be changes made to the strings by an operator, which we just > said is possible. >=20 > This document defines an initial list of AlertMsg-Error values for > any SIP response, including provisional responses (other than 100 > Trying) and the new 425 response. There MUST be no more than one > AlertMsg-Error code in a SIP response. AlertMsg-Error values sent = in >=20 > Is this redundant with the "MUST NOT" I was asking about above? >=20 > Additionally, if an entity cannot or chooses not to process the = alert > message from a SIP request, a 500 (Server Internal Error) SHOULD be > used with or without a configurable Retry-After header field. >=20 > I don't think I understand when it's recommended to use 500 vs 425 = (and > vice versa). >=20 > Section 7 >=20 > It's probably worth mentioning RFC 3428's note about: >=20 > % The size of MESSAGE requests outside of a media session MUST NOT > % exceed 1300 bytes, unless the UAC has positive knowledge that the > % message will not traverse a congestion-unsafe link at any hop, or > % that the message size is at least 200 bytes less than the lowest = MTU > % value found en route to the UAS >=20 > since that seems to still apply here. >=20 > Section 8 >=20 > I'd consider using a more recent date than 2008-11-19 for the example > time. Also, why is the timestamp in the additional information > 2010-11-14, almost two years later? >=20 > 32.86726 -97.16054 >=20 > Is that ... someone's house? Maybe some different coordinates would = be > more appropriate. >=20 > Figure 3 has "Content-Disposition: by-reference;handling=3Doptional" = but > Figure 4 does not; is that significant? >=20 > Section 9 >=20 > In any case, for alerts initiated by sensors, the identity could = play > an important role in deciding whether to accept or ignore an = incoming > alert message. With the scenario shown in Figure 1 it is very = likely > that only authenticated sensor input will be processed. For this > reason, it needs to be possible to refuse to accept alert messages > from an unknown origin. Two types of information elements can be > used for this purpose: >=20 > 1. SIP itself provides security mechanisms that allow the > verification of the originator's identity, such as P-Asserted- > Identity [RFC3325] or SIP Identity [RFC8224]. The latter > provides a cryptographic assurance while the former relies on a > chain of trust model. These mechanisms can be reused. >=20 > 2. CAP provides additional security mechanisms and the ability to > carry further information about the sender's identity. > Section 3.3.4.1 of [cap] specifies the signing algorithms of CAP > documents. >=20 > I'd consider adding a note that "the specific policy and mechanisms = used > in a given deployment are out of scope for this document", since the > actual requirements in practice are so broad that we cannot really = make > detailed recommendations here. >=20 > In addition to the desire to perform identity-based access control, > the classic communication security threats need to be considered, > including integrity protection to prevent forgery or replay of alert > messages in transit. To deal with replay of alerts, a CAP document > contains the mandatory , , elements and = an > optional element. Together, these elements make the CAP > document unique for a specific sender and provide time restrictions. > An entity that has already received a CAP message within the > indicated timeframe is able to detect a replayed message and, if the > content of that message is unchanged, then no additional security >=20 > Is *able* to detect, sure. But is it recommended to do so? Required? >=20 > vulnerability is created. Additionally, it is RECOMMENDED to make > use of SIP security mechanisms, such as the SIP Identity PASSporT > [RFC8225], to tie the CAP message to the SIP message. To provide >=20 > Not required? Please describe the risks of not doing so (whether > directly or by reference). >=20 > protection of the entire SIP message exchange between neighboring = SIP > entities, the usage of TLS is REQUIRED. >=20 > Just to check: this is a 100% always, for everyone, "REQUIRED", not = just > in the subset of cases where protection of the entire exchange is > desired? >=20 > Note that none of the security mechanism in this document protect > against a compromised sensor sending crafted alerts. Privacy > provided for any emergency calls, including non-interactive = messages, > is subject to local regulations. >=20 > I suggest using "confidentiality protection" rather than "privacy" > (unless it's a term of art in this field), to avoid confusion with... > Privacy considerations for alerts (e.g., generated by sensors) that > should be discussed. RFC 7852 has some extensive privacy = considerations > that can be referenced to do the bulk of the work here. >=20 > I'd also consider reiterating the opportunistic nature of = cryptographic > protection on emergency messages, as discussed in 6443 (since insecure > emergency messaging is preferred to no emergency messaging), but this = is > not strictly speaking required. >=20 > Section 12.2 >=20 > RFC 8225, as a RECOMMENDED feature, is more properly listed as a > normative reference, per > = https://www.ietf.org/about/groups/iesg/statements/normative-informative-re= ferences/ >=20 >=20 >=20 From nobody Mon Mar 9 12:28:01 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5DF3A1551; Mon, 9 Mar 2020 12:27:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ecrit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ecrit@ietf.org Message-ID: <158378207318.5651.16523812139239126646@ietfa.amsl.com> Date: Mon, 09 Mar 2020 12:27:53 -0700 Archived-At: Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-22.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 19:27:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies WG of the IETF. Title : Non-Interactive Emergency Calls Authors : Brian Rosen Henning Schulzrinne Hannes Tschofenig Randall Gellens Filename : draft-ietf-ecrit-data-only-ea-22.txt Pages : 24 Date : 2020-03-09 Abstract: Use of the Internet for emergency calling is described in RFC 6443, 'Framework for Emergency Calling Using Internet Multimedia'. In some cases of emergency calls, the transmission of application data is all that is needed and no interactive media channel is established: a situation referred to as 'non-interactive emergency calls', where, unlike most emergency calls, there is no two way interactive media such as voice or video or text. This document describes use of a SIP MESSAGE transaction that includes a container for the data based on the Common Alerting Protocol (CAP). That type of emergency request does not establish a session, distinguishing it from SIP INVITE, which does. Any device that needs to initiate a request for emergency services without an interactive media channel would use the mechanisms in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-22 https://datatracker.ietf.org/doc/html/draft-ietf-ecrit-data-only-ea-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-data-only-ea-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 14:05:47 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA9C3A1742 for ; Mon, 9 Mar 2020 14:05:44 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 cEvcOfZWDDkg for ; Mon, 9 Mar 2020 14:05:42 -0700 (PDT) Received: from mail-yw1-xc44.google.com (mail-yw1-xc44.google.com [IPv6:2607:f8b0:4864:20::c44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D87A3A1717 for ; Mon, 9 Mar 2020 14:05:42 -0700 (PDT) Received: by mail-yw1-xc44.google.com with SMTP id t141so11583063ywc.11 for ; Mon, 09 Mar 2020 14:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Pl75FEg+I+xnUg7RVyjOwvqtGHj+rNalEvaETTDnQGw=; b=xlGdiGVRw7R3MwpkvWDoLvWXzd6+FeZGl/sJt2MaKS9X8g69hs2RlnrLV0gFXPOCcl oNlKL7OoNDI5o5ahIvdjdibrbYb+a4zt6UGiB+whxDKjfTk5/+JblnkbIgf/yYM22ggI mPiG6fb4Ahujjt9Zek7sG4P/0RVVCzxKVnK1TeV5ie73vDNzyeILAzzG4m0EruVRq+lZ ppCJyUqTfHoOhrOTrET56i5gzMtHqxmAR6sC51a8TsFowmfojya3W5i9dr9/ZCPdaLRP eIETNXPmm907UvMC4QgB5dVH0zBjFru/g0sKLrJjxHBA6JtTS+GjiiI1MYm7Y9BGEeoI VvbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Pl75FEg+I+xnUg7RVyjOwvqtGHj+rNalEvaETTDnQGw=; b=jitNT4sMqJtMA+5Wwwt92eJsrggpPYPkciAde8MFjor47DnnWVCHsVnAbTwkf5W83I HXmGSX2nzWvziUudE4Vd3BuG8Jv1M5AA3iGkjTTP8gZDHu0azEhBrPpoY84AkaMseFja 1lO67I+q5cgRbAkRmYzqcVoyeMIbEDo8C7UvLb7v1vhIkEXA2C5tYMEhbJTIYrkKn94t d64ySsEgF1c9W6ZHd4ov7w9osJADUf8ql5r8dvNHsN56qucxBJzWQ/ctgQfiHkn0h/Vl nnG9B5TH5W2vSnu7JMNFT2js8Isn9zljXRut9rP2RDRr0ZLNQDDWALBxzD5XtGuqKDMv jc9g== X-Gm-Message-State: ANhLgQ2oQKPz4G45PRdIngh16JSiNoJsK6hxjm78rSJGDH8NeE0aoGws KMlatS1l8EwharVJkNi83BiWLg== X-Google-Smtp-Source: ADFU+vuTkfxdTSBN79HOoplxwvBHW5wPrIr+mhrFRbnOigoMKRuMKphwNUm5Cs1whBCx9DSPSszRGQ== X-Received: by 2002:a0d:c487:: with SMTP id g129mr19861097ywd.366.1583787941243; Mon, 09 Mar 2020 14:05:41 -0700 (PDT) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id u84sm3515609ywb.26.2020.03.09.14.05.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2020 14:05:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Brian Rosen In-Reply-To: <158250533653.1160.12882300058392230264.idtracker@ietfa.amsl.com> Date: Mon, 9 Mar 2020 17:05:38 -0400 Cc: The IESG , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin Content-Transfer-Encoding: quoted-printable Message-Id: References: <158250533653.1160.12882300058392230264.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Ecrit] Barry Leiba's No Objection on draft-ietf-ecrit-data-only-ea-21: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 21:05:45 -0000 -22 addresses your comments, I hope. https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-22 Brian > On Feb 23, 2020, at 7:48 PM, Barry Leiba via Datatracker = wrote: >=20 > Barry Leiba has entered the following ballot position for > draft-ietf-ecrit-data-only-ea-21: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for this document. I have only a few editorial comments: >=20 > The Abstract strikes me as a bit long =E2=80=94 certainly not = ridiculously so, but > longer than necessary for an abstract. Much of the information there, = useful > as it be, is stuff for an Introduction, not an Abstract. Clearly, = this is > entirely up to the working group, and this is just a minor comment. = In case > you find it useful, here=E2=80=99s what I would do with the Abstract = for this: >=20 > NEW > Use of the Internet for emergency calling is described in RFC 6443, = 'Framework > for Emergency Calling Using Internet Multimedia=E2=80=99. In some = cases of emergency > calls, the transmission of application data is all that is needed and = no > interactive media channel is established =E2=80=94 a situation = referred to as > non-interactive emergency calls. This document describes use of a SIP = MESSAGE > transaction that includes a container for the data based on the Common = Alerting > Protocol (CAP). That type of emergency request does not establish a = session, > distinguishing it from SIP INVITE, which does. Any device that needs = to > initiate a request for emergency services without an interactive media = channel > would use the mechanisms in this document. END >=20 > =E2=80=94 Section 1 =E2=80=94 >=20 > Examples of such > environments includes sensors issuing alerts, or certain types of > medical monitors. >=20 > Nit: Examples =E2=80=9Cinclude=E2=80=9D. And plural =E2=80=9Cexamples=E2= =80=9D needs =E2=80=9Cand=E2=80=9D, not =E2=80=9Cor=E2=80=9D. >=20 > These > type of interactions >=20 > Nit: These =E2=80=9Ctypes=E2=80=9D >=20 > Non-Interactive emergency calls are similar to regular emergency >=20 > In the previous paragraph you didn=E2=80=99t capitalize = =E2=80=9Cinteractive=E2=80=9D; usage should be > consistent. >=20 > calls in the sense that they require the emergency indications, > emergency call routing functionality and may even have the same > location requirements. >=20 > The third item isn=E2=80=99t parallel to the first two. >=20 > NEW > calls in the sense that they require the emergency indications, > they require emergency call routing functionality, and they may > even have the same location requirements. > END >=20 > This document is concerned with > citizen to authority "alerts", where the alert >=20 > =E2=80=9Ccitizen-to-authority=E2=80=9D, as it=E2=80=99s a compound = modifier. But shouldn=E2=80=99t it be > =E2=80=9Cauthority-to-citizen=E2=80=9D anyway? >=20 > (a URI is included in the message, which when dereferenced returns > the CAP message). >=20 > This sounds as if it=E2=80=99s the message that=E2=80=99s = dereferenced. This reads better (and > is also in active voice): >=20 > NEW > (the message includes a URI that, when dereferenced, returns > the CAP message). > END >=20 > alert specific data beyond that available in the CAP message. >=20 > Nit: =E2=80=9Calert-specific=E2=80=9D >=20 > =E2=80=94 Section 3 =E2=80=94 >=20 > 2. Establishing a third-party initiated emergency call >=20 > Nit: =E2=80=9Cthird-party-initiated=E2=80=9D >=20 > to determine the next hop proxy to route the alert message to. >=20 > Nit: =E2=80=9Cnext-hop proxy=E2=80=9Dx >=20 > relationship between the originator and the receiver, e.g., a PSAP. > A PSAP, for example, is likely to receive and accept alerts from >=20 > The double =E2=80=9Cfor example, PSAP=E2=80=9D structure feels odd. I = would just remove =E2=80=9C, > e.g., a PSAP=E2=80=9D and let the =E2=80=9CA PSAP, for example,=E2=80=A6= =E2=80=9D take care of it. >=20 > =E2=80=94 Section 4.2 =E2=80=94 >=20 > given combination. Note that the > element is optional and may not be present. >=20 > A minor thing that you can ignore if you disagree with: I think = =E2=80=9Cmight not be > present=E2=80=9D is less likely to be confused with a BCP 14 =E2=80=9CMA= Y=E2=80=9D in this sentence > construction. >=20 > Arc- > bands and ellipses SHOULD be converted to an equivalent polygon. > 3D locations SHOULD be converted to their equivalent 2D forms. >=20 > Can they really be made =E2=80=9Cequivalent=E2=80=9D? Or do we really = mean something like this > (also correcting the number-agreement problem in the first sentence)?: >=20 > NEW, maybe? > Arc- > bands and ellipses SHOULD be converted to polygons with similar > coverage, and 3D locations SHOULD be converted to 2D forms with > similar coverage. > END >=20 > =E2=80=94 Section 5.2 =E2=80=94 >=20 > For > example, a UA includes an alert in a MESSAGE to a PSAP. >=20 > Nit: I would say, =E2=80=9CFor example, suppose a UA includes=E2=80=A6=E2= =80=9D >=20 > A SIP intermediary that requires the UA's alert message in order to > properly process the transaction may also sends a 425 with an >=20 > Nit: =E2=80=9Cmay also send a 425=E2=80=9D >=20 > There MUST be no more than one > AlertMsg-Error code in a SIP response. >=20 > I find =E2=80=9CMUST=E2=80=9D with a negative statement to be awkward, = especially when it=E2=80=99s > easily avoided; it=E2=80=99s OK, of course, if you disagree. I = suggest this: >=20 > NEW > There MUST NOT be more than one > AlertMsg-Error code in a SIP response. > END >=20 > [RFC3262]; or, if that mechanism is not negotiated, it must be >=20 > Nit: remove =E2=80=9Cit=E2=80=9D. >=20 > =E2=80=94 Section 7 =E2=80=94 >=20 > The CAP message itself can be sent by-reference > using this mechanism, as well as any or all of the Additional Data > blocks that may contain sensor-specific data. >=20 > This structure makes the antecedent to =E2=80=9Cas well as=E2=80=9D = ambiguous (it looks like > it=E2=80=99s =E2=80=9Cthis mechanism=E2=80=9D, but it=E2=80=99s not). = I suggest this (which also removes the > stray hyphen from =E2=80=9Cby reference=E2=80=9D): >=20 > NEW > The CAP message itself can be sent by reference > using this mechanism, as can any or all of the Additional Data > blocks that may contain sensor-specific data. > END >=20 > =E2=80=94 Section 9 =E2=80=94 >=20 > Location specific > threats are not unique to this document >=20 > Nit: hyphenate =E2=80=9CLocation-specific=E2=80=9D >=20 > reason, it needs to be possible to refuse to accept alert messages > from an unknown origin. >=20 > Nit: =E2=80=9Cfrom unknown origins=E2=80=9D >=20 > Note that none of the security mechanism in this document protect >=20 > Nit: =E2=80=9Cmechanisms=E2=80=9D >=20 > =E2=80=94 Section 10.1 =E2=80=94 >=20 > Please use =E2=80=9Cmedia type=E2=80=9D, not =E2=80=9CMIME type=E2=80=9D= nor =E2=80=9CMIME media type=E2=80=9D. >=20 > Please check the registration template in RFC 6838, Section 5.6, and = align with > it (there are just slight variations that will be easy to sort out). >=20 >=20 >=20 From nobody Mon Mar 9 14:06:14 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E2F3A173B for ; Mon, 9 Mar 2020 14:06:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 QE0wOnENKhAT for ; Mon, 9 Mar 2020 14:06:06 -0700 (PDT) Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5033A1739 for ; Mon, 9 Mar 2020 14:06:06 -0700 (PDT) Received: by mail-yw1-xc29.google.com with SMTP id x5so10737574ywb.13 for ; Mon, 09 Mar 2020 14:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZTFsZCrhcOQyuMh6hcr9VTmjc9WTV8GzGfZRPoleoyo=; b=f801WD7vZ+3BGpBYEGyv2h95QXJyZ4ZA4a3UWgERsDHoX4sz7CrakN1sHCyfEszaEa 5SLhMphWsy1iqoiHUtuXGoknjEVyAPEXf5FQG9HGo99CVkoaZYL7HPHlTjbHeg6/38Cb TfCDG2qahh/4bY9dKd8FwAJTCp6YCtq5svHl4ay6N8CpV23ohfBQOVKtRxVkiJrcL2rq AliGexf4Q9jUOn0rkplAkp5hk0Vw5cV84r2fHT/1FAXj8M4s/VGJGyl8jLIP3XOnQhEt MMOczX2JuIhoY0Ovr5jFtN6mj/AIqNmKaImwDJkLBSnORWdoOD0mIbmfoiD94EOAdwV6 unMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZTFsZCrhcOQyuMh6hcr9VTmjc9WTV8GzGfZRPoleoyo=; b=CT8Ej5ymCOh3hvSDfYmX6NnQ4FEiTii6y+r3idQPAc9cpTnU7QDpQZKva8yXP03HIx lHbae2DwCDaq7K2WY4MuAgaIXNJf5vveyeHb6ejZ0cDiOBr4WtwNHmSAl/4IFtjtq0L0 J28djNIg/asS5f97uP5UqTcI3Le1KnpTE25VAo5dCh5fYzaN3BgUKXS/vgO6EO5GJ+vq +yLqcxNRs2sPH/jWkMVOmMD+KwOb5yOgzZdhm/Suq4yFjJ3s5CTEz9nWxhzQSdVfc0++ MN073lwNxSN7w/SuAgLZ1Qg8svM+R3rS35wHpjCjLrQxPhha6Kbq6BIlYcQFLM1LahQf /92A== X-Gm-Message-State: ANhLgQ0PDQCcfD+eEsOSdIkk/k+ZIeNLOO1q4VtP+g1FutxcqUjUm3rN LDKJR/ihckpd2i494OJtzCE31Q== X-Google-Smtp-Source: ADFU+vse2N+PnQnp1IEz/JqxAaWq8qJ2MMqJolss6i0N3wgiO05z6oeklXGoMZIoQR2VHmbmsdHlpQ== X-Received: by 2002:a81:380b:: with SMTP id f11mr18667904ywa.145.1583787965068; Mon, 09 Mar 2020 14:06:05 -0700 (PDT) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id u84sm3515609ywb.26.2020.03.09.14.06.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2020 14:06:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Brian Rosen In-Reply-To: <158291422008.22449.8600928959018481644@ietfa.amsl.com> Date: Mon, 9 Mar 2020 17:06:03 -0400 Cc: The IESG , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin Content-Transfer-Encoding: quoted-printable Message-Id: References: <158291422008.22449.8600928959018481644@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Ecrit] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-ecrit-data-only-ea-21=3A_=28with_COMMENT=29?= X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 21:06:09 -0000 -22 fixes your comments, I hope: https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-22 > On Feb 28, 2020, at 1:23 PM, Mirja K=C3=BChlewind via Datatracker = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-ecrit-data-only-ea-21: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > One question: Should non-inactive SIP MESSAGEs be rated-limited = somehow or it > that already specified in the SIP spec (sorry don't know that by heart = ;-)? If > so a pointer would probably be good. Or maybe another thing to add to = section 7 > (or a subsection or an own section) or alternatively to the security > considerations section I guess. >=20 > One small comment/nit: > Sec 5.2: > "AlertMsg-Error values sent in > provisional responses must be sent using the mechanism defined in > [RFC3262]; or, if that mechanism is not negotiated, it must be > repeated in the final response to the transaction." > Maybe two times MUST? >=20 >=20 >=20 From nobody Mon Mar 9 14:07:08 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FBA3A1790 for ; Mon, 9 Mar 2020 14:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 W258vguxEOvf for ; Mon, 9 Mar 2020 14:06:52 -0700 (PDT) Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C6A3A1768 for ; Mon, 9 Mar 2020 14:06:52 -0700 (PDT) Received: by mail-yw1-xc2a.google.com with SMTP id x5so10739730ywb.13 for ; Mon, 09 Mar 2020 14:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6SOk8UGofwUYFpuqilD6cpVaXOQB1MOodJk5/atDOSQ=; b=1DcfTt6rn2cdpiFE10PcCd8jUgpOB5HeV7+0ZeAbbfDKQaC0DDtN2NdwaPhbgQNaXm ax0wF2CMEoPYiF8pLQabMNw2SHiuAWTO21VAnVw9E+9D3C7iZ0CrohXnYUQ8u4F1tFkN WBCZcvVTkbWQ84SbocTf+yZsnJhNPbBz+bjz74BFekBL/ewBBj7b858McNm58CJs9ApT XkqZMlMHgyK1sEGR4weToVYj56TB0Fg4OLlT5l6CIzMMKWCgvwCcEjUJ96WgjohQeDDU 8q2KjbVJyFafAx7ENeJ4APYWCfYjBFpYKaYuAni20Trcf/n7GD9ThP/iT5fFzpyOJOCL n5Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6SOk8UGofwUYFpuqilD6cpVaXOQB1MOodJk5/atDOSQ=; b=uXFvXDKTxpiTXr9fWSuGHHUYmEM+LrxIJ5COEhgzw8Wo1A1cikiRt3E4XP/NNWHLfh 2Rh74s7bkpa9PXhHGAEkYUtb3TufsfaIG2rfwzFoLFbkFqy/9OuiHCFMpmkQoeKZpJI8 AXOwq2KxJiHtstpvgMwukg5QAs57qbsDTZimqGS161WPDQ2AQ7A9K+cW4CdJM5m4KODL vLIbP8dJZnP6oskaoJSMma7TVkK+FpM1+xAm5Hc4m6ic/z90QUPIQkqV9DTI6jwTyLk3 HsO1CNwY+pkl7uux4TvvR1ovGkCIDkNTbYE4Jfs4mmTIW/Iea9He2HeeFDDyIOL1GC9t PR7g== X-Gm-Message-State: ANhLgQ2/XS9KReapfE19+cj05Y0YU4xrRYfJsvnYlq7MWsdXtdYMboU7 eOKT/8XnUE1TF5/PKXtGu5qhp2Agf/uEsg== X-Google-Smtp-Source: ADFU+vtYh107FgIgDJXiSd/sysKL7LX+2jpTc0A9pExTJuXqc5SCPHr/P2UqlUriBrLJovOB0AXOHA== X-Received: by 2002:a81:4ed8:: with SMTP id c207mr20187955ywb.188.1583788010928; Mon, 09 Mar 2020 14:06:50 -0700 (PDT) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id u84sm3515609ywb.26.2020.03.09.14.06.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2020 14:06:50 -0700 (PDT) From: Brian Rosen Message-Id: <14047770-28BE-4EB2-8866-D12D5B5C3771@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_D91AEEBC-CC05-48FC-AB6A-036422147861" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Mon, 9 Mar 2020 17:06:49 -0400 In-Reply-To: <4C966190-8F2F-42EB-BD24-60D90C86F2EA@brianrosen.net> Cc: Adam Roach , The IESG , Allison Mankin , "ecrit-chairs@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-data-only-ea@ietf.org" To: Roman Danyliw References: <158318494177.27467.10769075669362560529@ietfa.amsl.com> <227ba0d7-8ace-2ad2-c28c-e74996210c4e@nostrum.com> <359EC4B99E040048A7131E0F4E113AFC0216F60CEA@marchand> <4C966190-8F2F-42EB-BD24-60D90C86F2EA@brianrosen.net> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Ecrit] Roman Danyliw's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 21:07:03 -0000 --Apple-Mail=_D91AEEBC-CC05-48FC-AB6A-036422147861 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I hope I got all your comments fixed in -22 https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-22 Brian > On Mar 2, 2020, at 5:24 PM, Brian Rosen wrote: >=20 > I=E2=80=99ll add Adam=E2=80=99s suggested language. >=20 > WRT the first issue: URIs to untrusted entities, I note that there is = no discussion of untrusted entities in Section 7 of RFC 3986. There is = discussion of misleading URIs. If I added text to the security section = that read: >=20 > When the CAP message is passed by reference, the recipients of the = MESSAGE may not have a trust relationship with the sender. Recipients = MUST take precautions in retrieving the CAP message because the URI may = point to a malicious actor. =20 >=20 > Would that satisfy your concerns? >=20 > I will also fix the nits. >=20 >> On Mar 2, 2020, at 4:51 PM, Roman Danyliw > wrote: >>=20 >> Hi Adam! >>=20 >>> -----Original Message----- >>> From: Adam Roach > >>> Sent: Monday, March 02, 2020 4:45 PM >>> To: Roman Danyliw >; The IESG = > >>> Cc: allison.mankin@gmail.com ; = ecrit-chairs@ietf.org ; ecrit@ietf.org = ; draft- >>> ietf-ecrit-data-only-ea@ietf.org = >>> Subject: Re: Roman Danyliw's Discuss on = draft-ietf-ecrit-data-only-ea-21: >>> (with DISCUSS and COMMENT) >>>=20 >>> On 3/2/2020 3:35 PM, Roman Danyliw via Datatracker wrote: >>>> Section 9. Per =E2=80=9CTo provide protection of the entire SIP = message >>>> exchange between neighboring SIP entities, the usage of TLS is >>>> REQUIRED.=E2=80=9D, can you please provide guidance on how to use = TLS. >>>=20 >>>=20 >>> I think the strong implication here is that TLS is to be used in the = same way >>> that TLS is used in other SIP applications (in the same way that an = HTTP >>> document saying "MUST use TLS" is pretty clearly saying to use HTTPS = as per >>> the existing HTTP RFCs). >>>=20 >>> Unfortunately, the TLS handling for SIP is mixed into RFC 3261 all = _over_ the >>> place, so there's not anything particularly comprehensive to point = to. The >>> best that I think could be said would be something along the lines = of "...the >>> usage of TLS, as described in section 26 of [RFC3261], is REQUIRED." >>>=20 >>> Would that satisfy your concern? >>=20 >> I can appreciate this difficulty. Sounds good to me.=20 >>=20 >> Roman >=20 --Apple-Mail=_D91AEEBC-CC05-48FC-AB6A-036422147861 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = hope I got all your comments fixed in -22
https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-22

Brian

On Mar 2, 2020, at 5:24 PM, Brian Rosen <br@brianrosen.net> = wrote:

I=E2=80=99ll add = Adam=E2=80=99s suggested language.

WRT the first issue: URIs to untrusted = entities, I note that there is no discussion of untrusted entities in = Section 7 of RFC 3986.  There is discussion of misleading URIs. =  If I added text to the security section that read:

When the = CAP message is passed by reference, the recipients of the MESSAGE may = not have a trust relationship with the sender.  Recipients MUST = take precautions in retrieving the CAP message because the URI may point = to a malicious actor.  

Would that satisfy your = concerns?

I = will also fix the nits.

On Mar = 2, 2020, at 4:51 PM, Roman Danyliw <rdd@cert.org> wrote:

Hi Adam!

-----Original Message-----
From: Adam Roach = <adam@nostrum.com>
Sent: Monday, March = 02, 2020 4:45 PM
To: Roman Danyliw <rdd@cert.org>; The IESG = <iesg@ietf.org>
Cc: allison.mankin@gmail.com; ecrit-chairs@ietf.org; ecrit@ietf.org; draft-
ietf-ecrit-data-only-ea@ietf.org
Subject: = Re: Roman Danyliw's Discuss on draft-ietf-ecrit-data-only-ea-21:
(with DISCUSS and COMMENT)

On = 3/2/2020 3:35 PM, Roman Danyliw via Datatracker wrote:
Section 9.  Per = =E2=80=9CTo provide protection of the entire SIP message
exchange between neighboring SIP entities, the usage of TLS = is
REQUIRED.=E2=80=9D, can you please provide guidance on = how to use TLS.


I= think the strong implication here is that TLS is to be used in the same = way
that TLS is used in other SIP applications (in the = same way that an HTTP
document saying "MUST use TLS" is = pretty clearly saying to use HTTPS as per
the existing = HTTP RFCs).

Unfortunately, the TLS handling = for SIP is mixed into RFC 3261 all _over_ the
place, so = there's not anything particularly comprehensive to point to. The
best that I think could be said would be something along the = lines of "...the
usage of TLS, as described in section 26 = of [RFC3261], is REQUIRED."

Would that = satisfy your concern?

I can appreciate this difficulty.  Sounds good to = me. 

Roman


= --Apple-Mail=_D91AEEBC-CC05-48FC-AB6A-036422147861-- From nobody Mon Mar 9 14:07:23 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503F63A0A15 for ; Mon, 9 Mar 2020 14:07:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 KXUAMvHzmxxx for ; Mon, 9 Mar 2020 14:07:18 -0700 (PDT) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF483A17A3 for ; Mon, 9 Mar 2020 14:07:18 -0700 (PDT) Received: by mail-yw1-xc2c.google.com with SMTP id x5so10740948ywb.13 for ; Mon, 09 Mar 2020 14:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=70aaxptEIjCBOEAikwDDizP3vYOAvCcZuvuXCkFqNJk=; b=R5u0W8Uqb4b6AQ4y44hrgds10foSw3p80KtJnMFRJfhojuNObAJ4zfzM4tOrcs+1jK Xe31rpKGac/jTD0lZE1EmG7MhjLzawOLOdQWlM3GfCO/lqwJ3dgYEuVfR/jpw7BBWoql pHRizus7VgtrFszTLOcOEBQ5mFIueHJahKlrfDJeJMhrnx1PgpGlvF4Kqw1m78Vxv7qS jdUPGcw9igJeX2sONOlGXzfvMR0pojwA/8TIXv3MWSAVKsMpaCSQW6OQjogn4sKp4Pw7 Rby7nK73Ui7iUtACYPXaxYHYSb4b4zHLv2ane63CYiL+qUvj1mgo4u1KPcwl7keXVDLw hcxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=70aaxptEIjCBOEAikwDDizP3vYOAvCcZuvuXCkFqNJk=; b=EZzatKBgEqcfJekuExUMGVSyOU20s94okwZsRs5MDjEFE9Gr3aj6GNR8GekB6B2Pi6 X0knLzdlAOT7YwNLxN7Uurhhc6SwXsgD9yFMMwBLd/4IVqqDBrd4sLXGL2hjDhVOAW1B 7P+6YUgF/uQLi1Xtqw/MGMbcGgtWu4ZapsbOZvcvMNgatWzG5NiT92IKHILu1GJu04RF 3d6WvwmtpXvt5aR0ek5GmFxXxX5whd5UFdA3NlRx0h7bZy6MBXExUC0dA0LXvJ/6bzNs 210beTmi32RDVwMM46vfKVRSMeO81hMYJfDb8EsHFTk90MFi467quwdEY2tR+nNE2/SK KgVQ== X-Gm-Message-State: ANhLgQ39QRabRbXQnGQrN+xwH9rc0iq5CL3KU5bBLk0a75t/3eOdrKTG X2+065+v5Ntq7eWNhalRHTpWSg== X-Google-Smtp-Source: ADFU+vtVoh+/GGibdr/Z8+DayRHxTQFeEhr2WIo8kJsFXMP0lPJwOyItfTs47g5qbmUwQ+MV7zUsMA== X-Received: by 2002:a25:3485:: with SMTP id b127mr20337329yba.110.1583788037749; Mon, 09 Mar 2020 14:07:17 -0700 (PDT) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id u84sm3515609ywb.26.2020.03.09.14.07.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2020 14:07:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Brian Rosen In-Reply-To: <158324748449.7657.12581369226723862050@ietfa.amsl.com> Date: Mon, 9 Mar 2020 17:07:16 -0400 Cc: The IESG , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin Content-Transfer-Encoding: quoted-printable Message-Id: <31C71CCD-0591-4130-B393-B13767B78A05@brianrosen.net> References: <158324748449.7657.12581369226723862050@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Ecrit] Alexey Melnikov's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 21:07:21 -0000 Should be fixed in -22 https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-22 > On Mar 3, 2020, at 9:58 AM, Alexey Melnikov via Datatracker = wrote: >=20 > Alexey Melnikov has entered the following ballot position for > draft-ietf-ecrit-data-only-ea-21: Discuss >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This is a tiny point, but I think it needs fixing for clarity: >=20 > 5.2. The AlertMsg-Error Header Field >=20 > error-code =3D 1*3DIGIT >=20 > The text below makes it clear that the error-code is 3 digits: >=20 > The ErrorValue contains a 3-digit error code indicating what was > wrong with the alert in the request. >=20 > What you have above allows for 1, 2 or 3 digits. I think you meant: >=20 > error-code =3D 3DIGIT >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I initially thought that error-codes are from the same namespace as = SIP Status > Codes. I think you should explicitly say that they are not. >=20 > The first mention of HTTPS needs a normative reference. >=20 > In Section 10.1: >=20 > Encoding considerations: Uses XML, which can employ 8-bit > characters, depending on the character encoding used. See > [RFC7303], Section 3.2. >=20 > This field of the form should say one of "7bit", "8bit", "binary" or = "framed". > I think in your case it is "binary", because UTF-16 charsets are not = prohibited > in your document. >=20 >=20 >=20 From nobody Tue Mar 10 04:14:44 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 311BA3A0C9D; Tue, 10 Mar 2020 04:14:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov via Datatracker To: "The IESG" Cc: draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, allison.mankin@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alexey Melnikov Message-ID: <158383887710.16672.7780715988025198120@ietfa.amsl.com> Date: Tue, 10 Mar 2020 04:14:37 -0700 Archived-At: Subject: [Ecrit] Alexey Melnikov's No Objection on draft-ietf-ecrit-data-only-ea-22: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 11:14:38 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-ecrit-data-only-ea-22: 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-ecrit-data-only-ea/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS points and comments. From nobody Tue Mar 10 10:53:15 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EED3A03FC; Tue, 10 Mar 2020 10:53:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, allison.mankin@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158386278691.16369.10286901911015179104@ietfa.amsl.com> Date: Tue, 10 Mar 2020 10:53:06 -0700 Archived-At: Subject: [Ecrit] Benjamin Kaduk's No Objection on draft-ietf-ecrit-data-only-ea-22: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 17:53:07 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-ecrit-data-only-ea-22: 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-ecrit-data-only-ea/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss points! Original (presumed stale) comments preserved below. Introduction (and Abstract?) medical monitors. These messages may be one-shot alerts to emergency authorities and do not require establishment of a session. These type of interactions are called 'non-interactive emergency calls'. Is this an existing/widespread definition or one new to this document? It may be worth providing a reference or rewording to clarify that it is a new definition. Section 2 CID is Content InDirection [RFC2392] The string "InDirection" does not appear in RFC 2392. Section 4.1 A CAP message may be sent in the initial message of any SIP transaction. However, this document only addresses sending a CAP message in a SIP MESSAGE transaction for a one-shot, non-interactive emergency call. Behavior with other transactions is not defined. I suggest rephrasing to "A CAP message is sent in the initial message of a SIP transaction" to avoid potential concerns about inconsistency between "may be sent" and "not defined". the CAP message. Alternatively, the Call-Info header field may contain a Content Indirect url [RFC2392] and the CAP message included nit: "Indirect" here vs. "InDirection" in Section 2 Section 4.2 field. If there is a need to copy the PIDF-LO structure referenced by 'geolocation' to , implementers must be aware When might this occur? (It seems almost out of scope for this document based on my limited understanding.) that is limited to a circle or polygon, and conversion of other shapes will be required. Points SHOULD be converted to a circle with a radius equal to the uncertainty of the point. Arc- bands and ellipses SHOULD be converted to an equivalent polygon. 3D locations SHOULD be converted to their equivalent 2D forms. nit: what is an "equivalent" polygon to an ellipse or arc-band? In a mathematical sense it might mean "strict equivalence" or a large-n limit of an n-gon, or perhaps there is a corresponding uncertainty on the ellipse/arc-band that the polygon must stay within? Rewording to "corresponding" might be an easy fix. Section 5.1 The 425 response code is a rejection of the request due to its included alert content, indicating that it was malformed or not satisfactory for the recipient's purpose. A SIP intermediary can also reject an alert it receives from a User Agent (UA) when it detects that the provided alert is malformed. (I assume there's an implicit "reject with this code" in here.) It is only appropriate to generate a 425 response when the responding entity has no other information in the request that is usable by the responder. I'm not sure I'm parsing this sentence correctly. My best guess is that it's saying "if there's anything in the request that you can respond to, don't use 425, even if there's some malformed CAP", but that doesn't really seem to be what the actual words are saying. [Section 5.2 seems to support my guess.] Section 5.2 message-header /= AlertMsg-Error ; (message-header from 3261) nit: mybe "RFC3261" to match the later comments? wrong with the alert in the request. This error code has a pedantic nit: the ABNF has 1-to-3-digit standardized -- meaning an operator can change the strings -- but MUST NOT change the meaning of the error code. Similar to how RFC 3261 specifies, there MUST NOT be more than one string per error code. RFC 3261 is ... pretty long. Maybe throw us a bone with a section reference? Also, I assume this "MUST NOT be more than one" is within a single AlertMsg-Error construction, since a truly global interpretation would mean that (since this document assigns strings) there cannot actually be changes made to the strings by an operator, which we just said is possible. This document defines an initial list of AlertMsg-Error values for any SIP response, including provisional responses (other than 100 Trying) and the new 425 response. There MUST be no more than one AlertMsg-Error code in a SIP response. AlertMsg-Error values sent in Is this redundant with the "MUST NOT" I was asking about above? Additionally, if an entity cannot or chooses not to process the alert message from a SIP request, a 500 (Server Internal Error) SHOULD be used with or without a configurable Retry-After header field. I don't think I understand when it's recommended to use 500 vs 425 (and vice versa). Section 7 It's probably worth mentioning RFC 3428's note about: % The size of MESSAGE requests outside of a media session MUST NOT % exceed 1300 bytes, unless the UAC has positive knowledge that the % message will not traverse a congestion-unsafe link at any hop, or % that the message size is at least 200 bytes less than the lowest MTU % value found en route to the UAS since that seems to still apply here. Section 8 I'd consider using a more recent date than 2008-11-19 for the example time. Also, why is the timestamp in the additional information 2010-11-14, almost two years later? 32.86726 -97.16054 Is that ... someone's house? Maybe some different coordinates would be more appropriate. Figure 3 has "Content-Disposition: by-reference;handling=optional" but Figure 4 does not; is that significant? Section 9 In any case, for alerts initiated by sensors, the identity could play an important role in deciding whether to accept or ignore an incoming alert message. With the scenario shown in Figure 1 it is very likely that only authenticated sensor input will be processed. For this reason, it needs to be possible to refuse to accept alert messages from an unknown origin. Two types of information elements can be used for this purpose: 1. SIP itself provides security mechanisms that allow the verification of the originator's identity, such as P-Asserted- Identity [RFC3325] or SIP Identity [RFC8224]. The latter provides a cryptographic assurance while the former relies on a chain of trust model. These mechanisms can be reused. 2. CAP provides additional security mechanisms and the ability to carry further information about the sender's identity. Section 3.3.4.1 of [cap] specifies the signing algorithms of CAP documents. I'd consider adding a note that "the specific policy and mechanisms used in a given deployment are out of scope for this document", since the actual requirements in practice are so broad that we cannot really make detailed recommendations here. In addition to the desire to perform identity-based access control, the classic communication security threats need to be considered, including integrity protection to prevent forgery or replay of alert messages in transit. To deal with replay of alerts, a CAP document contains the mandatory , , elements and an optional element. Together, these elements make the CAP document unique for a specific sender and provide time restrictions. An entity that has already received a CAP message within the indicated timeframe is able to detect a replayed message and, if the content of that message is unchanged, then no additional security Is *able* to detect, sure. But is it recommended to do so? Required? vulnerability is created. Additionally, it is RECOMMENDED to make use of SIP security mechanisms, such as the SIP Identity PASSporT [RFC8225], to tie the CAP message to the SIP message. To provide Not required? Please describe the risks of not doing so (whether directly or by reference). protection of the entire SIP message exchange between neighboring SIP entities, the usage of TLS is REQUIRED. Just to check: this is a 100% always, for everyone, "REQUIRED", not just in the subset of cases where protection of the entire exchange is desired? Note that none of the security mechanism in this document protect against a compromised sensor sending crafted alerts. Privacy provided for any emergency calls, including non-interactive messages, is subject to local regulations. I suggest using "confidentiality protection" rather than "privacy" (unless it's a term of art in this field), to avoid confusion with... Privacy considerations for alerts (e.g., generated by sensors) that should be discussed. RFC 7852 has some extensive privacy considerations that can be referenced to do the bulk of the work here. I'd also consider reiterating the opportunistic nature of cryptographic protection on emergency messages, as discussed in 6443 (since insecure emergency messaging is preferred to no emergency messaging), but this is not strictly speaking required. Section 12.2 RFC 8225, as a RECOMMENDED feature, is more properly listed as a normative reference, per https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ From nobody Tue Mar 10 11:00:11 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECFF3A07C3 for ; Tue, 10 Mar 2020 11:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 LAlap2BJhjXw for ; Tue, 10 Mar 2020 11:00:02 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462B53A0795 for ; Tue, 10 Mar 2020 11:00:02 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id p62so13648983qkb.0 for ; Tue, 10 Mar 2020 11:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TRNh/pVHL0IGd4fRi5eL3Tpu9ME58RXtGk0NdP0qqg0=; b=YHBy9++LLQi2HU4eFPmMWshaBjD5FTlfP6L8JtqnOR7a4m3gmWWtdiO+zbHC1QVjFv pbiU2qG70J239G3GFciiKFi8qFoYbrCtTkLzT2iRbSlg9HRb0n1JsadqSwbxf7ZQ+FBb qTnWMkOc4onQtbttt3YxCvCDKBf4+gBlIt2GQ99KkH3s56+A0kga/nfsuxyyxSjvx5qb JbANw5M9vwKtXGErj5Qq1hXlh2v+oaXpSS9gOnKsSBQ37RMWJicu/cAtvnaBQeMVLiYI 3+VlPeBDiR9tjNNvtn1oQOEKsZryf9r7CUd7RQLfgoPbDbSWeqRIpsYWLK4LzZ3Q2mZm CFSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TRNh/pVHL0IGd4fRi5eL3Tpu9ME58RXtGk0NdP0qqg0=; b=fbQj8o6+/Lucn1LhH93i16MiWbdTCmMGsoHVCXZmk9T1YobtRpAtzQTV2mMsuN+D1b fu4ykbsUnw0YMAQJJ6v4g/QFFc8SDj2M8QitM1NJ3q8KGqB8YOiLagMASn6TCk17JrYB xuojJ0fTEod9jWG8teP+TM0e1P1H/34Zw9YFgiSQ3MzJLx7zwX4+jnIB4503lvfeQf4g hsM2xA3BfTNoVIv8La4PZp7sBFwQ5uL8Wmh63hQd2bWXZqaLeDUVleSVlpq87HTc6sFr uwFdz9dh0IzgiXtupZQYnZ58sMK34x1GKt6kPv6bwkEyx2noQ2LwGIR23xDvrE7toIZe ahQg== X-Gm-Message-State: ANhLgQ15z7E+MOEI3K2bWzEZhj1H6MTWT2mCFV8w5+VxDY4RwZSSbL1s dISMBEwVBlTP53pFlI7eJBSvfP6bzgiB6r6RfI9CDA== X-Google-Smtp-Source: ADFU+vvC+CCqHlRuwPJdhbJW/VK5tUU2lsCnvLC1l6huwRKx64tQUFkkFDdsot8Q1nhPk/lwfsipoYIXN8AnxqHp+uQ= X-Received: by 2002:a37:4644:: with SMTP id t65mr19409021qka.58.1583863200939; Tue, 10 Mar 2020 11:00:00 -0700 (PDT) MIME-Version: 1.0 References: <158386278691.16369.10286901911015179104@ietfa.amsl.com> In-Reply-To: <158386278691.16369.10286901911015179104@ietfa.amsl.com> From: Brian Rosen Date: Tue, 10 Mar 2020 13:59:50 -0400 Message-ID: To: Benjamin Kaduk Cc: Allison Mankin , The IESG , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit@ietf.org, ecrit-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000771cb305a083e344" Archived-At: Subject: Re: [Ecrit] Benjamin Kaduk's No Objection on draft-ietf-ecrit-data-only-ea-22: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 18:00:09 -0000 --000000000000771cb305a083e344 Content-Type: text/plain; charset="UTF-8" All of your comments were addressed in -22 On Tue, Mar 10, 2020 at 1:53 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-ecrit-data-only-ea-22: 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-ecrit-data-only-ea/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for addressing my Discuss points! > > Original (presumed stale) comments preserved below. > > Introduction (and Abstract?) > > medical monitors. These messages may be one-shot alerts to emergency > authorities and do not require establishment of a session. These > type of interactions are called 'non-interactive emergency calls'. > > Is this an existing/widespread definition or one new to this document? > It may be worth providing a reference or rewording to clarify that it is > a new definition. > > Section 2 > > CID is Content InDirection [RFC2392] > > The string "InDirection" does not appear in RFC 2392. > > Section 4.1 > > A CAP message may be sent in the initial message of any SIP > transaction. However, this document only addresses sending a CAP > message in a SIP MESSAGE transaction for a one-shot, non-interactive > emergency call. Behavior with other transactions is not defined. > > I suggest rephrasing to "A CAP message is sent in the initial message of > a SIP transaction" to avoid potential concerns about inconsistency > between "may be sent" and "not defined". > > the CAP message. Alternatively, the Call-Info header field may > contain a Content Indirect url [RFC2392] and the CAP message included > > nit: "Indirect" here vs. "InDirection" in Section 2 > > Section 4.2 > > field. If there is a need to copy the PIDF-LO structure > referenced by 'geolocation' to , implementers must be aware > > When might this occur? (It seems almost out of scope for this document > based on my limited understanding.) > > that is limited to a circle or polygon, and conversion of > other shapes will be required. Points SHOULD be converted to a > circle with a radius equal to the uncertainty of the point. Arc- > bands and ellipses SHOULD be converted to an equivalent polygon. > 3D locations SHOULD be converted to their equivalent 2D forms. > > nit: what is an "equivalent" polygon to an ellipse or arc-band? In a > mathematical sense it might mean "strict equivalence" or a large-n limit > of an n-gon, or perhaps there is a corresponding uncertainty on the > ellipse/arc-band that the polygon must stay within? Rewording to > "corresponding" might be an easy fix. > > Section 5.1 > > The 425 response code is a rejection of the request due to its > included alert content, indicating that it was malformed or not > satisfactory for the recipient's purpose. > > A SIP intermediary can also reject an alert it receives from a User > Agent (UA) when it detects that the provided alert is malformed. > > (I assume there's an implicit "reject with this code" in here.) > > It is only appropriate to generate a 425 response when the responding > entity has no other information in the request that is usable by the > responder. > > I'm not sure I'm parsing this sentence correctly. My best guess is that > it's saying "if there's anything in the request that you can respond to, > don't use 425, even if there's some malformed CAP", but that doesn't > really seem to be what the actual words are saying. [Section 5.2 seems > to support my guess.] > > Section 5.2 > > message-header /= AlertMsg-Error > ; (message-header from 3261) > > nit: mybe "RFC3261" to match the later comments? > > wrong with the alert in the request. This error code has a > > pedantic nit: the ABNF has 1-to-3-digit > > standardized -- meaning an operator can change the strings -- but > MUST NOT change the meaning of the error code. Similar to how RFC > 3261 specifies, there MUST NOT be more than one string per error > code. > > RFC 3261 is ... pretty long. Maybe throw us a bone with a section > reference? Also, I assume this "MUST NOT be more than one" is within a > single AlertMsg-Error construction, since a truly global interpretation > would mean that (since this document assigns strings) there cannot > actually be changes made to the strings by an operator, which we just > said is possible. > > This document defines an initial list of AlertMsg-Error values for > any SIP response, including provisional responses (other than 100 > Trying) and the new 425 response. There MUST be no more than one > AlertMsg-Error code in a SIP response. AlertMsg-Error values sent in > > Is this redundant with the "MUST NOT" I was asking about above? > > Additionally, if an entity cannot or chooses not to process the alert > message from a SIP request, a 500 (Server Internal Error) SHOULD be > used with or without a configurable Retry-After header field. > > I don't think I understand when it's recommended to use 500 vs 425 (and > vice versa). > > Section 7 > > It's probably worth mentioning RFC 3428's note about: > > % The size of MESSAGE requests outside of a media session MUST NOT > % exceed 1300 bytes, unless the UAC has positive knowledge that the > % message will not traverse a congestion-unsafe link at any hop, or > % that the message size is at least 200 bytes less than the lowest MTU > % value found en route to the UAS > > since that seems to still apply here. > > Section 8 > > I'd consider using a more recent date than 2008-11-19 for the example > time. Also, why is the timestamp in the additional information > 2010-11-14, almost two years later? > > 32.86726 -97.16054 > > Is that ... someone's house? Maybe some different coordinates would be > more appropriate. > > Figure 3 has "Content-Disposition: by-reference;handling=optional" but > Figure 4 does not; is that significant? > > Section 9 > > In any case, for alerts initiated by sensors, the identity could play > an important role in deciding whether to accept or ignore an incoming > alert message. With the scenario shown in Figure 1 it is very likely > that only authenticated sensor input will be processed. For this > reason, it needs to be possible to refuse to accept alert messages > from an unknown origin. Two types of information elements can be > used for this purpose: > > 1. SIP itself provides security mechanisms that allow the > verification of the originator's identity, such as P-Asserted- > Identity [RFC3325] or SIP Identity [RFC8224]. The latter > provides a cryptographic assurance while the former relies on a > chain of trust model. These mechanisms can be reused. > > 2. CAP provides additional security mechanisms and the ability to > carry further information about the sender's identity. > Section 3.3.4.1 of [cap] specifies the signing algorithms of CAP > documents. > > I'd consider adding a note that "the specific policy and mechanisms used > in a given deployment are out of scope for this document", since the > actual requirements in practice are so broad that we cannot really make > detailed recommendations here. > > In addition to the desire to perform identity-based access control, > the classic communication security threats need to be considered, > including integrity protection to prevent forgery or replay of alert > messages in transit. To deal with replay of alerts, a CAP document > contains the mandatory , , elements and an > optional element. Together, these elements make the CAP > document unique for a specific sender and provide time restrictions. > An entity that has already received a CAP message within the > indicated timeframe is able to detect a replayed message and, if the > content of that message is unchanged, then no additional security > > Is *able* to detect, sure. But is it recommended to do so? Required? > > vulnerability is created. Additionally, it is RECOMMENDED to make > use of SIP security mechanisms, such as the SIP Identity PASSporT > [RFC8225], to tie the CAP message to the SIP message. To provide > > Not required? Please describe the risks of not doing so (whether > directly or by reference). > > protection of the entire SIP message exchange between neighboring SIP > entities, the usage of TLS is REQUIRED. > > Just to check: this is a 100% always, for everyone, "REQUIRED", not just > in the subset of cases where protection of the entire exchange is > desired? > > Note that none of the security mechanism in this document protect > against a compromised sensor sending crafted alerts. Privacy > provided for any emergency calls, including non-interactive messages, > is subject to local regulations. > > I suggest using "confidentiality protection" rather than "privacy" > (unless it's a term of art in this field), to avoid confusion with... > Privacy considerations for alerts (e.g., generated by sensors) that > should be discussed. RFC 7852 has some extensive privacy considerations > that can be referenced to do the bulk of the work here. > > I'd also consider reiterating the opportunistic nature of cryptographic > protection on emergency messages, as discussed in 6443 (since insecure > emergency messaging is preferred to no emergency messaging), but this is > not strictly speaking required. > > Section 12.2 > > RFC 8225, as a RECOMMENDED feature, is more properly listed as a > normative reference, per > > https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ > > > > --000000000000771cb305a083e344 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All of your comments were addressed in -22

On Tue, Mar 10, 2020 at 1:53 PM Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
Benjamin Kaduk has entered the following ballot p= osition for
draft-ietf-ecrit-data-only-ea-22: 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/s= tatement/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/draf= t-ietf-ecrit-data-only-ea/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my Discuss points!

Original (presumed stale) comments preserved below.

Introduction (and Abstract?)

=C2=A0 =C2=A0medical monitors.=C2=A0 These messages may be one-shot alerts = to emergency
=C2=A0 =C2=A0authorities and do not require establishment of a session.=C2= =A0 These
=C2=A0 =C2=A0type of interactions are called 'non-interactive emergency= calls'.

Is this an existing/widespread definition or one new to this document?
It may be worth providing a reference or rewording to clarify that it is a new definition.

Section 2

=C2=A0 =C2=A0CID is Content InDirection [RFC2392]

The string "InDirection" does not appear in RFC 2392.

Section 4.1

=C2=A0 =C2=A0A CAP message may be sent in the initial message of any SIP =C2=A0 =C2=A0transaction.=C2=A0 However, this document only addresses sendi= ng a CAP
=C2=A0 =C2=A0message in a SIP MESSAGE transaction for a one-shot, non-inter= active
=C2=A0 =C2=A0emergency call.=C2=A0 Behavior with other transactions is not = defined.

I suggest rephrasing to "A CAP message is sent in the initial message = of
a SIP transaction" to avoid potential concerns about inconsistency
between "may be sent" and "not defined".

=C2=A0 =C2=A0the CAP message.=C2=A0 Alternatively, the Call-Info header fie= ld may
=C2=A0 =C2=A0contain a Content Indirect url [RFC2392] and the CAP message i= ncluded

nit: "Indirect" here vs. "InDirection" in Section 2

Section 4.2

=C2=A0 =C2=A0 =C2=A0 field.=C2=A0 If there is a need to copy the PIDF-LO st= ructure
=C2=A0 =C2=A0 =C2=A0 referenced by 'geolocation' to <area>, i= mplementers must be aware

When might this occur?=C2=A0 (It seems almost out of scope for this documen= t
based on my limited understanding.)

=C2=A0 =C2=A0 =C2=A0 that <area> is limited to a circle or polygon, a= nd conversion of
=C2=A0 =C2=A0 =C2=A0 other shapes will be required.=C2=A0 Points SHOULD be = converted to a
=C2=A0 =C2=A0 =C2=A0 circle with a radius equal to the uncertainty of the p= oint.=C2=A0 Arc-
=C2=A0 =C2=A0 =C2=A0 bands and ellipses SHOULD be converted to an equivalen= t polygon.
=C2=A0 =C2=A0 =C2=A0 3D locations SHOULD be converted to their equivalent 2= D forms.

nit: what is an "equivalent" polygon to an ellipse or arc-band?= =C2=A0 In a
mathematical sense it might mean "strict equivalence" or a large-= n limit
of an n-gon, or perhaps there is a corresponding uncertainty on the
ellipse/arc-band that the polygon must stay within?=C2=A0 Rewording to
"corresponding" might be an easy fix.

Section 5.1

=C2=A0 =C2=A0The 425 response code is a rejection of the request due to its=
=C2=A0 =C2=A0included alert content, indicating that it was malformed or no= t
=C2=A0 =C2=A0satisfactory for the recipient's purpose.

=C2=A0 =C2=A0A SIP intermediary can also reject an alert it receives from a= User
=C2=A0 =C2=A0Agent (UA) when it detects that the provided alert is malforme= d.

(I assume there's an implicit "reject with this code" in here= .)

=C2=A0 =C2=A0It is only appropriate to generate a 425 response when the res= ponding
=C2=A0 =C2=A0entity has no other information in the request that is usable = by the
=C2=A0 =C2=A0responder.

I'm not sure I'm parsing this sentence correctly.=C2=A0 My best gue= ss is that
it's saying "if there's anything in the request that you can r= espond to,
don't use 425, even if there's some malformed CAP", but that d= oesn't
really seem to be what the actual words are saying.=C2=A0 [Section 5.2 seem= s
to support my guess.]

Section 5.2

=C2=A0 =C2=A0 =C2=A0 message-header=C2=A0 =C2=A0/=3D AlertMsg-Error
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; (message-header from 3261)

nit: mybe "RFC3261" to match the later comments?

=C2=A0 =C2=A0wrong with the alert in the request.=C2=A0 This error code has= a

pedantic nit: the ABNF has 1-to-3-digit

=C2=A0 =C2=A0standardized -- meaning an operator can change the strings -- = but
=C2=A0 =C2=A0MUST NOT change the meaning of the error code.=C2=A0 Similar t= o how RFC
=C2=A0 =C2=A03261 specifies, there MUST NOT be more than one string per err= or
=C2=A0 =C2=A0code.

RFC 3261 is ... pretty long.=C2=A0 Maybe throw us a bone with a section
reference?=C2=A0 Also, I assume this "MUST NOT be more than one" = is within a
single AlertMsg-Error construction, since a truly global interpretation
would mean that (since this document assigns strings) there cannot
actually be changes made to the strings by an operator, which we just
said is possible.

=C2=A0 =C2=A0This document defines an initial list of AlertMsg-Error values= for
=C2=A0 =C2=A0any SIP response, including provisional responses (other than = 100
=C2=A0 =C2=A0Trying) and the new 425 response.=C2=A0 There MUST be no more = than one
=C2=A0 =C2=A0AlertMsg-Error code in a SIP response.=C2=A0 AlertMsg-Error va= lues sent in

Is this redundant with the "MUST NOT" I was asking about above?
=C2=A0 =C2=A0Additionally, if an entity cannot or chooses not to process th= e alert
=C2=A0 =C2=A0message from a SIP request, a 500 (Server Internal Error) SHOU= LD be
=C2=A0 =C2=A0used with or without a configurable Retry-After header field.<= br>
I don't think I understand when it's recommended to use 500 vs 425 = (and
vice versa).

Section 7

It's probably worth mentioning RFC 3428's note about:

%=C2=A0 The size of MESSAGE requests outside of a media session MUST NOT %=C2=A0 exceed 1300 bytes, unless the UAC has positive knowledge that the %=C2=A0 message will not traverse a congestion-unsafe link at any hop, or %=C2=A0 that the message size is at least 200 bytes less than the lowest MT= U
%=C2=A0 value found en route to the UAS

since that seems to still apply here.

Section 8

I'd consider using a more recent date than 2008-11-19 for the example <sent> time.=C2=A0 Also, why is the timestamp in the additional infor= mation
2010-11-14, almost two years later?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<gml:pos>32.86726 -97.16054</gml:pos>

Is that ... someone's house?=C2=A0 Maybe some different coordinates wou= ld be
more appropriate.

Figure 3 has "Content-Disposition: by-reference;handling=3Doptional&qu= ot; but
Figure 4 does not; is that significant?

Section 9

=C2=A0 =C2=A0In any case, for alerts initiated by sensors, the identity cou= ld play
=C2=A0 =C2=A0an important role in deciding whether to accept or ignore an i= ncoming
=C2=A0 =C2=A0alert message.=C2=A0 With the scenario shown in Figure 1 it is= very likely
=C2=A0 =C2=A0that only authenticated sensor input will be processed.=C2=A0 = For this
=C2=A0 =C2=A0reason, it needs to be possible to refuse to accept alert mess= ages
=C2=A0 =C2=A0from an unknown origin.=C2=A0 Two types of information element= s can be
=C2=A0 =C2=A0used for this purpose:

=C2=A0 =C2=A01.=C2=A0 SIP itself provides security mechanisms that allow th= e
=C2=A0 =C2=A0 =C2=A0 =C2=A0verification of the originator's identity, s= uch as P-Asserted-
=C2=A0 =C2=A0 =C2=A0 =C2=A0Identity [RFC3325] or SIP Identity [RFC8224].=C2= =A0 The latter
=C2=A0 =C2=A0 =C2=A0 =C2=A0provides a cryptographic assurance while the for= mer relies on a
=C2=A0 =C2=A0 =C2=A0 =C2=A0chain of trust model.=C2=A0 These mechanisms can= be reused.

=C2=A0 =C2=A02.=C2=A0 CAP provides additional security mechanisms and the a= bility to
=C2=A0 =C2=A0 =C2=A0 =C2=A0carry further information about the sender's= identity.
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 3.3.4.1 of [cap] specifies the signing a= lgorithms of CAP
=C2=A0 =C2=A0 =C2=A0 =C2=A0documents.

I'd consider adding a note that "the specific policy and mechanism= s used
in a given deployment are out of scope for this document", since the actual requirements in practice are so broad that we cannot really make
detailed recommendations here.

=C2=A0 =C2=A0In addition to the desire to perform identity-based access con= trol,
=C2=A0 =C2=A0the classic communication security threats need to be consider= ed,
=C2=A0 =C2=A0including integrity protection to prevent forgery or replay of= alert
=C2=A0 =C2=A0messages in transit.=C2=A0 To deal with replay of alerts, a CA= P document
=C2=A0 =C2=A0contains the mandatory <identifier>, <sender>, <= ;sent> elements and an
=C2=A0 =C2=A0optional <expire> element.=C2=A0 Together, these element= s make the CAP
=C2=A0 =C2=A0document unique for a specific sender and provide time restric= tions.
=C2=A0 =C2=A0An entity that has already received a CAP message within the =C2=A0 =C2=A0indicated timeframe is able to detect a replayed message and, = if the
=C2=A0 =C2=A0content of that message is unchanged, then no additional secur= ity

Is *able* to detect, sure.=C2=A0 But is it recommended to do so?=C2=A0 Requ= ired?

=C2=A0 =C2=A0vulnerability is created.=C2=A0 Additionally, it is RECOMMENDE= D to make
=C2=A0 =C2=A0use of SIP security mechanisms, such as the SIP Identity PASSp= orT
=C2=A0 =C2=A0[RFC8225], to tie the CAP message to the SIP message.=C2=A0 To= provide

Not required?=C2=A0 Please describe the risks of not doing so (whether
directly or by reference).

=C2=A0 =C2=A0protection of the entire SIP message exchange between neighbor= ing SIP
=C2=A0 =C2=A0entities, the usage of TLS is REQUIRED.

Just to check: this is a 100% always, for everyone, "REQUIRED", n= ot just
in the subset of cases where protection of the entire exchange is
desired?

=C2=A0 =C2=A0Note that none of the security mechanism in this document prot= ect
=C2=A0 =C2=A0against a compromised sensor sending crafted alerts.=C2=A0 Pri= vacy
=C2=A0 =C2=A0provided for any emergency calls, including non-interactive me= ssages,
=C2=A0 =C2=A0is subject to local regulations.

I suggest using "confidentiality protection" rather than "pr= ivacy"
(unless it's a term of art in this field), to avoid confusion with... Privacy considerations for alerts (e.g., generated by sensors) that
should be discussed.=C2=A0 RFC 7852 has some extensive privacy consideratio= ns
that can be referenced to do the bulk of the work here.

I'd also consider reiterating the opportunistic nature of cryptographic=
protection on emergency messages, as discussed in 6443 (since insecure
emergency messaging is preferred to no emergency messaging), but this is not strictly speaking required.

Section 12.2

RFC 8225, as a RECOMMENDED feature, is more properly listed as a
normative reference, per
https://www.ietf.= org/about/groups/iesg/statements/normative-informative-references/



--000000000000771cb305a083e344-- From nobody Tue Mar 10 12:49:32 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B37C93A099F; Tue, 10 Mar 2020 12:49:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rfc-editor@rfc-editor.org, allison.mankin@gmail.com, draft-ietf-ecrit-data-only-ea@ietf.org, ecrit@ietf.org, ecrit-chairs@ietf.org, The IESG , Allison Mankin , adam@nostrum.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158386976660.15427.4651235176795386716@ietfa.amsl.com> Date: Tue, 10 Mar 2020 12:49:26 -0700 Archived-At: Subject: [Ecrit] Protocol Action: 'Non-Interactive Emergency Calls' to Proposed Standard (draft-ietf-ecrit-data-only-ea-22.txt) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 19:49:27 -0000 The IESG has approved the following document: - 'Non-Interactive Emergency Calls' (draft-ietf-ecrit-data-only-ea-22.txt) as Proposed Standard This document is the product of the Emergency Context Resolution with Internet Technologies Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Working Group Summary This document did not have controversy in the WG. Its revisions were in response to a number of very detailed reviews in 2013-2015, and then in order to track with RFC 7252 'Additional Data Related to an Emergency Call.' Document Quality There were many detailed reviews throughout the lifetime of the draft. Another quality indicator is that the editors worked with the NENA Long Term Direction Working Group, and updated other emergency communications groups throughout the development time in ECRIT. The Media Type expert review request for application/EmergencyCallData.cap+xml was posted on March 23, 2018. The Document Shepherd has reviewed the mailing list discussions, expert reviewing, and normative references. There are no concerns about the degree of review, special review needs, or other concerns. Because of the very active reviewing early on, the Shepherd views this document as having solid WG consensus. The document had its required formal review of the media type (see above) There is a normative reference that will need to be added to the Downref Registry - the document depends on the OASIS Common Alerting Protocol v.1.2 specification (http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html) No existing RFCs are updated or obsoleted by this document. A new block is to be added to the IANA Emergency Call Data Types Registry. The criteria for this (RFC 7852) are Specification Required with explicit Expert Review - the IANA Expert Reviewer is Brian Rosen, who is also the pen-holding editor of this document. A SIP Response Code is requested - the criterion for this (RFC 3261) is RFC Required. A SIP Header Type is requested - the policy for this is Standards Action - the Expert Reviewer is Adam Roach, who is also the Responsible AD. A new SIP Registry, called AlertMsg Error Codes, is to be created, with a Specification Required policy. There is one XML example, and it was validated through the Oxygen XML Editor. Personnel The Document Shepherd is Allison Mankin, and the Responsible Area Director is Adam Roach.